也谈Redis HA方案总结

Redis是一个Key Value数据库，支持丰富的数据类型，可以用做cache来也可以用做storage。目前仅支持replication。

以下是对Redis HA方案进行总结，没有万能的解决方案，需要根据自己的生产环境的业务情况不断修改和完善自己的方案。

一、redis_failover

官方网站

简介：

使用ruby编写，通过NodeManager检查redis服务器的状态，然后更新zookeeper中的列表，zookeeper来维护当前可用服务器列表。

zookeeper中保存三个列表：master、slaves、unavailable。

NodeManager通过配置文件读取node列表。

每个node一个NodeWatcher线程，每隔2秒钟检查一次node的状态（syncing、available、unavailable）
如果node连续max_failures次失败的话，设置为unavailable
NodeWatcher将 状态存放在NodeManager的状态queue中

NodeManager的一个线程定期的检查queue中的状态，对状态进行处理：
1.unavailable
处理时判断node是否为master，如果为master则执行promote_new_master将选出新的master并对剩余的slave执行slaveof，如果是slave的话，则从slave列表中移除
2.syncing
将node加入到unavailable列表中，并从slave列表中移除
3.available
判断node是否在当前的available列表中，如果不在列表中，则加入到available列表中。

可以部署多个NodeManager，一个时间只有一个 NodeManager处于可用状态，多个NodeManager注册到zookeeper中。

缺点:

1．现有代码需要进行改造，以支持通过zookeeper来获取可用的服务列表（有现成的客户端）。

2．没有考虑到多机房的本地化原则（可以通过增加客户端的判断逻辑来进行）。

3．只有一个active的NodeManager节点，如果该NodeManager节点的网络出现问题，则会出现误操作的现象。

二、redis + sentinel （官方）

官方网站

简介：通过多个Sentinel一起监控redis集群，检测到master不可用时，通过投票来决定master是否需要切换。Sentinel 之间互相检测（通过在共同检测的master中写入信息来进行），Sentinel 只需要配置master节点，自动通过master来获取已经连接的slave列表。当其中的某一个Sentinel 检测到master宕机之后，标示master为SDOWN，向其他的Sentinel 发送SENTINEL is-master-down-by-addr命令来进行投票，投票确认之后标识为ODOWN，开始选择一个新的master，并且进行切换。

缺点：

1． 没有合适的客户端，需要自己处理各种事件。

2． 目前还没有release。

 

三、redis 双写

通过应用服务器在程序侧写入到两个节点来进行高可用.

缺点：

1. 数据的一致性比较欠缺。（程序侧采用随机读，如果网络出现抖动延迟，写入数据延迟，随机导致读取的数据不一致,所以后来双写的读写都在同一个节点上而不是随机读，尽量保证数据一致性）

2. 当其中一台master挂掉之后，后续添加新的master进行运维成本比较高。（手动重做主从复制）

典型的一个实现是淘宝的tedis，是一个redis的java客户端，通过客户端的多写随机读来实现高可用。

 

四、redis + keepalived

 

五、redis cluster

完全的一个分布式解决方案，通过hash和自身的replication实现水平扩展和高可用。

不存在类似于HBase Meta表一样的索引表，客户端在访问随机一台redis server时，redis server告知map of hash slots和nodes之间的关系，客户端缓存起来，下次访问自己进行路由；cluster发生变化之后，客户端访问时出出错并告知正确的信息然后重新访问。cluster不负责转发。