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