memcached 学习笔记 2

• 原理

1 核心组件

Memcached有两个核心组件组成：服务端（ms）和客户端（mc）。

首先mc拿到ms列表，并对key作hash转化，根据hash值肯定kv对所存的ms位置。

而后在一个memcached的查询中，mc先经过计算key的hash值来肯定kv对所处在的ms位置。

当ms肯定后，客户端就会发送一个查询请求给对应的ms，让它来查找确切的数据。

由于ms之间并无护卫备份，也就不须要互相通讯，因此效率较高。

 

 

Memcached Client目前有一下四种：

Memcached Client for Java，比 SpyMemcached更稳定、更早、更普遍；

SpyMemcached，比 Memcached Client for Java更高效；

XMemcached，比 SpyMemcache并发效果更好。 

alisoft-xplatform-asf-cache阿里软件的架构师岑文初进行封装的。里面的注释都是中文的，比较好

 

2 memcached是怎么工做的？

Memcached的神奇来自两阶段哈希（two-stage hash）。

Memcached就像一个巨大的、存储了不少<key,value>对的哈希表。经过key，能够存储或查询任意的数据。

客户端能够把数据存储在多台memcached上。

当查询数据时，客户端首先参考节点列表计算出key的哈希值（阶段一哈希），进而选中一个节点；

客户端将请求发送给选中的节点，而后memcached节点经过一个内部的哈希算法（阶段二哈希），查找真正的数据（item）。

举个列子，假设有3个客户端1, 2, 3，3台memcached A, B, C：
Client 1想把数据"barbaz"以key "foo"存储。

Client 1首先参考节点列表（A, B, C），计算key "foo"的哈希值，假设memcached B被选中。

接着，Client 1直接connect到memcached B，经过key "foo"把数据"barbaz"存储进去。　　

Client 2使用与Client 1相同的客户端库（意味着阶段一的哈希算法相同），也拥有一样的memcached列表（A, B, C）。
因而，通过相同的哈希计算（阶段一），Client 2计算出key "foo"在memcached B上，而后它直接请求memcached B，获得数据"barbaz"。

各类客户端在memcached中数据的存储形式是不一样的（perl Storable, php serialize, java hibernate, JSON等）。

一些客户端实现的哈希算法也不同。可是，memcached服务器端的行为老是一致的。

最后，从实现的角度看，memcached是一个非阻塞的、基于事件的服务器程序。这种架构能够很好地解决C10K problem ，并具备极佳的可扩展性。

 

3 内存分配原理

Memcached有一个颇有特点的内存管理方式，为了提升效率，它使用预申请和分组的方式管理内存空间，

而并非每次须要写入数据的时候去malloc，删除数据的时候free一个指针。

Memcached使用slab->chunk的组织方式管理内存。

 

3.1 Slab Allocation 机制(板 分配)：

 

整理内存以便重复使用最近的 memcached 默认状况下采用了名为 Slab Allocator 的机制分配、 管理内存。

 

在该机制出现之前，内存的分配是经过对全部记录简单地进行 malloc 和 free 来进行的。 

 

可是，这种方式会致使内存碎片，加剧操做系统内存管理器的负担，最坏的状况下，会致使操做系统比 memcached 进程自己还慢。 

 

Slab Allocator 就是为解决该问题而诞生的。

下面来看看 Slab Allocator 的原理。 

下面是 memcached 文档中的 slab allocator 的目 标：

the primary goal of the slabs subsystem in memcached was to eliminate memory fragmentation issues

totally by using fixed­size memory chunks coming from a few predetermined size classes.

也就是说， Slab Allocator 的基本原理是按照预先规定的大小， 将分配的内存分割成特定长度的块，以彻底解决内存碎片问题。

Slab Allocation 的原理至关简单。 

将分配的内存分割成各类尺寸的块（ chunk）， 并把尺寸相同的块分红组（ chunk 的集合 slab class）（图 2.1）。

 

 

memcached给Slab分配内存空间，默认是1MB。

分配给Slab以后 把slab的切分红大小相同的chunk。

Chunk是用于缓存记录的内存空间。

Slab Class特定大小的chunk的组。

并且， slab allocator 还有重复使用已分配的内存的目的。

也就是说，分配到的内存不会释放，而是重复利用。

 

2 在 Slab 中缓存记录的原理

memcached 根据收到的数据的大小， 选择最适合数据大小的 slab（图 ）。

