07 Redis 的哨兵机制

  • 前言
  • 一、哨兵机制的基本流程
  • 二、监控：主库的主观下线和客观下线
  • 三、选主：筛选 + 打分
  • 3.1 筛选的条件
  • 3.2 打分的规则
  • 总结


前言

如果从库发生故障了，客户端可以继续向主库或其他从库发送请求，进行相关的操作，但是如果主库发生故障了，那就直接会影响到从库的同步，因为从库没有相应的主库可以进行数据复制操作了。

而且，如果客户端发送的都是读操作请求，那还可以由从库继续提供服务，但是一旦有写操作请求了，按照主从库模式下的读写分离要求， 需要由主库来完成写操作。没有实例可以来服务客户端的写操作请求了。

redis哨兵会不会宕机 redis哨兵挂了会怎样_数据库

无论是写服务中断，还是从库无法进行数据同步，都是不能接受的。如果主库挂了，就需要运行一个新主库，比如说把一个从库切换为主库，把它当成主库。这就涉及到三个问题：

  • 主库真的挂了吗？
  • 该选择哪个从库作为主库？
  • 怎么把新主库的相关信息通知给从库和客户端呢？

Redis 主从集群中，哨兵机制是实现主从库自动切换的关键机制，它有效地解决了主从复制模式下故障转移的这三个问题。

一、哨兵机制的基本流程

哨兵是一个运行在特殊模式下的 Redis 进程，主从库实例运行的同时，它也在运行。

哨兵主要负责的就是三个任务：监控、选主、通知。

  • 监控：指哨兵进程在运行时，周期性地给所有的主从库发送 PING 命令， 检测它们是否仍然在线运行。如果从库没有在规定时间内响应哨兵的 PING 命令，哨兵就会把它标记为“下线状态”；同样，如果主库也没有在规定时间内响应哨兵的 PING 命令，哨兵就会判定主库下线，然后开始自动切换主库的流程。
  • 选主：主库挂了以后，哨兵需要从多个从库里，按照一定的规则选择一个从库实例，把它作为新的主库。这一步完成后，现在的集群里就有了新主库。
  • 通知：哨兵会把新主库的连接信息发给其他从库，让它们执行 replicaof 命令和新主库建立连接，并进行数据复制。同时哨兵会把新主库的连接信息通知给客户端，让它们把请求操作发到新主库上。

redis哨兵会不会宕机 redis哨兵挂了会怎样_数据库_02

在这三个任务中，通知任务相对来说比较简单，哨兵只需要把新主库信息发给从库和客户端，让它们和新主库建立连接就行，并不涉及决策的逻辑。

但是在监控和选主这两个任务中，哨兵需要做出两个决策：

  • 在监控任务中，哨兵需要判断主库是否处于下线状态；
  • 在选主任务中，哨兵也要决定选择哪个从库实例作为主库。

二、监控：主库的主观下线和客观下线

主观下线：哨兵进程会使用 PING 命令检测它自己和主、从库的网络连接情况，用来判断实例的状态。如果哨兵发现主库或从库对 PING 命令的响应超时了，哨兵就会先把它标记 为“主观下线”。

  • 如果检测的是从库，哨兵简单地把它标记为“主观下线”就行了，因为从库的下线影响一般不太大，集群的对外服务不会间断。
  • 如果检测的是主库，哨兵还不能简单地把它标记为“主观下线”，开启主从切换。因为很有可能存在这么一个情况：那就是哨兵误判了，其实主库并没有故障。可是一旦启动了主从切换，后续的选主和通知操作都会带来额外的计算和通信开销。

注意误判的情况： 主库实际并没有下线，但是哨兵误以为它下线了。误判一般会发生在集群网络压力较大、网络拥塞，或者是主库本身压力较大的情况下。

一旦哨兵判断主库下线了，就会开始选择新主库，并让从库和新主库进行数据同步，这个过程本身就会有开销。
例如，哨兵要花时间选出新主库，从库也需要花时间和新主库同步。而在误判的情况下，主库本身根本就不需要进行切换的，所以这个过程的开销是没有价值的。

正因为这样，需要判断是否有误判，以及减少误判。

哨兵机制采用多实例组成的集群模式进行部署（哨兵集群）。

  • 引入多个哨兵实例一起来判断，避免单个哨兵因为自身网络状况不好，而误判主库下线的情况。
  • 多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。

在判断主库是否下线时，不能由一个哨兵说了算，只有大多数的哨兵实例，都判断主库已经“主观下线”了，主库才会被标记为“客观下线”。

原则是：少数服从多数。这会进一步触发哨兵开始主从切换流程。

如图，Redis 主从集群有一个主库、三个从库，还有三个哨兵实例。左图哨兵 2 判断主库为“主观下线”，但哨兵 1 和 3 却判定主库是上线状态，主库仍然被判断为处于上线状态。右图，哨兵 1 和 2 都判断主库为“主观下线”，此时，即使哨兵 3 仍然判断主库为上线状态，主库也被标记为“客观下线”了。

