大家好，我是 memo，这几天正在看 <<Redis 设计与实现 >> 这本书籍，看到了哨兵机制这块知识点，置信大家在面试中或多或少都会遇到。为此，我做了小笔记，坚固常识。

什么是哨兵机制

哨兵机制（sentinel） 是 Redis 解决高可用的一种解决方案：它是由一个或者多个 sentinel 实例组成的一个 sentinel 零碎。如图所示：

上图显示 sentinel 系统监控着 master 节点和 slave 节点，并且 slave 节点与 master 节点存在数据复制性能。那么问题来了：

• sentinel 零碎如何监控 master 节点和 slave 节点？
• master 节点和 slave 节点复制原理？
• 如果 master 节点呈现故障，sentinel 零碎进行故障转移？
• sentinel 零碎中多个 sentinel 节点如何进行通信？
• sentinel 零碎如何把 master 节点和 slave 节点告诉给客户端？
• sentinel 零碎如何判断 master 库是真的挂了？
• sentinel 零碎到底选举哪个从库为新主库？
  ……

这些问题都会在后续文章中一一解答，心愿能够带着问题来阅读文章，带着本人的思考在文章中寻求解答，心愿能给你们一点帮忙。

sentinel 根本流程

sentinel 其实就是一个运行在非凡模式下的 Redis 服务器。

在服务器初始化时，一般 Redis 服务器初始化时会通过载入 RDB 文件或者 AOF 文件来复原数据库状态，而 sentinel 服务器因为不应用数据库，所以它在初始化时无需载入 RDB 文件或者 AOF 文件。

哨兵机制提供三个性能：监控 、 故障转移 、 告诉。

• 监控：sentinel 零碎能够监控任意多个主服务，以及主服务所属的所有从服务器，监控着他们的生命状态。
• 故障转移：当 Redis 主服务挂掉之后，sentinel 零碎会从其所属的从服务器中选取一台从服务器作为 master 服务器保障服务的高可用。
• 告诉：sentinel 零碎会将主服务节点和从服务器节点相干信息告诉到客户端，让客户端的数据始终为最新状态。

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

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

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

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

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

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

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

sentinel 获取主从服务器信息

sentinel 过程默认会以每隔 10 秒一次的频率，通过命令连贯向被连贯的主服务器发送 INFO 命令，并通过剖析 INFO 命令返回的数据来获取主服务器的以后信息以及所属从服务器信息。

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

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

多个 sentinel 进行通信

在哨兵集群下，哨兵实例进行通信，是基于 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 将依据信息中的各个参数，对相应主服务器的实例构造进行更新。

主观下线和主观下线

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

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

如果哨兵检测从库，发现从库在规定工夫内未响应，那么哨兵就会把它标记为 ” 主观在线 ”，因为从库的下线影响个别不太大，集群的对外服务不会间断。然而，如果检测主库，哨兵不会简略把它标记为 ” 主观在线 ”，开启主从切换。

因为很有可能会有一种非凡状况：哨兵误判。也就是说主库自身没有故障，但因为哨兵的误判，判断它为下线状态。一旦启动主从切换，后续的选举和告诉操作都会带来额定的计算和通信开销。因而，为了不必要开销，咱们要严格留神误判的状况。

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

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

简略的来说，” 主观下线 ” 的规范为，当有 N 个实例，最好要有 N /2+ 1 个哨兵实例认为其 ” 主观下线 ”，那么主库才是 ” 主观下线 ”。 这样的益处缩小了误判的概率，防止了不必要的开销。(当然，有多个实例做出 ” 主线下线 ” 的判断才能够，也能够由 Redis 管理员自行设定)

选举新库

当哨兵开始进行主从切换时，哨兵如何进行选举新的主库呢？它到底遵循什么样的机制？

一般来说，我把哨兵选举新主的过程总结为“ 筛选 + 排序“。首先，哨兵会依照肯定的筛选机制筛选掉不符合要求的从库，而后从符合条件的从库中进行排序，从而诞生出新库。

上述我把哨兵选举的过程称为 ”筛选 + 排序“，那么接下来说一下筛选机制和排序机制。

首先先说 筛选机制。

• 筛除掉所有处于下线或者断线状态的从服务器，这能够保障残余的从服务器都是失常在线的。
• 筛除掉所有在规定工夫内没有响应哨兵的 INFO 命令的从服务器，这能够保障残余的从服务器都是最近胜利进行通信的。
• 筛除掉所有与已下线主服务器连贯断开超过 down-after-milliseconds*10 毫秒的从服务器，这样能够保障残余的从服务器都没有过早地与主服务器断开连接，换句话来说，列表中的从服务器保留的数据都是比拟新的。

上述的为筛选机制，接下来 排序机制。

• 哨兵会依据从服务器的优先级，对列表中残余的从服务器进行排序，选出优先级最好的从服务器。
• 若有多个雷同最好优先级的从服务器，那么哨兵会依照复制偏移量对具备雷同优先级的所有从服务器进行排序，并选出其中偏移量最大的从服务器。
• 若有多个优先级最高、复制偏移量最大的从服务器，那么哨兵将依照运行 ID 对这些从服务器进行排序，并选出其中运行 ID 最小的从服务器。

到这里，新主库就被选出来了，” 选举 ” 过程实现。咱们来回顾一下选举过程。首先哨兵会筛选掉已下线、断线状态、网络状态不好的从服务器，其次，会依据从服务器优先级、复制偏移量、运行 ID 方面进行排序，最终失去一个从服务器，那么该从服务器为新的主服务器。

基于 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 命令，则断定其为主观下线。
• 在哨兵集群下，当 sentinel 收到足够多的主观下线投票之后，他会将主服务器判断为主观下线，并发动一个针对主服务器的故障转移操作。

到这里，Redis 哨兵机制内容也完结了，咱们下期再见！！！

我是 memo，一个 IT 界的小学生。