memcached簡單學習

分布式緩存出于如下考慮，首先是緩存本身的水準線性擴充問題，其次是緩存大并發下的本身的性能問題，再次避免緩存的單點故障問題(多副本和副本一緻性)。分布式緩存的核心技術包括首先是記憶體本身的管理問題，包括了記憶體的配置設定，管理和回收機制。其次是分布式管理和分布式算法，其次是緩存鍵值管理和路由。

什麼是Memcached

許多Web 應用程式都将資料儲存到RDBMS中，應用伺服器從中讀取資料并在浏覽器中顯示。但随着資料量的增大，通路的集中，就會出現REBMS的負擔加重，資料庫響應惡化，網站顯示延遲等重大影響。Memcached是高性能的分布式記憶體緩存伺服器。一般的使用目的是通過緩存資料庫查詢結果，減少資料庫的通路次數，以提高動态Web 應用的速度、提高擴充性。如圖：

Memcached作為高速運作的分布式緩存伺服器具有以下特點。

協定簡單：memcached的伺服器用戶端通信并不使用複雜的MXL等格式，而是使用簡單的基于文本的協定。

基于libevent的事件處理：libevent是個程式庫，他将Linux 的epoll、BSD類作業系統的kqueue等時間處理功能封裝成統一的接口。memcached使用這個libevent庫，是以能在Linux、BSD、Solaris等作業系統上發揮其高性能。

内置記憶體存儲方式：為了提高性能，memcached中儲存的資料都存儲在memcached内置的記憶體存儲空間中。由于資料僅存在于記憶體中，是以重新開機memcached，重新開機作業系統會導緻全部資料消失。另外，内容容量達到指定的值之後memcached回自動删除不适用的緩存。

Memcached不互通信的分布式：memcached盡管是“分布式”緩存伺服器，但伺服器端并沒有分布式功能。各個memcached不會互相通信以共享資訊。他的分布式主要是通過用戶端實作的。

Memcached的記憶體管理

最近的memcached預設情況下采用了名為Slab Allocatoion的機制配置設定，管理記憶體。在改機制出現以前，記憶體的配置設定是通過對所有記錄簡單地進行malloc和free來進行的。但是這中方式會導緻記憶體碎片，加重作業系統記憶體管理器的負擔。

Slab Allocator的基本原理是按照預先規定的大小，将配置設定的記憶體分割成特定長度的塊，已完全解決記憶體碎片問題。Slab Allocation  的原理相當簡單。将配置設定的記憶體分割成各種尺寸的塊（chucnk），并把尺寸相同的塊分成組（chucnk的集合）如圖：

<a href="http://s3.51cto.com/wyfs02/M02/43/75/wKioL1PbIK-Ryvq0AAEJhSePlkI374.jpg" target="_blank"></a>

而且slab allocator 還有重複使用已配置設定記憶體的目的。也就是說，配置設定到的記憶體不會釋放，而是重複利用。

Slab Allocation 的主要術語

Page :配置設定給Slab 的記憶體空間，預設是1MB。配置設定給Slab 之後根據slab 的大小切分成chunk.

Chunk : 用于緩存記錄的記憶體空間。

Slab Class:特定大小的chunk 的組。

在Slab 中緩存記錄的原理

Memcached根據收到的資料的大小，選擇最合适資料大小的Slab (圖2) memcached中儲存着slab内空閑chunk的清單，根據該清單選擇chunk,然後将資料緩存于其中。

<a href="http://s3.51cto.com/wyfs02/M01/43/75/wKiom1PbH6KTAko4AAB8W65Sl94768.jpg" target="_blank"></a>

Memcached在資料删除方面有效裡利用資源

Memcached删除資料時資料不會真正從memcached中消失。Memcached不會釋放已配置設定的記憶體。記錄逾時後，用戶端就無法再看見該記錄（invisible 透明），其存儲空間即可重複使用。

Lazy Expriationmemcached内部不會監視記錄是否過期，而是在get時檢視記錄的時間戳，檢查記錄是否過期。這種技術稱為lazy expiration.是以memcached不會再過期監視上耗費CPU時間。

對于緩存存儲容量滿的情況下的删除需要考慮多種機制，一方面是按隊列機制，一方面應該對應緩存對象本身的優先級，根據緩存對象的優先級進行對象的删除。

LRU:從緩存中有效删除資料的原理

Memcached會優先使用已逾時的記錄空間，但即使如此，也會發生追加新紀錄時空間不足的情況。此時就要使用名為Least Recently Used (LRU)機制來配置設定空間。這就是删除最少使用的記錄的機制。是以當memcached的記憶體空間不足時（無法從slab class）擷取到新空間時，就從最近未使用的記錄中搜尋，并将空間配置設定給新的記錄。

