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