Memcache技术分享:介绍、使用、存储、算法、优化、命中率

1、memcached 介绍

1.1 memcached 是什么?

memcached 是以LiveJournal旗下Danga Interactive 公司的Brad Fitzpatric 为首开发的一款软件。现在已成为mixi、hatena、Facebook、Vox、LiveJournal 等众多服务中提高Web

应用扩展性的重要因素。许多Web 应用都将数据保存到RDBMS 中,应用服务器从中读取数据并在浏览器中显示。但随着数据量的增大、访问的集中,就会出现RDBMS 的负担加重、数据库响应恶化、网站显示延迟等重大影响。这时就该memcached 大显身手了。memcached 是高性能的分布式内存缓存服务器。一般的使用目的是,通过缓存数据库查询结果,减少数据库访问次数,以提高动态Web 应用的速度、提高可扩展性。

Memcache技术分享:介绍、使用、存储、算法、优化、命中率_第1张图片

内置内存存储方式

研究memcached这个产品,首先从它的内存模型开始:我们知道c++里分配内存有两种方式,预先分配和动态分配,显然,预先分配内存会使程序比较快,但是它的缺点是不能有效利用内存,而动态分配可以有效利用内存,但是会使程序运行效率下降,memcached的内存分配就是基于以上原理,显然为了获得更快的速度,有时候我们不得不以空间换时间。

Memcached的高性能源于两阶段哈希(two-stage hash)结构。Memcached就像一个巨大的、存储了很多<key,value>对的哈希表。通过key,可以存储或查询任意的数据。 客户端
可以把数据存储在多台memcached上。当查询数据时,客户端首先参考节点列表计算出key的哈希值(阶段一哈希),进而选中一个节点;客户端将请求发送给选中的节点,然后
memcached节点通过一个内部的哈希算法(阶段二哈希),查找真正的数据(item)并返回给客户端。从实现的角度看,memcached是一个非阻塞的、基于事件的服务器程序。

为了提高性能,memcached 中保存的数据都存储在memcached 内置的内存存储空间中。由于数据仅存在于内存中,因此重启memcached、重启操作系统会导致全部数据消失。另外,内容容量达到指定值之后,就基于LRU(Least Recently Used)算法自动删除不使用的缓存。memcached 本身是为缓存而设计的服务器,因此并没有过多考虑数据的永久性问题

memcached 不互相通信的分布式

memcached 尽管是“分布式”缓存服务器,但服务器端并没有分布式功能。各个

memcached 不会互相通信以共享信息。那么,怎样进行分布式呢?这完全取决于客户端的实现。

Memcache技术分享:介绍、使用、存储、算法、优化、命中率_第2张图片

2.2 memcached 启动

memcached 启动的命令在安装目录的bin 二级目录下,如/home/test/app/memcahced-1.4.2/bin/memcached -p 11222 -m 128–d

常用的一些启动选项介绍选项说明

-p 侦听的端口,默认为11211

-m 使用内存大小,默认的64m

-d 作为daemon 在后台启动

-vv 用very vrebose 模式启动,调试信息和错误输出到控制台

-l 侦听的地址,默认为所有可以访问的地址

-M 用于在内存溢出的时候,返回一个错误,禁止自动的移出数

据,替代的是返回一个error

-P Pid 文件存在的路径,仅限加上-d 参数是用

-c 最大同时的连接数,默认为1024

其它的一些选项,可以通过–h 命令来进行查看

2.3命令行访问memcached

下面假设memcached 启动时的-p 参数为11311,命令操作在启动memcached

本机首先telnet 连接到memcached 服务器

telnet 127.0.0.1 11311

telnet 成功之后,大概会显示下面的信息

Trying 127.0.0.1...

Connected to localhost.localdomain (127.0.0.1).

Escape character is '^]'.

各种状态(stats)

STAT <name> <value>\r\n

如:stats命令,则返回以下信息:

