Redis主库挂了，只能半夜爬起来手动切换？Sentinel笑了

技术解析

Sentinel 的四大核心职责

Sentinel不是一个单一的进程，而是一个分布式系统，通常由多个Sentinel节点（推荐至少3个，且为奇数）组成一个哨兵集群。它的核心职责有四个：

1. 1. 监控 (Monitoring): Sentinel会持续地、周期性地向它所监控的所有主从节点发送PING命令，检查它们是否在线和正常工作。

2. 2. 通知 (Notification): 当被监控的某个Redis节点出现问题时，Sentinel可以通过API通知系统管理员或其他应用程序。

3. 3. 自动故障转移 (Automatic Failover): 这是Sentinel最核心的功能。当Master节点被判定为下线时，Sentinel会自动启动一个故障转移流程，从所有Slave节点中选举出一个新的Master，并让其他Slave节点去复制这个新Master。

4. 4. 配置提供者 (Configuration Provider): 在故障转移后，Sentinel会提供新Master的地址。客户端在初始化时，不再是直接连接Redis的Master地址，而是连接Sentinel集群，由Sentinel告知当前Master是谁。

自动故障转移的详细流程

这个流程是Sentinel的精髓所在，分为三个阶段：

阶段一：判定Master下线 (主观下线 -> 客观下线)

1. 1. 主观下线 (SDown - Subjective Down):
   一个Sentinel节点，在超过了配置文件中down-after-milliseconds指定的时间后，仍然没有收到某个Master节点的有效PONG回复，那么这个Sentinel节点就会在自己的认知里，主观地认为该Master已经下线。

2. 2. 客观下线 (ODown - Objective Down):
   光一个Sentinel节点认为Master下线还不够，可能是这个Sentinel自己网络出了问题。于是，这个“发现者”Sentinel会向哨兵集群中的其他Sentinel节点发出询问：“嘿，你们也觉得老大挂了吗？” 如果收到超过配置文件中quorum（法定数量）个Sentinel节点都同意Master已经下线，那么Master就会被正式标记为客观下线。这是哨兵们达成的一个共识。

阶段二：选举“领头”Sentinel

一旦Master被确定为客观下线，就需要一个Sentinel节点来“主持大局”，负责执行整个故障转移操作。

• • 选举过程:
  所有发现Master客观下线的Sentinel节点，都有资格成为“领导者”。它们会发起一次选举，第一个向其他Sentinel发起投票，并获得半数以上选票的Sentinel节点，将成为这次故障转移的领导者。

阶段三：执行故障转移

1. 1. 选举新Master:
   “领导者”Sentinel会从所有Slave节点中，按照一套严格的规则，选举出一个最合适的“继任者”：
   a. 首先，过滤掉所有状态不佳（如下线、断连）的Slave。
   b. 然后，按照replica-priority（副本优先级，在redis.conf中配置）进行排序，值越小，优先级越高。
   c. 如果优先级相同，则比较复制偏移量（replication offset），选择偏移量最大（即数据最新、最完整）的那个Slave。
   d. 如果以上都相同，则选择运行ID（run_id）最小的那个。

2. 2. 执行“加冕”与“改换门庭”:

   • • 领导者Sentinel对选出的新Master（比如Slave-A）发送 REPLICAOF NO ONE 命令，使其“黄袍加身”，正式成为新的Master。

   • • 领导者Sentinel再向所有其余的Slave节点发送 REPLICAOF <new_master_ip> <new_master_port> 命令，让它们“改换门庭”，去复制新的Master。

   • • 最后，Sentinel会持续监控那个已经下线的老Master。如果它某天又“复活”了，Sentinel会立刻给它发送REPLICAOF命令，让它去复制新Master，降级为Slave。

故事场景：学院董事会的危机处理预案

你（应用程序）是艺术学校的一名学生家长。你不再直接联系大师（Master），而是通过“学院董事会”（Sentinel）来了解学校的最新情况。这个董事会由三位德高望重、独立运作的老先生组成。

阶段一：发现大师病倒了

1. 1. 老先生A的怀疑 (主观下线):
   董事会的三位老先生，每隔一段时间就会派信鸽（PING）去大师的工作室问安。今天，老先生A派出的信鸽迟迟没有带回大师的回信。他等了很久（超过down-after-milliseconds），开始担心起来，并在自己的小本本上记下：“大师可能出事了。”

2. 2. 董事会达成共识 (客观下线):
   老先生A不敢怠慢，立刻派信鸽去问另外两位老先生：“你们能联系上大师吗？”
   很快，老先生B回信：“我也联系不上了！”
   由于三位董事中有两位（达到quorum法定人数）都确认大师失联，他们立刻召开紧急会议，达成共识，并对外发布公告：“学校进入紧急状态，大师确认失联！”

阶段二：推举“危机总指挥”

公告发出后，三位老先生需要推举一位来全权负责处理这次危机。老先生A因为最早发现问题，他率先提议：“我来牵头吧！” 另外两位老先生也同意了。于是，老先生A成为了这次“继承人选举”的总指挥。

阶段三：挑选并扶持新大师

1. 1. 挑选继承人:
   总指挥老先生A拿出了所有学徒的档案，开始筛选：

   • • “学徒小李虽然勤奋，但最近身体不好，先排除。”

   • • “剩下的学徒中，小张的‘优先级’档案里写的是最高的（replica-priority），就他了！”

   • • （如果大家优先级一样）“那我们看看谁的临摹笔记（replication offset）记得最全，最接近大师的水平... 噢，是小王！”

2. 2. “加冕”与“改换门庭”:

   • • 选定了小王后，总指挥立刻派人给小王送去一封委任状：“停止临摹，从现在起，你就是新一代的大师！”（REPLICAOF NO ONE）。

   • • 紧接着，他又向所有其他学徒发出通知：“旧大师失联，学院已任命王大师为新一代宗师。请各位立刻放下手中的旧摹本，开始学习王大师的画法！”（REPLICAOF <new_master>）。

   • • 学校的访客（客户端）再来董事会询问时，董事会就会告诉他们：“现在我们学校的代表人物是王大师。”

就这样，一场可能导致学校停摆的巨大危机，被“学院董事会”通过一套自动化的、有预案的流程，平稳地化解了。

故事总结：