緩存系統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的讀寫性能沒有差異。

相關廠商內容

優化您的數據庫與時間，實現更高性能

還記得Delphi麼？Embarcadero攜ER/Studio、RAD Studio XE和HTML5 Builder重裝上陣

QCon北京2013大會「社區之夜」開放報名中（4月26日 週五）

QCon北京2013晚場活動4月27日晚"Tencent Cloud Party"免費報名中！

GitHub首屆中國Drinkup活動，就在QCon北京2013前夜，中關村貝塔咖啡

分佈式擴展：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開源實現基礎上作再次封裝。

1. 緩存服務接口化：定義了IMemCache接口，在應用部分僅僅只是使用接口，爲未來替換緩存服務實現提供基礎。
2. 使用配置代替代碼初始化客戶端：經過配置客戶端和SocketIO Pool屬性，直接交由CacheManager來維護Cache Client Pool的生命週期，便於單元測試。
3. KeySet的實現：對於MemCached來講自己是不提供KeySet的方法的，在接口封裝初期，同事向我提出這個需求的時候，我個 人以爲也是沒有必要提供，由於緩存輪詢是比較低效的，同時這類場景，每每能夠去數據源獲取KeySet，而不是從MemCached去獲取。可是SIP的 一個場景的出現，讓我不得不去實現了KeySet。
   SIP在做服務訪問頻率控制的時候須要記錄在控制間隔期內的訪問次數和流量，此時因爲是集羣，所以數據必須放在集中式的存儲或者緩存中，數據庫確定撐不住 這樣大數據量的更新頻率，所以考慮使用Memcached的很出彩的操做——全局計數器 （storeCounter,getCounter,inc,dec），可是在檢查計數器的時候如何去獲取當前全部的計數器？我曾考慮使用DB或者文件， 可是效率有問題，同時若是放在一個字段中的話，還會存在併發問題。所以不得不實現了KeySet，在使用KeySet的時候有一個參數，類型是 Boolean，這個字段的存在是由於在Memcached中數據的刪除並非直接刪除，而是標註一下，這樣會致使實現keySet的時候取出可能已經刪 除的數據。若是對於數據嚴謹性要求低，速度要求高，那麼不須要再去驗證Key是否真的有效，而若是要求Key必須正確存在，就須要再多一次的輪詢查找。
4. 集羣的實現：Memcached做爲集中式緩存，存在着集中式的致命問題：單點問題。雖然Memcached支持多Instance分佈 在多臺機器上，但僅僅只是解決了數據所有丟失的問題，當其中一臺機器出錯之後，仍是會致使部分數據的丟失，一個籃子掉在地上仍是會把部分的雞蛋打破。所以 就須要實現一個備份機制，可以保證Memcached在部分失效之後，數據還可以依然使用，固然你們不少時候都用緩存不命中就去數據源獲取的策略。然而在 SIP的場景中，若是部分信息找不到就去數據庫查找，很容易將SIP弄垮，所以SIP對於Memcached中的數據認爲是可信的，作集羣也是必要的。
5. 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/。

1. 優化Synchronized：在原有代碼中SockIO的資源池被分紅三個池（普通Map實現），——Free（閒）、Busy（忙） 和Dead（死鎖），而後根據SockIO使用狀況來維護這三個資源池。優化方式爲首先簡化資源池，只有一個資源池，設置一個狀態池，在變動資源狀態的過 程時僅僅變動資源池中的內容。而後用ConcurrentMap來替代Map，同時使用putIfAbsent方法來簡化Synchronized，具體 的代碼可參見Google上該軟件的源文件。
2. 原覺得此次優化後，效率應該會有很大的提升，可是在初次壓力測試後發現，並無明顯的提升，看來有其餘地方的耗時遠遠大於鏈接池資源維 護，所以用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客戶端在易用性和性能方面是否有所提升，也期待更多對於這部分開源內容的反饋，可以將它作的更好