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集群之間不會相互通信（與之形成對比的，比如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，取余數得到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）通過模擬請求的方式逐漸預熱緩存，使緩存服務器中的數據重新分布
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的數據存放在內存中，存放在內存中個人認為意味著幾點：
1、訪問數據的速度比傳統的關系型數據庫要快，因為Oracle、MySQL這些傳統的關系型數據庫為了保持數據的持久性，數據存放在硬盤中，IO操作速度慢
2、MemCache的數據存放在內存中同時意味著只要MemCache重啟了，數據就會消失
3、既然MemCache的數據存放在內存中，那么勢必受到機器位數的限制，這個之前的文章寫過很多次了，32位機器最多只能使用2GB的內存空間，64位機器可以認為沒有上限
然后我們來看一下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將被放到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的內存分配及回收算法，總結三點：
1、MemCache的內存分配chunk里面會有內存浪費，88字節的value分配在128字節（緊接著大的用）的chunk中，就損失了30字節，但是這也避免了管理內存碎片的問題
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有哪幾種命令：
| 命 ? ?令 | 作 ? ?用 |
| 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對應的valueif (!mc.cas(key, 0, i, cas)){return false;}return true;} } ==================================================================================我不能保證寫的每個地方都是對的，但是至少能保證不復制、不黏貼，保證每一句話、每一行代碼都經過了認真的推敲、仔細的斟酌。每一篇文章的背后，希望都能看到自己對于技術、對于生活的態度。
我相信喬布斯說的，只有那些瘋狂到認為自己可以改變世界的人才能真正地改變世界。面對壓力，我可以挑燈夜戰、不眠不休；面對困難，我愿意迎難而上、永不退縮。
其實我想說的是，我只是一個程序員，這就是我現在純粹人生的全部。
==================================================================================
總結
以上是生活随笔為你收集整理的MemCache详细解读的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Memcache缓存系统原理
- 下一篇： Memcache工作原理总结