MemCache超詳細解讀

MemCache是什麼

MemCache是一個自由、源碼開放、高性能、分佈式的分佈式內存對象緩存系統，用於動態Web應用以減輕數據庫的負載。它經過在內存中緩存數據和對象來減小讀取數據庫的次數，從而提升了網站訪問的速度。MemCaChe是一個存儲鍵值對的HashMap，在內存中對任意的數據（好比字符串、對象等）所使用的key-value存儲，數據能夠來自數據庫調用、API調用，或者頁面渲染的結果。MemCache設計理念就是小而強大，它簡單的設計促進了快速部署、易於開發並解決面對大規模的數據緩存的許多難題，而所開放的API使得MemCache能用於Java、C/C++/C#、Perl、Python、PHP、Ruby等大部分流行的程序語言。

另外，說一下MemCache和MemCached的區別：

一、MemCache是項目的名稱

二、MemCached是MemCache服務器端能夠執行文件的名稱

MemCache的官方網站爲http://memcached.org/

 

MemCache訪問模型

爲了加深理解，我模仿着原阿里技術專家李智慧老師《大型網站技術架構 核心原理與案例分析》一書MemCache部分，本身畫了一張圖：

特別澄清一個問題，MemCache雖然被稱爲"分佈式緩存"，可是MemCache自己徹底不具有分佈式的功能，MemCache集羣之間不會相互通訊（與之造成對比的，好比JBoss Cache，某臺服務器有緩存數據更新時，會通知集羣中其餘機器更新緩存或清除緩存數據），所謂的"分佈式"，徹底依賴於客戶端程序的實現，就像上面這張圖的流程同樣。

同時基於這張圖，理一下MemCache一次寫緩存的流程：

一、應用程序輸入須要寫緩存的數據

二、API將Key輸入路由算法模塊，路由算法根據Key和MemCache集羣服務器列表獲得一臺服務器編號

三、由服務器編號獲得MemCache及其的ip地址和端口號

四、API調用通訊模塊和指定編號的服務器通訊，將數據寫入該服務器，完成一次分佈式緩存的寫操做

讀緩存和寫緩存同樣，只要使用相同的路由算法和服務器列表，只要應用程序查詢的是相同的Key，MemCache客戶端老是訪問相同的客戶端去讀取數據，只要服務器中還緩存着該數據，就能保證緩存命中。

這種MemCache集羣的方式也是從分區容錯性的方面考慮的，假如Node2宕機了，那麼Node2上面存儲的數據都不可用了，此時因爲集羣中Node0和Node1還存在，下一次請求Node2中存儲的Key值的時候，確定是沒有命中的，這時先從數據庫中拿到要緩存的數據，而後路由算法模塊根據Key值在Node0和Node1中選取一個節點，把對應的數據放進去，這樣下一次就又能夠走緩存了，這種集羣的作法很好，可是缺點是成本比較大。

 

一致性Hash算法

從上面的圖中，能夠看出一個很重要的問題，就是對服務器集羣的管理，路由算法相當重要，就和負載均衡算法同樣，路由算法決定着究竟該訪問集羣中的哪臺服務器，先看一個簡單的路由算法。

一、餘數Hash

比方說，字符串str對應的HashCode是50、服務器的數目是3，取餘數獲得2，str對應節點Node2，因此路由算法把str路由到Node2服務器上。因爲HashCode隨機性比較強，因此使用餘數Hash路由算法就能夠保證緩存數據在整個MemCache服務器集羣中有比較均衡的分佈。

若是不考慮服務器集羣的伸縮性（什麼是伸縮性，請參見大型網站架構學習筆記），那麼餘數Hash算法幾乎能夠知足絕大多數的緩存路由需求，可是當分佈式緩存集羣須要擴容的時候，就難辦了。

就假設MemCache服務器集羣由3臺變爲4臺吧，更改服務器列表，仍然使用餘數Hash，50對4的餘數是2，對應Node2，可是str原來是存在Node1上的，這就致使了緩存沒有命中。若是這麼說不夠明白，那麼不妨舉個例子，原來有HashCode爲0~19的20個數據，那麼：

HashCode	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19
路由到的服務器	0	1	2	0	1	2	0	1	2	0	1	2	0	1	2	0	1	2	0	1

如今我擴容到4臺，加粗標紅的表示命中：

HashCode	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19
路由到的服務器	0	1	2	3	0	1	2	3	0	1	2	3	0	1	2	3	0	1	2	3

