MemCache超詳細解讀

jopen 9年前發布 | 14K 次閱讀 Memcache

MemCache是什么

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

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

1、MemCache是項目的名稱

2、MemCached是MemCache服務器端可以執行文件的名稱

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

MemCache訪問模型

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

MemCache超詳細解讀

特別澄清一個問題， MemCache雖然被稱為"分布式緩存"，但是MemCache本身完全不具備分布式的功能，MemCache集群之間不會相互通信（與之形成對比的，比如JBoss Cache，某臺服務器有緩存數據更新時，會通知集群中其他機器更新緩存或清除緩存數據），所謂的"分布式"，完全依賴于客戶端程序的實現，就像上面這張圖的流程一樣。

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

1、應用程序輸入需要寫緩存的數據

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

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

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

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

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

一致性Hash算法

從上面的圖中，可以看出一個很重要的問題，就是對服務器集群的管理，路由算法至關重要，就和負載均衡算法一樣，路由算法決定著究竟該訪問集群中的哪臺服務器，先看一個簡單的路由算法。

1、余數Hash

比方說，字符串str對應的HashCode是50、服務器的數目是3，取余數得到1，str對應節點Node1，所以路由算法把str路由到Node1服務器上。由于HashCode隨機性比較強，所以使用余數Hash路由算法就可以保證緩存數據在整個MemCache服務器集群中有比較均衡的分布。

如果不考慮服務器集群的伸縮性（什么是伸縮性，請參見大型網站架構學習筆記），那么余數Hash算法幾乎可以滿足絕大多數的緩存路由需求，但是當分布式緩存集群需要擴容的時候，就難辦了。

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

</tr>

</tr> </tbody> </table>

現在我擴容到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	0	1	2	0	1	2	0	1	2	0	1	2	0	1	2	0	1

</tr>

</tr> </tbody> </table>

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

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

（1）在網站訪問量低估，通常是深夜，技術團隊加班，擴容、重啟服務器

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

2、一致性Hash算法

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

MemCache超詳細解讀

具體算法過程為：先構造一個長度為2 ³² 的整數環（這個環被稱為一致性Hash環），根據節點名稱的Hash值（其分布為[0, 2 ³² -1]）將緩存服務器節點放置在這個Hash環上，然后根據需要緩存的數據的Key值計算得到其Hash值（其分布也為[0, 2 ³² -1]），然后在Hash環上順時針查找舉例這個Key值的Hash值最近的服務器節點，完成Key到服務器的映射查找。

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

MemCache超詳細解讀

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

至于具體應用，這個長度為2 ³² 的一致性Hash環通常使用二叉查找樹實現，至于二叉查找樹，就是算法的問題了，可以自己去查詢相關資料。

MemCache實現原理

首先要說明一點，MemCache的數據存放在內存中，存放在內存中個人認為意味著幾點：

1、訪問數據的速度比傳統的關系型數據庫要快，因為Oracle、MySQL這些傳統的關系型數據庫為了保持數據的持久性，數據存放在硬盤中，IO操作速度慢

2、MemCache的數據存放在內存中同時意味著只要MemCache重啟了，數據就會消失

3、既然MemCache的數據存放在內存中，那么勢必受到機器位數的限制，這個之前的文章寫過很多次了，32位機器最多只能使用2GB的內存空間，64位機器沒有上限

然后我們來看一下MemCache的原理，MemCache最重要的莫不是內存分配的內容了，MemCache采用的內存分配方式是固定空間分配，還是自己畫一張圖說明：

MemCache超詳細解讀

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

1、MemCache將內存空間分為一組slab

2、每個slab下又有若干個page，每個page默認是1M，如果一個slab占用100M內存的話，那么這個slab下應該有100個page

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

4、有相同大小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將被放到1號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的內存分配及回收算法，總結三點：

1、MemCache的內存分配chunk里面會有內存浪費，88字節的value分配在80自己的chunk中，就損失了8字節，但是這也避免了管理內存碎片的問題

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

3、應該可以理解為什么MemCache存放的value大小是限制的，因為一個新數據過來，slab會先以page為單位申請一塊內存，申請的內存最多就只有1M，所以value大小自然不能大于1M了

再總結MemCache的特性和限制

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

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

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

3、Key最大為250個字節，超過該長度無法存儲

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

5、MemCache服務端是不安全的，比如已知某個MemCache節點，可以直接telnet過去，并通過flush_all讓已經存在的鍵值對立即失效

6、不能夠遍歷MemCache中所有的item，因為這個操作的速度相對緩慢且會阻塞其他的操作

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

8、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有哪幾種命令：

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

</tr>

</tr> </tbody> </table>

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服務器的基本信息，它們的意思是：

命令	作用
get	返回Key對應的Value值
add	無條件地設置一個Key值，沒有就增加，有就覆蓋
set	按照相應的Key值添加數據，如果Key已經存在則會操作失敗
replace	按照相應的Key值替換數據，如果Key值不存在則會操作失敗
stats	返回MemCache通用統計信息（下面有詳細解讀）
stats items	返回各個slab中item的數目和最老的item的年齡（最后一次訪問距離現在的秒數）
stats slabs	返回MemCache運行期間創建的每個slab的信息（下面有詳細解讀）
version	返回當前MemCache版本號
flush_all	清空所有鍵值，但不會刪除items，所以此時MemCache依舊占用內存
quit	關閉連接

</tr>

</tr> </tbody> </table>

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倍增長。然后解釋下字段的含義：

參數名	作用
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總數量

</tr>

</tr> </tbody> </table>

看到這個命令的輸出量很大，所有信息都很有作用。舉個例子吧，比如第一個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;
}

}</pre>原文 http://www.cnblogs.com/xrq730/p/4948707.html
                    
                    
                         本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
                         轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
                         本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！
                         本文地址：http://www.baiduhome.net/lib/view/open1447394935772.html
                         Memcache
                    

                
                
                    
                        相關經驗
                        
  MemCache超詳細解讀
   C++指針的概念解讀 超詳細
   Ehcache詳細解讀
   Ehcache詳細解讀
   Memcache 詳細介紹
                         
                    
                    
                        相關資訊
                        
  Docker 1.9新特性解讀
   Docker CEO帶你解讀Docker
   解讀 Android 4.2 Jelly Bean 新特性
   聽Awcloud CTO李華解讀OpenStack
   Facebook員工解讀：看上WhatsApp哪兒了？
                         
                    
                    
                        相關文檔
                        
   Maven 的超詳細幫助文檔
    Memcache 的使用
    VS 2010發布、打包安裝程序(超全超詳細)
    深入了解memcache
    Palantir解讀
    Palantir 產品技術解讀
    超詳細wordpress_主題教程：從零開始制作
    weka中文詳細教程
    vsftp配置大全(超完整版)
                         
                    

                    目錄
                
            
        
      


    
      
        
          社區
            項目
問答
文庫
代碼
經驗
資訊
          安卓開發專欄
開發者周刊
Android Studio 使用推薦
Android開發推薦
        

        
          幫助中心
          文檔上傳須知
          關于我們
          關于深度開源
免責聲明
聯系我們
        
        © 2006-2019 深度開源 —— 開源項目,開源代碼,開源文檔,開源新聞,開源社區  杭州精創信息技術有限公司  

  浙公網安備 33018302001163 號  浙ICP備09019653號-31

參數名	作用
chunk_size	當前slab每個chunk的大小，單位為字節
chunks_per_page	每個page可以存放的chunk數目，由于每個page固定為1M即10241024字節，所以這個值就是（10241024/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請求數

sesese色