Redis集群研究.docx

Redis Sentinel 数据库 M-S 配置(Redis 的分片与复制集技术) 1. Redis Sentinel 介绍 Redis Sentinel 是Redis 官方提供的集群管理工具,主要有三大功能: 监控,能持续监控 Redis 的主从实例是否正常工作; 通知,当被监控的 Redis 实例出问题时,能通过 API 通知系统管理员或其他程序; 自动故障恢复,如果主实例无法正常工作, Sentinel 将启动故障恢复机制把一个从实例提升为主实例,其他的从实例将会被重新配置到新的主实例,且应用程序会得到一个更换新地址的通知。 Redis Sentinel 是一个分布式系统,可以部署多个 Sentinel 实例来监控同一组 Redis 实例,它们通过 Gossip 协议来确定一个主实例宕机,通过 Agreement 协议来执行故障恢复和配置变更,一般在生产环境中部署多个实例来提高系统可用性,只要有一个 Sentinel 实例运行正常,就能保证被监控的 Redis 实例运行正常(类似 Zookeeper ,通过多个 Zookeeper 来提高系统可用性); 2. Redis HA 方案 HA的关键在于避免单点故障及故障恢复,在 Redis Cluster 未发布之前, Redi s 一般以主/从方式部署(这里讨论的应用从实例主要用于备份,主实例提供读写, 有不少应用是读写分离的,读写操作需要取不同的 Redis 实例,该方案也可用于此种应用,原理都是相通的,区别在于数据操作层如何封装),该方式要实现 HA主要有如下几种方案: 1).keepalived :通过 keepalived 的虚拟 IP ,提供主从的统一访问,在主出现问题时,通过 keepalived 运行脚本将从提升为主,待主恢复后先同步后自动变为主,该方案的好处是主从切换后,应用程序不需要知道( 因为访问的虚拟 IP 不变),坏处是引入 keepalived 增加部署复杂性; 2).zookeeper :通过 zookeeper 来监控主从实例,维护最新有效的 IP ,应用通过zookeeper 取得 IP,对 Redis 进行访问; 3).sentinel :通过 Sentinel 监控主从实例,自动进行故障恢复,该方案有个缺陷:因为主从实例地址(IP&PORT) 是不同的,当故障发生进行主从切换后, 应用程序无法知道新地址,故在 中新增了对 Sentinel 的支持,应用通过 () 取得的 Jedi s 实例会及时更新到新的主实例地址。笔者所在的公司先使用了方案 1 一段时间后,发现 keepalived 在有些情况下会导致数据丢失, keepalived 通过 shell 脚本进行主从切换, 配置复杂,而且 keepalived 成为新的单点,后来选用了方案 3,使用 Redis 官方解决方案;(方案2 需要编写大量的监控代码,没有方案 3 简便,网上有人使用方案 2 读者可自行查看) Sentinel&Jedis 看上去是个完美的解决方案,这句话只说对了一半,在无分片的情况是这样,但我们的应用使用了数据分片-sharing ,数据被平均分布到 4 个