若是我擴容到20+的臺數，只有前三個HashCode對應的Key是命中的，也就是15%。固然這只是個簡單例子，現實狀況確定比這個複雜得多，不過足以說明，使用餘數Hash的路由算法，在擴容的時候會形成大量的數據沒法正確命中（其實不只僅是沒法命中，那些大量的沒法命中的數據還在原緩存中在被移除前佔據着內存）。這個結果顯然是沒法接受的，在網站業務中，大部分的業務數據度操做請求上事實上是經過緩存獲取的，只有少許讀操做會訪問數據庫，所以數據庫的負載能力是以有緩存爲前提而設計的。當大部分被緩存了的數據由於服務器擴容而不能正確讀取時，這些數據訪問的壓力就落在了數據庫的身上，這將大大超過數據庫的負載能力，嚴重的可能會致使數據庫宕機。

這個問題有解決方案，解決步驟爲：

（1）在網站訪問量低谷，一般是深夜，技術團隊加班，擴容、重啓服務器

（2）經過模擬請求的方式逐漸預熱緩存，使緩存服務器中的數據從新分佈

二、一致性Hash算法

一致性Hash算法經過一個叫作一致性Hash環的數據結構實現Key到緩存服務器的Hash映射，看一下我本身畫的一張圖：

具體算法過程爲：先構造一個長度爲232的整數環（這個環被稱爲一致性Hash環），根據節點名稱的Hash值（其分佈爲[0, 232-1]）將緩存服務器節點放置在這個Hash環上，而後根據須要緩存的數據的Key值計算獲得其Hash值（其分佈也爲[0, 232-1]），而後在Hash環上順時針查找距離這個Key值的Hash值最近的服務器節點，完成Key到服務器的映射查找。

就如同圖上所示，三個Node點分別位於Hash環上的三個位置，而後Key值根據其HashCode，在Hash環上有一個固定位置，位置固定下以後，Key就會順時針去尋找離它最近的一個Node，把數據存儲在這個Node的MemCache服務器中。使用Hash環若是加了一個節點會怎麼樣，看一下：

看到我加了一個Node4節點，隻影響到了一個Key值的數據，原本這個Key值應該是在Node1服務器上的，如今要去Node4了。採用一致性Hash算法，的確也會影響到整個集羣，可是影響的只是加粗的那一段而已，相比餘數Hash算法影響了遠超一半的影響率，這種影響要小得多。更重要的是，集羣中緩存服務器節點越多，增長節點帶來的影響越小，很好理解。換句話說，隨着集羣規模的增大，繼續命中原有緩存數據的機率會愈來愈大，雖然仍然有小部分數據緩存在服務器中不能被讀到，可是這個比例足夠小，即便訪問數據庫，也不會對數據庫形成致命的負載壓力。

至於具體應用，這個長度爲232的一致性Hash環一般使用二叉查找樹實現，至於二叉查找樹，就是算法的問題了，能夠本身去查詢相關資料。

 

MemCache實現原理

首先要說明一點，MemCache的數據存放在內存中，存放在內存中我的認爲意味着幾點：

一、訪問數據的速度比傳統的關係型數據庫要快，由於Oracle、MySQL這些傳統的關係型數據庫爲了保持數據的持久性，數據存放在硬盤中，IO操做速度慢

二、MemCache的數據存放在內存中同時意味着只要MemCache重啓了，數據就會消失

三、既然MemCache的數據存放在內存中，那麼勢必受到機器位數的限制，這個以前的文章寫過不少次了，32位機器最多隻能使用2GB的內存空間，64位機器能夠認爲沒有上限

而後咱們來看一下MemCache的原理，MemCache最重要的莫不是內存分配的內容了，MemCache採用的內存分配方式是固定空間分配，仍是本身畫一張圖說明：

這張圖片裏面涉及了slab_class、slab、page、chunk四個概念，它們之間的關係是：

一、MemCache將內存空間分爲一組slab

二、每一個slab下又有若干個page，每一個page默認是1M，若是一個slab佔用100M內存的話，那麼這個slab下應該有100個page

三、每一個page裏面包含一組chunk，chunk是真正存放數據的地方，同一個slab裏面的chunk的大小是固定的

四、有相同大小chunk的slab被組織在一塊兒，稱爲slab_class

MemCache內存分配的方式稱爲allocator，slab的數量是有限的，幾個、十幾個或者幾十個，這個和啓動參數的配置相關。

