特点
多线程
异步IO
KV存储
内存存储，没有持久化
不提供主从同步
内存结构
MC默认通过 Slab Allocator 管理内存，主要用来解决频繁 malloc/free 会产生内存碎片的问题，Slab Allocator创建Slab时的参数有三个：Chunk大小的增长因子、Chunk大小的初始值、Page的大小。在运行时会根据要保存的对象的大小来逐渐创建Slab。
- Slab：MC把内存分为许多不同类型的 Slab，每种类型的Slab用来保存不同大小的对象。
- Page：每个Slab由若干Page组成，不同Slab的Page，默认大小都一样是1M（这也是默认MC存储对象不能超过1M的原因）。
- Chunk：每个Page内划分为许多Chunk，就是实际存储对象的空间，不同类型Slab中的Chunk大小不同，当保存一对象时，MC会根据对象大小选择最合适的Chunk来存储，减少空间浪费。
钙化问题
何为钙化问题？
考虑这样一个场景，使用 MC 来保存用户信息，假设单个对象大约 300 字节。这时会产生大量的 384 字节大小的 Slab。运行一段时间后，用户信息增加了一个属性，单个对象的大小变成了 500 字节，这时再保存对象需要使用 768 字节的 Slab，而 MC 中的容量大部分创建了 384 字节的 Slab，所以 768 的 Slab 非常少。这时虽然 384 Slab 的内存大量空闲，但 768 Slab 还是会根据 LRU 算法频繁剔除缓存，导致 MC 的剔除率升高，命中率降低。这就是所谓的 MC 钙化问题。
如何解决钙化问题？
解决钙化问题可以开启 MC 的 Automove 机制，每 10s 调整 Slab。也可以分批重启 MC 缓存，不过要注意重启时要进行一定时间的预热，防止雪崩问题。
在使用 Memcached 时，最好计算一下数据的预期平均长度，调整 growth factor， 以获得最恰当的设置，避免内存的大量浪费。
失效与剔除机制
采用延迟失效（即当再次使用数据时检查是否失效）。
当容量存满时，除了剔除过期的Key，还会按LRU策略剔除数据。
限制
- key不超过250字节
- value不超过1M字节
- 最大失效时间是30天（即过期时间<30天）