來源：http://www.infoq.com/cn/articles/memcached-java

?

作者 岑文初 發(fā)布于 2008年9月27日 上午12時(shí)38分

社區(qū)

Java

主題

集群與緩存

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í) 間比較長，后續(xù)就會(huì)優(yōu)化，也就是說序列化最大的消耗不是對(duì)象序列化，而是類的序列化。如果穿過去的只是字符串，這種情況是最理想的，省去了序列化的操作， 因此在Memcached中保存的往往是較小的內(nèi)容。

特殊的內(nèi)存分配機(jī)制： 首先要說明的是Memcached支持最大的存儲(chǔ)對(duì)象為1M。它的內(nèi)存分配比較特殊，但是 這樣的分配方式其實(shí)也是基于性能考慮的，簡單的分配機(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ī)制也很簡單，首先新酒入庫，看看酒架是否有可以回收的地方，如果有就直接使 用，如果沒有則申請(qǐng)新的地方，如果申請(qǐng)不到，就采用配置的過期策略。從這個(gè)特點(diǎn)來看，如果要放的內(nèi)容大小十分離散，同時(shí)大小比例相差梯度很明顯的話，那么 可能對(duì)于空間使用來說效果不好，因?yàn)楹芸赡茉诰萍蹵上就放了一瓶酒，但卻占用掉了一個(gè)酒架的位置。

緩存機(jī)制簡單： 有時(shí)候很多開源項(xiàng)目做的面面俱到，但到最后因?yàn)檫^于注重一些非必要的功能而拖累了性能，這里提到 的就是Memcached的簡單性。首先它沒有什么同步，消息分發(fā)，兩階段提交等等，它就是一個(gè)很簡單的緩存，把東西放進(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的簡單協(xié)議就可以通信。但是客戶端設(shè)計(jì)的合理十分重要，同時(shí)也給使用者提供了很大的空間去擴(kuò)展和設(shè)計(jì)客戶端來滿 足各種場景的需要，包括容錯(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ǔ)上做再次封裝。

緩存服務(wù)接口化 ：定義了IMemCache接口，在應(yīng)用部分僅僅只是使用接口，為將來替換緩存服務(wù)實(shí) 現(xiàn)提供基礎(chǔ)。

使用配置代替代碼初始化客戶端 ：通過配置客戶端和SocketIO Pool屬性，直接交由CacheManager來維護(hù)Cache Client Pool的生命周期，便于單元測(cè)試。

KeySet的實(shí)現(xiàn)：對(duì)于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ù)必須放在集中式的存儲(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必須正確存在，就需要再多一次的輪詢查找。

集群的實(shí)現(xiàn)：Memcached作為集中式緩存，存在著集中式的致命問題：單點(diǎn)問題。雖然Memcached支持多Instance分布 在多臺(tái)機(jī)器上，但僅僅只是解決了數(shù)據(jù)全部丟失的問題，當(dāng)其中一臺(tái)機(jī)器出錯(cuò)以后，還是會(huì)導(dǎo)致部分?jǐn)?shù)據(jù)的丟失，一個(gè)籃子掉在地上還是會(huì)把部分的雞蛋打破。因此 就需要實(shí)現(xiàn)一個(gè)備份機(jī)制，能夠保證Memcached在部分失效以后，數(shù)據(jù)還能夠依然使用，當(dāng)然大家很多時(shí)候都用緩存不命中就去數(shù)據(jù)源獲取的策略。然而在 SIP的場景中，如果部分信息找不到就去數(shù)據(jù)庫查找，很容易將SIP弄垮，因此SIP對(duì)于Memcached中的數(shù)據(jù)認(rèn)為是可信的，做集群也是必要的。

LocalCache結(jié)合Memcached使用，提高數(shù)據(jù)獲取效率：在第一次壓力測(cè)試過程中，發(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è)置，也就是可以對(duì)放進(jìn)去的數(shù)據(jù)設(shè)置有效期，從而在一 定的容忍時(shí)間內(nèi)對(duì)那些不敏感的數(shù)據(jù)就可以不去更新，以提高效率。根據(jù)這個(gè)思想，其實(shí)在集群中的每一個(gè)Memcached客戶端也可以使用本地的緩存，來存 儲(chǔ)獲取過的數(shù)據(jù)，設(shè)置一定的失效時(shí)間，來減少對(duì)于Memcached的訪問次數(shù)，提高整體性能。

因此，在每一個(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/ 。

優(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)該會(huì)有很大的提高，但是在初次壓力測(cè)試后發(fā)現(xiàn)，并沒有明顯的提高，看來有其他地方的耗時(shí)遠(yuǎn)遠(yuǎn)大于連接池資源維 護(hù)，因此用JProfiler作了性能分析，發(fā)現(xiàn)了最大的一個(gè)瓶頸：Read數(shù)據(jù)部分。原有設(shè)計(jì)中讀取數(shù)據(jù)是按照單字節(jié)讀取，然后逐步分析，為的僅僅就是 遇到協(xié)議中的分割符可以識(shí)別。但是循環(huán)Read單字節(jié)和批量分頁Read性能相差很大，因此我內(nèi)置了讀入緩存頁（可設(shè)置大小），然后再按照協(xié)議的需求去讀 取和分析數(shù)據(jù)，結(jié)果顯示效率得到了很大的提高。具體的數(shù)據(jù)參見最后部分的壓力測(cè)試結(jié)果。

上面兩部分的工作不論是否提升了性能，但是對(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è)比較。場景就是模擬多用戶多線程在同一時(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)。沒有什么擅長或者精通，工作到現(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客户端优化历程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。