MemCache中的value過來存放的地方是由value的大小決定的，value老是會被存放到與chunk大小最接近的一個slab中，好比slab[1]的chunk大小爲80字節、slab[2]的chunk大小爲100字節、slab[3]的chunk大小爲128字節（相鄰slab內的chunk基本以1.25爲比例進行增加，MemCache啓動時能夠用-f指定這個比例），那麼過來一個88字節的value，這個value將被放到2號slab中。放slab的時候，首先slab要申請內存，申請內存是以page爲單位的，因此在放入第一個數據的時候，不管大小爲多少，都會有1M大小的page被分配給該slab。申請到page後，slab會將這個page的內存按chunk的大小進行切分，這樣就變成了一個chunk數組，最後從這個chunk數組中選擇一個用於存儲數據。

若是這個slab中沒有chunk能夠分配了怎麼辦，若是MemCache啓動沒有追加-M（禁止LRU，這種狀況下內存不夠會報Out Of Memory錯誤），那麼MemCache會把這個slab中最近最少使用的chunk中的數據清理掉，而後放上最新的數據。針對MemCache的內存分配及回收算法，總結三點：

一、MemCache的內存分配chunk裏面會有內存浪費，88字節的value分配在128字節（緊接着大的用）的chunk中，就損失了30字節，可是這也避免了管理內存碎片的問題

二、MemCache的LRU算法不是針對全局的，是針對slab的

三、應該能夠理解爲何MemCache存放的value大小是限制的，由於一個新數據過來，slab會先以page爲單位申請一塊內存，申請的內存最多就只有1M，因此value大小天然不能大於1M了

 

再總結MemCache的特性和限制

上面已經對於MemCache作了一個比較詳細的解讀，這裏再次總結MemCache的限制和特性：

一、MemCache中能夠保存的item數據量是沒有限制的，只要內存足夠

二、MemCache單進程在32位機中最大使用內存爲2G，這個以前的文章提了屢次了，64位機則沒有限制

三、Key最大爲250個字節，超過該長度沒法存儲

四、單個item最大數據是1MB，超過1MB的數據不予存儲

五、MemCache服務端是不安全的，好比已知某個MemCache節點，能夠直接telnet過去，並經過flush_all讓已經存在的鍵值對當即失效

六、不可以遍歷MemCache中全部的item，由於這個操做的速度相對緩慢且會阻塞其餘的操做

七、MemCache的高性能源自於兩階段哈希結構：第一階段在客戶端，經過Hash算法根據Key值算出一個節點；第二階段在服務端，經過一個內部的Hash算法，查找真正的item並返回給客戶端。從實現的角度看，MemCache是一個非阻塞的、基於事件的服務器程序

八、MemCache設置添加某一個Key值的時候，傳入expiry爲0表示這個Key值永久有效，這個Key值也會在30天以後失效，見memcache.c的源代碼：

#define REALTIME_MAXDELTA 60*60*24*30
static rel_time_t realtime(const time_t exptime) {
       if (exptime == 0) return 0;
       if (exptime > REALTIME_MAXDELTA) {                       
              if (exptime <= process_started)                         
                      return (rel_time_t)1;                                 
              return (rel_time_t)(exptime - process_started);  
       } else {                                                                  
              return (rel_time_t)(exptime + current_time);     
       }
}

這個失效的時間是memcache源碼裏面寫的，開發者沒有辦法改變MemCache的Key值失效時間爲30天這個限制

 

MemCache指令彙總

上面說過，已知MemCache的某個節點，直接telnet過去，就可使用各類命令操做MemCache了，下面看下MemCache有哪幾種命令：

命    令	做    用
get	返回Key對應的Value值
add	添加一個Key值，沒有則添加成功並提示STORED，有則失敗並提示NOT_STORED
set	無條件地設置一個Key值，沒有就增長，有就覆蓋，操做成功提示STORED
replace	按照相應的Key值替換數據，若是Key值不存在則會操做失敗
stats	返回MemCache通用統計信息（下面有詳細解讀）
stats items	返回各個slab中item的數目和最老的item的年齡（最後一次訪問距離如今的秒數）
stats slabs	返回MemCache運行期間建立的每一個slab的信息（下面有詳細解讀）
version	返回當前MemCache版本號
flush_all	清空全部鍵值，但不會刪除items，因此此時MemCache依舊佔用內存
quit	關閉鏈接

 

