這是一篇比較老的文章了，對(duì)Memcached的JAVA客戶端優(yōu)化做了非常詳細(xì)的總結(jié)。讓我們認(rèn)識(shí)到，要深入了解一樣事物，必須深入去研究，而不能僅僅停留在使用的層面上。Memcached JAVA客戶端優(yōu)化過(guò)程原文如下：

Memcached 是什么？

Memcached是一種集中式Cache，支持分布式橫向擴(kuò)展。這里需要解釋說(shuō)明一下，很多開(kāi)發(fā)者覺(jué)得Memcached是一種分布式緩存系統(tǒng)， 但是其實(shí)Memcached服務(wù)端本身是單實(shí)例的，只是在客戶端實(shí)現(xiàn)過(guò)程中可以根據(jù)存儲(chǔ)的主鍵做分區(qū)存儲(chǔ)，而這個(gè)區(qū)就是Memcached服務(wù)端的一個(gè)或 者多個(gè)實(shí)例，如果將客戶端也囊括到Memcached中，那么可以部分概念上說(shuō)是集中式的。其實(shí)回顧一下集中式的構(gòu)架，無(wú)非兩種情況：一是節(jié)點(diǎn)均衡的網(wǎng)狀 （JBoss Tree Cache），利用JGroup的多播通信機(jī)制來(lái)同步數(shù)據(jù)；二是Master-Slaves模式（分布式文件系統(tǒng)），由Master來(lái)管理Slave，比 如如何選擇Slave，如何遷移數(shù)據(jù)等都是由Master來(lái)完成，但是Master本身也存在單點(diǎn)問(wèn)題。下面再總結(jié)幾個(gè)它的特點(diǎn)來(lái)理解一下其優(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）：避開(kāi)了分布式緩存的傳播問(wèn)題，但是需要非單點(diǎn)來(lái)保證其可靠性，這個(gè)就是后面集成中所作的集群（Cluster）工作，可以將多個(gè)Memcached作為一個(gè)虛擬的集群，同時(shí)對(duì)于集群的讀寫(xiě)和普通的Memcached的讀寫(xiě)性能沒(méi)有差別。

分布式擴(kuò)展：Memcached很突出的一個(gè)優(yōu)點(diǎn)就是采用了可分布式擴(kuò)展的模式?？梢詫⒉渴鹪谝慌_(tái)機(jī)器上的多個(gè) Memcached服務(wù)端或者部署在多個(gè)機(jī)器上的Memcached服務(wù)端組成一個(gè)虛擬的服務(wù)端，對(duì)于調(diào)用者來(lái)說(shuō)則是完全屏蔽和透明的。這樣做既提高了單 機(jī)的內(nèi)存利用率，也提供了向上擴(kuò)容（Scale Out）的方式。

Socket通信：這兒需要注意傳輸內(nèi)容的大小和序列化的問(wèn)題，雖然Memcached通常會(huì)被放置到內(nèi)網(wǎng)作為 緩存，Socket傳輸速率應(yīng)該比較高（當(dāng)前支持TCP和UDP兩種模式，同時(shí)根據(jù)客戶端的不同可以選擇使用NIO的同步或者異步調(diào)用方式），但是序列化 成本和帶寬成本還是需要注意。這里也提一下序列化，對(duì)于對(duì)象序列化的性能往往讓大家頭痛，但是如果對(duì)于同一類(lèi)的Class對(duì)象序列化傳輸，第一次序列化時(shí) 間比較長(zhǎng)，后續(xù)就會(huì)優(yōu)化，也就是說(shuō)序列化最大的消耗不是對(duì)象序列化，而是類(lèi)的序列化。如果穿過(guò)去的只是字符串，這種情況是最理想的，省去了序列化的操作， 因此在Memcached中保存的往往是較小的內(nèi)容。

特殊的內(nèi)存分配機(jī)制：首先要說(shuō)明的是Memcached支持最大的存儲(chǔ)對(duì)象為1M。它的內(nèi)存分配比較特殊，但是 這樣的分配方式其實(shí)也是基于性能考慮的，簡(jiǎn)單的分配機(jī)制可以更容易回收再分配，節(jié)省對(duì)CPU的使用。這里用一個(gè)酒窖做比來(lái)說(shuō)明這種內(nèi)存分配機(jī)制，首先在 Memcached啟動(dòng)的時(shí)候可以通過(guò)參數(shù)來(lái)設(shè)置使用的所有內(nèi)存——酒窖，然后在有酒進(jìn)入的時(shí)候，首先申請(qǐng)（通常是1M）的空間，用來(lái)建酒架，而酒架根據(jù) 這個(gè)酒瓶的大小將自己分割為多個(gè)小格子來(lái)安放酒瓶，并將同樣大小范圍內(nèi)的酒瓶都放置在一類(lèi)酒架上面。例如20厘米半徑的酒瓶放置在可以容納20-25厘米 的酒架A上，30厘米半徑的酒瓶就放置在容納25-30厘米的酒架B上。回收機(jī)制也很簡(jiǎn)單，首先新酒入庫(kù)，看看酒架是否有可以回收的地方，如果有就直接使 用，如果沒(méi)有則申請(qǐng)新的地方，如果申請(qǐng)不到，就采用配置的過(guò)期策略。從這個(gè)特點(diǎn)來(lái)看，如果要放的內(nèi)容大小十分離散，同時(shí)大小比例相差梯度很明顯的話，那么 可能對(duì)于空間使用來(lái)說(shuō)效果不好，因?yàn)楹芸赡茉诰萍蹵上就放了一瓶酒，但卻占用掉了一個(gè)酒架的位置。

