缓存系统MemCached的Java客户端优化历程
來源：http://www.infoq.com/cn/articles/memcached-java
?
作者 岑文初 發(fā)布于 2008年9月27日 上午12時(shí)38分
社區(qū)Memcached 是什么？
Memcached是一種集中式Cache，支持分布式橫向擴(kuò)展。這里需要解釋說明一下，很多開發(fā)者覺得Memcached是一種分布式緩存系統(tǒng)， 但是其實(shí)Memcached服務(wù)端本身是單實(shí)例的，只是在客戶端實(shí)現(xiàn)過程中可以根據(jù)存儲(chǔ)的主鍵做分區(qū)存儲(chǔ)，而這個(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)存存儲(chǔ) ：不言而喻，速度快，但對(duì)于內(nèi)存的要求高。這種情況對(duì)CPU要求很低，所以常常采用將 Memcached服務(wù)端和一些CPU高消耗內(nèi)存、低消耗應(yīng)用部署在一起。（我們的某個(gè)產(chǎn)品正好有這樣的環(huán)境，我們的接口服務(wù)器有多臺(tái)，它們對(duì)CPU要求 很高——原因在于WS-Security的使用，但是對(duì)于內(nèi)存要求很低，因此可以用作Memcached的服務(wù)端部署機(jī)器）。
集中式緩存（Cache） ：避開了分布式緩存的傳播問題，但是需要非單點(diǎn)來保證其可靠性，這個(gè)就是后面集成中所 作的集群（Cluster）工作，可以將多個(gè)Memcached作為一個(gè)虛擬的集群，同時(shí)對(duì)于集群的讀寫和普通的Memcached的讀寫性能沒有差別。
分布式擴(kuò)展 ：Memcached很突出的一個(gè)優(yōu)點(diǎn)就是采用了可分布式擴(kuò)展的模式。可以將部署在一臺(tái)機(jī)器上的多個(gè) Memcached服務(wù)端或者部署在多個(gè)機(jī)器上的Memcached服務(wù)端組成一個(gè)虛擬的服務(wù)端，對(duì)于調(diào)用者來說則是完全屏蔽和透明的。這樣做既提高了單 機(jī)的內(nèi)存利用率，也提供了向上擴(kuò)容（Scale Out）的方式。
Socket通信： 這兒需要注意傳輸內(nèi)容的大小和序列化的問題，雖然Memcached通常會(huì)被放置到內(nèi)網(wǎng)作為 緩存，Socket傳輸速率應(yīng)該比較高（當(dāng)前支持TCP和UDP兩種模式，同時(shí)根據(jù)客戶端的不同可以選擇使用NIO的同步或者異步調(diào)用方式），但是序列化 成本和帶寬成本還是需要注意。這里也提一下序列化，對(duì)于對(duì)象序列化的性能往往讓大家頭痛，但是如果對(duì)于同一類的Class對(duì)象序列化傳輸，第一次序列化時(shí) 間比較長(zhǎng)，后續(xù)就會(huì)優(yōu)化，也就是說序列化最大的消耗不是對(duì)象序列化，而是類的序列化。如果穿過去的只是字符串，這種情況是最理想的，省去了序列化的操作， 因此在Memcached中保存的往往是較小的內(nèi)容。
特殊的內(nèi)存分配機(jī)制： 首先要說明的是Memcached支持最大的存儲(chǔ)對(duì)象為1M。它的內(nèi)存分配比較特殊，但是 這樣的分配方式其實(shí)也是基于性能考慮的，簡(jiǎn)單的分配機(jī)制可以更容易回收再分配，節(jié)省對(duì)CPU的使用。這里用一個(gè)酒窖做比來說明這種內(nèi)存分配機(jī)制，首先在 Memcached啟動(dòng)的時(shí)候可以通過參數(shù)來設(shè)置使用的所有內(nèi)存——酒窖，然后在有酒進(jìn)入的時(shí)候，首先申請(qǐng)（通常是1M）的空間，用來建酒架，而酒架根據(jù) 這個(gè)酒瓶的大小將自己分割為多個(gè)小格子來安放酒瓶，并將同樣大小范圍內(nèi)的酒瓶都放置在一類酒架上面。例如20厘米半徑的酒瓶放置在可以容納20-25厘米 的酒架A上，30厘米半徑的酒瓶就放置在容納25-30厘米的酒架B上。回收機(jī)制也很簡(jiǎn)單，首先新酒入庫，看看酒架是否有可以回收的地方，如果有就直接使 用，如果沒有則申請(qǐng)新的地方，如果申請(qǐng)不到，就采用配置的過期策略。從這個(gè)特點(diǎn)來看，如果要放的內(nèi)容大小十分離散，同時(shí)大小比例相差梯度很明顯的話，那么 可能對(duì)于空間使用來說效果不好，因?yàn)楹芸赡茉诰萍蹵上就放了一瓶酒，但卻占用掉了一個(gè)酒架的位置。
緩存機(jī)制簡(jiǎn)單： 有時(shí)候很多開源項(xiàng)目做的面面俱到，但到最后因?yàn)檫^于注重一些非必要的功能而拖累了性能，這里提到 的就是Memcached的簡(jiǎn)單性。首先它沒有什么同步，消息分發(fā)，兩階段提交等等，它就是一個(gè)很簡(jiǎn)單的緩存，把東西放進(jìn)去，然后可以取出來，如果發(fā)現(xiàn)所 提供的Key沒有命中，那么就很直白地告訴你，你這個(gè)Key沒有任何對(duì)應(yīng)的東西在緩存里，去數(shù)據(jù)庫或者其他地方取；當(dāng)你在外部數(shù)據(jù)源取到的時(shí)候，可以直接 將內(nèi)容置入到緩存中，這樣下次就可以命中了。這里介紹一下同步這些數(shù)據(jù)的兩種方式：一種是在你修改了以后立刻更新緩存內(nèi)容，這樣就會(huì)即時(shí)生效；另一種是說 容許有失效時(shí)間，到了失效時(shí)間，自然就會(huì)將內(nèi)容刪除，此時(shí)再去取的時(shí)候就不會(huì)命中，然后再次將內(nèi)容置入緩存，用來更新內(nèi)容。后者用在一些實(shí)時(shí)性要求不高， 寫入不頻繁的情況。
客戶端的重要性： Memcached是用C寫的一個(gè)服務(wù)端，客戶端沒有規(guī)定，反正是Socket傳輸，只要語言 支持Socket通信，通過Command的簡(jiǎn)單協(xié)議就可以通信。但是客戶端設(shè)計(jì)的合理十分重要，同時(shí)也給使用者提供了很大的空間去擴(kuò)展和設(shè)計(jì)客戶端來滿 足各種場(chǎng)景的需要，包括容錯(cuò)、權(quán)重、效率、特殊的功能性需求和嵌入框架等等。
幾個(gè)應(yīng)用點(diǎn)： 小對(duì)象的緩存（用戶的Token、權(quán)限信息、資源信息）；小的靜態(tài)資源緩存；SQL結(jié)果的緩存（這 部分如果用的好，性能提高會(huì)相當(dāng)大，同時(shí)由于Memcached自身提供向上擴(kuò)容，那么對(duì)于數(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)然對(duì)于它的內(nèi)存分配機(jī)制等細(xì)節(jié)還是有所了解，因此在使用的時(shí)候也 會(huì)十分注意，這些文章在網(wǎng)絡(luò)上有很多。這里我重點(diǎn)介紹一下對(duì)于MemCache系統(tǒng)的Java客戶端優(yōu)化的兩個(gè)階段。
第一階段：封裝Whalin
第一階段主要是在官方推薦的Java客戶端之一whalin開源實(shí)現(xiàn)基礎(chǔ)上做再次封裝。
SIP在作服務(wù)訪問頻率控制的時(shí)候需要記錄在控制間隔期內(nèi)的訪問次數(shù)和流量，此時(shí)由于是集群，因此數(shù)據(jù)必須放在集中式的存儲(chǔ)或者緩存中，數(shù)據(jù)庫肯定撐不住 這樣大數(shù)據(jù)量的更新頻率，因此考慮使用Memcached的很出彩的操作——全局計(jì)數(shù)器 （storeCounter,getCounter,inc,dec），但是在檢查計(jì)數(shù)器的時(shí)候如何去獲取當(dāng)前所有的計(jì)數(shù)器？我曾考慮使用DB或者文件， 但是效率有問題，同時(shí)如果放在一個(gè)字段中的話，還會(huì)存在并發(fā)問題。因此不得不實(shí)現(xiàn)了KeySet，在使用KeySet的時(shí)候有一個(gè)參數(shù)，類型是 Boolean，這個(gè)字段的存在是因?yàn)樵贛emcached中數(shù)據(jù)的刪除并不是直接刪除，而是標(biāo)注一下，這樣會(huì)導(dǎo)致實(shí)現(xiàn)keySet的時(shí)候取出可能已經(jīng)刪 除的數(shù)據(jù)。如果對(duì)于數(shù)據(jù)嚴(yán)謹(jǐn)性要求低，速度要求高，那么不需要再去驗(yàn)證Key是否真的有效，而如果要求Key必須正確存在，就需要再多一次的輪詢查找。
因此，在每一個(gè)客戶端中都內(nèi)置了一個(gè)有超時(shí)機(jī)制的本地緩存（采用Lazy Timeout機(jī)制），在獲取數(shù)據(jù)的時(shí)候，首先在本地查詢數(shù)據(jù)是否存在，如果不存在則再向Memcache發(fā)起請(qǐng)求，獲得數(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（同步），多多少少會(huì)影響性能。雖然過去看過這部分代碼，但是當(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/ 。
上面兩部分的工作不論是否提升了性能，但是對(duì)于客戶端本身來說都是有意義的，當(dāng)然提升性能給應(yīng)用帶來的吸引力更大。這部分細(xì)節(jié)內(nèi)容可以參看代碼實(shí)現(xiàn) 部分，對(duì)于調(diào)用者來說完全沒有任何功能影響，僅僅只是性能。
壓力測(cè)試比較
在這個(gè)壓力測(cè)試之前，其實(shí)已經(jīng)做過很多次壓力測(cè)試了，測(cè)試中的數(shù)據(jù)本身并沒有衡量Memcached的意義，因?yàn)闇y(cè)試是使用我自己的機(jī)器，其中性 能、帶寬、內(nèi)存和網(wǎng)絡(luò)IO都不是服務(wù)器級(jí)別的，這里僅僅是將使用原有的第三方客戶端和改造后的客戶端作一個(gè)比較。場(chǎng)景就是模擬多用戶多線程在同一時(shí)間發(fā)起 緩存操作，然后記錄下操作的結(jié)果。
Client版本在測(cè)試中有兩個(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ā)送一次請(qǐng)求并接受響應(yīng)），因此啟用該設(shè)置對(duì)于性能來說會(huì)有不少的影響，不過建議還是使用這個(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% |
從上面的壓力測(cè)試可以看出這么幾點(diǎn)，首先優(yōu)化SockIO提升了不少性能，其次SockIO優(yōu)化的是get的性能，對(duì)于put沒有太大的作用。原以 為獲取數(shù)據(jù)越大性能效果提升越明顯，但結(jié)果并不是這樣。
單個(gè)緩存實(shí)例和雙緩存實(shí)例的測(cè)試比較：
| 緩存配置 | 用戶 | 操作 | 客戶端 版本 | 總耗時(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è)客戶端對(duì)應(yīng)多個(gè)服務(wù)端實(shí)例性能提升略高于單客戶端對(duì)應(yīng)單服務(wù)端實(shí)例。
緩存集群的測(cè)試比較：
| 緩存配置 | 用戶 | 操作 | 客戶端 版本 | 總耗時(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)用的代碼、范例和說明等，有興趣的朋友可以下載下來測(cè)試一下，與現(xiàn)在用的Java Memcached客戶端在易用性和性能方面是否有所提高，也期待更多對(duì)于這部分開源內(nèi)容的反饋，能夠?qū)⑺龅母谩?/p>
鏈接地址：http://code.google.com/p/memcache-client-forjava/ 。
作者介紹： 岑文初，就職于阿里軟件公司研發(fā)中心平臺(tái)一部，任架構(gòu)師。當(dāng)前主要工作涉及阿里軟件開發(fā)平臺(tái)服務(wù)框架 （ASF）設(shè)計(jì)與實(shí)現(xiàn)，服務(wù)集成平臺(tái)（SIP）設(shè)計(jì)與實(shí)現(xiàn)。沒有什么擅長(zhǎng)或者精通，工作到現(xiàn)在唯一提升的就是學(xué)習(xí)能力和速度。個(gè)人Blog為：http://blog.csdn.net/cenwenchu79 。
志愿參與InfoQ中文站內(nèi)容建設(shè)，請(qǐng)郵件至editors@cn.infoq.com 。 也歡迎大家到InfoQ中文站用戶討論組 參與我們的線 上討論。
總結(jié)
以上是生活随笔為你收集整理的缓存系统MemCached的Java客户端优化历程的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 部落冲突哥布林镇怎么打(《部落冲突》官方
- 下一篇： 部落冲突怎么邀请好友进部落(《部落冲突》