下面是《memcached全面剖析》的第三部分。
發(fā)表日：2008/7/16
作者：前坂徹(Toru Maesaka)
原文鏈接：http://gihyo.jp/dev/feature/01/memcached/0003
memcached是緩存，所以數據不會永久保存在服務器上，這是向系統(tǒng)中引入memcached的前提。
本次介紹memcached的數據刪除機制，以及memcached的最新發(fā)展方向——二進制協(xié)議（Binary Protocol）
和外部引擎支持。
memcached在數據刪除方面有效利用資源
數據不會真正從memcached中消失
上次介紹過，
memcached不會釋放已分配的內存。記錄超時后，客戶端就無法再看見該記錄（invisible，透明），
其存儲空間即可重復使用。
Lazy Expiration
memcached內部不會監(jiān)視記錄是否過期，而是在get時查看記錄的時間戳，檢查記錄是否過期。
這種技術被稱為lazy（惰性）expiration。因此，memcached不會在過期監(jiān)視上耗費CPU時間。
LRU：從緩存中有效刪除數據的原理
memcached會優(yōu)先使用已超時的記錄的空間，但即使如此，也會發(fā)生追加新記錄時空間不足的情況，
此時就要使用名為 Least Recently Used（LRU）機制來分配空間。
顧名思義，這是刪除“最近最少使用”的記錄的機制。
因此，當memcached的內存空間不足時（無法從slab class
獲取到新的空間時），就從最近未被使用的記錄中搜索，并將其空間分配給新的記錄。
從緩存的實用角度來看，該模型十分理想。
不過，有些情況下LRU機制反倒會造成麻煩。memcached啟動時通過“-M”參數可以禁止LRU，如下所示：
$ memcached -M -m 1024
啟動時必須注意的是，小寫的“-m”選項是用來指定最大內存大小的。不指定具體數值則使用默認值64MB。
指定“-M”參數啟動后，內存用盡時memcached會返回錯誤。
話說回來，memcached畢竟不是存儲器，而是緩存，所以推薦使用LRU。
memcached的最新發(fā)展方向
memcached的roadmap上有兩個大的目標。一個是二進制協(xié)議的策劃和實現(xiàn)，另一個是外部引擎的加載功能。
關于二進制協(xié)議
使用二進制協(xié)議的理由是它不需要文本協(xié)議的解析處理，使得原本高速的memcached的性能更上一層樓，
還能減少文本協(xié)議的漏洞。目前已大部分實現(xiàn)，開發(fā)用的代碼庫中已包含了該功能。
memcached的下載頁面上有代碼庫的鏈接。
二進制協(xié)議的格式
協(xié)議的包為24字節(jié)的幀，其后面是鍵和無結構數據（Unstructured Data）。
實際的格式如下（引自協(xié)議文檔）：
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字節(jié)的頭部(HEADER)分為
請求頭（Request Header）和響應頭（Response Header）兩種。
頭部中包含了表示包的有效性的Magic字節(jié)、命令種類、鍵長度、值長度等信息，格式如下：
Request 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 | 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的二進制協(xié)議的代碼樹，
參考其中的docs文件夾中的protocol_binary.txt文檔。
HEADER中引人注目的地方
看到HEADER格式后我的感想是，鍵的上限太大了！現(xiàn)在的memcached規(guī)格中，鍵長度最大為250字節(jié)，
但二進制協(xié)議中鍵的大小用2字節(jié)表示。因此，理論上最大可使用65536字節(jié)（2<sup>16</sup>）長的鍵。
盡管250字節(jié)以上的鍵并不會太常用，二進制協(xié)議發(fā)布之后就可以使用巨大的鍵了。
二進制協(xié)議從下一版本1.3系列開始支持。
外部引擎支持
我去年曾經試驗性地將memcached的存儲層改造成了可擴展的（pluggable）。
MySQL的Brian Aker看到這個改造之后，就將代碼發(fā)到了memcached的郵件列表。
memcached的開發(fā)者也十分感興趣，就放到了roadmap中。現(xiàn)在由我和
memcached的開發(fā)者Trond Norbye協(xié)同開發(fā)（規(guī)格設計、實現(xiàn)和測試）。
和國外協(xié)同開發(fā)時時差是個大問題，但抱著相同的愿景，
最后終于可以將可擴展架構的原型公布了。
代碼庫可以從memcached的下載頁面
上訪問。
外部引擎支持的必要性
世界上有許多memcached的派生軟件，其理由是希望永久保存數據、實現(xiàn)數據冗余等，
即使犧牲一些性能也在所不惜。我在開發(fā)memcached之前，在mixi的研發(fā)部也曾經
考慮過重新發(fā)明memcached。
外部引擎的加載機制能封裝memcached的網絡功能、事件處理等復雜的處理。
因此，現(xiàn)階段通過強制手段或重新設計等方式使memcached和存儲引擎合作的困難
就會煙消云散，嘗試各種引擎就會變得輕而易舉了。
簡單API設計的成功的關鍵
該項目中我們最重視的是API設計。函數過多，會使引擎開發(fā)者感到麻煩；
過于復雜，實現(xiàn)引擎的門檻就會過高。因此，最初版本的接口函數只有13個。
具體內容限于篇幅，這里就省略了，僅說明一下引擎應當完成的操作：
- 引擎信息（版本等）
- 引擎初始化
- 引擎關閉
- 引擎的統(tǒng)計信息
- 在容量方面，測試給定記錄能否保存
- 為item（記錄）結構分配內存
- 釋放item（記錄）的內存
- 刪除記錄
- 保存記錄
- 回收記錄
- 更新記錄的時間戳
- 數學運算處理
- 數據的flush
對詳細規(guī)格有興趣的讀者，可以checkout engine項目的代碼，閱讀器中的engine.h。
重新審視現(xiàn)在的體系
memcached支持外部存儲的難點是，網絡和事件處理相關的代碼（核心服務器）與
內存存儲的代碼緊密關聯(lián)。這種現(xiàn)象也稱為tightly coupled（緊密耦合）。
必須將內存存儲的代碼從核心服務器中獨立出來，才能靈活地支持外部引擎。
因此，基于我們設計的API，memcached被重構成下面的樣子：
重構之后，我們與1.2.5版、二進制協(xié)議支持版等進行了性能對比，證實了它不會造成性能影響。
在考慮如何支持外部引擎加載時，讓memcached進行并行控制（concurrency control）的方案是最為容易的，
但是對于引擎而言，并行控制正是性能的真諦，因此我們采用了將多線程支持完全交給引擎的設計方案。
以后的改進，會使得memcached的應用范圍更為廣泛。
總結
本次介紹了memcached的超時原理、內部如何刪除數據等，在此之上又介紹了二進制協(xié)議和
外部引擎支持等memcached的最新發(fā)展方向。這些功能要到1.3版才會支持，敬請期待！
這是我在本連載中的最后一篇。感謝大家閱讀我的文章！
下次由長野來介紹memcached的應用知識和應用程序兼容性等內容。