深入理解memcached

memcached产生原因:

许多web应用都是将数据存在RDBMS(Relational Database Management System)中,应用服务器直接从中读取并显示到页面上。但是随着数据量的增大,访问的集中,就会出现RDBMS的负担加重、数据库响应恶化,数据库宕机等重大影响。

这就产生了memcached,一个高性能的分布式内存缓存服务器。通过缓存频繁调用的数据,减少数据库访问次数,以提高动态web应用的速度,提高可扩展性。


图一:一般情况下memcached的用途

Memcached特征:

1. 协议简单    不使用复杂的xml格式,使用简单的基于文本行的协议

2. 基于libeven的时间处理    libevent是个程序库,它将Linux的epoll、BSD类操作系统的kqueue等事件处理功能 封装成统一的接口。即使对服务器的连接数增加,也能发挥O(1)的性能。参考链接:http://www.noobyard.com/article/p-zqojzrcw-kb.html

3. 内置内存存储方式   memcached中保存的数据都存储在memcached内置的内存存储空间中

4. memcached不互相通行的分布式   各个memcached不会互相通信以共享信息

memcache内存机制:Slab Allocation机制

Slab Allocation机制出现以前,内存的分配是通过对所有记录简单地进行malloc和free来进行的。 但是,这种方式会导致内存碎片,加重操作系统内存管理器的负担,最坏的情况下, 会导致操作系统比memcached进程本身还慢。Slab Allocator就是为解决该问题而诞生的。

Slab Allocation原理

Slab Allocator的基本原理是按照预先规定的大小,将分配的内存分割成特定长度的块, 以完全解决内存碎片问题。
Slab Allocation的原理相当简单。 将分配的内存分割成各种尺寸的块(chunk), 并把尺寸相同的块分成组(chunk的集合)(图1)。

在Slab中缓存记录的原理

下面说明memcached如何针对客户端发送的数据选择slab并缓存到chunk中。

memcached根据收到的数据的大小,选择最适合数据大小的slab(图2)。 memcached中保存着slab内空闲chunk的列表,根据该列表选择chunk, 然后将数据缓存于其中。

Slab Allocator的缺点

Slab Allocator解决了当初的内存碎片问题,但新的机制也给memcached带来了新的问题。

这个问题就是,由于分配的是特定长度的内存,因此无法有效利用分配的内存。 例如,将100字节的数据缓存到128字节的chunk中,剩余的28字节就浪费了(图3)。


memcached在数据删除方面有效利用资源

数据不会真正从memcached中消失

memcached不会释放已分配的内存。记录超时后,客户端就无法再看见该记录(invisible,透明), 其存储空间即可重复使用。

Lazy Expiration

memcached内部不会监视记录是否过期,而是在get时查看记录的时间戳,检查记录是否过期。 这种技术被称为lazy(惰性)expiration。因此,memcached不会在过期监视上耗费CPU时间。

LRU:从缓存中有效删除数据的原理

memcached会优先使用已超时的记录的空间,但即使如此,也会发生追加新记录时空间不足的情况, 此时就要使用名为 Least Recently Used(LRU)机制来分配空间。 顾名思义,这是删除“最近最少使用”的记录的机制。 因此,当memcached的内存空间不足时(无法从slab class 获取到新的空间时),就从最近未被使用的记录中搜索,并将其空间分配给新的记录。

memcached的分布式

 memcached虽然称为“分布式”缓存服务器,但服务器端并没有“分布式”功能。  至于memcached的分布式,则是完全由客户端程序库实现的。 这种分布式是memcached的最大特点。

memcached的分布式是什么意思?

这里多次使用了“分布式”这个词,但并未做详细解释。 现在开始简单地介绍一下其原理,各个客户端的实现基本相同。

下面假设memcached服务器有node1~node3三台, 应用程序要保存键名为“tokyo”“kanagawa”“chiba”“saitama”“gunma” 的数据。


