Redis高可用：哨兵机制（Redis Sentinel）详解

1.什么是哨兵机制（Redis Sentinel）

2.哨兵机制基本流程

3.哨兵获取主从服务器信息

4.多个哨兵进行通信

5.主观下线和客观下线

6.哨兵集群的选举

7.新主库的选出

8.故障的转移

9.基于pub/sub机制的客户端事件通知

1.什么是哨兵机制（Redis Sentinel）

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

哨兵机制（sentinel）是Redis解决高可用的一种解决方案：它是由一个或者多个sentinel 实例组成的一个sentinel 系统。

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

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

监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常。
自动故障转移（Automatic failover）：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
配置提供者（Configuration provider）：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。
通知（Notification）：哨兵可以将故障转移的结果发送给客户端。

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

2.哨兵机制基本流程

sentinel(哨兵机制)其实就是一个运行在特殊模式下的Redis服务器。

在服务器初始化时，普通Redis服务器初始化时会通过载入RDB文件或者AOF文件来恢复数据库状态，而sentinel服务器由于不使用数据库，所以它在初始化时无需载入RDB文件或者AOF文件。

我们先看监控。监控指的就是哨兵进程运行时，它会周期性地心跳检测，检测所有主从服务器是否正常运行。心跳检测方式为周期性向主从服务器发送PING命令，若主从服务器在规定时间内响应哨兵进程，则判断该服务器处于存活状态；若主从服务器在规定时间内没有响应哨兵进程，则哨兵进程会判定其下线。

如下图所示，主服务器server2在规定时间内未响应sentinel进程，则sentinel进程判断主服务器server2主观下线，进行选举操作。

若主服务器处于下线状态时，哨兵进程会进行故障转移，也就是重新选主。选主就是会从其所属的多个从服务器中选举一个服务器作为新的主服务器，来提供服务。选举成功后，哨兵进程让已下线主服务器属下的所有从服务器去复制新的主服务器，这一动作会通过向从服务器发送SLAVEOF命令来实现。

如下图，则展示了在故障转移操作中，server1已下线server2选举成为主节点,sentinel节点向已下线主服务器server1的两个从服务器server3发送SLAVEOF命令，进行复制新的主服务器数据信息。

若旧的主服务器重新启动后，会成为新的主服务器的从服务器。

如下图所示，旧主服务器server1重新启动后，会默认成为新主服务器server2的从服务器，进行运行。

哨兵选举出新的主服务器后，会将新主服务器信息发送给客户端，让它和新的主服务器建立连接就行，并不涉及决策的逻辑。但是，在监控和选举过程中，哨兵需要做出两个决策：一个是判断主库是否下线；第二个是在选举过程中，选举哪个从服务器作为新的主服务器，提供服务。

3.哨兵获取主从服务器信息

sentinel(哨兵)进程默认会以每隔10秒一次的频率，通过命令连接向被连接的主服务器发送INFO命令，并通过分析INFO命令返回的数据来获取主服务器的当前信息以及所属从服务器信息。

如下图所示，主服务器server2和其三个从服务器server1、server3、server4。sentinel进程会向主服务器server2发送INFO命令，主服务器会返回对应的主服务器和从服务器的信息。

同理，sentinel进程也会向从服务器发送INFO命令，获取从服务器对应的节点信息。频率默认10秒一次。

4.多个哨兵进行通信

在哨兵集群下，哨兵实例进行通信，是基于Redis提供的pub/sub机制的，也就是发布/订阅模式。

在主从集群中，哨兵节点不会直接与其他哨兵节点建立连接，而是首先会和主库建立起连接，然后向一个名为"_sentinel_:hello"频道发送自己的信息（IP+port），其他订阅了该频道的哨兵节点就会获取到该哨兵节点信息，从而哨兵节点之间互知。

通俗讲，Redis哨兵模式中，哨兵节点的互通是通过订阅指定的频道来进行的，而不是直接与其他sentinel节点建立起连接。

举个例子，假如现在有sentinel1、sentinel2、sentinel3三个sentinel在监控同一个服务器，那么当sentinel1向主服务器的_sentinel_:hello频道发送一条信息时，所有订阅了_sentinel_:hello频道的sentinel(包含sentinel自己在内)都会收到这条消息。如下图所示：

当一个sentinel从_sentinel_:hello频道收到一条消息后，sentinel会对这条信息进行分析，提取出信息中的sentinel IP地址、sentinel端口号、sentinel运行ID等八个参数，并进行检查：

