memcached 学习研究（java调用）

Memcached是什么？
Memcached是一个高性能的、分布式的内存对象的Key-Value缓存系统，它能减少数据库负载，为动态Web应用提速。
Memcached是分布式的，它是基于网络的，也就是说，Mecmcached通常是以独立的进程部署到独立的服务器上，用于为业务应用提供动态缓存服务，对Memcached服务器的访问一定是通过网络进行的。
Memcached本身是用C实现的，通常以集群方式部署到多台服务器上，对客户端提供分布式缓存服务。
Memcached是一个对象缓存系统，它会自主管理服务器的内存，为数据分配合适的存储空间，尽可能高效地利用空间。
Memcached即可以缓存原始数据类型，也可以缓存序列化的对象。Map List  都可以存储
注意：客户端访问Memcached集群时，具体选择集群中的哪台服务器来存储数据，这个策略不是由Memcached本身提供的，而是由客户端实现的，客户端会选择合适的算法确定访问哪台服务器。memcached 服务之间不会进行通信，集群是通过客户端实现的。
另外，Memcached以Key-Value存取数据，K-V是一种扁平结构，所以要特别注意Key的唯一性问题。如果用同一个Key值存储数据，那么先前该Key的值将被覆盖。建议实际使用时按一定规则来分配Key。

Memcached适合什么场合？

通常可用作数据库的前端Cache，以减轻数据库的负载。
如果一个Web应用中对数据库的访问非常频繁，而且多数的查询都是一样的，这种情况下最适合使用Memcached作为前端缓存。虽然数据库本身也是有Cached的，但是依然需要解析SQL、完成一些必要的辅助操作、格式化查询结果等。而如果把查询结果格式化后直接放到Memcached中，那么对于同一个查询，则根本无须访问数据库，直接从Memcached中取出格式化的结果数据返回给客户端即可，如此可大大减轻数据库服务器的压力。
Memcached是分布式的内存缓存系统，如果应用不是分布式的，则根本无须使用Memcached。因为Memcached服务必须是通过网络访问，而且客户端与Memcached服务之间的通信还要遵循Memcached定义的协议，对于非分布式的简单Web应用而言，使用Memcached可能会加重服务器的负载，性能反而降低。


Memcached协议要点（文本协议）

建议客户端缓存TCP链接以节省创建的开销
协议中有两种类型的数据：文本和非结构化数据，前者用来表示命令或服务端客户端交互，后者用来表示被缓存的数据。所以服务端不去管客户端存进来的是什么，当客户端来取时，只是以字节流的形式原样返还。
上述两种数据类型都会以'\r\n'结束，由于被缓存的对象里也有可能含有\r\n，所以客户端应该以数据长度作为对象结束的依据，而不是\r\n
key用来标识存进memcached的对象，key是一个长度小于250的字串，且不能含有控制字符或空格
一些命令中可以有过期时间，这个时间是一个整数值，如果大于60*60*24*30(30天)，它将被作为一个Unix时间
错误代码一共有三种
"ERROR\r\n" 表示客户端发送了一个不存在的命令
"CLIENT_ERROR <error>\r\n" 表示客户端的命令格式不正确
"SERVER_ERROR <error>\r\n" 表示服务端错误。当严重的错误发生时，服务端在发送完这个响应后会关闭链接

服务器端主要命令

命令说明：
set: 置值
add: 如果不存在，置值
replace: 如果存在，置值
append: 如果存在，在原值后添加
prepend: 如果存在，在原值前添加
cas: check and set，检查并置值，确保在上次获取值后没有被置过值


Memcached存储单个item最大数据是在1MB内，如果数据超过1M,存取set和get是都是返回false，而且引起性能的问题。
所以Memcahce不适合缓存大数据，超过1MB的数据，可以考虑在客户端压缩或拆分到多个key中。大的数据在进行load和uppack到内存的时候需要花很长时间，从而降低服务器的性能。
Memcached支持最大的存储对象为1M。这个值由其内存分配机制决定的。
也就是说memcached server不能存储超过1M的数据，但是经过客户端压缩数据后，只要小于1M的数据都能存储成功。

