作者：长野雅广(Masahiro Nagano)
原文链接：http://gihyo.jp/dev/feature/01/memcached/0005
我是Mixi的长野。memcached的连载最终要结束了。 到上次为止， 我们介绍了与memcached直接相关的话题，本次介绍一些mixi的案例和 实际应用上的话题，并介绍一些与memcached兼容的程序。
mixi案例研究
mixi在提供服务的初期阶段就使用了memcached。 随着站点訪问量的急剧添加�，单纯为数据库加入�slave已无法满足须要，因此引入了memcached。 此外，我们也从添加�可扩展性的方面进行了验证，证明了memcached的速度和稳定性都能满足须要。 如今，memcached已成为mixi服务中很重要的组成部分。
图1 如今的系统组件
server配置和数量
mixi使用了许很多多server，如数据库server、应用server、图片server、 反向代理server等。单单memcached就有将近200台server在执行。 memcachedserver的典型配置例如以下：
- CPU：Intel Pentium 4 2.8GHz
- 内存：4GB
- 硬盘：146GB SCSI
- 操作系统：Linux（x86_64）
这些server曾经曾用于数据库server等。随着CPU性能提升、内存价格下降， 我们积极地将数据库server、应用server等换成了性能更强大、内存很多其它的server。 这样，能够抑制mixi总体使用的server数量的急剧添加�，减少管理成本。 因为memcachedserver差点儿不占用CPU，就将换下来的server用作memcachedserver了。
memcached进程
每台memcachedserver仅启动一个memcached进程。分配给memcached的内存为3GB， 启动參数例如以下：
/usr/bin/memcached -p 11211 -u nobody -m 3000 -c 30720
因为使用了x86_64的操作系统，因此能分配2GB以上的内存。32位操作系统中， 每一个进程最多仅仅能使用2GB内存。也以前考虑过启动多个分配2GB下面内存的进程， 但这样一台server上的TCP连接数就会成倍添加�，管理上也变得复杂， 所以mixi就统一使用了64位操作系统。
另外，尽管server的内存为4GB，却仅分配了3GB，是由于内存分配量超过这个值， 就有可能导致内存交换(swap)。连载的第2次中 前坂解说过了memcached的内存存储“slab allocator”，当时说过，memcached启动时 指定的内存分配量是memcached用于保存数据的量，没有包含“slab allocator”本身占用的内存、 以及为了保存数据而设置的管理空间。因此，memcached进程的实际内存分配量要比 指定的容量要大，这一点应当注意。
mixi保存在memcached中的数据大部分都比較小。这样，进程的大小要比 指定的容量大非常多。因此，我们重复改变内存分配量进行验证， 确认了3GB的大小不会引发swap，这就是如今应用的数值。
memcached用法和client
如今，mixi的服务将200台左右的memcachedserver作为一个pool使用。 每台server的容量为3GB，那么全体就有了将近600GB的巨大的内存数据库。 client程序库使用了本连载中多次提到车的Cache::Memcached::Fast， 与server进行交互。当然，缓存的分布式算法使用的是 第4次介绍过的 Consistent Hashing算法。
应用层上memcached的用法由开发应用程序的project师自行决定并实现。 可是，为了防止车轮再造、防止Cache::Memcached::Fast上的教训再次发生， 我们提供了Cache::Memcached::Fast的wrap模块并使用。
通过Cache::Memcached::Fast维持连接
Cache::Memcached的情况下，与memcached的连接（文件句柄）保存在Cache::Memcached包内的类变量中。 在mod_perl和FastCGI等环境下，包内的变量不会像CGI那样随时又一次启动， 而是在进程中一直保持。其结果就是不会断开与memcached的连接， 降低了TCP连接建立时的开销，同一时候也能防止短时间内重复进行TCP连接、断开 而导致的TCPport资源枯竭。
可是，Cache::Memcached::Fast没有这个功能，所以须要在模块之外 将Cache::Memcached::Fast对象保持在类变量中，以保证持久连接。
package Gihyo::Memcached;
use strict;
use warnings;
use Cache::Memcached::Fast;
my @server_list = qw/192.168.1.1:11211 192.168.1.1:11211/;
my $fast; ## 用于保持对象
sub new {
my $self = bless {}, shift;
if ( !$fast ) {
$fast = Cache::Memcached::Fast->new({ servers => @server_list });
}
$self->{_fast} = $fast;
return $self;
}
sub get {
my $self = shift;
$self->{_fast}->get(@_);
}
上面的样例中，Cache::Memcached::Fast对象保存到类变量$fast中。
公共数据的处理和rehash
诸如mixi的主页上的新闻这种全部用户共享的缓存数据、设置信息等数据， 会占用很多页，訪问次数也非常多。在这种条件下，訪问非常easy集中到某台memcachedserver上。 訪问集中本身并非问题，可是一旦訪问集中的那台server发生问题导致memcached无法连接， 就会产生巨大的问题。
连载的第4次 中提到，Cache::Memcached拥有rehash功能，即在无法连接保存数据的server的情况下， 会再次计算hash值，连接其它的server。
可是，Cache::Memcached::Fast没有这个功能。只是，它可以在连接server失败时， 短时间内不再连接该server的功能。
my $fast = Cache::Memcached::Fast->new({
max_failures => 3,
failure_timeout => 1
});
在failure_timeout秒内发生max_failures以上次连接失败，就不再连接该memcachedserver。 我们的设置是1秒钟3次以上。
此外，mixi还为全部用户共享的缓存数据的键名设置命名规则， 符合命名规则的数据会自己主动保存到多台memcachedserver中， 取得时从中仅选取一台server。创建该函数库后，就能够使memcachedserver故障 不再产生其它影响。
memcached应用经验
到此为止介绍了memcached内部构造和函数库，接下来介绍一些其它的应用经验。
通过daemontools启动
通常情况下memcached执行得相当稳定，但mixi如今使用的最新版1.2.5 以前发生过几次memcached进程死掉的情况。架构上保证了即使有几台memcached故障 也不会影响服务，只是对于memcached进程死掉的server，仅仅要又一次启动memcached， 就能够正常执行，所以採用了监视memcached进程并自己主动启动的方法。 于是使用了daemontools。
daemontools是qmail的作者DJB开发的UNIX服务管理工具集， 当中名为supervise的程序可用于服务启动、停止的服务重新启动等。
这里不介绍daemontools的安装了。mixi使用了下面的run脚本来启动memcached。
#!/bin/sh
if [ -f /etc/sysconfig/memcached ];then
. /etc/sysconfig/memcached
fi
exec 2>&1
exec /usr/bin/memcached -p $PORT -u $USER -m $CACHESIZE -c $MAXCONN $OPTIONS
监视
mixi使用了名为“nagios”的开源监视软件来监视memcached。
在nagios中能够简单地开发插件，能够具体地监视memcached的get、add等动作。 只是mixi仅通过stats命令来确认memcached的执行状态。
define command {
command_name check_memcached
command_line $USER1$/check_tcp -H $HOSTADDRESS$ -p 11211 -t 5 -E -s 'stats
quit
' -e 'uptime' -M crit
}
此外，mixi将stats文件夹的结果通过rrdtool转化成图形，进行性能监视， 并将每天的内存使用量做成报表，通过邮件与开发人员共享。
memcached的性能
连载中已介绍过，memcached的性能十分优秀。我们来看看mixi的实际案例。 这里介绍的图表是服务所使用的訪问最为集中的memcachedserver。
图2 请求数
图3 流量
图4 TCP连接数
从上至下依次为请求数、流量和TCP连接数。请求数最大为15000qps， 流量达到400Mbps，这时的连接数已超过了10000个。 该server没有特别的硬件，就是开头介绍的普通的memcachedserver。 此时的CPU利用率为：
图5 CPU利用率
可见，仍然有idle的部分。因此，memcached的性能很高， 能够作为Web应用程序开发人员放心地保存暂时数据或缓存数据的地方。
兼容应用程序
memcached的实现和协议都十分简单，因此有非常多与memcached兼容的实现。 一些功能强大的扩展能够将memcached的内存数据写到磁盘上，实现数据的持久性和冗余。 连载第3次 介绍过，以后的memcached的存储层将变成可扩展的（pluggable），逐渐支持这些功能。
这里介绍几个与memcached兼容的应用程序。
- repcached
- 为memcached提供复制(replication)功能的patch。
- Flared
- 存储到QDBM。同一时候实现了异步复制和fail over等功能。
- memcachedb
- 存储到BerkleyDB。还实现了message queue。
- Tokyo Tyrant
- 将数据存储到Tokyo Cabinet。不仅与memcached协议兼容，还能通过HTTP进行訪问。
Tokyo Tyrant案例
mixi使用了上述兼容应用程序中的Tokyo Tyrant。Tokyo Tyrant是平林开发的 Tokyo Cabinet DBM的网络接口。它有自己的协议，但也拥有memcached兼容协议， 也能够通过HTTP进行数据交换。Tokyo Cabinet尽管是一种将数据写到磁盘的实现，但速度相当快。
mixi并没有将Tokyo Tyrant作为缓存server，而是将它作为保存键值对组合的DBMS来使用。 主要作为存储用户上次訪问时间的数据库来使用。它与差点儿全部的mixi服务都有关， 每次用户訪问页面时都要更新数据，因此负荷相当高。MySQL的处理十分笨重， 单独使用memcached保存数据又有可能会丢失数据，所以引入了Tokyo Tyrant。 但无需又一次开发client，仅仅需原封不动地使用Cache::Memcached::Fast就可以， 这也是长处之中的一个。关于Tokyo Tyrant的具体信息，请參考本公司的开发blog。
总结
到本次为止，“memcached全面剖析”系列就结束了。我们介绍了memcached的基础、内部结构、 分散算法和应用等内容。读完后假设您能对memcached产生兴趣，就是我们的荣幸。 关于mixi的系统、应用方面的信息，请參考本公司的开发blog。 感谢您的阅读。