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