❏ 站外平台:

几个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,扯远了 ~~~

via http://blog.csdn.net/zoufeiyy/article/details/4507451



最新评论


返回顶部

分享到微信

打开微信,点击顶部的“╋”,
使用“扫一扫”将网页分享至微信。