Memcached 工作原理

Memcached处理的原子是每一个（key，value）对（以下简称kv对），key会通过一个hash算法转化成hash-key，便于查找、对比以及做到尽可能的散列。同时，memcached用的是一个二级散列，通过一张大hash表来维护。

Memcached有两个核心组件组成：服务端（ms）和客户端（mc），在一个memcached的查询中，mc先通过计算key的hash值来 确定kv对所处在的ms位置。当ms确定后，客户端就会发送一个查询请求给对应的ms，让它来查找确切的数据。因为这之间没有交互以及多播协议，所以 memcached交互带给网络的影响是最小化的。

举例说明：考虑以下这个场景，有三个mc分别是X，Y，Z，还有三个ms分别是A，B，C：

设置kv对

X想设置key=”foo”,value=”seattle”

X拿到ms列表，并对key做hash转化，根据hash值确定kv对所存的ms位置

B被选中了

X连接上B，B收到请求，把（key=”foo”,value=”seattle”）存了起来

获取kv对

Z想得到key=”foo”的value

Z用相同的hash算法算出hash值，并确定key=”foo”的值存在B上

Z连接上B，并从B那边得到value=”seattle”

其他任何从X，Y，Z的想得到key=”foo”的值的请求都会发向B



Memcached服务器(ms)



内存分配

默认情况下，ms是用一个内置的叫“块分配器”的组件来分配内存的。舍弃c++标准的malloc/free的内存分配，而采用块分配器的主要目的 是为了避免内存碎片，否则操作系统要花费更多时间来查找这些逻辑上连续的内存块（实际上是断开的）。用了块分配器，ms会轮流的对内存进行大块的分配，并 不断重用。当然由于块的大小各不相同，当数据大小和块大小不太相符的情况下，还是有可能导致内存的浪费。

同时，ms对key和data都有相应的限制，key的长度不能超过250字节，data也不能超过块大小的限制 --- 1MB。

因为 mc所使用的hash算法，并不会考虑到每个ms的内存大小。理论上mc会分配概率上等量的kv对给每个ms，这样如果每个ms的内存都不太一样，那可能 会导致内存使用率的降低。所以一种替代的解决方案是，根据每个ms的内存大小，找出他们的最大公约数，然后在每个ms上开n个容量=最大公约数的 instance，这样就等于拥有了多个容量大小一样的子ms，从而提供整体的内存使用率。

缓存策略

当ms的hash表满了之后，新的插入数据会替代老的数据，更新的策略是LRU（最近最少使用），以及每个kv对的有效时限。Kv对存储有效时限是在mc端由app设置并作为参数传给ms的。

同时ms采用是偷懒替代法，ms不会开额外的进程来实时监测过时的kv对并删除，而是当且仅当，新来一个插入的数据，而此时又没有多余的空间放了，才会进行清除动作。

Memcached客户端（mc）

Memcached客户端有各种语言的版本供大家使用，包括java，c，php，.net等等。

大家可以根据自己项目的需要，选择合适的客户端来集成。

缓存式的Web应用程序架构

有了缓存的支持，我们可以在传统的app层和db层之间加入cache层， 每个app服务器都可以绑定一个mc，每次数据的读取都可以从ms中取得，如果没有，再从db层读取。而当数据要进行更新时，除了要发送update的 sql给db层，同时也要将更新的数据发给mc，让mc去更新ms中的数据。



假设今后我们的数据库可以和ms进行通讯了，那可以将更新的任务统一交给db层，每次数据库更新数据的同时会自动去更新ms中的数据，这样就可以进一步减少app层的逻辑复杂度。如下图：



不过每次我们如果没有从cache读到数据，都不得不麻烦数据库。为了最小化数据库的负载压力，我们可以部署数据库复写，用slave数据库来完成读取操作，而master数据库永远只负责三件事：1.更新数据；2.同步slave数据库；3.更新cache。如下图：



以上这些缓存式web架构在实际应用中被证明是能有效并能极大地降低数据库的负载同时又能提高web的运行性能。当然这些架构还可以根据具体的应用环境进行变种，以达到不同硬件条件下性能的最优化。

参考

[1]. Memcached website: http://danga.com/memcached/
[2]. Memcached API Page: http://danga.com/memcached/apis.bml
[3]. memcached_engine: http://tangent.org/506/memcache_engine.html