緩存機(jī)制簡(jiǎn)單：有時(shí)候很多開(kāi)源項(xiàng)目做的面面俱到，但到最后因?yàn)檫^(guò)于注重一些非必要的功能而拖累了性能，這里提到 的就是Memcached的簡(jiǎn)單性。首先它沒(méi)有什么同步，消息分發(fā)，兩階段提交等等，它就是一個(gè)很簡(jiǎn)單的緩存，把東西放進(jìn)去，然后可以取出來(lái)，如果發(fā)現(xiàn)所 提供的Key沒(méi)有命中，那么就很直白地告訴你，你這個(gè)Key沒(méi)有任何對(duì)應(yīng)的東西在緩存里，去數(shù)據(jù)庫(kù)或者其他地方?。划?dāng)你在外部數(shù)據(jù)源取到的時(shí)候，可以直接 將內(nèi)容置入到緩存中，這樣下次就可以命中了。這里介紹一下同步這些數(shù)據(jù)的兩種方式：一種是在你修改了以后立刻更新緩存內(nèi)容，這樣就會(huì)即時(shí)生效；另一種是說(shuō) 容許有失效時(shí)間，到了失效時(shí)間，自然就會(huì)將內(nèi)容刪除，此時(shí)再去取的時(shí)候就不會(huì)命中，然后再次將內(nèi)容置入緩存，用來(lái)更新內(nèi)容。后者用在一些實(shí)時(shí)性要求不高， 寫(xiě)入不頻繁的情況。

客戶端的重要性：Memcached是用C寫(xiě)的一個(gè)服務(wù)端，客戶端沒(méi)有規(guī)定，反正是Socket傳輸，只要語(yǔ)言 支持Socket通信，通過(guò)Command的簡(jiǎn)單協(xié)議就可以通信。但是客戶端設(shè)計(jì)的合理十分重要，同時(shí)也給使用者提供了很大的空間去擴(kuò)展和設(shè)計(jì)客戶端來(lái)滿 足各種場(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ù)庫(kù)向上擴(kuò)容的老大難問(wèn)題無(wú)疑是一劑好藥）；ESB消息緩存。

優(yōu)化MemCached系統(tǒng)Java客戶端的原因