Memcached分布式

Memcached雖然稱為“分布式“緩存伺服器，但伺服器端并沒有“分布式”的功能。Memcached的分布式完全是有用戶端實作的。現在我們就看一下memcached是怎麼實作分布式緩存的。

例如下面假設memcached伺服器有node1～node3三台，應用程式要儲存鍵名為“tokyo”“kanagawa”“chiba”“saitama”“gunma” 的資料。

首先向memcached中添加“tokyo”。将“tokyo”傳給用戶端程式庫後，用戶端實作的算法就會根據“鍵”來決定儲存資料的memcached伺服器。伺服器標明後，即指令它儲存“tokyo”及其值。

同樣，“kanagawa”“chiba”“saitama”“gunma”都是先選擇伺服器再儲存。

接下來擷取儲存的資料。擷取時也要将要擷取的鍵“tokyo”傳遞給函數庫。函數庫通過與資料儲存時相同的算法，根據“鍵”選擇伺服器。使用的算法相同，就能選中與儲存時相同的伺服器，然後發送get指令。隻要資料沒有因為某些原因被删除，就能獲得儲存的值。

這樣，将不同的鍵儲存到不同的伺服器上，就實作了memcached的分布式。 memcached伺服器增多後，鍵就會分散，即使一台memcached伺服器發生故障無法連接配接，也不會影響其他的緩存，系統依然能繼續運作。

Consistent Hashing的簡單說明

Consistent Hashing如下所示：首先求出memcached伺服器（節點）的哈希值， 并将其配置到0～232的圓（continuum）上。 然後用同樣的方法求出存儲資料的鍵的哈希值，并映射到圓上。 然後從資料映射到的位置開始順時針查找，将資料儲存到找到的第一個伺服器上。 如果超過232仍然找不到伺服器，就會儲存到第一台memcached伺服器上。

<a href="http://s3.51cto.com/wyfs02/M01/43/75/wKiom1PbH8CzYgCNAAGVKzrpETo981.jpg" target="_blank"></a>

從上圖的狀态中添加一台memcached伺服器。餘數分布式算法由于儲存鍵的伺服器會發生巨大變化 而影響緩存的命中率，但Consistent Hashing中，隻有在continuum上增加伺服器的地點逆時針方向的 第一台伺服器上的鍵會受到影響。

<a href="http://s3.51cto.com/wyfs02/M00/43/75/wKioL1PbIPWigXPCAAGVKzrpETo878.jpg" target="_blank"></a>

是以，Consistent Hashing最大限度地抑制了鍵的重新分布。 而且，有的Consistent Hashing的實作方法還采用了虛拟節點的思想。 使用一般的hash函數的話，伺服器的映射地點的分布非常不均勻。 是以，使用虛拟節點的思想，為每個實體節點（伺服器） 在continuum上配置設定100～200個點。這樣就能抑制分布不均勻， 最大限度地減小伺服器增減時的緩存重新分布。

緩存多副本

緩存多副本主要是用于在緩存資料存放時存儲緩存資料的多個副本，以防止緩存失效。緩存失效發生在以下幾種情況：

1. 

 緩存逾時被移除（正常失效）

2. 

 緩存由于存儲空間限制被移除（異常失效）

3. 

 由于緩存節點變化而導緻的緩存失效（異常失效）

在緩存多副本的情況下，需要重新考慮緩存的分布式分布政策。其次緩存的多個副本實際本身是可能的多個讀的節點，可以做為分布式的并行讀，這是另外一個可以考慮的問題。

緩存資料的一緻性問題

緩存資料盡量隻讀，是以緩存本身是不适合大量寫和更新操作的資料場景的。對于讀的情況下，如果存在資料變化，一種是同時更新緩存和資料庫。一種是直接對緩存資料進行失效處理。

參考：

可從以下幾方面考慮優化

1. 重新設定配置參數。

2. 盡量使用小容量的資料内容.

3. 增加memcached提高服務擷取的記憶體總量、提高命中率。

4. 可以采用多個memcache服務進行偵聽,分開處理,針對服務提供的頻繁度劃分服務記憶體

5. 根據伺服器的性能不同設定權重 weights

6. 對需要使用memcache服務的機器ip,服務端做通路限制。

避免memcached裡的資料不會被别有心意的人再利用，或責保證伺服器的記憶體不被漫天遍地的垃圾資料所堆積,造成命中極低

7. 優化memcached用戶端的代碼。

     本文轉自韓立偉 51CTO部落格，原文連結：http://blog.51cto.com/hanchaohan/1532929，如需轉載請自行聯系原作者