共計 4722 個字符，預計需要花費 12 分鐘才能閱讀完成。

本篇文章為大家展示了如何分析 memcached 的刪除機制和發展方向，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

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 的下載頁面上有代碼庫的鏈接。

http://danga.com/memcached/download.bml

二進制協議的格式

協議的包為 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 中引人注目的地方

看到 HEADER 格式后我的感想是，鍵的上限太大了！現在的 memcached 規格中，鍵長度最大為 250 字節，但二進制協議中鍵的大小用 2 字節表示。因此，理論上最大可使用 65536 字節（2 sup 16 /sup）長的鍵。盡管 250 字節以上的鍵并不會太常用，二進制協議發布之后就可以使用巨大的鍵了。

二進制協議從下一版本 1.3 系列開始支持。

外部引擎支持

我去年曾經試驗性地將 memcached 的存儲層改造成了可擴展的（pluggable）。

http://alpha.mixi.co.jp/blog/?p=129

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 的刪除機制和發展方向，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注丸趣 TV 行業資訊頻道。