如果信息中记录的sentinel运行ID和接收信息的sentinel的运行ID相同，那么说明这条消息是sentinel自己发送的，sentinel将丢失这条信息，不做进一步处理。
相反地，如果信息记录的sentinel运行ID和接收信息的sentinel的运行ID不相同，那么说明这条信息是监控同一个服务器的其他sentinel发来的，接收信息的sentinel将根据信息中的各个参数，对相应主服务器的实例结构进行更新。

5.主观下线和客观下线

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

主观下线：任何一个哨兵都是可以监控探测，并作出Redis节点下线的判断；
客观下线：有哨兵集群共同决定Redis节点是否下线；

首先先解释一下什么是"主观下线"。

哨兵进程会使用PING命令的方式来检测各个主库和从库的网络连接情况，用来判断实例状态。如果哨兵发现主库或者从库响应超时，那么哨兵会判定其为"主观下线"。

如果哨兵检测从库，发现从库在规定时间内未响应，那么哨兵就会把它标记为"主观下线"，因为从库的下线影响一般不太大，集群的对外服务不会间断。但是，如果检测主库，哨兵不会简单把它标记为"主观下线"，开启主从切换。

因为很有可能会有一种特殊情况：哨兵误判。也就是说主库本身没有故障，但由于哨兵的误判，判断它为下线状态。一旦启动主从切换，后续的选举和通知操作都会带来额外的计算和通信开销。因此，为了不必要开销，我们要严格注意误判的情况。

在哨兵集群中，判定主库是否处于下线状态，不是由一个哨兵来决定的，而是只有大多数哨兵认为主库已经"主观下线"，主库才会标记为"客观下线"。这种判断机制为：少数服从多数。同时会触发主从切换模式。

举个例子，现在有sentinel1、sentinel2、sentinel3三个哨兵和master1一个主库和slave1、slave2、slave3三个从服务器。但sentinel1和sentinel2 判断master1处于上线状态，而sentinel3判断master1处于"主观下线"，那么最终master1仍然为上线状态。

简单的来说，"客观下线"的标准为，当有N个实例，最好要有N/2+1个哨兵实例认为其"主观下线"，那么主库才是"客观下线"。这样的好处减少了误判的概率，避免了不必要的开销。(当然，有多个实例做出"主线下线"的判断才可以，也可以由Redis管理员自行设定)

6.哨兵集群的选举

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

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

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

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

哨兵的选举机制其实很简单，就是一个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选票的结果。

7.新主库的选出

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

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

8.故障的转移

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

假设：判断主库客观下线了，同时选出sentinel 3是哨兵leader

故障转移流程如下：

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

转移之后：

9.基于pub/sub机制的客户端事件通知

从本质上说，哨兵就是一个运行在特定模式的Redis，只不过它并不服务于请求操作，只是完成监控、故障转移、通知的任务。每个哨兵提供pub/sub机制，客户端可以从哨兵订阅消息。

客户端可以从哨兵订阅所有事件，这样客户端不仅可以在主从切换后得到新主库的连接信息，还可以监控主从库切换过程中发生的各个重要事件。

有了pub/sub机制，哨兵和哨兵之间、哨兵与从库之间、哨兵与客户端之间就能连接起来了，再加上上述将的主库判断依据和选举依据，哨兵集群的监控、选举、通知三个任务就可以正常运行了。

总结

sentinel只是一个运行在特殊环境下的Redis，不提供数据存储服务。
sentinel会通过向主服务器发送INFO命令获取主服务器所属的从服务器的地址信息，并为这些从服务器创建相应的实例结构，以及向这些从服务器发送命令连接和订阅连接。

在一般情况下，sentinel会以每10s一次的频率向被监视的主库和从库发送INFO命令，获取主库和从库的相关信息。当主库处于下线状态，或者sentinel正对主服务器进行故障转移操作时，sentinel向从服务发送INFO命令的频率修改为每秒一次。
对于监控同一个主服务器的哨兵来说，他们通过向主服务器的_sentinel_:hello发送消息来向其他sentinel告知自己的存在。其他订阅了该频道的sentinel都可以接收到，从而各个sentinel互知。

sentinel只会与主服务器和从服务器之间建立命令连接和订阅连接，而sentinel之间只会建立命令建立，进行通信。
sentinel会以每秒一次的频率向实例（从服务器、主服务器、其他sentinel）发送PING命令，并根据实例对PING命令的回复来判断实例是否在线，当一个实例在指定时间内未响应PING命令，则判定其为主观下线。