1   Memcached簡介

1.1 什麼是Memcached

Memcached是一個高效能的分散式記憶體物件快取系統，用於動態Web應用以減輕資料庫負載。它通過在記憶體中快取資料和物件來減少讀取資料庫的次數，從而提供動態、資料庫驅動網站的速度。Memcached基於一個儲存鍵/值對的hashmap。其守護程序（daemon ）是用C寫的，但是客戶端可以用任何語言來編寫，並通過memcached協議與守護程序通訊。

Memcached是免費並且開源的。

1.2 Memcached主頁

http://memcached.org/

1.3 Memcached版本

最新版本為V1.4.15  

2013-09-03 釋出

1.4 Memcached License

BSD license

1.5 Memcached使用者

LiveJournal

Wikipedia

Flickr

Bebo

Twitter

Typepad

Yellowbot

Youtube

Digg

WordPress.com

Craigslist

Mixi

2   memcached的特徵

memcached作為高速執行的分散式快取伺服器，具有以下的特點。

• 協議簡單
• 基於libevent的事件處理
• 內建記憶體儲存方式
• memcached不互相通訊的分散式

2.1 協議簡單

memcached的伺服器客戶端通訊並不使用複雜的XML等格式， 而使用簡單的基於文字行的協議。因此，通過telnet 也能在memcached上儲存資料、取得資料。下面是例子。

$ telnet localhost 11211

Trying 127.0.0.1...

Connected to localhost.localdomain (127.0.0.1).

Escape character is '^]'.

set foo 0 0 3     （儲存命令）

bar               （資料）

STORED            （結果）

get foo           （取得命令）

VALUE foo 0 3     （資料）

bar               （資料）

2.2 基於libevent的事件處理

libevent是個程式庫，它將Linux的epoll、BSD類作業系統的kqueue等事件處理功能 封裝成統一的介面。即使對伺服器的連線數增加，也能發揮O(1)的效能。 memcached使用這個libevent庫，因此能在Linux、BSD、Solaris等作業系統上發揮其高效能。 關於事件處理這裡就不再詳細介紹，可以參考Dan Kegel的The C10K Problem。

2.3 內建記憶體儲存方式

為了提高效能，memcached中儲存的資料都儲存在memcached內建的記憶體儲存空間中。 由於資料僅存在於記憶體中，因此重啟memcached、重啟作業系統會導致全部資料消失。 另外，內容容量達到指定值之後，就基於LRU(Least Recently Used)演算法自動刪除不使用的快取。 memcached本身是為快取而設計的伺服器，因此並沒有過多考慮資料的永久性問題。 關於記憶體儲存的詳細資訊，本連載的第二講以後前阪會進行介紹，請屆時參考。

2.4 memcached不互相通訊的分散式

memcached儘管是“分散式”快取伺服器，但伺服器端並沒有分散式功能。 各個memcached不會互相通訊以共享資訊。那麼，怎樣進行分散式呢？ 這完全取決於客戶端的實現。本連載也將介紹memcached的分散式。

3   Memcached記憶體分配

Memcached預設情況下采用了名為Slab Allocator的機制分配、管理記憶體。 在該機制出現以前，記憶體的分配是通過對所有記錄簡單地進行malloc和free來進行的。 但是，這種方式會導致記憶體碎片，加重作業系統記憶體管理器的負擔，最壞的情況下， 會導致作業系統比memcached程序本身還慢。Slab Allocator就是為解決該問題而誕生的。

3.1 Slab Allocation的術語

Page

分配給Slab的記憶體空間，預設是1MB。分配給Slab之後根據slab的大小切分成chunk。

Ø  Chunk

用於快取記錄的記憶體空間。

Ø  Slab （Slab Class）

特定大小的chunk的組。

3.2 Slab Allocation機制

Slab Allocation的原理相當簡單。 將分配的記憶體(page)分割成各種尺寸的塊（chunk）， 並把尺寸相同的塊分成組（Slab,即chunk的集合）

Memcached的記憶體分配策略就是：按slab需求分配page，各slab按需使用chunk儲存。

這裡有幾個特點要注意，

1). Memcached分配出去的page不會被回收或者重新分配

2). Memcached申請的記憶體不會被釋放

3). slab空閒的chunk不會借給任何其他slab使用

3.2.1    Page為記憶體分配的最小單位

Memcached的記憶體分配以page為單位，預設情況下一個page是1M，可以通過-I引數在啟動時指定。如果需要申請記憶體時，memcached會劃分出一個新的page並分配給需要的slab區域。page一旦被分配在重啟前不會被回收或者重新分配（page ressign已經從1.2.8版移除了）

3.2.2    Slabs劃分資料空間

Memcached並不是將所有大小的資料都放在一起的，而是預先將資料空間劃分為一系列slabs，每個slab只負責一定範圍內的資料儲存。如下圖，每個slab只儲存大於其上一個slab的size並小於或者等於自己最大size的資料。例如：slab 3只儲存大小介於137 到 224 bytes的資料。如果一個數據大小為230byte將被分配到slab 4中。從下圖可以看出，每個slab負責的空間其實是不等的，memcached預設情況下下一個slab的最大值為前一個的1.25倍，這個可以通過修改-f引數來修改增長比例。

Slab Class 示意圖：

3.2.3    Chunk 才是儲存資料的單位

