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