關於分布式快取

快取的目的就是為了提高響應速度，尤其是併發訪問的速度，降低資料庫伺服器的壓力，在同等硬體配置的情況下，提供更高的系統效能。

總的來說，請指導原則就是：盡量用低開銷的計算代替高開銷的計算。比如直接從資料庫查詢的開銷要遠高於記憶體中的計算返回，網路請求要遠高於本地（同一vm中）請求。

如果單從這一點上來分析的話，現在很多關於ehcache（local）與memcached（client/server）效能pk的討論是可以比較簡單的得出乙個結論的。

（老實說，我對memcached的了解只是一知半解。不過國內比較知名的阿里巴巴的系統就是用的memcached，alisoft有個哥們也在這方面有比較深的研究。詳細請參見：

下面圖是國外乙個哥們做的對比，按照greg的測試，ehcache的效能不memcached真的高很多，不過其試驗的詳細過程並沒有資料，所以公證性也受到很多人的懷疑。

因為在liferay框架中使用了ehcache, 對這個快取框架，我倒是做了一些research，下面簡單的羅列一下ehcache在分布式快取方面的知識點。

ehcache的分布式快取

——在分布式情況下，乙個節點的快取發生變動，需要通過廣播通知其他節點。ehcache有兩種通知策略：copy和invalidate。乙個是沒有就拷貝過來，比較自然；另外乙個是如果沒有，那就反過來連自己也取消，這樣就必須重新到資料庫中查詢，網路負載低。

——發現機制。也就是發現其他節點的機制，有兩種，一種是利用rfc1112進行廣播，好處是可以動態增減節點，另外一種是維護乙個靜態列表（ip）。

——傳遞機制。(delivery mechanism) 支援jms, rmi, tcp, udp, 廣播,jxta, jgroups。預設是rmi。

——複製的缺陷和ehcache的解決辦法

☆ 碎嘴的通訊協議（chatty protocal）

因為是乙個網狀拓撲，乙個節點的每個變化需要通知其他n-1個其他節點，造成網路較大的負載。

可以通過批量非同步操作來降低負載。加快對客戶端的響應。

☆ 冗餘的通知

發起通知的不應該收到並處理通知。（因為是廣播，所以會收到）

可以通過為每個cache建立乙個guid來標明身份，這樣如果發起的cache guid與自身相同，則不用處理。

☆ 潛在的資料不一致

這是乙個比較大的問題。只要是分布式儲存，就一定會遇到這個問題。造成這個問題的原因有很多，比如對同一cache的同一資料進行並行更新等；

解決的辦法是通過：同步傳遞。客戶端請求先處於掛起狀態，在同步傳遞並在所有快取中資料都同步之後再返回。

自己的一些設想

在研究關於分布式快取的時候，我不由得想起來分布式資料庫儲存來。這兩者有很多相似的地方，最核心的問題就是保持資料的一致性問題。

當前，在資料的分布式儲存方面的解決方案已經有很多，很多產品、技術都很成熟，是否有一些東西可以借鑑在這裡呢？比如說，記憶體資料庫，資料庫鎖，訊息中介軟體等等。

巧的是，上面那個做對比的哥們greg就這個問題有不同的看法。

確實，確保每個快取中的資料完全的一致是不可能的，總會存在這樣那樣的問題，即使像memcached，也因為沒有commit機制，可能出現乙個node上先放入cache，而最後transaction回滾，但其他的cache node已經為其他使用者提供了這個資料。

所以，分布式快取還只能是具體問題具體分析了。

另外，簡單地總結一下memcached的features如下：

1、請求由client端進行處理，client端維護著乙個memcached伺服器列表，根據使用者的請求將響應指向不同的memcached伺服器；（也就是說，每個緩衝值，在所有伺服器中只保持著乙份copy，不像ehcache每個伺服器中都有）

3、可以動態地，甚至無限地增加memcached伺服器的數量；