Memcached原理分析

Memcached的內存管理方式

Memcached採用了名爲Slab Allocation的機制分配，管理內存。

Slab Allocation的原理至關簡單。將分配的內存分割成各類尺寸的塊（chucnk），並把尺寸相同的塊分紅組（chucnk的集合）如圖：



並且slab Allocation還有重複使用已分配內存的目的。也就是說，分配到的內存不會釋放，而是重複利用。
Slab Allocation 的主要術語

• Page :分配給Slab 的內存空間，默認是1MB。分配給Slab 以後根據slab 的大小切分紅chunk.
• Chunk : 用於緩存記錄的內存空間。
• Slab Class:特定大小的chunk 的組。

 

在Slab 中緩存記錄的原理

Memcached根據收到的數據的大小，選擇最合適數據大小的Slab (圖2) memcached中保存着slab內空閒chunk的列表，根據該列表選擇chunk,而後將數據緩存於其中。

 

 

Memcached在數據過時與刪除

Memcached內部不會監視記錄是否過時，而是在get此條記錄時查看其時間戳，檢查記錄是否過時。這種技術稱爲lazy expiration.所以memcached不會再過時監視上耗費CPU時間。

添加新數據時，Memcached會優先使用已超時的記錄空間，若是空間不足，此時就要使用名爲Least Recently Used (LRU最近最少使用)機制來分配空間。所以當memcached的內存空間不足時（沒法從slab class）獲取到新空間時，就從最近未使用的記錄中搜索，並將空間分配給新的記錄。

 

Memcached的分佈式原理

Memcached是經過客戶端來實現分佈式的，以新數據（鍵值對）的鍵經過必定的算法選擇一個服務器，保存在此服務器的Memcached中。

例如：

向memcached中添加「tokyo」。將「tokyo」傳給客戶端程序庫後，客戶端實現的算法就會根據「鍵」來決定保存數據的memcached服務器。服務器選定後，即命令它保存「tokyo」及其值。一樣，「kanagawa」「chiba」「saitama」「gunma」都是先選擇服務器再保存。接下來獲取保存的數據。獲取時也要將要獲取的鍵「tokyo」傳遞給函數庫。函數庫經過與數據保存時相同的算法，根據「鍵」選擇服務器。使用的算法相同，就能選中與保存時相同的服務器，而後發送get命令。只要數據沒有由於某些緣由被刪除，就能得到保存的值。

 
這樣，將不一樣的鍵保存到不一樣的服務器上，就實現了memcached的分佈式。 memcached服務器增多後，鍵就會分散，即便一臺memcached服務器發生故障沒法鏈接，也不會影響其餘的緩存，系統依然能繼續運行。