redis哨兵机制详解

前言

Redis Sentinel，即Redis哨兵，在Redis 2.8版本开始引入。哨兵的核心功能是主节点的自动故障转移。

下图是一个典型的哨兵集群监控的逻辑图：

哨兵实现了什么功能呢？下面是Redis官方文档的描述：

监控（Monitoring）

哨兵会不断地检查主节点和从节点是否运作正常。

自动故障转移（Automatic failover）

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

配置提供者（Configuration provider）

客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。

通知（Notification）

哨兵可以将故障转移的结果发送给客户端。

其中，监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移；而配置提供者和通知功能，则需要在与客户端的交互中才能体现。

哨兵集群的组建

上图中哨兵集群是如何组件的呢？哨兵实例之间可以相互发现，要归功于 Redis 提供的 pub/sub 机制，也就是发布 / 订阅机制。

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

通过这个方式，哨兵 2 和 3 也可以建立网络连接，这样一来，哨兵集群就形成了。它们相互间可以通过网络连接进行通信，比如说对主库有没有下线这件事儿进行判断和协商。

哨兵监控Redis库

哨兵监控什么呢？怎么监控呢？

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

主库下线的判定

哨兵如何判断主库已经下线了呢？

首先要理解两个概念：主观下线和客观下线

主观下线

任何一个哨兵都是可以监控探测，并作出Redis节点下线的判断；

客观下线

有哨兵集群共同决定Redis节点是否下线；

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

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

哨兵集群的选举

判断完主库下线后，由哪个哨兵节点来执行主从切换呢？这里就需要哨兵集群的选举机制了。

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

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

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

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

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

第一，拿到半数以上的赞成票；
第二，拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。

以 3 个哨兵为例，假设此时的 quorum 设置为 2，那么，任何一个想成为 Leader 的哨兵只要拿到 2 张赞成票，就可以了。

更进一步理解

这里很多人会搞混 判定客观下线 和 是否能够主从切换（用到选举机制） 两个概念，我们再看一个例子。

案例

Redis 1主4从，5个哨兵，哨兵配置quorum为2，如果3个哨兵故障，当主库宕机时，哨兵能否判断主库“客观下线”？能否自动切换？

经过实际测试

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

2、但哨兵不能完成主从切换。哨兵标记主库“客观下线后”，在选举“哨兵领导者”时，一个哨兵必须拿到超过多数的选票(5/2+1=3票)。但目前只有2个哨兵活着，无论怎么投票，一个哨兵最多只能拿到2票，永远无法达到N/2+1选票的结果

新主库的选出

主库既然判定客观下线了，那么如何从剩余的从库中选择一个新的主库呢？

1、过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点
2、选择salve-priority从节点优先级最高（redis.conf）的
3、选择复制偏移量最大，只复制最完整的从节点
4、最后是runid最小的

故障的转移

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

假设根据我们一开始的图：（我们假设：判断主库客观下线了，同时选出sentinel 3是哨兵leader）

故障转移流程如下

将slave-1脱离原从节点（PS: 5.0 中应该是replicaof no one)，升级主节点，
将从节点slave-2指向新的主节点
通知客户端主节点已更换
将原主节点（oldMaster）变成从节点，指向新的主节点

转移之后

脑裂问题

什么是脑裂

从名字分析，脑裂现象就是大脑裂开了，一个人如果有两个大脑，就出现了两个决策者，此时身体就不知道该听谁的了，势必会造成混乱。

对应到 Redis 上，就是指在主从集群中，同时有两个主节点，它们都能接收写请求，那么什么时候会出现这种情况呢？

就是如果当前主库突然出现暂时性 “失联”，而并不是真的发生了故障，此时监听的哨兵会自动启动主从切换机制。当这个原始的主库从假故障中恢复后，又开始处理请求，但是哨兵已经选出了新的主库，这样一来，旧的主库和新主库就会同时存在，这就是脑裂现象。

脑裂有什么影响

脑裂最直接的影响，就是客户端不知道应该往哪个主节点写入数据，结果就是不同的客户端会往不同的主节点上写入数据。严重的话，脑裂会进一步导致数据丢失。也就是说，等到哨兵让原主库和新主库做全量同步后，原主库在切换期间保存的数据就丢失了。

数据丢失一定是发生了脑裂吗？

那可能你想问了，数据丢失一定是发生了脑裂吗？如何判断发生了脑裂？

数据丢失不一定是发生了脑裂，最常见的原因是主库的数据还没有同步到从库，结果主库发生了故障，等从库升级为主库后，未同步的数据就丢失了。

如果是这种情况的数据丢失，我们可以通过比对主从库上的复制进度差值来进行判断，也就是计算 master_repl_offset 和 slave_repl_offset 的差值。如果从库上的 slave_repl_offset 小于原主库的 master_repl_offset，那么，我们就可以认定数据丢失是由数据同步未完成导致的。

而判断是否发生了脑裂，可以采取排查客户端的操作日志的方式。

通过看日志能够发现，在主从切换后的一段时间内，会有客户端仍然在和原主库通信，并没有和升级的新主库进行交互，这就相当于主从集群中同时有了两个主库。根据这个迹象，我们就可以判断可能是发生了脑裂。

如何解决脑裂问题？

Redis 中有两个关键的配置项可以解决这个问题，分别是 min-slaves-to-write（最小从服务器数） 和 min-slaves-max-lag（从连接的最大延迟时间）。

min-slaves-to-write

是指主库最少得有 N 个健康的从库存活才能执行写命令。

这个配置虽然不能保证 N 个从库都一定能接收到主库的写操作，但是能避免当没有足够健康的从库时，主库无法正常写入，以此来避免数据的丢失 ，如果设置为 0 则表示关闭该功能。

min-slaves-max-lag

是指从库和主库进行数据复制时的 ACK 消息延迟的最大时间；

可以确保从库在指定的时间内，如果 ACK 时间没在规定时间内，则拒绝写入。

这两个配置项组合后的要求是，主库连接的从库中至少有 N 个从库，和主库进行数据复制时的 ACK 消息延迟不能超过 T 秒，否则，主库就不会再接收客户端的请求了。

这样一来，即使原主库是假故障，它在假故障期间也无法响应哨兵发出的心跳测试，也不能和从库进行同步，自然也就无法和从库进行 ACK 确认了。

此时的 min-slaves-to-write 和 min-slaves-max-lag 的组合要求就无法得到满足，原主库就会被限制接收客户端请求，客户端也就不能在原主库中写入新数据，就可以避免脑裂现象的发生了。