發(fā)表日：2008/7/30
作者：長野雅廣(Masahiro Nagano)
原文鏈接：http://gihyo.jp/dev/feature/01/memcached/0005
我是Mixi的長野。memcached的連載終于要結束了。到上次為止，我們介紹了與memcached直接相關的話題，本次介紹一些mixi的案例和實際應用上的話題，并介紹一些與memcached兼容的程序。
mixi案例研究
mixi在提供服務的初期階段就使用了memcached。隨著網站訪問量的急劇增加，單純?yōu)閿祿焯砑觭lave已無法滿足需要，因此引入了memcached。此外，我們也從增加可擴展性的方面進行了驗證，證明了memcached的速度和穩(wěn)定性都能滿足需要。現在，memcached已成為mixi服務中非常重要的組成部分。
圖1 現在的系統(tǒng)組件
服務器配置和數量
mixi使用了許許多多服務器，如數據庫服務器、應用服務器、圖片服務器、反向代理服務器等。單單memcached就有將近200臺服務器在運行。 memcached服務器的典型配置如下：
- CPU：Intel Pentium 4 2.8GHz
- 內存：4GB
- 硬盤：146GB SCSI
- 操作系統(tǒng)：Linux（x86_64）
這些服務器以前曾用于數據庫服務器等。隨著CPU性能提升、內存價格下降，我們積極地將數據庫服務器、應用服務器等換成了性能更強大、內存更多的服務器。這樣，可以抑制mixi整體使用的服務器數量的急劇增加，降低管理成本。由于memcached服務器幾乎不占用CPU，就將換下來的服務器用作memcached服務器了。
memcached進程
每臺memcached服務器僅啟動一個memcached進程。分配給memcached的內存為3GB，啟動參數如下：
/usr/bin/memcached -p 11211 -u nobody -m 3000 -c 30720
由于使用了x86_64的操作系統(tǒng)，因此能分配2GB以上的內存。32位操作系統(tǒng)中，每個進程最多只能使用2GB內存。也曾經考慮過啟動多個分配2GB以下內存的進程，但這樣一臺服務器上的TCP連接數就會成倍增加，管理上也變得復雜，所以mixi就統(tǒng)一使用了64位操作系統(tǒng)。
另外，雖然服務器的內存為4GB，卻僅分配了3GB，是因為內存分配量超過這個值，就有可能導致內存交換(swap)。連載的第2次中前坂講解過了memcached的內存存儲“slab allocator”，當時說過，memcached啟動時指定的內存分配量是memcached用于保存數據的量，沒有包括“slab allocator”本身占用的內存、以及為了保存數據而設置的管理空間。因此，memcached進程的實際內存分配量要比指定的容量要大，這一點應當注意。
mixi保存在memcached中的數據大部分都比較小。這樣，進程的大小要比指定的容量大很多。因此，我們反復改變內存分配量進行驗證，確認了3GB的大小不會引發(fā)swap，這就是現在應用的數值。
memcached使用方法和客戶端
現在，mixi的服務將200臺左右的memcached服務器作為一個pool使用。每臺服務器的容量為3GB，那么全體就有了將近600GB的巨大的內存數據庫。客戶端程序庫使用了本連載中多次提到車的Cache::Memcached::Fast，與服務器進行交互。當然，緩存的分布式算法使用的是 第4次介紹過的 Consistent Hashing算法。
應用層上memcached的使用方法由開發(fā)應用程序的工程師自行決定并實現。但是，為了防止車輪再造、防止Cache::Memcached::Fast上的教訓再次發(fā)生，我們提供了Cache::Memcached::Fast的wrap模塊并使用。
通過Cache::Memcached::Fast維持連接
Cache::Memcached的情況下，與memcached的連接（文件句柄）保存在Cache::Memcached包內的類變量中。在mod_perl和FastCGI等環(huán)境下，包內的變量不會像CGI那樣隨時重新啟動，而是在進程中一直保持。其結果就是不會斷開與memcached的連接，減少了TCP連接建立時的開銷，同時也能防止短時間內反復進行TCP連接、斷開而導致的TCP端口資源枯竭。
但是，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的主頁上的新聞這樣的所有用戶共享的緩存數據、設置信息等數據，會占用許多頁，訪問次數也非常多。在這種條件下，訪問很容易集中到某臺memcached服務器上。訪問集中本身并不是問題，但是一旦訪問集中的那臺服務器發(fā)生故障導致memcached無法連接，就會產生巨大的問題。
連載的第4次 中提到，Cache::Memcached擁有rehash功能，即在無法連接保存數據的服務器的情況下，會再次計算hash值，連接其他的服務器。
但是，Cache::Memcached::Fast沒有這個功能。不過，它能夠在連接服務器失敗時，短時間內不再連接該服務器的功能。
my $fast = Cache::Memcached::Fast->new({
max_failures => 3,
failure_timeout => 1
});
在failure_timeout秒內發(fā)生max_failures以上次連接失敗，就不再連接該memcached服務器。我們的設置是1秒鐘3次以上。
此外，mixi還為所有用戶共享的緩存數據的鍵名設置命名規(guī)則，符合命名規(guī)則的數據會自動保存到多臺memcached服務器中，取得時從中僅選取一臺服務器。創(chuàng)建該函數庫后，就可以使memcached服務器故障不再產生其他影響。
memcached應用經驗
到此為止介紹了memcached內部構造和函數庫，接下來介紹一些其他的應用經驗。
通過daemontools啟動
通常情況下memcached運行得相當穩(wěn)定，但mixi現在使用的最新版1.2.5 曾經發(fā)生過幾次memcached進程死掉的情況。架構上保證了即使有幾臺memcached故障也不會影響服務，不過對于memcached進程死掉的服務器，只要重新啟動memcached，就可以正常運行，所以采用了監(jiān)視memcached進程并自動啟動的方法。于是使用了daemontools。
daemontools是qmail的作者DJB開發(fā)的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
監(jiān)視
mixi使用了名為“nagios”的開源監(jiān)視軟件來監(jiān)視memcached。
在nagios中可以簡單地開發(fā)插件，可以詳細地監(jiān)視memcached的get、add等動作。不過mixi僅通過stats命令來確認memcached的運行狀態(tài)。
define command {
command_name check_memcached
command_line $USER1$/check_tcp -H $HOSTADDRESS$ -p 11211 -t 5 -E -s 'stats\r\nquit\r\n' -e 'uptime' -M crit
}
此外，mixi將stats目錄的結果通過rrdtool轉化成圖形，進行性能監(jiān)視，并將每天的內存使用量做成報表，通過郵件與開發(fā)者共享。
memcached的性能
連載中已介紹過，memcached的性能十分優(yōu)秀。我們來看看mixi的實際案例。這里介紹的圖表是服務所使用的訪問最為集中的memcached服務器。
圖2 請求數
圖3 流量
圖4 TCP連接數
從上至下依次為請求數、流量和TCP連接數。請求數最大為15000qps，流量達到400Mbps，這時的連接數已超過了10000個。該服務器沒有特別的硬件，就是開頭介紹的普通的memcached服務器。此時的CPU利用率為：
圖5 CPU利用率
可見，仍然有idle的部分。因此，memcached的性能非常高，可以作為Web應用程序開發(fā)者放心地保存臨時數據或緩存數據的地方。
兼容應用程序
memcached的實現和協(xié)議都十分簡單，因此有很多與memcached兼容的實現。一些功能強大的擴展可以將memcached的內存數據寫到磁盤上，實現數據的持久性和冗余。連載第3次 介紹過，以后的memcached的存儲層將變成可擴展的（pluggable），逐漸支持這些功能。
這里介紹幾個與memcached兼容的應用程序。
- repcached
- 為memcached提供復制(replication)功能的patch。
- Flared
- 存儲到QDBM。同時實現了異步復制和fail over等功能。
- memcachedb
- 存儲到BerkleyDB。還實現了message queue。
- Tokyo Tyrant
- 將數據存儲到Tokyo Cabinet。不僅與memcached協(xié)議兼容，還能通過HTTP進行訪問。
Tokyo Tyrant案例
mixi使用了上述兼容應用程序中的Tokyo Tyrant。Tokyo Tyrant是平林開發(fā)的 Tokyo Cabinet DBM的網絡接口。它有自己的協(xié)議，但也擁有memcached兼容協(xié)議，也可以通過HTTP進行數據交換。Tokyo Cabinet雖然是一種將數據寫到磁盤的實現，但速度相當快。
mixi并沒有將Tokyo Tyrant作為緩存服務器，而是將它作為保存鍵值對組合的DBMS來使用。主要作為存儲用戶上次訪問時間的數據庫來使用。它與幾乎所有的mixi服務都有關，每次用戶訪問頁面時都要更新數據，因此負荷相當高。MySQL的處理十分笨重，單獨使用memcached保存數據又有可能會丟失數據，所以引入了Tokyo Tyrant。但無需重新開發(fā)客戶端，只需原封不動地使用Cache::Memcached::Fast即可，這也是優(yōu)點之一。關于Tokyo Tyrant的詳細信息，請參考本公司的開發(fā)blog。
總結
到本次為止，“memcached全面剖析”系列就結束了。我們介紹了memcached的基礎、內部結構、分散算法和應用等內容。讀完后如果您能對memcached產生興趣，就是我們的榮幸。關于mixi的系統(tǒng)、應用方面的信息，請參考本公司的開發(fā)blog。感謝您的閱讀。
為了方便閱讀，現將原來的翻譯結果打包成PDF文檔，下載。