几个Cache方案的比较

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

## Memcachedb

[http://memcachedb.org/memcachedb-guide-1.0.pdf](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/](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://repcached.lab.klab.org/)

[http://dsas.blog.klab.org/archives/51136918.html](http://dsas.blog.klab.org/archives/51136918.html)

[http://www.fcicq.net/wp/?p=555](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 <num> 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数据推断)

memcached一定是最优选择了 ~~~
1

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

原文:http://blog.csdn.net/zoufeiyy/article/details/4507451