stats指令解讀

stats是一個比較重要的指令，用於列出當前MemCache服務器的狀態，拿一組數據舉個例子：

STAT pid 1023
STAT uptime 21069937
STAT time 1447235954
STAT version 1.4.5
STAT pointer_size 64
STAT rusage_user 1167.020934
STAT rusage_system 3346.933170
STAT curr_connections 29
STAT total_connections 21
STAT connection_structures 49
STAT cmd_get 49
STAT cmd_set 7458
STAT cmd_flush 0
STAT get_hits 7401
STAT get_misses 57
..（delete、incr、decr、cas的hits和misses數，cas還多一個badval）
STAT auth_cmds 0
STAT auth_errors 0
STAT bytes_read 22026555
STAT bytes_written 8930466
STAT limit_maxbytes 4134304000
STAT accepting_conns 1
STAT listen_disabled_num 0
STAT threads 4
STAT bytes 151255336
STAT current_items 57146
STAT total_items 580656
STAT evicitions 0

這些參數反映着MemCache服務器的基本信息，它們的意思是：

參  數  名	做      用
pid	MemCache服務器的進程id
uptime	服務器已經運行的秒數
time	服務器當前的UNIX時間戳
version	MemCache版本
pointer_size	當前操做系統指針大小，反映了操做系統的位數，64意味着MemCache服務器是64位的
rusage_user	進程的累計用戶時間
rusage_system	進程的累計系統時間
curr_connections	當前打開着的鏈接數
total_connections	當服務器啓動之後曾經打開過的鏈接數
connection_structures	服務器分配的鏈接構造數
cmd_get	get命令總請求次數
cmd_set	set命令總請求次數
cmd_flush	flush_all命令總請求次數
get_hits	總命中次數，重要，緩存最重要的參數就是緩存命中率，以get_hits / (get_hits + get_misses)表示，好比這個緩存命中率就是99.2%
get_misses	總未命中次數
auth_cmds	認證命令的處理次數
auth_errors	認證失敗的處理次數
bytes_read	總讀取的字節數
bytes_written	總髮送的字節數
limit_maxbytes	分配給MemCache的內存大小（單位爲字節）
accepting_conns	是否已經達到鏈接的最大值，1表示達到，0表示未達到
listen_disabled_num	統計當前服務器鏈接數曾經達到最大鏈接的次數，這個次數應該爲0或者接近於0，若是這個數字不斷增加， 就要當心咱們的服務了
threads	當前MemCache總線程數，因爲MemCache的線程是基於事件驅動機制的，所以不會一個線程對應一個用戶請求
bytes	當前服務器存儲的items總字節數
current_items	當前服務器存儲的items總數量
total_items	自服務器啓動之後存儲的items總數量

 

stats slab指令解讀

若是對上面的MemCache存儲機制比較理解了，那麼咱們來看一下各個slab中的信息，仍是拿一組數據舉個例子：

1 STAT1:chunk_size 96
 2 ...
 3 STAT 2:chunk_size 144
 4 STAT 2:chunks_per_page 7281
 5 STAT 2:total_pages 7
 6 STAT 2:total_chunks 50967
 7 STAT 2:used_chunks 45197
 8 STAT 2:free_chunks 1
 9 STAT 2:free_chunks_end 5769
10 STAT 2:mem_requested 6084638
11 STAT 2:get_hits 48084
12 STAT 2:cmd_set 59588271
13 STAT 2:delete_hits 0
14 STAT 2:incr_hits 0
15 STAT 2:decr_hits 0
16 STAT 2:cas_hits 0
17 STAT 2:cas_badval 0
18 ...
19 STAT 3:chunk_size 216
20 ...

首先看到，第二個slab的chunk_size（144）/第一個slab的chunk_size（96）=1.5，第三個slab的chunk_size（216）/第二個slab的chunk_size（144）=1.5，能夠肯定這個MemCache的增加因子是1.5，chunk_size以1.5倍增加。而後解釋下字段的含義：

