幾個Cache方案的比較

這兩天 try了一些 cache solution，基本都是 memcached一派出來的，但功能和适應的需求還是有很大不一樣的，我主要從 replication這個角度來看，因為我們項目中需要用到 replication~~~

<a target="_blank"></a>

<a href="http://memcachedb.org/memcachedb-guide-1.0.pdf" target="_blank">http://memcachedb.org/memcachedb-guide-1.0.pdf</a>

很好的一個介紹，對于功能和使用已經很詳細了（一個不大不小的問題，文檔更新有點問題哦，竟然自己的私有協定改了 readme都不及時更新一下，我是看代碼才知道 rep_ismaster/rep_whoismaster都不能用了，可以用stats repms來代替）

問題：

不支援 cache逾時，得 application自己來判定處理

特性：

支援單 master多 slave（我試驗了 1master+2slave的環境）

隻有 master可寫，所有 node都可以讀（寫會報錯）

支援 fail over，通過 priority可以定義 fail over的政策

部分支援 transaction

可以查詢 master（ stats repms）

資料庫采用 berkeley db

支援 memcached協定

<a href="http://blog.s135.com/post/362/" target="_blank">http://blog.s135.com/post/362/</a>

支援雙 master備份（僅支援雙 master，不支援更多 master）

兩個 master都可讀寫，自動雙機同步

不需要 fail over（都是 master，任何 node壞了都可以繼續 work）

支援單 master多 slave

這種情況下，隻有對 master的寫會被同步，對 slave的寫會是 local write

master會單點故障，并且無法 fail over？

支援雙 master備份，同時多 slave從 master同步

就是上面兩種的組合，對 slave寫是 local write

master可以解決單點故障，但還不是多 master方案（比如有 master a/b， slave c從 a上同步，如果 a壞了， c還是無法自動從 b同步的，是以這個方案不解決什麼問題）

資料庫采用 tokyo cabinet（據說性能更好？）

支援 memcached協定和 http協定

說明：

它的參數 mhost和 mport是指定了 master的 ip/hostname和 port，也就是 replicate的 source，是以：

雙 master就是兩個 node互相指定 mhost和 mport

單 master多 slave就是 master不指定 mhost和 mport， slave指定 mhost和 mport到 master

<a href="http://repcached.lab.klab.org/" target="_blank">http://repcached.lab.klab.org/</a>

<a href="http://dsas.blog.klab.org/archives/51136918.html" target="_blank">http://dsas.blog.klab.org/archives/51136918.html</a>

<a href="http://www.fcicq.net/wp/?p=555" target="_blank">http://www.fcicq.net/wp/?p=555</a>

又是一個日本人的 memcached的擴充（通過 patch），發現日本人在 memcached上做的工作真不少啊 ~~~

它給 memcached加上了 replication的支援，應該說它是一個單 master單 slave的同步方案，本來我想試一下它是否支援更多 node的，結果發現奇怪的事情在于：編譯時如果 —enable-replication就不能 —enable-threads，master在啟動後會 listen replication端口，但一旦有人 connect上來，該端口就不再 listen，這樣就隻能一個client connect上來，是以也就隻能一個 master+一個 slave了，不知道是不是我用得有問題？

repcached的資料相比于前兩個比較少，這裡多說兩句，由于它是 memcached的 patch，是以使用方法和memcached基本相似，隻是多了兩個參數：

-x &lt;ip_addr&gt;  hostname or ip address of peer repcached -x       tcp port number for replication (default: 11212)

在 master上可以通過 -x指定 replication port，在 slave上通過 -x/-x找到 master并 connect上去，事實上，如果同時指定了 -x/-x， repcached一定會嘗試連接配接，但如果連接配接失敗，它就會用 -x參數來自己 listen（成為master）；如果 master壞掉， slave偵測到連接配接斷了，它會自動 listen而成為 master；而如果 slave壞掉，master也會偵測到連接配接斷，它就會重新 listen等待新的 slave加入。

從這方案的技術實作來看，其實它是一個單 master單 slave的方案，但它的 master/slave都是可讀寫的，而且可以互相同步，是以從功能上看，也可以認為它是雙機 master-master方案。

支援單 master單 slave

master-slave間互相同步，二者都可讀寫

master支援 fail over

不支援 persistent

資料較少

tokyo tyrant适合雙機 master-master方案， memcachedb适合單 master多 slave方案，如果很在意性能，并且不需要持久化， repcached也是一個不錯的選擇。

從可靠性上看，雙機互備已經是足夠了，但隻支援雙機客觀上還是限制了 load-balance對 scalability的貢獻（特别是如果讀多寫少的時候）

從性能上看，讀多寫少的場景， memcachedb是個不錯的選擇，當然如果不要持久化可能會更好點（ sina能不能把 persistent作為一個 option阿？）寫操作多的時候， repcached應該是最高效的了，其次 tokyo tyrant。（此處的性能說明我還沒有真實地測過，隻是從它們的實作和 benchmark資料推斷） ~~~~當然當然，如果不要replication， memcached一定是最優選擇了 ~~~

為什麼要 replication呢？如果你不單單把它當 cache用，希望及時有機器挂掉，資料都不會丢失 ~~~當然這個問題也有其他解決方案，比如 gfs，扯遠了 ~~~

<b>原文釋出時間為：2012-06-26</b>

<b>本文來自雲栖社群合作夥伴“linux中國”</b>