几个Cache方案的比较

这两天 try了一些 cache solution，基本都是 memcached一派出来的，但功能和适应的需求还是有很大不一样的，我主要从 replication这个角度来看，因为我们项目中需要用到 replication~~~

Memcachedb

http://memcachedb.org/memcachedb-guide-1.0.pdf

很好的一个介绍，对于功能和使用已经很详细了（一个不大不小的问题，文档更新有点问题哦，竟然自己的私有协议改了 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协议

Tokyo Tyrant

http://blog.s135.com/post/362/

特性：

支持双 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

Repcached

http://repcached.lab.klab.org/

http://dsas.blog.klab.org/archives/51136918.html

http://www.fcicq.net/wp/?p=555

又是一个日本人的 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 <ip_addr> 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
支持 memcached协议
资料较少

总结：

Tokyo Tyrant适合双机 master-master方案， memcachedb适合单 master多 slave方案，如果很在意性能，并且不需要持久化， repcached也是一个不错的选择。

从可靠性上看，双机互备已经是足够了，但只支持双机客观上还是限制了 load-balance对 scalability的贡献（特别是如果读多写少的时候）

从性能上看，读多写少的场景， memcachedb是个不错的选择，当然如果不要持久化可能会更好点（ sina能不能把 persistent作为一个 option阿？）写操作多的时候， repcached应该是最高效的了，其次 Tokyo Tyrant。（此处的性能说明我还没有真实地测过，只是从它们的实现和 benchmark数据推断） ~~~~当然当然，如果不要replication， memcached一定是最优选择了 ~~~

为什么要 replication呢？如果你不单单把它当 cache用，希望及时有机器挂掉，数据都不会丢失 ~~~当然这个问题也有其他解决方案，比如 GFS，扯远了 ~~~

原文发布时间为：2012-06-26

本文来自云栖社区合作伙伴“Linux中国”