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