高并发架构基石【二】——Memcache

特点

多线程

异步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天）