memcached 中保存着slab 内空闲 chunk 的列表，根据该列表选择 chunk，而后将数据缓存于其中。

实际上， Slab Allocator 也是有利也有弊。 下面介绍一下它的缺点。

Slab Allocator 解决了当初的内存碎片问题， 但新的机制也给 memcached 带来了新的问题。
这个问题就是， 因为分配的是特定长度的内存，所以没法有效利用分配的内存。

例如， 将 100 字节的数据缓存到 128 字节的 chunk 中， 剩余的 28 字节就浪费了（图 ）。

 

对于该问题目前尚未完美的解决方案， 但在文档中记载了比较有效的解决方案。

The most efficient way to reduce the waste is to use a list of size classes that closely matches (if that's at all

possible) common sizes of objects that the clients of this particular installation of memcached are likely tostore.

就是说，若是预先知道客户端发送的数据的公用大小， 或者仅缓存大小相同的数据的状况下， 只要使用适合数据大小的组的列表， 就能够减小浪费。

可是很遗憾，如今还不能进行任何调优， 只能期待之后的版本了。 

可是， 咱们能够调节 slab class的大小的差异。接下来讲明 growth factor 选项。

 

3 使用 Growth Factor 进行调优

memcached 在启动时指定 Growth Factor 因子（经过­f选项）， 就能够在某种程度上控制 slab 之间的差别。 默认值为 1.25。

可是，在该选项出现以前，这个因子曾经固定为 2， 称为“ powers of 2”策略。让咱们用之前的设置，以 verbose 模式启动 memcached 试试看：

$ memcached ­f 2 ­vv

下面是启动后的 verbose 输出：

slab class   1: chunk size    128 perslab  8192

slab class   2: chunk size    256 perslab  4096

slab class   3: chunk size    512 perslab  2048

slab class   4: chunk size   1024 perslab  1024

slab class   5: chunk size   2048 perslab   512

slab class   6: chunk size   4096 perslab   256

slab class   7: chunk size   8192 perslab   128

slab class   8: chunk size  16384 perslab    64

slab class   9: chunk size  32768 perslab    32

slab class  10: chunk size  65536 perslab    16

slab class  11: chunk size 131072 perslab     8

slab class  12: chunk size 262144 perslab     4

slab class  13: chunk size 524288 perslab     2

 

可见，从 128 字节的组开始， 组的大小依次增大为原来的 2 倍。

这样设置的问题是， slab 之间的差异比较大，有些状况下就至关浪费内存。 所以，为尽可能减小内存浪费，两年前追加了 growth factor这个选项。

来看看如今的默认设置（ f=1.25） 时的输出（篇幅所限，这里只写到第 10 组）：

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

 

可见， 组间差距比因子为 2 时小得多， 更适合缓存几百字节的记录。从上面的输出结果来看， 可能会以为有些计算偏差，这些偏差是为了保持字节数的对齐而故意设置的。

将 memcached 引入产品， 或是直接使用默认值进行部署时，最好是从新计算一下数据的预期平均长度，调整 growth factor，以得到最恰当的设置。

内存是珍贵的资源， 浪费就太惋惜了

 

4 memcached 的删除机制

1）memcached是缓存，因此数据不会永久保存在服务器上，其实数据不会真正从memcached中消失。

   实际上memcached不会释放已分配的内存，记录超时后，客户端就没法再看见该记录，其存储空间便可重复使用。

2）Lazy Expiration：memcached内部不会监视记录是否过时，而是在get时查看记录的时间戳，检查记录是否过时。

  这种技术被称为lazy（惰性）expiration。所以，memcached不会在过时监视上耗费CPU时间。

3）memcached会优先使用已超时的记录的空间，但即便如此，也会发生追加新记录时空间不足的状况，此时就要使用名为 Least Recently Used（LRU）机制来分配空间。 

   顾名思义，这是删除“最近最少使用”的记录的机制。所以，当memcached的内存空间不足时（没法从slab class 获取到新的空间时），

   就从最近未被使用的记录中搜索，并将其空间分配给新的记录。

 

memcached 启动时经过“ ­M”参数能够禁止 LRU，以下所示：

$ memcached ­M ­m 1024

启动时必须注意的是， 小写的“ ­m”选项是用来指定最大内存大小的。不指定具体数值则使用默认值 64MB。

