Redis高可用性集群方案

snsunny 2013-05-07 01:48:26

基本架构：zookeeper + redis

方案各种资源部署：
1. 1个master和2个以上slave
2. 1个以上zookeeper
3. 1个以上监控组件detector
4. 有watcher功能的client

实现原理：
detector功能
1. 通过detector实时查看Master和Slave的状态
2. 故障或恢复操作
1）master故障，更新zookeeper上的master和slave列表，取一个slave替代master
2）slave故障直接从列表删除，
3）故障机恢复了就增加到slave列表
4）以上根据不同的情况做相应slaveof操作
zookeeper功能
用来存储master和slave列表，承担协调作用
client功能
1. 客户端会watch zookeeper上的列表变动，同步更新，保持自己的数据于zookeeper上一致
2. 对于使用client的用户，基本上永远是可用的，除非机器全部故障

注：以上方案已经过基本测试

...全文

3603 12 打赏收藏转发到动态举报

写回复

用AI写文章

12 条回复

切换为时间正序

请发表友善的回复…

发表回复

snsunny 2014-10-16

打赏
举报

这个方案应该是参考当前各种分布式集群的主流做法，就是client+server才是整个一个完整的应用集群，也就是他有核心，外面一层一层的套壳，好处就是方案灵活多变，易于以后不管的更新发展。有其他使用ip的方案，鉴于长远考虑不建议这个方案，没有很好的整体性

snsunny 2014-10-16

打赏
举报

引用 8 楼 xloogson 的回复:

[quote=引用 5 楼 snsunny 的回复:] 此集群方案也仅仅是过渡方案，在数据量很大时，由于slaveof切换时，redis需要同步一个完整的snapshot，而不是增量，所以需要时间较长，master可能会短时间内影响写入性能。

楼主可以把redis也改造下。加入增量同步。 ps:楼主这个到线上环境了么？[/quote] 对，增量同步是很需要的一个功能，目前还在期待redis3.0的进展目前hbase、hadoop用的比较重，所以redis方向暂时没有太多的精力在上面现在这个方案已经用在线上环境了，但是访问压力不是很大，还没暴露出什么问题建议有兴趣应用的，要针对使用

snsunny 2014-10-16

打赏
举报

不好意思，好久没有上来了@kkion 是第一种情况 master-slave1,master-slave2，slave只有一层，都挂在master下面是你说的这样的，如果master挂掉了，需要把挂在他下面的所有slave都指向新的master上。但是这个failover方案，有规定的实用场景，不适合所有的，比如数据量太大的情况

kkion 2014-03-21

打赏
举报

楼主，请问你的主从部署是怎样的，是 1、master-slave1,master-slave2 还是 2、master-slave1-slave2 若1的情况，当master挂掉了，推slave1作master，那是不是要将slave列表下的所有slave（即slave2）都重新slaveof新的master 若2的情况，当slave1挂掉了，你说直接删除节点，那slave2是也删除还是要slaveof到master，如果slave1前面还有一个slave，那我怎么知道要slaveof到哪个若能回答感激不尽，加QQ951626700

ctcx2008 2013-11-20