歡迎來到Linux教程網
Linux教程網
Linux教程網
Linux教程網
Linux教程網 >> Linux基礎 >> Linux教程 >> memcached的刪除機制和發展方向

memcached的刪除機制和發展方向

日期:2017/2/27 16:00:26   编辑:Linux教程

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被重構成下面的樣子:

memcached-0003-001.png

重構之後,我們與1.2.5版、二進制協議支持版等進行了性能對比,證實了它不會造成性能影響。

在考慮如何支持外部引擎加載時,讓memcached進行並行控制(concurrency control)的方案是最為容易的, 但是對於引擎而言,並行控制正是性能的真谛,因此我們采用了將多線程支持完全交給引擎的設計方案。

以後的改進,會使得memcached的應用范圍更為廣泛。

總結

本次介紹了memcached的超時原理、內部如何刪除數據等,在此之上又介紹了二進制協議和 外部引擎支持等memcached的最新發展方向。這些功能要到1.3版才會支持,敬請期待!v

Copyright © Linux教程網 All Rights Reserved