memcached全麵剖析–3.memcached的移除機制和發展方嚮
日期:2008-07-17 作者:喜騰小二 來源:PHPChina
版權宣告：可以任意轉載，但轉載時必須標明原作者charlee、原始連結http://tech.idv2.com/2008/07/16/memcached-003/以及本宣告。
下麵是《memcached全麵剖析》的第三部分。
發表日：2008/7/16
作者：前坂徹(Toru Maesaka)
原文連結：http://gihyo.jp/dev/feature/01/memcached/0003
- memcached在資料移除方麵有效利用資源
- 資料不會真正從memcached中消失
- Lazy Expiration
- LRU：從快取中有效移除資料的原理
- memcached的最新發展方嚮
- 關於二進位協定
- 二進位協定的格式
- HEADER中引人注目的地方
- 外部引擎支援
- 外部引擎支援的必要性
- 簡單API設計的成功的關鍵
- 重新審視現在的體係
- 總結
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。
memcached的最新發展方嚮
memcached的roadmap上有兩個大的目的。一個是二進位協定的策劃和實現，另一個是外部引擎的載入功能。
關於二進位協定
使用二進位協定的理由是它不需要文字協定的解析處理，使得原本高速的memcached的效能更上一層樓，還能減少文字協定的漏洞。目前已大部分實現，開發用的程式碼庫中已包含了該功能。 memcached的下載页面上有程式碼庫的連結。
二進位協定的格式
協定的包為24位元組的幀，其後麵是鍵和無結構資料（Unstructured Data）。實際的格式如下（引自協定文檔）：
Byte/ 0 | 1 | 2 | 3 |/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0/ HEADER /
/ /
/ /
/ /
+---------------+---------------+---------------+---------------+
24/ COMMAND-SPECIFIC EXTRAS (as needed) /
+/ (note length in th extras length header field) /
+---------------+---------------+---------------+---------------+
m/ Key (as needed) /
+/ (note length in key length header field) /
+---------------+---------------+---------------+---------------+
n/ Value (as needed) /
+/ (note length is total body length header field, minus /
+/ sum of the extras and key length body fields) /
+---------------+---------------+---------------+---------------+
Total 24 bytes
如上所示，包格式十分簡單。需要注意的是，占據了16位元組的頭部(HEADER)分為請求頭（Request Header）和回應頭（Response Header）兩種。頭部中包含了表示包的有效性的Magic位元組、指令種類、鍵長度、值長度等資訊，格式如下：
Request HeaderByte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0| Magic | Opcode | Key length |
+---------------+---------------+---------------+---------------+
4| Extras length | Data type | Reserved |
+---------------+---------------+---------------+---------------+
8| Total body length |
+---------------+---------------+---------------+---------------+
12| Opaque |
+---------------+---------------+---------------+---------------+
16| CAS |
| |
+---------------+---------------+---------------+---------------+Response Header
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0| Magic | Opcode | Key Length |
+---------------+---------------+---------------+---------------+
4| Extras length | Data type | Status |
+---------------+---------------+---------------+---------------+
8| Total body length |
+---------------+---------------+---------------+---------------+
12| Opaque |
+---------------+---------------+---------------+---------------+
16| CAS |
| |
+---------------+---------------+---------------+---------------+
如希望瞭解各個部分的詳細內容，可以checkout出memcached的二進位協定的程式碼樹，參考其中的docs檔案夾中的protocol_binary.txt文檔。
HEADER中引人注目的地方
看到HEADER格式後我的感想是，鍵的上限太大了！現在的memcached規格中，鍵長度最大為250位元組，但二進位協定中鍵的大小用2位元組表示。因此，理論上最大可使用65536位元組（216）長的鍵。儘管250位元組以上的鍵並不會太常用，二進位協定發佈之後就可以使用巨大的鍵了。
二進位協定從下一版本1.3係列開始支援。
外部引擎支援
我去年曾經試驗性地將memcached的存儲層改造成了可延伸的（pluggable）。
MySQL的Brian Aker看到這個改造之後，就將程式碼發到了memcached的郵件清單。 memcached的開發者也十分感興趣，就放到了roadmap中。現在由我和 memcached的開發者Trond Norbye協同開發（規格設計、實現和測試）。和國外協同開發時時差是個大問題，但抱着相同的願景，最後終於可以將可延伸架構的原型公佈了。程式碼庫可以從memcached的下載页面 上訪問。
外部引擎支援的必要性
世界上有許多memcached的派生軟體，其理由是希望永久儲存資料、實現資料冗餘等，即使犧牲一些效能也在所不惜。我在開發memcached之前，在mixi的研發部也曾經考慮過重新發明memcached。
外部引擎的載入機制能封裝memcached的網路功能、事件處理等復雜的處理。因此，現階段透過強制手段或重新設計等方式使memcached和存儲引擎合作的困難就會煙消雲散，嘗試各種引擎就會變得輕而易舉了。
簡單API設計的成功的關鍵
該項目中我們最重視的是API設計。函式過多，會使引擎開發者感到麻煩；過於復雜，實現引擎的門檻就會過高。因此，最初版本的介麵函式隻有13個。俱體內容限於篇幅，這裡就省略了，僅幫助一下引擎應當完成的操作：
- 引擎資訊（版本等）
- 引擎初始化
- 引擎關閉
- 引擎的統計資訊
- 在容量方麵，測試給定記錄能否儲存
- 為item（記錄）結構分配記憶體
- 釋放item（記錄）的記憶體
- 移除記錄
- 儲存記錄
- 回收記錄
- 更新記錄的時間戳
- 數學運算處理
- 資料的flush
對詳細規格有興趣的讀者，可以checkout engine項目的程式碼，閱讀器中的engine.h。
重新審視現在的體係
memcached支援外部存儲的難點是，網路和事件處理相關的程式碼（核心伺服器）與記憶體存儲的程式碼緊密關聯。這種現象也稱為tightly coupled（緊密耦合）。必須將記憶體存儲的程式碼從核心伺服器中獨立出來，才能靈活地支援外部引擎。因此，基於我們設計的API，memcached被重構成下麵的樣子：
重構之後，我們與1.2.5版、二進位協定支援版等進行了效能對比，證實了它不會造成效能影響。
在考慮如何支援外部引擎載入時，讓memcached進行並行控制（concurrency control）的方案是最為容易的，但是對於引擎而言，並行控制正是效能的真谛，因此我們采用了將多執行緒支援完全交給引擎的設計方案。
以後的改進，會使得memcached的應用範圍更為廣泛。
總結
本次介紹了memcached的逾時原理、內部如何移除資料等，在此之上又介紹了二進位協定和外部引擎支援等memcached的最新發展方嚮。這些功能要到1.3版才會支援，敬請期待！
這是我在本連載中的最後一篇。感謝大家閱讀我的文章！
下次由長野來介紹memcached的應用知識和應用程式相容性等內容。