分布式緩存Memcached的Java客戶端優化歷程
這是一篇比較老的文章了，對Memcached的JAVA客戶端優化做了非常詳細的總結。讓我們認識到，要深入了解一樣事物，必須深入去研究，而不能僅僅停留在使用的層面上。Memcached JAVA客戶端優化過程原文如下：
Memcached 是什么？
Memcached是一種集中式Cache，支持分布式橫向擴展。這里需要解釋說明一下，很多開發者覺得Memcached是一種分布式緩存系統， 但是其實Memcached服務端本身是單實例的，只是在客戶端實現過程中可以根據存儲的主鍵做分區存儲，而這個區就是Memcached服務端的一個或 者多個實例，如果將客戶端也囊括到Memcached中，那么可以部分概念上說是集中式的。其實回顧一下集中式的構架，無非兩種情況：一是節點均衡的網狀 （JBoss Tree Cache），利用JGroup的多播通信機制來同步數據；二是Master-Slaves模式（分布式文件系統），由Master來管理Slave，比 如如何選擇Slave，如何遷移數據等都是由Master來完成，但是Master本身也存在單點問題。下面再總結幾個它的特點來理解一下其優點和限制。
內存存儲：不言而喻，速度快，但對于內存的要求高。這種情況對CPU要求很低，所以常常采用將 Memcached服務端和一些CPU高消耗內存、低消耗應用部署在一起。（我們的某個產品正好有這樣的環境，我們的接口服務器有多臺，它們對CPU要求 很高——原因在于WS-Security的使用，但是對于內存要求很低，因此可以用作Memcached的服務端部署機器）。
集中式緩存（Cache）：避開了分布式緩存的傳播問題，但是需要非單點來保證其可靠性，這個就是后面集成中所作的集群（Cluster）工作，可以將多個Memcached作為一個虛擬的集群，同時對于集群的讀寫和普通的Memcached的讀寫性能沒有差別。
分布式擴展：Memcached很突出的一個優點就是采用了可分布式擴展的模式。可以將部署在一臺機器上的多個 Memcached服務端或者部署在多個機器上的Memcached服務端組成一個虛擬的服務端，對于調用者來說則是完全屏蔽和透明的。這樣做既提高了單 機的內存利用率，也提供了向上擴容（Scale Out）的方式。
Socket通信：這兒需要注意傳輸內容的大小和序列化的問題，雖然Memcached通常會被放置到內網作為 緩存，Socket傳輸速率應該比較高（當前支持TCP和UDP兩種模式，同時根據客戶端的不同可以選擇使用NIO的同步或者異步調用方式），但是序列化 成本和帶寬成本還是需要注意。這里也提一下序列化，對于對象序列化的性能往往讓大家頭痛，但是如果對于同一類的Class對象序列化傳輸，第一次序列化時 間比較長，后續就會優化，也就是說序列化最大的消耗不是對象序列化，而是類的序列化。如果穿過去的只是字符串，這種情況是最理想的，省去了序列化的操作， 因此在Memcached中保存的往往是較小的內容。
特殊的內存分配機制：首先要說明的是Memcached支持最大的存儲對象為1M。它的內存分配比較特殊，但是 這樣的分配方式其實也是基于性能考慮的，簡單的分配機制可以更容易回收再分配，節省對CPU的使用。這里用一個酒窖做比來說明這種內存分配機制，首先在 Memcached啟動的時候可以通過參數來設置使用的所有內存——酒窖，然后在有酒進入的時候，首先申請（通常是1M）的空間，用來建酒架，而酒架根據 這個酒瓶的大小將自己分割為多個小格子來安放酒瓶，并將同樣大小范圍內的酒瓶都放置在一類酒架上面。例如20厘米半徑的酒瓶放置在可以容納20-25厘米 的酒架A上，30厘米半徑的酒瓶就放置在容納25-30厘米的酒架B上。回收機制也很簡單，首先新酒入庫，看看酒架是否有可以回收的地方，如果有就直接使 用，如果沒有則申請新的地方，如果申請不到，就采用配置的過期策略。從這個特點來看，如果要放的內容大小十分離散，同時大小比例相差梯度很明顯的話，那么 可能對于空間使用來說效果不好，因為很可能在酒架A上就放了一瓶酒，但卻占用掉了一個酒架的位置。
緩存機制簡單：有時候很多開源項目做的面面俱到，但到最后因為過于注重一些非必要的功能而拖累了性能，這里提到 的就是Memcached的簡單性。首先它沒有什么同步，消息分發，兩階段提交等等，它就是一個很簡單的緩存，把東西放進去，然后可以取出來，如果發現所 提供的Key沒有命中，那么就很直白地告訴你，你這個Key沒有任何對應的東西在緩存里，去數據庫或者其他地方取；當你在外部數據源取到的時候，可以直接 將內容置入到緩存中，這樣下次就可以命中了。這里介紹一下同步這些數據的兩種方式：一種是在你修改了以后立刻更新緩存內容，這樣就會即時生效；另一種是說 容許有失效時間，到了失效時間，自然就會將內容刪除，此時再去取的時候就不會命中，然后再次將內容置入緩存，用來更新內容。后者用在一些實時性要求不高， 寫入不頻繁的情況。
客戶端的重要性：Memcached是用C寫的一個服務端，客戶端沒有規定，反正是Socket傳輸，只要語言 支持Socket通信，通過Command的簡單協議就可以通信。但是客戶端設計的合理十分重要，同時也給使用者提供了很大的空間去擴展和設計客戶端來滿 足各種場景的需要，包括容錯、權重、效率、特殊的功能性需求和嵌入框架等等。
幾個應用點：小對象的緩存（用戶的Token、權限信息、資源信息）；小的靜態資源緩存；SQL結果的緩存（這部分如果用的好，性能提高會相當大，同時由于Memcached自身提供向上擴容，那么對于數據庫向上擴容的老大難問題無疑是一劑好藥）；ESB消息緩存。
優化MemCached系統Java客戶端的原因
MemCached在大型網站被應用得越來越廣泛，不同語言的客戶端也都在官方網站上有提供，但是Java開發者的選擇并不多。由于現在的 MemCached服務端是用C寫的，因此我這個C不太熟悉的人也就沒有辦法去優化它。當然對于它的內存分配機制等細節還是有所了解，因此在使用的時候也 會十分注意，這些文章在網絡上有很多。這里我重點介紹一下對于MemCache系統的Java客戶端優化的兩個階段。
第一階段：封裝Whalin
第一階段主要是在官方推薦的Java客戶端之一whalin開源實現基礎上做再次封裝。
- 緩存服務接口化：定義了IMemCache接口，在應用部分僅僅只是使用接口，為將來替換緩存服務實現提供基礎。
- 使用配置代替代碼初始化客戶端：通過配置客戶端和SocketIO Pool屬性，直接交由CacheManager來維護Cache Client Pool的生命周期，便于單元測試。
- KeySet的實現：對于MemCached來說本身是不提供KeySet的方法的，在接口封裝初期，同事向我提出這個需求的時候，我個 人覺得也是沒有必要提供，因為緩存輪詢是比較低效的，同時這類場景，往往可以去數據源獲取KeySet，而不是從MemCached去獲取。但是SIP的 一個場景的出現，讓我不得不去實現了KeySet。
SIP在作服務訪問頻率控制的時候需要記錄在控制間隔期內的訪問次數和流量，此時由于是集群，因此數據必須放在集中式的存儲或者緩存中，數據庫肯定撐不住 這樣大數據量的更新頻率，因此考慮使用Memcached的很出彩的操作——全局計數器 （storeCounter,getCounter,inc,dec），但是在檢查計數器的時候如何去獲取當前所有的計數器？我曾考慮使用DB或者文件， 但是效率有問題，同時如果放在一個字段中的話，還會存在并發問題。因此不得不實現了KeySet，在使用KeySet的時候有一個參數，類型是 Boolean，這個字段的存在是因為在Memcached中數據的刪除并不是直接刪除，而是標注一下，這樣會導致實現keySet的時候取出可能已經刪 除的數據。如果對于數據嚴謹性要求低，速度要求高，那么不需要再去驗證Key是否真的有效，而如果要求Key必須正確存在，就需要再多一次的輪詢查找。 - 集群的實現：Memcached作為集中式緩存，存在著集中式的致命問題：單點問題。雖然Memcached支持多Instance分布 在多臺機器上，但僅僅只是解決了數據全部丟失的問題，當其中一臺機器出錯以后，還是會導致部分數據的丟失，一個籃子掉在地上還是會把部分的雞蛋打破。因此 就需要實現一個備份機制，能夠保證Memcached在部分失效以后，數據還能夠依然使用，當然大家很多時候都用緩存不命中就去數據源獲取的策略。然而在 SIP的場景中，如果部分信息找不到就去數據庫查找，很容易將SIP弄垮，因此SIP對于Memcached中的數據認為是可信的，做集群也是必要的。
- LocalCache結合Memcached使用，提高數據獲取效率：在第一次壓力測試過程中，發現和原先預料的一 樣，Memcached并不是完全無損失的，Memcached是通過Socket數據交互來進行通信的，因此機器的帶寬，網絡IO，Socket連接數 都是制約Memcached發揮其作用的障礙。Memcache的一個突出優點就是Timeout的設置，也就是可以對放進去的數據設置有效期，從而在一 定的容忍時間內對那些不敏感的數據就可以不去更新，以提高效率。根據這個思想，其實在集群中的每一個Memcached客戶端也可以使用本地的緩存，來存 儲獲取過的數據，設置一定的失效時間，來減少對于Memcached的訪問次數，提高整體性能。
因此，在每一個客戶端中都內置了一個有超時機制的本地緩存（采用Lazy Timeout機制），在獲取數據的時候，首先在本地查詢數據是否存在，如果不存在則再向Memcache發起請求，獲得數據以后，將其緩存在本地，并設置有效時間。方法定義如下：
- /**
- * 降低memcache的交互頻繁造成的性能損失，因此采用本地cache結合memcache的方式
- * @param key
- * @param 本地緩存失效時間單位秒
- * @return
- **/
- public Object get(String key,int localTTL);
第二階段：優化
第一階段的封裝基本上已經可以滿足現有的需求，也被自己的項目和其他產品線所使用，但是不經意的一句話，讓我開始了第二階段的優化。有同事告訴我說 Memcached客戶端的SocketIO代碼里面有太多的Synchronized（同步），多多少少會影響性能。雖然過去看過這部分代碼，但是當時 只是關注里面的Hash算法。根據同事所說的回去一看，果然有不少的同步，可能是作者當時寫客戶端的時候JDK版本較老的緣故造成的，現在 Concurrent包被廣泛應用，因此優化并不是一件很難的事情。但是由于原有Whalin沒有提供擴展的接口，因此不得不將Whalin除了 SockIO，其余全部納入到封裝過的客戶端的設想，然后改造SockIO部分。
結果也就有了這個放在Google上的開源客戶端：http://code.google.com/p/memcache-client-forjava/。
- 優化Synchronized：在原有代碼中SockIO的資源池被分成三個池（普通Map實現），——Free（閑）、Busy（忙） 和Dead（死鎖），然后根據SockIO使用情況來維護這三個資源池。優化方式為首先簡化資源池，只有一個資源池，設置一個狀態池，在變更資源狀態的過 程時僅僅變更資源池中的內容。然后用ConcurrentMap來替代Map，同時使用putIfAbsent方法來簡化Synchronized，具體 的代碼可參見Google上該軟件的源文件。
- 原以為這次優化后，效率應該會有很大的提高，但是在初次壓力測試后發現，并沒有明顯的提高，看來有其他地方的耗時遠遠大于連接池資源維 護，因此用JProfiler作了性能分析，發現了最大的一個瓶頸：Read數據部分。原有設計中讀取數據是按照單字節讀取，然后逐步分析，為的僅僅就是 遇到協議中的分割符可以識別。但是循環Read單字節和批量分頁Read性能相差很大，因此我內置了讀入緩存頁（可設置大小），然后再按照協議的需求去讀 取和分析數據，結果顯示效率得到了很大的提高。具體的數據參見最后部分的壓力測試結果。
上面兩部分的工作不論是否提升了性能，但是對于客戶端本身來說都是有意義的，當然提升性能給應用帶來的吸引力更大。這部分細節內容可以參看代碼實現部分，對于調用者來說完全沒有任何功能影響，僅僅只是性能。
壓力測試比較
在這個壓力測試之前，其實已經做過很多次壓力測試了，測試中的數據本身并沒有衡量Memcached的意義，因為測試是使用我自己的機器，其中性 能、帶寬、內存和網絡IO都不是服務器級別的，這里僅僅是將使用原有的第三方客戶端和改造后的客戶端作一個比較。場景就是模擬多用戶多線程在同一時間發起 緩存操作，然后記錄下操作的結果。
Client版本在測試中有兩個：2.0和2.2。2.0是封裝調用Whalin Memcached Client 2.0.1版本的客戶端實現。2.2是使用了新SockIO的無第三方依賴的客戶端實現。checkAlive指的是在使用連接資源以前是否需要驗證連接 資源有效（發送一次請求并接受響應），因此啟用該設置對于性能來說會有不少的影響，不過建議還是使用這個檢查。
單個緩存服務端實例的各種配置和操作下比較：
| 緩存配置 | 用戶 | 操作 | 客戶端 版本 | 總耗時(ms) | 單線程耗時(ms) | 提高處理能力百分比 |
| checkAlive | 100 | 1000 put simple obj 1000 get simple obj |
2.0 2.2 |
13242565 7772767 |
132425 77727 |
+41.3% |
| No checkAlive | 100 | 1000 put simple obj 1000 put simple obj |
2.0 2.2 |
7200285 4667239 |
72002 46672 |
+35.2% |
| checkAlive | 100 | 1000 put simple obj 2000 get simple obj |
2.0 2.2 |
20385457 11494383 |
203854 114943 |
+43.6% |
| No checkAlive | 100 | 1000 put simple obj 2000 get simple obj |
2.0 2.2 |
11259185 7256594 |
112591 72565 |
+35.6% |
| checkAlive | 100 | 1000 put complex obj 1000 get complex obj |
2.0 2.2 |
15004906 9501571 |
150049 95015 |
+36.7% |
| No checkAlive | 100 | 1000 put complex obj 1000 put complex obj |
2.0 2.2 |
9022578 6775981 |
90225 67759 |
+24.9% |
從上面的壓力測試可以看出這么幾點，首先優化SockIO提升了不少性能，其次SockIO優化的是get的性能，對于put沒有太大的作用。原以為獲取數據越大性能效果提升越明顯，但結果并不是這樣。
單個緩存實例和雙緩存實例的測試比較：
| 緩存配置 | 用戶 | 操作 | 客戶端 版本 | 總耗時(ms) | 單線程耗時(ms) | 提高處理能力百分比 |
| One Cache instance checkAlive |
100 | 1000 put simple obj 1000 get simple obj |
2.0 2.2 |
13242565 7772767 |
132425 77727 |
+41.3% |
| Two Cache instance checkAlive |
100 | 1000 put simple obj 1000 put simple obj |
2.0 2.2 |
13596841 7696684 |
135968 76966 |
+43.4% |
結果顯示，單個客戶端對應多個服務端實例性能提升略高于單客戶端對應單服務端實例。
緩存集群的測試比較：
| 緩存配置 | 用戶 | 操作 | 客戶端 版本 | 總耗時(ms) | 單線程耗時(ms) | 提高處理能力百分比 |
| No Cluster checkAlive |
100 | 1000 put simple obj 1000 get simple obj |
2.0 2.2 |
13242565 7772767 |
132425 77727 |
+41.3% |
| Cluster checkAlive |
100 | 1000 put simple obj 1000 put simple obj |
2.0 2.2 |
25044268 8404606 |
250442 84046 |
+66.5% |
這部分和SocketIO優化無關。2.0采用的是向集群中所有客戶端更新成功以后才返回的策略，2.2采用了異步更新，并且是分布式客戶端節點獲取的方式來分散壓力，因此提升效率很多。
開源代碼下載
其實封裝后的客戶端一直在內部使用，現在作了二次優化以后，覺得應該開源出來，一是可以完善自己的客戶端代碼，二是也可以和更多的開發者交流使用心 得。目前我已經在Google Code上傳了應用的代碼、范例和說明等，有興趣的朋友可以下載下來測試一下，與現在用的Java Memcached客戶端在易用性和性能方面是否有所提高，也期待更多對于這部分開源內容的反饋，能夠將它做的更好。
鏈接地址：http://code.google.com/p/memcache-client-forjava/。
原文鏈接：http://www.itivy.com/arch/archive/2011/11/30/memcached-java-program.html
【編輯推薦】
