memcached笔记

1. 现在的memcached规格中，键长度最大为250字节，但二进制协议中键的大小用2字节表示。因此，理论上最大可使用65536字节（2的16次方）长的键。尽管250字节以上的键并不会太常用，二进制协议发布之后就可以使用巨大的键了。
二进制协议从版本1.3系列开始支持，

2. memcached默认采用机制分配、整理内存，其基本原理是按照预先规定的大小，将分配的内存分割成特定长度的块（chunk），以完全解决内存碎片问题。

2.5 slab allocation术语介绍
slab（有时又写作page）：分配给slab的内存空间，默认是1M。分配给slab后根据slab的大小切分成chunk。
chunk：用于缓存记录的内存空间。
slab class：特定大小的slab组（所有在slab class中的slab拥有同样大小的chunk）

3. slab allocation可以重复使用已分配的内存，分配到的内存不会释放，而是重复利用。

4. slab allocation的缺点是由于分配的是特定长度的内存，因此无法有效利用分配的内存，将100字节的数据缓存到128字节的chunk中，就有28字节浪费了。
比较好的调优方案是计算预先客户端的数据大小，采用合适的chunk大小分组，调整chunk大小方法见第5点

5. chunk大小分组的方法：memcached -f 2，其中-f是growth factor因子，默认为1.25，曾经为2，即每个chunk划分的大小是前一个chunk大小的f倍。
按照计算的数据预期长度来调节growth factor值

6. 连接上memcached（可以用telnet连接），输入stats可以查看memcached状态，stats slabs或者stats items可以获得关于缓存的信息，quit退出。

7. 关于memcached分布式
7.1 根据余数进行打散：mc key的hash值(crc32等)/服务器台数，无法连接时将连接次数添加到key后面，rehash后再连接
余数打散法优点：方法简单，数据分散性也很优秀。
缺点：当添加/移除服务器时，缓存重组的代价相当巨大，缓存命中率明显下降。

7.2 mixi采用的Consistent Hashing分布法：首先求出memcached服务器（节点）的hash值，并将其配置到0~2的32次方的圆上，然后用同样的方法求出mc key的hash值，并映射到圆上。然后从数据映射的位置开始顺时针查找，将数据保存到找到的第一个服务器上。如果超过2的32次方仍然找不到服务器，就 会保存到第一台memcached服务器上。
优点：当添加服务器时，只有这台服务器添加位置的逆时针方向的第一台服务器上的key会受到影响，最大程序抑制了key的重新分布。

*而且，有的Consistent Hashing实现方法还采用了虚拟节点的思想。使用一般hash函数的话，服务器的映射地点非常不均匀。因此，使用虚拟节点的思想，为每个服务器在圆上 虚拟分配100~200个点。这样就能抑制分布不均匀，最大限度减少服务器增减时的缓存重新分布。

8. last.fm开发了一个支持Consistent Hashing的PHP库，名为ketama

9. memcached进程的实际内存分配量要比指定的容量要大，因为启动指定的只是用于数据保存的内存大小，并不包括slab allocation本身占用的内存以及为保存数据而设置的管理空间等。

10. memcached内存分配量尽量不要超过3G（即使是64位的4G内存的服务器），因有可能造成内存交换(swap)

11. 将与memcache的连接保持在进程中，以减少TCP连接的开销。

12. 如果不支持连接失败的rehash功能，则最好限制连接失败后指定时间内不要再连接该失败的服务器。

13. 将所有共享/公用的缓存数据设置类命名空间，将该命名空间下的key保存到多台memcached服务器中，取得时从中仅选取一台即可。

14. daemontools可以监视memcached进程的停止并自动启动。

15. nagios监视memcached的get、add动作，也可以监视stats

16. rrdtool将stats目录转化成图形，进行性能监视