stats
STAT pid 26804
STAT uptime 182783
STAT time 1404973716
STAT version 1.4.13
STAT libevent 2.0.11-stable
STAT pointer_size 64
STAT rusage_user 2.320647
STAT rusage_system 5.411177
STAT curr_connections 34
STAT total_connections 558
STAT connection_structures 37
STAT reserved_fds 20
STAT cmd_get 127292
STAT cmd_set 60056
STAT cmd_flush 145
STAT cmd_touch 0
STAT get_hits 83811
STAT get_misses 43481
STAT delete_misses 15970
STAT delete_hits 11992
STAT incr_misses 0
STAT incr_hits 0
STAT decr_misses 0
STAT decr_hits 0
STAT cas_misses 0
STAT cas_hits 0
STAT cas_badval 0
STAT touch_hits 0
STAT touch_misses 0
STAT auth_cmds 0
STAT auth_errors 0
STAT bytes_read 14300156
STAT bytes_written 11507140
STAT limit_maxbytes 134217728      #  分配给memcache的内存大小(字节)
STAT accepting_conns 1
STAT listen_disabled_num 0
STAT threads 4
STAT conn_yields 0
STAT hash_power_level 16
STAT hash_bytes 524288
STAT hash_is_expanding 0
STAT expired_unfetched 16884
STAT evicted_unfetched 0
STAT bytes 609350    # 当前服务器存储items占用的字节数
STAT curr_items 4668    # 服务器当前存储的items数量
STAT total_items 60056
STAT evictions 0     # 分配给memcache的空间用满后需要删除旧的items数,踢出。
STAT reclaimed 27160  #回收再利用,已过期的数据条目来存储新数据。
END

存储命令(set ,add ,replace)

客户端会发送一行像这样的命令:

<command name> <key> <flags> <exptime> <bytes>\r\n

如:

set key1 0 600 5\r\nvalue\r\n

add key2 0 500 2\r\n

replace key1 0 600 6\r\nvalue1\r\n

详细的命令说明,可以见附录的memcached 中英文协议内容

读取命令(get)

命令如下:get <key>*\r\n

- <key>* 表示一个或多个键值,由空格隔开的字串

如:

get key1

VALUE key1 0 7

value12

删除命令(delete)

命令如:delete <key> <time>\r\n

<key> 是客户端希望服务器删除的内容的键名

- <time> 是一个单位为秒的时间(或代表直到某一刻的Unix时间),在该时间内服务器会拒绝对于此键名的“add”和“replace”命令。此时内容被放入delete队列,无法再通过“get”得到该内容,也无法是用“add”和“replace”命令(但是“set”命令可用)。直到指定时间,这些内容被最终从服务器的内存中彻底清除

