（转）Redis(四)哨兵_sentinel

发现一篇文章写的特别的详细，所以在这里转载，记录一下。照着文章中的内容自己动手实践了。

原文地址：http://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安装目录

修改哨兵配置文件

1. vi sentinel.conf

设置 sentinel monitor 为Master 地址

最后面的数字 1 表示最低通过票数

新建一个xshell连接来启动哨兵,可以查看sentinel的控制台信息

1. 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

1. cp ./sentinel.conf sentinel.26479.conf
2. 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