转载自 https://blog.csdn.net/a67474506/article/details/50435498
Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务:
· 监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。
· 提醒(Notification):当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
· 自动故障迁移(Automatic failover):当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。
哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master.
每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown).
若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置.
虽然哨兵(sentinel) 释出为一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel).
哨兵(sentinel) 的一些设计思路和zookeeper非常类似
单个哨兵(sentinel)
启动 6379 6380 6381
配置主从架构
进入redis安装目录
修改哨兵配置文件
vi sentinel.conf
设置 sentinel monitor 为Master 地址
最后面的数字 1 表示最低通过票数
新建一个xshell连接来启动哨兵,可以查看sentinel的控制台信息
redis-sentinel ./sentinel.conf
将6380强制杀掉
等待一会 哨兵的控制台 打印出来 +sdown信息
说明已经监控到slave宕机了
重新启动 6380
哨兵控制台打印
可以看出slave重新加入到了主从复制中
-sdown: 说明是恢复服务
现在将Master 强制杀掉
哨兵控制台打印
我们进入 6381 查看状态
6381 已经是 master了 并且拥有一个 6380的slave
重新启动6379
6379已经恢复,并且将6379设置为6380的slave
这时我们查看sentinel.conf 发现 我们刚刚配置的端口已经变成6381
而6381也有2个slave
查看etc下面的redis.6379.conf 和 redis.6380.conf 发现哨兵(sentinel) 已经对该文件做了修改
6379之前是没有配置,所以就添加到了最后一行
sentinel后台运行和redis的配置文件一样修改daemonize参数
多个哨兵(sentinel)
配置了一个哨兵,如果该哨兵宕机了,那么整个主从架构就回复到了原始的情况,所以我们可以配置多个哨兵,每个哨兵监控Redis信息,并且哨兵之间也会互相监控
修改sentinel.conf中的最低通过票数
在拷贝二份sentinel.conf
cp ./sentinel.conf sentinel.26479.conf
cp ./sentinel.conf sentinel.26579.conf
修改sentinel.26579.conf和sentinel.26479.conf中的port
在新开二个xshell会话,查看26479 和 26579的控制台信息
在每个会话分别启动一个sentinel
此时控制台信息
26379:
增加了2个sentinel
26479:
26579:
强制杀掉6379
Sentinel发现宕机情况
3个都是一样的
重新启动6379,sentinel 打印的信息室一样的
好吧多个sentinel和一个sentinel的效果是一样,那么我们杀掉master试试
和单个哨兵是差不多的
整个故障转移过程是需要啊一个leader来调整的,所以多个sentinel会选举一个leader
在Leader触发failover之前，首先wait数秒(随即0~5)，以便让其他sentinel实例准备和调整, 如果一切正常，那么leader就需要开始将一个salve提升为master，此slave必须为状态良好(不能处于SDOWN/ODOWN状态)且权重值最低(redis.conf中)的，当master身份被确认后，开始failover
另外2个sentinel的控制台信息
26479:
26579:
大概结果就是这样 ╮(╯▽╰)╭
那么我们强行杀掉一个sentinel试试
杀掉之后另外2个sentinel 都打印出了这个结果
仅此而已 其他的暂时没有发现什么东东
详细学习文章:
Redis Sentinel：集群Failover解决方案
http://shift-alt-ctrl.iteye.com/blog/1884370
Redis基于Sentinel哨兵高可用方案
http://www.178linux.com/672
Redis中sentinel集群的搭建和Jedis测试图文教程
http://blog.csdn.net/wtyvhreal/article/details/46517483