Memcached工作原理、工作流程、优化建议

129次阅读

共计 2323 个字符，预计需要花费 6 分钟才能阅读完成。

一、memcached 工作原理
基本概念：slab，page，chunk。
slab，是一个逻辑概念。它是在启动 memcached 实例的时候预处理好的，每个 slab 对应一个 chunk size，也就是说不同 slab 有不同的 chunk size。具体分配多少个 slab 由参数 -f（增长因子）和 -n（chunk 最小尺寸）决定的。
page，可以理解为内存页。大小固定为 1m。slab 会在存储请求时向系统申请 page，并将 page 按 chunk size 进行切割。
chunk，是保存用户数据的最小单位。用户数据 item（包括 key，value）最终会保存到 chunk 内。chunk 规格是固定的，如果用户数据放进来后还有剩余则这剩余部分不能做其他用途。

二、memcached 工作流程
memcahed 实例启动，根据 -f 和 -n 进行预分配 slab。以 -n 为最小值开始，以 -f 为比值生成等比数列，直到 1m 为止（每个 slab 的 chunk size 都要按 8 的倍数进行补全，比如：如果按比值算是 556 的话，会再加 4 到 560 成为 8 的整倍数）。然后每个 slab 分配一个 page。当用户发来存储请求时（key,value），memcached 会计算 key+value 的大小，看看属于哪个 slab。确定 slab 后看里面的是否有空闲 chunk 放 key+value，如果不够就再向系统申请一个 page（如果此时已经达到 -m 参数设置的内存使用上限，则看是否设置了 -M。如果设置了 -M 则返回错误提示，否则按 LRU 算法删除数据）。申请后将该 page 按本 slab 的 chunk size 进行切割，然后分配一个来存放用户数据。
注意：
1）chunk 是在 page 里面划分的，而 page 固定为 1m，所以 chunk 最大不能超过 1m。
2）chunk 实际占用内存要加 48B，因为 chunk 数据结构本身需要占用 48B。
3）如果用户数据大于 1m，则 memcached 会将其切割，放到多个 chunk 内。
4）已分配出去的 page 不能回收。

三、优化建议
1）-n 参数的设置，注意将此参数设置为 1024 可以整除的数（还要考虑 48B 的差值），否则余下来的部分就浪费了。
2）不要存储超过 1m 的数据。因为要拆成多个 chunk，计算和时间成本都成倍增加。
3）善用 stats 命令查看 memcached 状态。
4）消灭 eviction（被删除的数据）。
造成 eviction 是因为内存不够，有三个思路：
（1）在 CPU 有余力的情况下开启压缩（PHP 扩展）；
（2）增加内存；
（3）调整 - f 参数，减少内存浪费。
5）调整业务代码，提高命中率。
6）缓存小数据。省带宽，省网络 I / O 时间，省内存。
7）根据业务特点，为数据尺寸区间小的业务分配专用的 memcached 实例。这样可以调小 -f 参数，使数据集中存在少数几个 slab 上，内存浪费较少。
启动时最重要的参数：
-m 整个 memcached 最大内存
-f chunk 大小增长因子
-n chunk 最小分配空间
-C 禁用 CAS
-vvv 打印详细信息
我们通过计算可以看出，每个 slab 的 chunk size 大小都是上一个大小的 1.25 倍，1.25 就是 memcached 启动时制定的 - f 的值，所以，要根据不同的业务场景调整，既要尽可能少的减少内存浪费，又要存得下我们业务中的数据，再举个例子，加入我们的业务很 BT，大小都是 200kb，我们该怎么做？那当然是要保证我们申请的 chunk 大小都是 200kb 了，虽然 memcached 并不支持这么做。假如创建了 38 个 slabs，最后数据全都落到了第 20-25 个 slab 中，那 0 -19 和 26-38 的内存就被浪费了，这只是能评估出来的，还有一种情况，加入我们的 chunk 大小是 500kb，数据才 200kb，因为每个 chunk 都只能存储一个，所以一个 chunk 就会有 500kb-200kb 的空间浪费，如果有一千万个 chunk 要存，那将会浪费多少空间？所以，在使用 memcached 之前，先要评估你的数据，根据它去调整 - f 因子。