Memcached学习篇【转】

特点

• 协议简单
• 基于libevent的事件处理
• 内置内存存储方式
• memcached不互相通信的分布式

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

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

内存分配

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

同时&＃xff0c;ms对key和data都有相应的限制&＃xff0c;key的长度不能超过250字节&＃xff0c;data也不能超过块大小的限制 --- 1MB。
因为mc所使用的hash算法&＃xff0c;并不会考虑到每个ms的内存大小。理论上mc会分配概率上等量的kv对给每个ms&＃xff0c;这样如果每个ms的内存都不太一样&＃xff0c;那 可能会导致内存使用率的降低。所以一种替代的解决方案是&＃xff0c;根据每个ms的内存大小&＃xff0c;找出他们的最大公约数&＃xff0c;然后在每个ms上开n个容量&＃61;最大公约数的 instance&＃xff0c;这样就等于拥有了多个容量大小一样的子ms&＃xff0c;从而提供整体的内存使用率。

缓存策略

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

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

缓存数据库查询

现在memcached最流行的一种使用方式是缓存数据库查询&＃xff0c;下面举一个简单例子说明&＃xff1a;

App需要得到userid&＃61;xxx的用户信息&＃xff0c;对应的查询语句类似&＃xff1a;

“SELECT * FROM users WHERE userid &＃61; xxx”

App先去问cache&＃xff0c;有没有“user:userid”&＃xff08;key定义可预先定义约束好&＃xff09;的数据&＃xff0c;如果有&＃xff0c;返回数据&＃xff1b;如果没有&＃xff0c;App会从数据库中读取数据&＃xff0c;并调用cache的add函数&＃xff0c;把数据加入cache中。

当取的数据需要更新&＃xff0c;app会调用cache的update函数&＃xff0c;来保持数据库与cache的数据同步。

从上面的例子我们也可以发现&＃xff0c;一旦数据库的数据发现变化&＃xff0c;我们一定要及时更新cache中的数据&＃xff0c;来保证app读到的是同步的正确数据。当然我们可 以通过定时器方式记录下cache中数据的失效时间&＃xff0c;时间一过就会激发事件对cache进行更新&＃xff0c;但这之间总会有时间上的延迟&＃xff0c;导致app可能从 cache读到脏数据&＃xff0c;这也被称为狗洞问题。&＃xff08;以后我会专门描述研究这个问题&＃xff09;

数据冗余与故障预防

从设计角度上&＃xff0c;memcached是没有数据冗余环节的&＃xff0c;它本身就是一个大规模的高性能cache层&＃xff0c;加入数据冗余所能带来的只有设计的复杂性和提高系统的开支。

当一个ms上丢失了数据之后&＃xff0c;app还是可以从数据库中取得数据。不过更谨慎的做法是在某些ms不能正常工作时&＃xff0c;提供额外的ms来支持cache&＃xff0c;这样就不会因为app从cache中取不到数据而一下子给数据库带来过大的负载。

同时为了减少某台ms故障所带来的影响&＃xff0c;可以使用“热备份”方案&＃xff0c;就是用一台新的ms来取代有问题的ms&＃xff0c;当然新的ms还是要用原来ms的IP地址&＃xff0c;大不了数据重新装载一遍。

另外一种方式&＃xff0c;就是提高你ms的节点数&＃xff0c;然后mc会实时侦查每个节点的状态&＃xff0c;如果发现某个节点长时间没有响应&＃xff0c;就会从mc的可用server列表里 删除&＃xff0c;并对server节点进行重新hash定位。当然这样也会造成的问题是&＃xff0c;原本key存储在B上&＃xff0c;变成存储在C上了。所以此方案本身也有其弱点&＃xff0c;最好 能和“热备份”方案结合使用&＃xff0c;就可以使故障造成的影响最小化。

Memcached客户端&＃xff08;mc&＃xff09;

Memcached客户端有各种语言的版本供大家使用&＃xff0c;包括java&＃xff0c;c&＃xff0c;php&＃xff0c;.net等等&＃xff0c;具体可参见memcached api page [2]。
大家可以根据自己项目的需要&＃xff0c;选择合适的客户端来集成。

缓存式的Web应用程序架构

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

性能测试

Memcached 读速度
平均速度: 20971 次/秒
最大速度 22497 次/秒

Memcachedb 写速度
平均速度: 8958 次/秒
最大速度 10480 次/秒

Memcachedb 读速度
平均速度: 6871 次/秒
最大速度 12542 次/秒