Redis—哨兵集群—工作原理

Redis哨兵系列文章目录

一、基础
二、常规命令
三、工作原理
四、主从切换

---

在redis sentinel集群中，如果主库挂了，需要新运行一个主库，比如说把一个从库切换为主库，把它当成主库。

---

前言

因为Sentinel实现Redis服务的主从切换功能，以实现Redis服务的高可用。通常是以Sentinel集群的方式实现对集高可用的功能实现。在哨兵集群中，将从库切换为主库时，我们需要确定：

1. 如何确定主库服务异常
2. 如何选择哪个从库做为主库

---

一、哨兵的机制

  哨兵如何实现Redis的主从切换呢？哨兵其实就是一个运行在特殊模式下的 Redis 进程，主从库实例运行的同时，它也在运 行。哨兵主要负责的就是三个任务：监控、选主（选择主库）和通知。

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

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

• 在监控任务中，哨兵需要判断主库服务是否异常；
• 在选主任务中，哨兵也要决定选择哪个从库实例作为主库。

当切换redis主从实例时,会重新写redis的conf文件

二、主库真的挂了吗？

sentinel如何判断master节点服务真的挂了吗？在实际判断中，哨兵对主库的下线判断有“主观下线”和“客观下线”两种

1.主观下线

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

2.客观下线

  Sentinel通常会采用多实例组成的集群模式进行部署，这也被称为哨兵集群。引入多个Sentinel实例一起来判断，就可以避免单个Sentinel因为自身网络状况不好或其他原因误判主库下线的情况。多个Sentinel的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。
  在判断主库是否下线时，不能由一个哨兵说了算，只有大多数的哨兵实例，都判断主库已 经“主观下线”了，主库才会被标记为“客观下线”，这个判断原则就是：少数服从多数。这个叫法也是表明主库下线成为一 个客观事实了。

3.为什么需要客观下线

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

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

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

三、新主库选择

新主库选择：哨兵在选择新主库时,先按照一定的筛选条件,把不符合条件的从库去掉。再按照一定的规则,给剩下的从库逐个打分，将得分最高的从库选为新主库。

1.从库筛选

  在选主时，除了要检查从库的当前在线状态，还要判断它之前的网络连接状态。如果从库总是和主库断连，而且断连次数超出了一定的阈值，表明这个从库的网络状况并不是太好，就可以把这个从库去掉了。
  在sentinel配置项down-after-milliseconds * 10中，down-after-milliseconds 是认定主从库断连的最大连接超时时间。如果在 down-aftermilliseconds 毫秒内，主从节点都没有通过网络联系上，就可以认为主从节点断连 了。如果发生断连的次数超过了 10 次，就说明这个从库的网络状况不好，不适合作为新主库。

2.从库分数判断

  Sentinle集群选主中，分别按照三个规则依次进行三轮打分，这三个规则分别是从库优先级、从库复制进度以及从库 ID 号。只要在某一轮中，有从库得分最高，那么它就是主库了，选主过程到此结束。如果没有出现得分最高的从库，那么就继续进行下一轮。
第一轮：优先级最高的从库得分高
  用户可以通过 slave-priority 配置项，给不同的从库设置不同优先级。比如，有两个从 库，它们的内存大小不一样，可以手动给内存大的实例设置一个高优先级。在选主时， 哨兵会给优先级高的从库打高分，如果有一个从库优先级最高，那么它就是新主库了。如 果从库的优先级都一样，那么哨兵开始第二轮打分。

第二轮：和旧主库同步程度最接近的从库得分高
  这个规则的依据是，如果选择和旧主库同步最接近的那个从库作为主库，那么，这个新主 库上就有最新的数据。

如何判断从库和旧主库间的同步进度呢？
  主从库同步时有个命令传播的过程。在这个过程中，主库会用master_repl_offset记录当前的最新写操作在 repl_backlog_buffer 中的位置，而从库会用slave_repl_offset这个值记录当前的复制进度。
  此时，我们想要找的从库，它的 slave_repl_offset 需要最接近 master_repl_offset。如果 在所有从库中，有从库的 slave_repl_offset 最接近 master_repl_offset，那么它的得分就最高，可以作为新主库。并不是取slave_repl_offset 与master_repl_offset做对比，而是不同从库的slave_repl_offset进行对比的，因为这个时候master已经挂掉了，无法获取master_repl_offset。所以在实际的选主代码中，哨兵在这一步，是通过比较不同从库的slave_repl_offset，找出最大slave_repl_offset的从库。也就是选择salve_repl_offset最大的那个从库。

master_repl_offset机制
    master_repl_offset是单调增加的，它的值可以大于repl_backlog_size。Redis会用一个名为repl_backlog_idx的值记录在环形缓冲区中的最新写入位置。
    举个例子，例如写入len的数据，那么 master_repl_offset += len > repl_backlog_idx += len，但是，如果repl_backlog_idx等于repl_backlog_size时，repl_backlog_idx会被置为0，表示从环形缓冲区开始位置继续写入。

第三轮：ID 号小的从库得分高
  每个实例都会有一个 ID，这个 ID 就类似于这里的从库的编号。目前，Redis 在选主库 时，有一个默认的规定：在优先级和复制进度都相同的情况下，ID 号最小的从库得分最 高，会被选为新主库。
  Redis server启动时，会生成一个40字节长的随机字符串作为runID，具体算法用的是 SHA-1算法。

总结

  至此通过对主节点客观下线和从库的选举，Sentinel实现Redis集群的主从切换的功能。

参考：Redis核心技术与实战