指定“ ­M”参数启动后，内存用尽时 memcached 会返回错误。 话说回来， memcached 毕竟不是存储器，而是缓存， 因此推荐使用 LRU。

 

•  一些重要的特性

1 memcached如何实现冗余机制？ 

不实现！

Memcached应该是应用的缓存层。它的设计自己就不带有任何冗余机制。

若是一个memcached节点失去了全部数据，您应该从数据源（好比数据库）再次获取到数据。您应该特别注意，您的应用应该能够容忍节点的失效。

不要写一些糟糕的查询代码，寄但愿于memcached来保证一切！若是您担忧节点失效会大大加剧数据库的负担，那么您能够采起一些办法。

好比您能够增长更多的节点（来减小丢失一个节点的影响），热备节点（在其余节点down了的时候接管IP），等等。

 

2 memcached如何处理容错的？ 

不处理！:) 

在memcached节点失效的状况下，集群没有必要作任何容错处理。若是发生了节点失效，应对的措施彻底取决于用户。节

点失效时，下面列出几种方案供您选择：

 

忽略它！ 在失效节点被恢复或替换以前，还有不少其余节点能够应对节点失效带来的影响。

把失效的节点从节点列表中移除。作这个操做千万要当心！在默认状况下（余数式哈希算法），客户端添加或移除节点，会致使全部的缓存数据不可用！

由于哈希参照的节点列表变化了，大部分key会由于哈希值的改变而被映射到（与原来）不一样的节点上。

 

启动热备节点，接管失效节点所占用的IP。这样能够防止哈希紊乱（hashing chaos）。

 

若是但愿添加和移除节点，而不影响原先的哈希结果，可使用一致性哈希算法（consistent hashing）。

您能够百度一下一致性哈希算法。支持一致性哈希的客户端已经很成熟，并且被普遍使用。去尝试一下吧！

 

两次哈希（reshing）。当客户端存取数据时，若是发现一个节点down了，就再作一次哈希（哈希算法与前一次不一样），从新选择另外一个节点（须要注意的时，客户端并无把down的节点从节点列表中移除，下次仍是有可能先哈希到它）。若是某个节点时好时坏，两次哈希的方法就有风险了，好的节点和坏的节点上均可能存在脏数据（stale data）。

 

 

3 memcached是如何作身份验证的？ 

 

没有身份认证机制！

memcached是运行在应用下层的软件（身份验证应该是应用上层的职责）。

memcached的客户端和服务器端之因此是轻量级的，部分缘由就是彻底没有实现身份验证机制。

这样，memcached能够很快地建立新链接，服务器端也无需任何配置。

 

 4 memcached能接受的key的最大长度是多少？ 

key的最大长度是250个字符。

须要注意的是，250是memcached服务器端内部的限制，若是您使用的客户端支持"key的前缀"或相似特性，

那么key（前缀+原始key）的最大长度是能够超过250个字符的。咱们推荐使用使用较短的key，由于能够节省内存和带宽。

 

5 memcached最大能存储多大的单个item？ 
　1MB。若是你的数据大于1MB，能够考虑在客户端压缩或拆分到多个key中。

 

6为何单个item的大小被限制在1M byte以内？ 

　　简单的回答：由于内存分配器的算法就是这样的。

　　详细的回答：Memcached的内存存储引擎（引擎未来可插拔...），使用slabs来管理内存。内存被分红大小不等的slabs chunks（先分红大小相等的slabs，而后每一个slab被分红大小相等chunks，不一样slab的chunk大小是不相等的）。chunk的大小依次从一个最小数开始，按某个因子增加，直到达到最大的可能值。

　　若是最小值为400B，最大值是1MB，因子是1.20，各个slab的chunk的大小依次是：slab1 - 400B slab2 - 480B slab3 - 576B ...

　　slab中chunk越大，它和前面的slab之间的间隙就越大。所以，最大值越大，内存利用率越低。Memcached必须为每一个slab预先分配内存，所以若是设置了较小的因子和较大的最大值，会须要更多的内存。

　　还有其余缘由使得您不要这样向memcached中存取很大的数据...不要尝试把巨大的网页放到mencached中。把这样大的数据结构load和unpack到内存中须要花费很长的时间，从而致使您的网站性能反而很差。

　　若是您确实须要存储大于1MB的数据，你能够修改slabs.c:POWER_BLOCK的值，而后从新编译memcached；或者使用低效的malloc/free。其余的建议包括数据库、MogileFS等。