缓存系统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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 部落冲突哥布林镇怎么打(《部落冲突》官方
- 下一篇: 部落冲突怎么邀请好友进部落(《部落冲突》