item对象的过期时间最长可以达到30天。memcached把传入的过期时间（时间段）解释成时间点后，一旦到了这个时间点，memcached就把item置为失效状态，这是一个简单但obscure的机制。代码中的注释： An expiration time, in seconds. Can be up to 30 days. After 30* days, is treated as a unix timestamp of an exact date.
memcached能接受的key的最大长度是250个字符
memcached能接受的key的最大长度是250个字符。需要注意的是，250是memcached服务器端内部的限制。如果使用的Memcached客户端支持"key的前缀"或类似特性，那么key（前缀+原始key）的最大长度是可以超过250个字符的。推荐使用较短的key，这样可以节省内存和带宽。

memcached的特点：
1.全内存运转
2.哈希方式存储
3.简单文本协议进行数据通信
4.只操作字符型数据
5.其它类型数据由应用解释，序列化以及反序列化
6.集群也由应用进行控制，采用一致性散列（哈希）算法

Memcached的缺点
纯内存操作，关机后数据全部丢失
保存字节数据，数据类型贫乏
LRU算法导致数据不可控的丢失
一致性处理简单
应用端太厚，服务器端太薄
应用场景有限，难以被看成是完整的数据库产品

----------------------------------------------------------------------------------------------------------------------

memcached的分布式

正如第1次中介绍的那样， memcached虽然称为“分布式”缓存服务器，但服务器端并没有“分布式”功能。 服务器端仅包括 第2次、 第3次 前坂介绍的内存存储功能，其实现非常简单。 至于memcached的分布式，则是完全由客户端程序库实现的。 这种分布式是memcached的最大特点。
memcached的分布式是什么意思？

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

下面假设memcached服务器有node1～node3三台， 应用程序要保存键名为“tokyo”“kanagawa”“chiba”“saitama”“gunma” 的数据。
memcached-0004-01.png

图1 分布式简介：准备

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

图2 分布式简介：添加时

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

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

图3 分布式简介：获取时

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

接下来介绍第1次 中提到的Perl客户端函数库Cache::Memcached实现的分布式方法。
Cache::Memcached的分布式方法

Perl的memcached客户端函数库Cache::Memcached是 memcached的作者Brad Fitzpatrick的作品，可以说是原装的函数库了。

    Cache::Memcached - search.cpan.org

该函数库实现了分布式功能，是memcached标准的分布式方法。
根据余数计算分散

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

下面将Cache::Memcached简化成以下的Perl脚本来进行说明。

use strict;
use warnings;
use String::CRC32;

my @nodes = ('node1','node2','node3');
my @keys = ('tokyo', 'kanagawa', 'chiba', 'saitama', 'gunma');