參  數  名	做      用
chunk_size	當前slab每一個chunk的大小，單位爲字節
chunks_per_page	每一個page能夠存放的chunk數目，因爲每一個page固定爲1M即1024*1024字節，因此這個值就是（1024*1024/chunk_size）
total_pages	分配給當前slab的page總數
total_chunks	當前slab最多可以存放的chunk數，這個值是total_pages*chunks_per_page
used_chunks	已經被分配給存儲對象的chunks數目
free_chunks	曾經被使用過可是由於過時而被回收的chunk數
free_chunks_end	新分配但尚未被使用的chunk數，這個值不爲0則說明當前slab歷來沒有出現過容量不夠的時候
mem_requested	當前slab中被請求用來存儲數據的內存空間字節總數，（total_chunks*chunk_size）-mem_requested表示有多少內存在當前slab中是被閒置的，這包括未用的slab+使用的slab中浪費的內存
get_hits	當前slab中命中的get請求數
cmd_set	當前slab中接收的全部set命令請求數
delete_hits	當前slab中命中的delete請求數
incr_hits	當前slab中命中的incr請求數
decr_hits	當前slab中命中的decr請求數
cas_hits	當前slab中命中的cas請求數
cas_badval	當前slab中命中可是更新失敗的cas請求數

看到這個命令的輸出量很大，全部信息都頗有做用。舉個例子吧，好比第一個slab中使用的chunks不多，第二個slab中使用的chunks不少，這時就能夠考慮適當增大MemCache的增加因子了，讓一部分數據落到第一個slab中去，適當平衡兩個slab中的內存，避免空間浪費。

 

MemCache的Java實現實例

講了這麼多，做爲一個Java程序員，怎麼能不寫寫MemCache的客戶端的實現呢？MemCache的客戶端有不少第三方jar包提供了實現，其中比較好的當屬XMemCached了，XMemCached具備效率高、IO非阻塞、資源耗費少、支持完整的協議、容許設置節點權重、容許動態增刪節點、支持JMX、支持與Spring框架集成、使用鏈接池、可擴展性好等諸多優勢，於是被普遍使用。這裏利用XMemCache寫一個簡單的MemCache客戶單實例，也沒有驗證過，純屬拋磚引玉：

public class MemCacheManager
{
    private static MemCacheManager instance = new MemCacheManager();
    
    /** XMemCache容許開發者經過設置節點權重來調節MemCache的負載，設置的權重越高，該MemCache節點存儲的數據越多，負載越大 */
    private static MemcachedClientBuilder mcb = 
            new XMemcachedClientBuilder(AddrUtil.getAddresses("127.0.0.1:11211 127.0.0.2:11211 127.0.0.3:11211"), new int[]{1, 3, 5});
    private static MemcachedClient mc = null;
    
    /** 初始化加載客戶端MemCache信息 */
    static
    {
        mcb.setCommandFactory(new BinaryCommandFactory()); // 使用二進制文件
        mcb.setConnectionPoolSize(10); // 鏈接池個數，即客戶端個數
        try
        {
            mc = mcb.build();
        }
        catch (IOException e)
        {
            e.printStackTrace();
        }
        
    }
    
    private MemCacheManager()
    {
        
    }
    
    public MemCacheManager getInstance()
    {
        return instance;
    }
    
    /** 向MemCache服務器設置數據 */
    public void set(String key, int expiry, Object obj) throws Exception
    {
        mc.set(key, expiry, obj);
    }
    
    /** 從MemCache服務器獲取數據 */
    public Object get(String key) throws Exception
    {
        return mc.get(key);
    }
    
    /**
     * MemCache經過compare and set即cas協議實現原子更新，相似樂觀鎖，每次請求存儲某個數據都要附帶一個cas值，MemCache
     * 比對這個cas值與當前存儲數據的cas值是否相等，若是相等就覆蓋老數據，若是不相等就認爲更新失敗，這在併發環境下特別有用
     */
    public boolean update(String key, Integer i) throws Exception
    {
        GetsResponse<Integer> result = mc.gets(key);
        long cas = result.getCas();
        // 嘗試更新key對應的value
        if (!mc.cas(key, 0, i, cas))
        {
            return false;
        }
        return true;
    }
}

 

================================================================================== 

我不能保證寫的每一個地方都是對的，可是至少能保證不復制、不黏貼，保證每一句話、每一行代碼都通過了認真的推敲、仔細的斟酌。每一篇文章的背後，但願都能看到本身對於技術、對於生活的態度。

我相信喬布斯說的，只有那些瘋狂到認爲本身能夠改變世界的人才能真正地改變世界。面對壓力，我能夠挑燈夜戰、不眠不休；面對困難，我願意迎難而上、永不退縮。

其實我想說的是，我只是一個程序員，這就是我如今純粹人生的所有。