memcached全面剖析–3.memcached的刪除機制和發展方向_PHP教程

下面是《memcached全面剖析》的第三部分。

發表日：2008/7/16
作者：前阪徹(Toru Maesaka)
原文連結：http://gihyo.jp/dev/feature/01/memcached/0003

這個系列文章的連結在這裡：

• 第1次：http://www.phpchina.com/html/29/n-35329.html
• 第2次：http://www.phpchina.com/html/30/n-35330.html
• 第3次：http://www.phpchina.com/html/31/n-35331.html
• 第4次：http://www.phpchina.com/html/32/n-35332.html
• 第5次：http://www.phpchina.com/html/32/n-35333.html

• 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的下載頁面上有程式碼程式庫的連結。

• 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位元組（216）長的鍵。 儘管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的逾時原理、內部如何刪除資料等，在此之上又介紹了二進位協議和 外部引擎支援等memcached的最新發展方向。這些功能要到1.3版才會支援，敬請期待！

這是我在本連載中的最後一篇。感謝大家閱讀我的文章！

下次由長野來介紹memcached的應用知識和應用程式相容性等內容。

http://www.bkjia.com/PHPjc/735132.htmlwww.bkjia.comtruehttp://www.bkjia.com/PHPjc/735132.htmlTechArticle下面是《memcached全面剖析》的第三部分。 發表日：2008/7/16 作者：前阪徹(Toru Maesaka) 原文連結：http://gihyo.jp/dev/feature/01/memcached/0003 這個系列...