MemCached在大型網(wǎng)站被應(yīng)用得越來(lái)越廣泛，不同語(yǔ)言的客戶端也都在官方網(wǎng)站上有提供，但是Java開(kāi)發(fā)者的選擇并不多。由于現(xiàn)在的 MemCached服務(wù)端是用C寫(xiě)的，因此我這個(gè)C不太熟悉的人也就沒(méi)有辦法去優(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開(kāi)源實(shí)現(xiàn)基礎(chǔ)上做再次封裝。

1. 緩存服務(wù)接口化：定義了IMemCache接口，在應(yīng)用部分僅僅只是使用接口，為將來(lái)替換緩存服務(wù)實(shí)現(xiàn)提供基礎(chǔ)。
2. 使用配置代替代碼初始化客戶端：通過(guò)配置客戶端和SocketIO Pool屬性，直接交由CacheManager來(lái)維護(hù)Cache Client Pool的生命周期，便于單元測(cè)試。
3. KeySet的實(shí)現(xiàn)：對(duì)于MemCached來(lái)說(shuō)本身是不提供KeySet的方法的，在接口封裝初期，同事向我提出這個(gè)需求的時(shí)候，我個(gè) 人覺(jué)得也是沒(méi)有必要提供，因?yàn)榫彺孑喸兪潜容^低效的，同時(shí)這類(lèi)場(chǎng)景，往往可以去數(shù)據(jù)源獲取KeySet，而不是從MemCached去獲取。但是SIP的 一個(gè)場(chǎng)景的出現(xiàn)，讓我不得不去實(shí)現(xiàn)了KeySet。
   SIP在作服務(wù)訪問(wèn)頻率控制的時(shí)候需要記錄在控制間隔期內(nèi)的訪問(wèn)次數(shù)和流量，此時(shí)由于是集群，因此數(shù)據(jù)必須放在集中式的存儲(chǔ)或者緩存中，數(shù)據(jù)庫(kù)肯定撐不住 這樣大數(shù)據(jù)量的更新頻率，因此考慮使用Memcached的很出彩的操作——全局計(jì)數(shù)器 （storeCounter,getCounter,inc,dec），但是在檢查計(jì)數(shù)器的時(shí)候如何去獲取當(dāng)前所有的計(jì)數(shù)器？我曾考慮使用DB或者文件， 但是效率有問(wèn)題，同時(shí)如果放在一個(gè)字段中的話，還會(huì)存在并發(fā)問(wèn)題。因此不得不實(shí)現(xiàn)了KeySet，在使用KeySet的時(shí)候有一個(gè)參數(shù)，類(lèi)型是 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必須正確存在，就需要再多一次的輪詢查找。
