内存分配机制
mc内存分配机制简介
memcached默认情况下采用了名为Slab Allocator的机制分配、管理内存，Slab Allocator的基本原理是按照预先规定的大小，将分配的内存分割成特定长度的块，以完全解决内存碎片问题。
先来解释一下与Slab Allocator存储有关的几个术语：
Page：分配给Slab的内存空间，默认是1MB。分配给Slab之后根据slab的大小切分成chunk。 Chunk：用于缓存记录的内存空间。 Slab Class：特定大小的chunk的组。
Growth Factor：增长因数，默认为1.25(较早的版本固定为2)
mc启动后，会根据这个factor，计算出从1M逐步递减的不同的slab，如factor=1.25时：
slab class 1: chunk size 88 perslab 11915
slab class 2: chunk size 112 perslab 9362
slab class 3: chunk size 144 perslab 7281
slab class 4: chunk size 184 perslab 5698
slab class 5: chunk size 232 perslab 4519
slab class 6: chunk size 296 perslab 3542
slab class 7: chunk size 376 perslab 2788
slab class 8: chunk size 472 perslab 2221
slab class 9: chunk size 592 perslab 1771
slab class 10: chunk size 744 perslab 1409
第一列数据(slab class)，为slab的编号；
第二列数据是chunk的大小，跟slab class是一一对应的关系，可以通俗的理解为slab就是存放一组相同大小chunk的集合，只不过这个集合是固定的(1M)，
第三列数据，表示每种不同slab中的page可以存放的chunk个数,实际上等于1MB/ (chunk size),例如slab1中的chunk size是88B，那么这种slab中每个page中可以存放的chunk个数为 1MB / 88B ，约等于11915
很显然，slab的chunk size越大，其中的每个page包含的chunk数量就越少
如图所示：
新入对象时，会根据自身大小来匹配slab列表，比如100KB的对象，根据最小空间损失原则，会被放入到slab2(size:112B)对应的page下，如下图
这时，如果slab2下的page中有尚可以使用的chunk(即空闲的chunk或者过期的chunk)，slab2会优先使用这些chunk，在没有chunk可用的情况下，mc会去内存中再申请一个page，然后切分成chunk，然后使用；需要注意的是，根据 Slab Allocator算法， 该实例中的100KB对象，是永远没有机会存放到其他slab(如slab3,slab4等等)，即便是其他slab中有大量的可用chunk，细心的朋友会发现，这种机制很有可能会导致内存浪费严重，mc命中率降低等问题，对，这种问题真的存在，这也正是这种机制的缺点，下面会进行详细的分析和探讨
mc数据删除机制简介：
首先我们知道，缓存在mc中的数据，不会主动从内存中消失，也就是说mc不会监视记录是否过期，而是在client端执行get方法时才去检查时间戳是否过期(这样做的目的就是避免在过期监视上耗费cpu资源，以提高mc的响应能力)；每次有新对象加入时，mc会优先将对象置于已超时的同一规格chunk中，然而，即使如此，内存仍然会发生追加新记录时空间不足的情况，那么，当mc内存耗完后，又是怎样处理新入的数据呢？mc有两种处理策略，一种是默认的LRU(Least Recently Used),指删除近段时间最少使用同规格chunk,再将对象塞入)，另一种策略是存满即不可再存，除非有过期的对象，否则会报错