Redis高可用集群-哨兵模式(Redis-Sentinel)

 前言
Redis哨兵模式,用现在流行的话可以说就是一个“哨兵机器人”,给“哨兵机器人”进行相应的配置之后,这个"机器人"可以7*24小时工作,它能能够自动帮助你做一些事情,如监控,提醒,自动处理故障等。
 
Redis-sentinel简介
Redis-sentinel是Redis的作者antirez,因为Redis集群的被各大公司使用,每个公司要写自己的集群管理工具,于是antirez花了几个星期写出了Redis-sentinel。
 
Redis 的 Sentinel 系统用于管理多个 Redis 服务器(instance),Redis 的 Sentinel 为Redis提供了高可用性。使用哨兵模式创建一个可以不用人为干预而应对各种故障的Redis部署。
 
该系统执行以下三个任务:
 
监控(Monitoring):Sentinel会不断地检查你的主服务器和从服务器是否允许正常。
提醒(Notification):当被监控的某个Redis服务器出现问题时,Sentinel可以通过API向管理员或者其他应用程序发送通知。
自动故障迁移(Automatic failover):
(1)当一个主服务器不能正常工作时,Sentinel会开始一次自动故障迁移操作,他会将失效主服务器的其中一个从服务器升级为新的主服务器,并让失效主服务器的其他从服务器改为复制新的主服务器;
(2)客户端试图连接失败的主服务器时,集群也会向客服端返回新主服务器的地址,是的集群可以使用新主服务器代替失效服务器。

sentinel的分布式特性
Redis Sentinel 是一个分布式系统, 你可以在一个架构中运行多个 Sentinel 进程(progress), 这些进程使用流言协议(gossip protocols)来接收关于主服务器是否下线的信息, 并使用投票协议(agreement protocols)来决定是否执行自动故障迁移, 以及选择哪个从服务器作为新的主服务器。
 
单个sentinel进程来监控redis集群是不可靠的,当sentinel进程宕掉后(sentinel本身也有单点问题,single-point-of-failure)整个集群系统将无法按照预期的方式运行。所以有必要将sentinel集群,这样有几个好处:
 
有一些sentinel进程宕掉了,依然可以进行redis集群的主备切换;
 
如果只有一个sentinel进程,如果这个进程运行出错,或者是网络堵塞,那么将无法实现redis集群的主备切换(单点问题);
 
如果有多个sentinel,redis的客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息
 
一个健壮的部署至少需要三个哨兵实例。
 
三个哨兵实例应该放置在客户使用独立方式确认故障的计算机或虚拟机中。例如不同的物理机或不同可用区域的虚拟机。

Redis-Sentinel高可用场景演示
场景1:主服务器master宕机
当主服务器master宕机,那么Sentinel会通过选举(算法)机制,从Salve中选出一个作为新Master。
大概原理是当选出一个Slave要作为Master的时候,会发送命令slaveofno one来取消选中的这个slave,使其成为Master。哨兵会发送给其他从服务器Slave配置选中的这个为新主服务器Master,并删除监听列表中出现故障的Master服务器。
(1)关闭掉 6379主服务器
(2)查看观察选举新的master的过程和显示了failover的过程,整个日志信息还是比较完整的。最后选举了6381为主服务器! 
(3)查看6381服务器信息,角色为主,从服务器6380!

场景2:之前故障的6379 master重新启动

(1)启动6379服务,发现6379成为6381的从服务器!
(2)查看6381服务器状态信息:原来的master自动切换成slave,不会自动恢复成master。

场景3:从服务器Slave宕机和重启

(1)关闭6380从服务器
(2)Sentinel日志
(3)查看住服务器6381状态信息
(4)启动从服务器6380
(5)查看住服务器6381状态信息:6380又回来了!

总结
Redis-Sentinel是Redis官方推荐的高可用性(HA) 解决方案,Redis-sentinel本身也是一个独立运行的进程,它能监控多个master-slave集群,发现master宕机后能进行自动切换。Sentinel可以监视任意多个主服务器(复用),以及主服务器属下的从服务器,并在被监视的主服务器下线时,自动执行故障转移操作。
为了防止sentinel的单点故障,可以对sentinel进行集群化,创建多个sentinel。

猜你喜欢

转载自www.cnblogs.com/starluke/p/11735081.html