也谈Redis HA方案总结

xiaozhuaia

　　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不负责转发。