图1 分布式简介:准备

首先向memcached中添加“tokyo”。将“tokyo”传给客户端程序库后, 客户端实现的算法就会根据“键”来决定保存数据的memcached服务器。 服务器选定后,即命令它保存“tokyo”及其值。


图2 分布式简介:添加时

同样,“kanagawa”“chiba”“saitama”“gunma”都是先选择服务器再保存。

接下来获取保存的数据。获取时也要将要获取的键“tokyo”传递给函数库。 函数库通过与数据保存时相同的算法,根据“键”选择服务器。 使用的算法相同,就能选中与保存时相同的服务器,然后发送get命令。 只要数据没有因为某些原因被删除,就能获得保存的值。


图3 分布式简介:获取时

这样,将不同的键保存到不同的服务器上,就实现了memcached的分布式。 memcached服务器增多后,键就会分散,即使一台memcached服务器发生故障 无法连接,也不会影响其他的缓存,系统依然能继续运行。

根据余数计算分散

Cache::Memcached的分布式方法简单来说,就是“根据服务器台数的余数进行分散”。 求得键的整数哈希值,再除以服务器台数,根据其余数来选择服务器。

根据余数计算分散的缺点

余数计算的方法简单,数据的分散性也相当优秀,但也有其缺点。 那就是当添加或移除服务器时,缓存重组的代价相当巨大。 添加服务器后,余数就会产生巨变,这样就无法获取与保存时相同的服务器, 从而影响缓存的命中率。

Consistent Hashing的简单说明

Consistent Hashing如下所示:首先求出memcached服务器(节点)的哈希值, 并将其配置到0~232的圆(continuum)上。 然后用同样的方法求出存储数据的键的哈希值,并映射到圆上。 然后从数据映射到的位置开始顺时针查找,将数据保存到找到的第一个服务器上。 如果超过232仍然找不到服务器,就会保存到第一台memcached服务器上。


图4 Consistent Hashing:基本原理

从上图的状态中添加一台memcached服务器。余数分布式算法由于保存键的服务器会发生巨大变化 而影响缓存的命中率,但Consistent Hashing中,只有在continuum上增加服务器的地点逆时针方向的 第一台服务器上的键会受到影响。


图5 Consistent Hashing:添加服务器

因此,Consistent Hashing最大限度地抑制了键的重新分布。 而且,有的Consistent Hashing的实现方法还采用了虚拟节点的思想。 使用一般的hash函数的话,服务器的映射地点的分布非常不均匀。 因此,使用虚拟节点的思想,为每个物理节点(服务器) 在continuum上分配100~200个点。这样就能抑制分布不均匀, 最大限度地减小服务器增减时的缓存重新分布。

Memcached实现集群方案 -  magent

magent是一款开源的代理服务软件,我们可以通过他来实现缓存数据的同步,当然这里说的同步不是说memcached之间就能互相通讯了,而是magent可以备份数据,而magent可以同时连接多个memcached节点,当memcached重启或者宕机恢复后可以从magent指定的memcached的备份节点中恢复丢失的缓存数据。


通过上图来说明一下原理:

magent在启动时会指定主的memcached节点与备份的memcached节点,假设我们指定了两个主的缓存节点,一个备份节点,当客户端写入时会通过算法写在其中一个指定的主缓存节点中,并把数据备份到memcached备份节点中,当写节点重启后或者宕机恢复后会从备份节点中恢复丢失的缓存数据。

同时magent还可以使用keepalived来实现高可用。

总结下memcached的优缺点

参考文章:http://www.noobyard.com/article/p-xcwbsnyt-bq.html

缓存击穿:https://blog.csdn.net/qianshangding0708/article/details/48024239




参考文献

1. https://kb.cnblogs.com/page/42735/

2. https://www.linuxidc.com/Linux/2015-01/112507.htm

3. http://www.noobyard.com/article/p-xcwbsnyt-bq.html