Redis高可用进阶之哨兵机制原理

（一）概述

上篇文章我们主要说了Redis主从复制的内容，但Redis主从复制有一个缺点，当Master宕机以后，我们需要人工解决，比如使用slaveof no one命令。实际上主从复制并没有实现真正的高可用。高可用侧重备份机器， 利用集群中系统的冗余，当系统中某台机器发生损坏的时候，其他后备的机器可以迅速的接替它来启动服务。很显然，我们需要一个机制来对主从复制进行增强，使得其真正可以做到高可用，于是哨兵模式就应运而生了。

Redis Sentinel（哨兵）是一个分布式架构，其中包含若干个Sentinel节点和Redis数据库节点，每个Sentinel节点会对数据库节点和其余Sentinel节点进行监控，当它发现节点不可达时，会对节点做下线标识。如果被标识的是主节点，它还会和其他Sentinel节点进行“协商”，当大多数Sentinel节点都认为主节点不可达时，它们会选举出一个Sentinel节点来完成自动故障转移的工作，同时会将这个变化实时通知给Redis应用方。整个过程完全是自动的，不需要人工来介入，所以这套方案很有效地解决了 Redis 的高可用问题。

（二）故障转移流程

1. 主节点故障

主节点出现故障，此时两个从节点与主节点失去连接，主从复制失败：

按照一般的主从复制架构，我们需要手动将一个从节点变成主节点。但是有了哨兵模式之后，我们可以让其自动完成，无需人工干预。

2. 多哨兵监控

每个Sentinel节点通过定期监控发现主节点出现了故障：

每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他Sentinel实例发送一个PING命令。如果一个实例距离最后一次有效回复PING命令的时间超过own-after-milliseconds选项所指定的值，则这个实例会被Sentinel标记为主观下线。如果一个Master被标记为主观下线，则正在监视这个Master的所有Sentinel要以每秒一次的频率确认Master的确进入了主观下线状态。当有足够数量的Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态，则Master会被标记为客观下线。

在一般情况下，每个Sentinel会以每10秒一次的频率向它已知的所有Master，Slave发送INFO命令。当Master被Sentinel标记为客观下线时，Sentinel向下线的Master的所有Slave发送INFO命令的频率会从10秒一次改为每秒一次。若没有足够数量的Sentinel实例同意Master已经下线，Master的客观下线状态就会被移除。若 Master重新向Sentinel的PING命令返回有效回复，Master的主观下线状态就会被移除。

3. 选举领导者

发现主节点发生故障之后，多个Sentinel节点对主节点的故障达成一致意见，然后会选举出其中一个节点作为领导者负责故障转移操作：

一个redis服务被判断为客观下线时，多个监视该服务的sentinel协商，选举一个领头sentinel，负责对该redis服务进行故障转移操作。选举领头sentinel遵循以下规则：

• 所有的sentinel都有公平被选举成领头的资格。
• 所有的sentinel都有且只有一次将某个sentinel选举成领头的机会（在一轮选举中），一旦选举某个sentinel为领头，不能更改。
• sentinel设置领头sentinel是先到先得，一旦当前sentinel设置了领头sentinel，以后其他sentinel要求成为领头请求都会被拒绝。
• 每个发现服务客观下线的sentinel，都会要求其他sentinel将自己设置成领头。
• 当一个sentinel（源sentinel）向另一个sentinel（目sentinel）发送is-master-down-by-addr ip port current_epoch runid命令的时候，runid参数不是*，而是sentinel运行id，就表示源sentinel要求目标sentinel选举其为领头。
• 源sentinel会检查目标sentinel对其要求设置成领头的回复，如果回复的leader_runid和leader_epoch为源sentinel，表示目标sentinel同意将源sentinel设置成领头。
• 如果某个sentinel被半数以上的sentinel设置成领头，那么该sentinel成为领头。
• 如果在限定时间内，没有选举出领头sentinel，暂定一段时间，再选举。

那么为什么Redis要设计这个领导者的选取过程呢？简单来说，就是因为只能让一个sentinel节点去完成故障转移。

4. 自动故障转移

Sentinel领导者节点执行了故障转移操作，整个过程基本是跟我们手动调整一致的，只不过是自动化完成的：

所谓故障转移就是当master宕机，选一个合适的slave来晋升为master的操作，sentinel会自动完成这个，不需要我们手动来实现。一次故障转移操作大致分为以下流程：

• 发现主服务器已经进入客观下线状态。
• 对当前集群进行自增，并尝试在这个集群中当选。
• 如果当选失败，那么在设定的故障迁移超时时间的两倍之后，重新尝试当选。 如果当选成功，那么执行下面的步骤：
• 选出一个从服务器，并将它升级为主服务器。
• 向被选中的从服务器发送SLAVEOF NO ONE命令，让它转变为主服务器。
• 通过发布与订阅功能， 将更新后的配置传播给所有其他Sentinel ，其他Sentinel对它们自己的配置进行更新。
• 向已下线主服务器的从服务器发送SLAVEOF命令，让它们去复制新的主服务器。
• 当所有从服务器都已经开始复制新的主服务器时，领头Sentinel终止这次故障迁移操作。

每当一个Redis实例被重新配置（reconfigured），无论是被设置成主服务器、从服务器、又或者被设置成其他主服务器的从服务器，Sentinel都会向被重新配置的实例发送一个CONFIG REWRITE命令， 从而确保这些配置会持久化在硬盘里。

上面的步骤中有提到选取新的主节点，我们来看一下Sentinel选择新的主服务器使用的规则：

• 在失效主服务器属下的从服务器当中，那些被标记为主观下线、已断线、或者最后一次回复PING命令的时间大于五秒钟的从服务器都会被淘汰。
• 在失效主服务器属下的从服务器当中，那些与失效主服务器连接断开的时长超过down-after选项指定的时长十倍的从服务器都会被淘汰。
• 在经历了以上两轮淘汰之后剩下来的从服务器中，我们选出复制偏移量（replication offset）最大的那个从服务器作为新的主服务器。如果复制偏移量不可用，或者从服务器的复制偏移量相同，那么带有最小运行ID的那个从服务器成为新的主服务器。

5. 重新选举主节点

故障转移后整个Redis Sentinel的结构，重新选举了新的主节点：

（三）总结

Sentinel是Redis实现高可用的保证。Sentinel系统作用就是监视Redis服务器集群，它可以不停的获得redis集群状态，当一个主节点挂了，故障转移操作会在从节点中选出一个新的主节点，这里故障转移就是由Sentinel来主导完成的。

不要把Sentinel想的太复杂，它其实就是一个特殊工作模式的Redis服务器而已，Redis是集群部署的，这里的Sentinel也是要集群部署的，如果是单点部署，Sentinel挂了，此时的Redis集群就全挂了。

2020年9月18日