redis哨兵会不会宕机 redis哨兵挂了会怎样_redis_03

“客观下线”的标准是有 N 个哨兵实例时，最好要有 N/2 + 1 个实例判断主库为“主观下线”，才能最终判定主库为“客观下线”。可以减少误判的概率，也能避免误判带来的无谓的主从库切换。（当然，有多少个实例做出“主观下 线”的判断才可以，也可以由 Redis 管理员自行设定）。

三、选主：筛选 + 打分

  1. 多个从库中，先按照一定的筛选条件，把不符合条件的从库去掉。
  2. 再按照一定的规则， 给剩下的从库逐个打分，将得分最高的从库选为新主库。

redis哨兵会不会宕机 redis哨兵挂了会怎样_database_04

3.1 筛选的条件

一般情况下，要先保证所选的从库仍然在线运行。不过在选主时从库正常在线，这只能表示从库的现状良好，并不代表它就是最适合做主库的。
例如，一个从库正常运行，把它选为新主库开始使用了。很快它的网络出了故障，就得重新选主了。这不是期望的结果。

所以，在选主时除了要检查从库的当前在线状态，还要判断它之前的网络连接状态。
如果从库总是和主库断连，而且断连次数超出了一定的阈值，说明这个从库的网络状况并不是太好，就可以把这个从库筛掉了。

使用配置项 down-after-milliseconds * 10：

  • down-after- milliseconds 是认定主从库断连的最大连接超时时间。
  • 如果在 down-after- milliseconds 毫秒内，主从节点都没有通过网络联系上，就可以认为主从节点断连了。
  • 如果发生断连的次数超过了 10 次，就说明这个从库的网络状况不好，不适合作为新主库。

这样就过滤掉了不适合做主库的从库，完成了筛选工作。

3.2 打分的规则

分别按照三个规则依次进行三轮打分：从库优先级、从库复制进度、从库 ID 号。只要在某一轮中从库得分最高的就是主库了，选主过程到此结束。如果没有出现得分最高的从库，那么就继续进行下一轮。

第一轮：优先级最高的从库得分高。

通过 slave-priority 配置项，给不同的从库设置不同优先级。
比如有两个从库，它们的内存大小不一样，可以手动给内存大的实例设置一个高优先级。在选主时， 哨兵会给优先级高的从库打高分，如果有一个从库优先级最高，那么它就是新主库了。如果从库的优先级都一样，那么哨兵开始第二轮打分。

第二轮：和旧主库同步程度最接近的从库得分高。

选择和旧主库同步最接近的那个从库作为主库，这个新主库上就有最新的数据。
主从库同步时有个命令传播的过程，主库会用 master_repl_offset 记录当前的最新写操作在 repl_backlog_buffer 中的位置，而从库会用 slave_repl_offset 这个值记录当前的复制进度。

想要找的从库，它的 slave_repl_offset 需要最接近 master_repl_offset。
如果在所有从库中，有从库的 slave_repl_offset 最接近 master_repl_offset，那么它的得分就最高，可以作为新主库。

下图，旧主库的 master_repl_offset 是 1000，从库 1、2 和 3 的 slave_repl_offset 分别是 950、990 和 900，从库 2 就应该被选为新主库。

redis哨兵会不会宕机 redis哨兵挂了会怎样_redis_05

当然，如果有两个从库的 slave_repl_offset 值大小是一样的（例如，从库 1 和从库 2 的 slave_repl_offset 值都是 990），就需要给它们进行第三轮打分了。

第三轮：ID 号小的从库得分高。

每个实例都会有一个 ID，这个 ID 就类似于这里的从库的编号。
Redis 在选主库时，有一个默认的规定：在优先级和复制进度都相同的情况下，ID 号最小的从库得分最高，会被选为新主库。

总结

哨兵机制是实现 Redis 不间断服务的重要保证。主从集群的数据同步是数据可靠的基础保证；而在主库发生故障时，自动的主从切换是服务不间断的关键支撑。

Redis 的哨兵机制自动完成了以下三大功能，从而实现了主从库的自动切换，可以降低 Redis 集群的运维开销：

  • 监控主库运行状态，并判断主库是否客观下线；
  • 在主库客观下线后，选取新主库；
  • 选出新主库后，通知从库和客户端。

为了降低误判率，在实际应用时，哨兵机制通常采用多实例的方式进行部署，多个哨兵实例通过“少数服从多数”的原则，来判断主库是否客观下线。可以部署三个哨兵，如果有两个哨兵认定主库“主观下线”，就可以开始切换过程。如果希望进一步提升判断准确率，也可以再适当增加哨兵个数，比如说使用五个哨兵（奇数个）。