Chunk是一系列固定的記憶體空間，這個大小就是管理它的slab的最大存放大小。例如：slab 1的所有chunk都是104byte，而slab 4的所有chunk都是280byte。chunk是memcached實際存放快取資料的地方，因為chunk的大小固定為slab能夠存放的最大值，所以所有分配給當前slab的資料都可以被chunk存下。如果時間的資料大小小於chunk的大小，空餘的空間將會被閒置，這個是為了防止記憶體碎片而設計的。例如下圖，chunk size是224byte，而儲存的資料只有200byte，剩下的24byte將被閒置。

3.2.4    Page  Slab  Chunk 三者的關係

3.3 Slab中快取記錄的原理

下面說明memcached如何針對客戶端傳送的資料選擇slab並快取到chunk中。

memcached根據收到的資料的大小，選擇最適合資料大小的slab（圖2）。 memcached中儲存著slab內空閒chunk的列表，根據該列表選擇chunk，然後將資料緩存於其中。

3.4 Slab Allocator的缺點

Slab Allocator解決了當初的記憶體碎片問題，但新的機制也給memcached帶來了新的問題。

這個問題就是，由於分配的是特定長度的記憶體，因此無法有效利用分配的記憶體。例如，將100位元組的資料快取到128位元組的chunk中，剩餘的28位元組就浪費了。

對於該問題目前還沒有完美的解決方案，但在文件中記載了比較有效的解決方案。

3.5 使用Growth Factor進行調優

memcached在啟動時指定 Growth Factor因子（通過-f選項），就可以在某種程度上控制slab之間的差異。預設值為1.25。但是，在該選項出現之前，這個因子曾經固定為2，稱為“powers of 2”策略。

讓我們用以前的設定，以verbose模式啟動memcached試試看：

$ memcached -f 2 -vv

下面是啟動後的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，以獲得最恰當的設定。記憶體是珍貴的資源，浪費就太可惜了。

接下來介紹一下如何使用memcached的stats命令檢視slabs的利用率等各種各樣的資訊。

3.6 檢視memcached的內部狀態

memcached有個名為stats的命令，使用它可以獲得各種各樣的資訊。執行命令的方法很多，用telnet最為簡單：

$ telnet 主機名 埠號

連線到memcached之後，輸入stats再按回車，即可獲得包括資源利用率在內的各種資訊。 此外，輸入"stats slabs"或"stats items"還可以獲得關於快取記錄的資訊。 結束程式請輸入quit。

這些命令的詳細資訊可以參考memcached軟體包內的protocol.txt文件。

各項引數的解釋：

pid memcache伺服器的程序ID

uptime 伺服器已經執行的秒數

time 伺服器當前的unix時間戳

version memcache版本

pointer_size 當前OS的指標大小（32位系統一般是32bit）

rusage_user 程序的累計使用者時間

rusage_system 程序的累計系統時間

curr_items 伺服器當前儲存的items數量

total_items 從伺服器啟動以後儲存的items總數量

bytes 當前伺服器儲存items佔用的位元組數

curr_connections 當前開啟著的連線數

total_connections 從伺服器啟動以後曾經開啟過的連線數

connection_structures 伺服器分配的連線構造數

cmd_get get命令（獲取）總請求次數

cmd_set set命令（儲存）總請求次數

get_hits 總命中次數

get_misses 總未命中次數

evictions 為獲取空閒記憶體而刪除的items數（分配給memcache的空間用滿後需要刪除舊的items來得到空間分配給新的items）

bytes_read 總讀取位元組數（請求位元組數）

bytes_written 總髮送位元組數（結果位元組數）

limit_maxbytes 分配給memcache的記憶體大小（位元組）

threads 當前執行緒數

3.7 檢視slabs的使用狀況

4   Memcached記憶體複用

4.1 資料不會真正從memcached中消失

memcached不會釋放已分配的記憶體。記錄超時後，客戶端就無法再看見該記錄（invisible，透明）,其儲存空間即可重複使用。

memcached內部不會監視記錄是否過期，而是在get時檢視記錄的時間戳，檢查記錄是否過期。這種技術被稱為lazy（惰性）expiration。因此，memcached不會在過期監視上耗費CPU時間。

memcached會優先使用已超時的記錄的空間，但即使如此，也會發生追加新記錄時空間不足的情況，此時就要使用名為 Least Recently Used（LRU）機制來分配空間。 顧名思義，這是刪除“最近最少使用”的記錄的機制。 因此，當memcached的記憶體空間不足時（無法從slab class 獲取到新的空間時），就從最近未被使用的記錄中搜索，並將其空間分配給新的記錄。 從快取的實用角度來看，該模型十分理想。

但如果在監控Memcached發現，evictions 不為0的時候，說明LRU已經開始顯現作用了，已經有部分item被重寫掉了。如果大量資訊被重寫掉了，需要看一下是否設定的memcached的記憶體太小！

不過，有些情況下LRU機制反倒會造成麻煩。memcached啟動時通過“-M”引數可以禁止LRU，如下所示：

$ memcached -M -m 1024

啟動時必須注意的是，小寫的“-m”選項是用來指定最大記憶體大小的。不指定具體數值則使用預設值64MB。

指定“-M”引數啟動後，記憶體用盡時memcached會返回錯誤。但memcached畢竟不是儲存器，而是快取，所以推薦使用LRU。