foreach my $key (@keys) {
    my $crc = crc32($key);             # CRC値
    my $mod = $crc % ( $#nodes + 1 );
    my $server = $nodes[ $mod ];       # 根据余数选择服务器
    printf "%s => %s/n", $key, $server;
}

Cache::Memcached在求哈希值时使用了CRC。

    String::CRC32 - search.cpan.org

首先求得字符串的CRC值，根据该值除以服务器节点数目得到的余数决定服务器。 上面的代码执行后输入以下结果：

tokyo       => node2
kanagawa => node3
chiba       => node2
saitama   => node1
gunma     => node1

根据该结果，“tokyo”分散到node2，“kanagawa”分散到node3等。 多说一句，当选择的服务器无法连接时，Cache::Memcached会将连接次数 添加到键之后，再次计算哈希值并尝试连接。这个动作称为rehash。 不希望rehash时可以在生成Cache::Memcached对象时指定“rehash => 0”选项。
根据余数计算分散的缺点

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

use strict;
use warnings;
use String::CRC32;

my @nodes = @ARGV;
my @keys = ('a'..'z');
my %nodes;

foreach my $key ( @keys ) {
    my $hash = crc32($key);
    my $mod = $hash % ( $#nodes + 1 );
    my $server = $nodes[ $mod ];
    push @{ $nodes{ $server } }, $key;
}

foreach my $node ( sort keys %nodes ) {
    printf "%s: %s/n", $node,  join ",", @{ $nodes{$node} };
}

这段Perl脚本演示了将“a”到“z”的键保存到memcached并访问的情况。 将其保存为mod.pl并执行。

首先，当服务器只有三台时：

$ mod.pl node1 node2 nod3
node1: a,c,d,e,h,j,n,u,w,x
node2: g,i,k,l,p,r,s,y
node3: b,f,m,o,q,t,v,z

结果如上，node1保存a、c、d、e……，node2保存g、i、k……， 每台服务器都保存了8个到10个数据。

接下来增加一台memcached服务器。

$ mod.pl node1 node2 node3 node4
node1: d,f,m,o,t,v
node2: b,i,k,p,r,y
node3: e,g,l,n,u,w
node4: a,c,h,j,q,s,x,z

添加了node4。可见，只有d、i、k、p、r、y命中了。像这样，添加节点后 键分散到的服务器会发生巨大变化。26个键中只有六个在访问原来的服务器， 其他的全都移到了其他服务器。命中率降低到23%。在Web应用程序中使用memcached时， 在添加memcached服务器的瞬间缓存效率会大幅度下降，负载会集中到数据库服务器上， 有可能会发生无法提供正常服务的情况。

mixi的Web应用程序运用中也有这个问题，导致无法添加memcached服务器。 但由于使用了新的分布式方法，现在可以轻而易举地添加memcached服务器了。 这种分布式方法称为 Consistent Hashing。
Consistent Hashing

关于Consistent Hashing的思想，mixi株式会社的开发blog等许多地方都介绍过， 这里只简单地说明一下。

    mixi Engineers' Blog - スマートな分散で快適キャッシュライフ
    ConsistentHashing - コンシステント ハッシュ法

Consistent Hashing的简单说明

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

图4 Consistent Hashing：基本原理

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

图5 Consistent Hashing：添加服务器

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

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

(1 - n/(n+m)) * 100
支持Consistent Hashing的函数库

本连载中多次介绍的Cache::Memcached虽然不支持Consistent Hashing， 但已有几个客户端函数库支持了这种新的分布式算法。 第一个支持Consistent Hashing和虚拟节点的memcached客户端函数库是 名为libketama的PHP库，由last.fm开发。

    libketama - a consistent hashing algo for memcache clients – RJ ブログ - Users at Last.fm

至于Perl客户端，连载的第1次 中介绍过的Cache::Memcached::Fast和Cache::Memcached::libmemcached支持 Consistent Hashing。

    Cache::Memcached::Fast - search.cpan.org
    Cache::Memcached::libmemcached - search.cpan.org

两者的接口都与Cache::Memcached几乎相同，如果正在使用Cache::Memcached， 那么就可以方便地替换过来。Cache::Memcached::Fast重新实现了libketama， 使用Consistent Hashing创建对象时可以指定ketama_points选项。

my $memcached = Cache::Memcached::Fast->new({
    servers => ["192.168.0.1:11211","192.168.0.2:11211"],
    ketama_points => 150
});

另外，Cache::Memcached::libmemcached 是一个使用了Brain Aker开发的C函数库libmemcached的Perl模块。 libmemcached本身支持几种分布式算法，也支持Consistent Hashing， 其Perl绑定也支持Consistent Hashing。

    Tangent Software: libmemcached

总结

本次介绍了memcached的分布式算法，主要有memcached的分布式是由客户端函数库实现， 以及高效率地分散数据的Consistent Hashing算法。下次将介绍mixi在memcached应用方面的一些经验， 和相关的兼容应用程序。

---------------------------------------------------------------------------------------------------------------------


memcached是缓存，所以数据不会永久保存在服务器上，这是向系统中引入memcached的前提。
本次介绍memcached的数据删除机制，以及memcached的最新发展方向——二进制协议（Binary Protocol） 和外部引擎支持。
memcached在数据删除方面有效利用资源
数据不会真正从memcached中消失

上次介绍过， memcached不会释放已分配的内存。记录超时后，客户端就无法再看见该记录（invisible，透明），
其存储空间即可重复使用。
Lazy Expiration

memcached内部不会监视记录是否过期，而是在get时查看记录的时间戳，检查记录是否过期。
这种技术被称为lazy（惰性）expiration。因此，memcached不会在过期监视上耗费CPU时间。
LRU：从缓存中有效删除数据的原理

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

不过，有些情况下LRU机制反倒会造成麻烦。memcached启动时通过“-M”参数可以禁止LRU，如下所示：

$ memcached -M -m 1024

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

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