几个Cache方案的比较
| 2012-06-26 07:55
这两天 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,扯远了 ~~~