4. 集群的實(shí)現(xiàn)：Memcached作為集中式緩存，存在著集中式的致命問(wèn)題：?jiǎn)吸c(diǎn)問(wèn)題。雖然Memcached支持多Instance分布 在多臺(tái)機(jī)器上，但僅僅只是解決了數(shù)據(jù)全部丟失的問(wèn)題，當(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的場(chǎng)景中，如果部分信息找不到就去數(shù)據(jù)庫(kù)查找，很容易將SIP弄垮，因此SIP對(duì)于Memcached中的數(shù)據(jù)認(rèn)為是可信的，做集群也是必要的。
5. LocalCache結(jié)合Memcached使用，提高數(shù)據(jù)獲取效率：在第一次壓力測(cè)試過(guò)程中，發(fā)現(xiàn)和原先預(yù)料的一 樣，Memcached并不是完全無(wú)損失的，Memcached是通過(guò)Socket數(shù)據(jù)交互來(lái)進(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客戶端也可以使用本地的緩存，來(lái)存 儲(chǔ)獲取過(guò)的數(shù)據(jù)，設(shè)置一定的失效時(shí)間，來(lái)減少對(duì)于Memcached的訪問(wèn)次數(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)意的一句話，讓我開(kāi)始了第二階段的優(yōu)化。有同事告訴我說(shuō) Memcached客戶端的SocketIO代碼里面有太多的Synchronized（同步），多多少少會(huì)影響性能。雖然過(guò)去看過(guò)這部分代碼，但是當(dāng)時(shí) 只是關(guān)注里面的Hash算法。根據(jù)同事所說(shuō)的回去一看，果然有不少的同步，可能是作者當(dāng)時(shí)寫(xiě)客戶端的時(shí)候JDK版本較老的緣故造成的，現(xiàn)在 Concurrent包被廣泛應(yīng)用，因此優(yōu)化并不是一件很難的事情。但是由于原有Whalin沒(méi)有提供擴(kuò)展的接口，因此不得不將Whalin除了 SockIO，其余全部納入到封裝過(guò)的客戶端的設(shè)想，然后改造SockIO部分。

結(jié)果也就有了這個(gè)放在Google上的開(kāi)源客戶端：http://code.google.com/p/memcache-client-forjava/。

1. 優(yōu)化Synchronized：在原有代碼中SockIO的資源池被分成三個(gè)池（普通Map實(shí)現(xiàn)），——Free（閑）、Busy（忙） 和Dead（死鎖），然后根據(jù)SockIO使用情況來(lái)維護(hù)這三個(gè)資源池。優(yōu)化方式為首先簡(jiǎn)化資源池，只有一個(gè)資源池，設(shè)置一個(gè)狀態(tài)池，在變更資源狀態(tài)的過(guò) 程時(shí)僅僅變更資源池中的內(nèi)容。然后用ConcurrentMap來(lái)替代Map，同時(shí)使用putIfAbsent方法來(lái)簡(jiǎn)化Synchronized，具體 的代碼可參見(jiàn)Google上該軟件的源文件。
2. 原以為這次優(yōu)化后，效率應(yīng)該會(huì)有很大的提高，但是在初次壓力測(cè)試后發(fā)現(xiàn)，并沒(méi)有明顯的提高，看來(lái)有其他地方的耗時(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é)和批量分頁(yè)Read性能相差很大，因此我內(nèi)置了讀入緩存頁(yè)（可設(shè)置大?。缓笤侔凑諈f(xié)議的需求去讀 取和分析數(shù)據(jù)，結(jié)果顯示效率得到了很大的提高。具體的數(shù)據(jù)參見(jiàn)最后部分的壓力測(cè)試結(jié)果。

上面兩部分的工作不論是否提升了性能，但是對(duì)于客戶端本身來(lái)說(shuō)都是有意義的，當(dāng)然提升性能給應(yīng)用帶來(lái)的吸引力更大。這部分細(xì)節(jié)內(nèi)容可以參看代碼實(shí)現(xiàn)部分，對(duì)于調(diào)用者來(lái)說(shuō)完全沒(méi)有任何功能影響，僅僅只是性能。

壓力測(cè)試比較

在這個(gè)壓力測(cè)試之前，其實(shí)已經(jīng)做過(guò)很多次壓力測(cè)試了，測(cè)試中的數(shù)據(jù)本身并沒(méi)有衡量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的無(wú)第三方依賴的客戶端實(shí)現(xiàn)。checkAlive指的是在使用連接資源以前是否需要驗(yàn)證連接 資源有效（發(fā)送一次請(qǐng)求并接受響應(yīng)），因此啟用該設(shè)置對(duì)于性能來(lái)說(shuō)會(huì)有不少的影響，不過(guò)建議還是使用這個(gè)檢查。

單個(gè)緩存服務(wù)端實(shí)例的各種配置和操作下比較：

從上面的壓力測(cè)試可以看出這么幾點(diǎn)，首先優(yōu)化SockIO提升了不少性能，其次SockIO優(yōu)化的是get的性能，對(duì)于put沒(méi)有太大的作用。原以為獲取數(shù)據(jù)越大性能效果提升越明顯，但結(jié)果并不是這樣。

單個(gè)緩存實(shí)例和雙緩存實(shí)例的測(cè)試比較：

結(jié)果顯示，單個(gè)客戶端對(duì)應(yīng)多個(gè)服務(wù)端實(shí)例性能提升略高于單客戶端對(duì)應(yīng)單服務(wù)端實(shí)例。

緩存集群的測(cè)試比較：

這部分和SocketIO優(yōu)化無(wú)關(guān)。2.0采用的是向集群中所有客戶端更新成功以后才返回的策略，2.2采用了異步更新，并且是分布式客戶端節(jié)點(diǎn)獲取的方式來(lái)分散壓力，因此提升效率很多。

開(kāi)源代碼下載

其實(shí)封裝后的客戶端一直在內(nèi)部使用，現(xiàn)在作了二次優(yōu)化以后，覺(jué)得應(yīng)該開(kāi)源出來(lái)，一是可以完善自己的客戶端代碼，二是也可以和更多的開(kāi)發(fā)者交流使用心 得。目前我已經(jīng)在Google Code上傳了應(yīng)用的代碼、范例和說(shuō)明等，有興趣的朋友可以下載下來(lái)測(cè)試一下，與現(xiàn)在用的Java Memcached客戶端在易用性和性能方面是否有所提高，也期待更多對(duì)于這部分開(kāi)源內(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

【編輯推薦】

1. Java虛擬機(jī)及JVM體系結(jié)構(gòu)
2. Java技能的優(yōu)化集錦
3. Java中Error與Exception的區(qū)別
4. 淺談Java的輸入輸出流
5. jOOQ 2.0發(fā)布 輕量級(jí)Java的ORM框架