哨兵机制(Redis Sentinel)

1. 哨兵机制

(1) 哨兵机制的核心功能

① 核心功能是主节点的自动故障转移

(2) 下图是一张典型的哨兵集群监控的逻辑图

 

(3) 哨兵实现了什么功能？

① 监控：哨兵会不断的检查主节点和从节点是否运行正常

② 自动故障转移：当主节点不能正常运行时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个节点升级为新的主节点，并让其他节点改为复制新的主节点

③ 配置提供者：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址

④ 通知：哨兵可以将故障转移的结果发送给客户端

1. 哨兵集群的组建

(1) 哨兵集群是如何组建的？

① 哨兵实例之间可以相互发现，要归公于Redis提供的pub/sub机制，也就是发布/订阅机制

② 实例

1) 在主从集群中，主库上有一个名为__sentinel__:hello的频道，不同哨兵就是通过它来相互发现，实现相互通信的，在下图中，哨兵1把自己的IP(172.16.19.3)和端口(26579)发布到__sentinel__:hello频道上，哨兵2和哨兵3订阅了该频道。此时，哨兵2和哨兵3就可以从这个频道上直接获取哨兵1的IP地址和端口号。然后哨兵2和3就可以和哨兵1建立网络连接

2) 图示

 

1. 哨兵监控Redis库

(1) 哨兵监控什么？如何监控？

① 这是由哨兵向主库发送INFO命令来完成的。如下图，哨兵2给主库发送INFO命令，主库接收到这个命令后，就会把从库列表返回给哨兵。接着哨兵就可以根据从库列表中的连接信息，和每个从库建立连接，并在这个连接上持续地对从库进行监控，哨兵1和哨兵3可以通过相同的方式和从库建立连接

② 图示

 

1. 主库下线的判断

(1) 哨兵如何判断主库已经下线了？

① 分类

1) 主观下线：任何一个哨兵都可以监控探测，并作出Redis节点下线的判断

2) 客观下线：由哨兵集群共同决定Redis是否下线

② 实例

1) 当某个哨兵(如下图中的哨兵2)判断主库”主库下线”后，就会给其他哨兵发送is-master-down-by-addr命令。接着其他哨兵根据自己和主库的连接情况，做出Y或者N的响应，Y相当于赞成票，N相当于反对票

2) 图示

 

如果赞成票数(上面是2)是大于等于哨兵配置文件中的quorum配置项(比如这里如果是quorum=2),则可以判定主库客观下线了

1. 哨兵集群的选取(重点)

(1) 为什么必然会出现选举/共识机制？

① 为了避免哨兵的单点情况的发生，所以需要一个哨兵的分布式集群。作为分布式集群，必然涉及到共识问题(即选举问题)；同时故障的转移和通知都只需要一个主的哨兵节点就可以了

(2) 哨兵的选举机制是什么样的？

① 描述

1) 哨兵的选举机制就是一个Raft选举算法：选举的票数大于等于num(sentinel)/2+1时，将成为领导者，如果没有超过继续选举

(3) 任何一个想要成为Leader的哨兵，要满足两个条件

① 拿到半数以上的赞成票

② 拿到票数的同时还要大于等于哨兵配置文件中的quorum值

(4) 区分判定客观下线和是否能够主从切换(用到选举机制)两个概念

① Redis一主四从，五个哨兵，哨兵配置quorum=2,如果三个哨兵故障，哨兵能否判断主库”客观下线”？能否自动切换?

1) 哨兵集群可以判定主库”主库下线”。由于quorum=2,所以当一个哨兵判断主库”主管下线”后。询问另外一个哨兵也会得到同样的结果，2个哨兵都达到了quorum值，因此，哨兵集群可以判定主库为”客观下线”

2) 哨兵不能完成主从切换。哨兵标记主库”客观下线”后，在选举哨兵领导者时，一个哨兵必须拿到超过多数的选票5/2+1=3.但是，目前只有两个哨兵或者，所以无论如果达不到N/2+1的结果

1. 新主库的选出

(1) 主库既然已经判定客观下线了，那么如果从剩余的从库中选择一个新的主库呢？

① 过滤掉不健康的(下线或断线)，没有回复过哨兵响应的从节点

② 选择slave-priority从优先级最高(redis.conf)的

③ 选择复制偏移量最大，指复制最完整的从节点

④ 图解

 

1. 故障的转移：新的主库选择出来后，就可以开始进行故障的转移了

(1) 实例：假设一开始的图：判断主库客观下线了，同时选出了sentinel3是哨兵的leader）

(2) 故障转移流程下

① 将slave-1脱离原从节点，升级为主节点

② 将从节点slave-2指向新的主节点

③ 通知客户端主节点已经更换

④ 将原主节点变为从节点，指向新的主节点

 

(3) 转移之后