memcached存储大数据的问题

memcached存储单个item最大数据是在1MB内（redis是512M），假设数据超过1M,存取set和get是都是返回false，并且引起性能的问题。

我们之前对排行榜的数据进行缓存，因为排行榜在我们全部sql select查询里面占了30%，并且我们排行榜每小时更新一次，所以必须对数据做缓存。为了清除缓存方便，把全部的用户的数据放在同一key中，因为memcached:set的时候没有压缩数据。在測试服測试的时候，没发现问题，当上线的时候，结果发现，在线人数刚刚490人的时候，serverload average飘到7.9。然后我们去掉缓存，一下子就下降到0.59。
所以Memcahce不适合缓存大数据，超过1MB的数据 ，需要考虑在client压缩或拆分到多个key中，或者使用redis。
因为大的数据在进行load和uppack到内存的时候要花很长时间，从而减少server的性能。
memcached支持最大的存储对象为 1M ，这个值由其内存分配机制决定的。
memcached默认情况下採用了名为Slab Allocator 的机制分配、管理内存。在该机制出现曾经，内存的分配是通过对全部记录简单地进行 malloc 和 free 来进行的。可是，这样的方式会导致内存碎片，加重操作系统内存管理器的负担，最坏的情况下，会导致操作系统比 memcached 进程本身还慢。 Slab Allocator 就是为解决该问题而诞生的。 Slab Allocator 的基本原理是依照预先规定的大小，将分配的内存切割成特定长度的块，以全然解决内存碎片问题.

测试缓存大数据

<?php$m = new Memcached();$m->addServer('127.0.0.1', 11211);$data = str_repeat('a', 1024* 1024); //1M的数据$data = str_repeat('a', 1024* 1024*50);//50M的数据//$m->setOption(Memcached::OPT_COMPRESSION,0);<span style="white-space:pre"></span>//不压缩存储数据echo $r  =  $m->set('key', $data, 9999);?>

不论是1M的数据还是100M的数据，都能set成功。memcached set数据是默认压缩的
因为这个这个是反复的字符串，压缩率高达1000倍。因此50M的数据压缩后实际也就50k而已。
当设置
$m->setOption(Memcached::OPT_COMPRESSION,0); //不压缩存储数据
$data = str_repeat('a', 1024* 1024); //1M数据
echo $r  =  $m->set('key', $data, 9999); //1M的数据set不成功。
也就是说memcached server不能存储超过1M的数据，可是经过client压缩数据后，只要小于1M的数据都能存储成功

适用memcached的业务场景：
1）假设站点包括了访问量非常大的动态网页，因而数据库的负载将会非常高。因为大部分数据库请求都是读操作，那么memcached能够显著地减小数据库负载。
2）假设数据库server的负载比较低但CPU使用率非常高，这时能够缓存计算好的结果（ computed objects ）和渲染后的网页模板（enderred templates）。
3）利用memcached能够缓存 session数据 、暂时数据以降低对他们的数据库写操作。
4）缓存一些非常小可是被频频访问的文件

不适用memcached的业务场景：
1）缓存对象的大小大于1MB或者key的长度大于250字符
Memcached本身就不是为了处理庞大的多媒体（large media）和巨大的二进制块（streaming huge blobs）而设计的。
2）虚拟主机不让执行memcached服务
假设应用本身托管在低端的虚拟私有server上，像vmware, xen这类虚拟化技术并不适合执行memcached。Memcached须要接管和控制大块的内存，假设memcached管理      的内存被OS或 hypervisor交换出去，memcached的性能将大打折扣。
3）应用执行在不安全的环境中
Memcached为提供不论什么安全策略，只通过telnet就能够訪问到memcached。假设应用执行在共享的系统上，须要着重考虑安全问题。
4）缓存数据需要持久化，这时用redis更合适