<time>参数是可选的,缺省为0(表示内容会立刻清除,并且随后的存储命令均可用

如:delete key1

退出命令(quit)

如:quit

4、理解memcached 的内存存储

Memcache内存分配机制
Memcache使用了Slab Allocator的内存分配机制:按照预先规定的大小,将分配的内存分割成特定长度的块,以完全解决内存碎片问题
Memcache的存储涉及到slab,page,chunk三个概念
1.Chunk为固定大小的内存空间,默认为96Byte。
2.page对应实际的物理空间,1个page为1M。
3.同样大小的chunk又称为slab。

4.1Slab Allocation 机制:整理内存以便重复使用

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

Slab Allocation 的原理相当简单。将分配的内存分割成各种尺寸的块

(chunk),并把尺寸相同的块分成组(chunk 的集合)

Memcache技术分享:介绍、使用、存储、算法、优化、命中率_第3张图片

而且,slab allocator 还有重复使用已分配的内存的目的。也就是说,分配到的内存不会释放,而是重复利用。

Slab Allocation 的主要术语

Page

分配给Slab 的内存空间,默认是1MB。分配给Slab 之后根据slab 的大小切分成chunk。

Chunk

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

Slab Class

特定大小的chunk 的组

4.2 Slab中缓存记录的原理

memcached 根据收到的数据的大小,选择最适合数据大小的slab,memcached 中保存着slab 内空闲chunk 的列表,根据该列表选择chunk,然

后将数据缓存于其中

Memcache技术分享:介绍、使用、存储、算法、优化、命中率_第4张图片

4.3 Slab Allocator 的缺点

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

Memcache技术分享:介绍、使用、存储、算法、优化、命中率_第5张图片

对于该问题目前还没有完美的解决方案,但在文档中记载了比较有效的解决方案。就是说,如果预先知道客户端发送的数据的公用大小,或者仅缓存大小相同的数据的情况下,只要使用适合数据大小的组的列表,就可以减少浪费。但是很遗憾,现在还不能进行任何调优,只能期待以后的版本了。但是,我们可以调节slab class 的大小的差别。接下来说明growth factor 选项。

4.4 使用Growth Factor进行调优

memcached 在启动时指定Growth Factor 因子(通过f 选项),就可以在某种程度上控制slab 之间的差异。默认值为1.25。但是,在该选项出现之前,这个因子曾经固定为2,称为“powers of 2”策略。

下面是启动后的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,以获得最恰当的设置。内存是珍贵的资源,浪费就太可惜了。

item占用空间计算
*nsuffix = (uint8_t) snprintf(suffix, 40, " %d %d\r\n", flags, nbytes – 2);     return sizeof(item) + nkey + *nsuffix + nbytes;
*nsuffix=" %d %d\r\n”的长度
如果ITEM_CAS标志设置时,这里有8字节的数据
完整的item长度是键长+值长+后缀长+item结构大小(48字节) + 8
item.length=56+key.lenght+value.length+后缀长
32位机器 item结构是32字节
64位机器 itme结构是48字节
memcache存储的时候对key的长度有限制,php和C的最大长度都是250

5、memcached 删除机制

memcached 是缓存,不需要永久的保存到服务器上,本章介绍memcache 的删除机制

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

Memcached 不会释放已经分配的内存,记录过期之后,客户端无法再看到这一条记录,其存储空间就可以利用。

Lazy Expiration

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

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

1.search->refcount == 0  && 已经过期的  删除
2.tries = 50; // 最多尝试50次    LRU队列tail 查找 search->refcount == 0  第一个 删除
3. tries = 50; // 最多尝试50次    LRU队列tail 查找search->refcount != 0 查询时间(超过3小时)的item  第一个 删除

memcached 会优先使用已超时的记录的空间,但即使如此,也会发生追加新记录时空间不足的情况,此时就要使用名为Least Recently Used(LRU)机制来分配空间。顾名思义,这是删除“最近最少使用”的记录的机制。因此,当memcached 的内存空间不足时(无法从slab class 获取到新的空间时),就从最近未被使用的记录中搜索,并将其空间分配给新的记录。从缓存的实用角度来看,该模型十分理想。不过,有些情况下LRU 机制反倒会造成麻烦。memcached 启动时通过“M”参数可以禁止LRU,如下所示:

$ memcached -M –m 1024

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

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

6、memcached 的分布式算法

6.1memcached 的分布式

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

memcached 的分布式是什么意思?

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

Memcache技术分享:介绍、使用、存储、算法、优化、命中率_第6张图片

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

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

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

6.2 余数分布式算法

就是“根据服务器台数的余数进行分散”。求得键的整数哈希值,再除以服务器台数,根据其余数来选择服务器

余数算法的缺点

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

6.3Consistent Hashing(一致哈希)

知识补充:哈希算法,即散列函数。将任意长度的二进制值映射为较短的固定长度的二进制值,这个小的二进制值称为哈希值。哈希值是一段数据唯一且极其紧凑的数值表示形式。如果散列一段明文而且哪怕只更改该段落的一个字母,随后的哈希都将产生不同的值。要找到散列为同一个值的两个不同的输入,在计算上是不可能的,所以数据的哈希值可以检验数据的完整性。一般用于快速查找和加密算法。(常见的有MD5,SHA-1)

Consistent Hashing 的简单说明

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

Memcache技术分享:介绍、使用、存储、算法、优化、命中率_第7张图片

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

Memcache技术分享:介绍、使用、存储、算法、优化、命中率_第8张图片

Consistent Hashing:添加服务器

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

通过上文中介绍的使用Consistent Hashing 算法的memcached 客户端函数库进行测试的结果是,由服务器台数(n)和增加的服务器台数(m)计算增加服务器后的命中率计算公式如下:

(1 n/(n+m)) * 100

存储命令

<command name> <key> <flags> <exptime> <bytes>\r\n

- <command name> 是set, add,或者repalce

- <key> 是接下来的客户端所要求储存的数据的键值

- <flags> 是在取回内容时,与数据和发送块一同保存服务器上的任意16位无符号整形(用十进制来书写)。客户端可以用它作为“位域”来存储一些特定的信息;它对服务器是不透明的。

- <exptime> 是终止时间。如果为0,该项永不过期(虽然它可能被删除,以便为其他缓存项目腾出位置)。如果非0(Unix 时间戳或当前时刻的秒偏移),到达终止时间后,客户端无法再获得这项内容。

- <bytes> 是随后的数据区块的字节长度,不包括用于分野的“\r\n”。它可以是0(这时后面跟随一个空的数据区块)。

- <data block> 是大段的8位数据,其长度由前面的命令行中的<bytes>指定。

• set 意思是“储存此数据”

• add 意思是“储存此数据,只在服务器*未*保留此键值的数据时”

• replace 意思是“储存此数据,只在服务器*曾*保留此键值的数据时”

发送命令行和数据区块以后,客户端等待回复,可能的回复如下:

- "STORED\r\n"表明成功.

- "NOT_STORED\r\n"表明数据没有被存储,但不是因为发生错误。这通常意味着add或replace 命令的条件不成立,或者,项目已经位列删除队列(参考后文的“delete”命令)。

取回命令

get <key>*\r\n

- <key>* 表示一个或多个键值,由空格隔开的字串这行命令以后,客户端的等待0个或多个项目,每项都会收到一行文本,然后跟着数据区块。所有项目传送完毕后,服务器发送以下字串:"END\r\n"来指示回应完毕,服务器用以下形式发送每项内容:

VALUE <key> <flags> <bytes>\r\n

<data block>\r\n

- <key> 是所发送的键名

- <flags> 是存储命令所设置的记号

- <bytes> 是随后数据块的长度,*不包括* 它的界定符“\r\n”

- <data block> 是发送的数据

如果在取回请求中发送了一些键名,而服务器没有送回项目列表,这意味着服务器没这些键名(可能因为它们从未被存储,或者为给其他内容腾出空间而被删除,或者到期,或者被已客户端删除)。

删除

delete <key> <time>\r\n

- <key> 是客户端希望服务器删除的内容的键名

- <time> 是一个单位为秒的时间(或代表直到某一刻的Unix时间),在该时间内服务器会拒绝对于此键名的“add”和“replace”命令。此时内容被放入delete队列,无法再通过“get”得到该内容,也无法是用“add”和“replace”命令(但是“set”命令可用)。直到指定时间,这些内容被最终从服务器的内存中彻底清除。<time>参数是可选的,缺省为0(表示内容会立刻清除,并且随后的存储命令均可用)。

此命令有一行回应:- "DELETED\r\n"表示执行成功

- "NOT_FOUND\r\n"表示没有找到这项内容

增加/减少

命令“incr”和“decr”被用来修改数据,当一些内容需要替换、增加或减少时。这些数据必须是十进制的32位无符号整新。如果不是,则当作0 来处理。修改的内容必须存在,当使用“incr”/“decr”命令修改不存在的内容时,不会被当作0处理,而是操作失败。

客户端发送命令行:

incr <key> <value>\r\n或decr <key> <value>\r\n

- <key> 是客户端希望修改的内容的建名

- <value> 是客户端要增加/减少的总数。

回复为以下集中情形:

- "NOT_FOUND\r\n"指示该项内容的值,不存在。

- <value>\r\n ,<value>是增加/减少。

注意"decr"命令发生下溢:如果客户端尝试减少的结果小于0 时,结果会是0。"incr" 命令不会发生溢出。

状态

命令"stats" 被用于查询服务器的运行状态和其他内部数据。有两种格式。不带参数的:

stats\r\n

这会在随后输出各项状态、设定值和文档。另一种格式带有一些参数:

stats <args>\r\n

通过<args>,服务器传回各种内部数据。因为随时可能发生变动,本文不提供参数的种类及其传回数据。

各种状态

受到无参数的"stats"命令后,服务器发送多行内容,如下:

STAT <name> <value>\r\n

服务器用以下一行来终止这个清单:END\r\n,在每行状态中,<name> 是状态的名字,<value>使状态的数据。以下清单,是所有的状态名称,数据类型,和数据代表的含义。

在“类型”一列中,"32u"表示32 位无符号整型,"64u"表示64 位无符号整型,"32u:32u"表示用冒号隔开的两个32 位无符号整型。

名称

类型

含义

pid

32u

服务器进程ID

uptime

32u

服务器运行时间,单位秒

time

32u

服务器当前的UNIX时间

version

string

服务器的版本号

rusage_user

32u

该进程累计的用户时间(秒:微妙)

rusage_system

32u

该进程累计的系统时间(秒:微妙)

curr_items

32u

服务器当前存储的内容数量

total_items

32u

服务器启动以来存储过的内容总数

bytes

64u

服务器当前存储内容所占用的字节数

curr_connections

32u

连接数

total_connections

32u

服务器运行以来接受的连接总数

connection_structures

32u

服务器分配的连接结构的数量

cmd_get

32u

取回请求总数

cmd_set

32u

存储请求总数

get_hits

32u

请求成功的总次数

get_misses

32u

请求失败的总次数

bytes_read

64u

服务器从网络读取到的总字节数

bytes_written

64u

服务器向网络发送的总字节数

limit_maxbytes

32u

服务器在存储时被允许使用的字节总数

如果不想每次通过输入stats来查看memcache状态,可以通过echo "stats" |nc  ip port 来查看,例如:echo "stats" | nc 127.0.0.1 9023。

 

7.Memcache 命中率
缓存命中率 = get_hits/cmd_get * 100% (总命中次数/总请求次数)

要提高memcached的命中率,预估我们的value大小并且适当的调整内存页大小和增长因子是必须的。

命中率的提升可以通过多种方案实现.
其一,提高服务获取的内存总量
其二,提高空间利用率,这实际上也是另一种方式的增加内存总量
其三,应用一级别上再来一次LRU
其四,对于整体命中率,可以采取有效的冗余策略,减少分布式服务时某个server发生服务抖动的情况

 

8.一些注意
1. memcache已经分配的内存不会再主动清理。
2. memcache分配给某个slab的内存页不能再分配给其他slab。
3. flush_all不能重置memcache分配内存页的格局,只是给所有的item置为过期。
4. memcache最大存储的item(key+value)大小限制为1M,这由page大小1M限制
5.由于memcache的分布式是客户端程序通过hash算法得到的key取模来实现,不同的语言可能会采用不同的hash算法,同样的客户端程序也有可能使用相异的方法,因此在多语言、多模块共用同一组memcached服务时,一定要注意在客户端选择相同的hash算法
6.启动memcached时可以通过-M参数禁止LRU替换,在内存用尽时add和set会返回失败
7.memcached启动时指定的是数据存储量,没有包括本身占用的内存、以及为了保存数据而设置的管理空间。因此它占用的内存量会多于启动时指定的内存分配量,这点需要注意。
8.memcache存储的时候对key的长度有限制,php和C的最大长度都是250

你可能感兴趣的:(Memcache技术分享:介绍、使用、存储、算法、优化、命中率)