Redis HA方案总结

Redis是一个高速的KV数据库，支持丰富的类型，既可以当做cache来使用，也可以当做存储来使用。目前仅支持replication。

因此和MySQL一样，需要外部的一些方案来实现本身的HA。当然和MySQL Cluster一样，Redis作者也在实现Redis Cluster，MySQL Cluster和MySQL区别非常大，使用范围十分有限。

下面是对已有的一些Redis HA方案进行总结，没有万金油的解决方案，需要根据自己的生产环境选择一款，选择“just work”的方案，解决现阶段遇到的问题即可。

一、redis_failover

官方网站

简介：

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





zk中保存三个列表：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客户端，通过客户端的多写随机读来实现高可用。

四、通过Keepalived实现

详细可以参照如下地址。

五、Redis Cluster

目前作者还在开发中，有兴趣的同学围观一些。

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

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