redis中的哨兵机制

Redis 哨兵 (Sentinel) 机制是 Redis 高可用性 (High Availability) 的核心解决方案。

简单来说，如果主从复制（Master-Slave）是"备份 "，那么哨兵机制就是"自动救灾"。

在没有哨兵的情况下，如果 Master 挂了，你需要手动把一个 Slave 提升为 Master，还需要修改应用连接配置，这在生产环境是不可接受的。哨兵就是一个运行在后台的"智能机器人"，全天候监控 Redis 集群，一旦发现 Master 挂了，自动把 Slave 扶上位。

以下是哨兵机制的详细拆解：

---

1. 哨兵的三大核心职责

哨兵本身也是一个 Redis 进程，但它不存储数据，只负责干活。它的工作可以总结为三个词：监控、通知、故障转移。

1. 监控 (Monitoring)：

   哨兵会不断地检查你的 Master 和 Slave 是否运作正常。它每秒都会向节点发送 PING 命令。

2. 通知 (Notification)：

   当被监控的某个 Redis 节点出现问题时，哨兵可以通过 API 向管理员或者其他应用程序发送通知。

3. 自动故障转移 (Automatic Failover)：

   如果 Master 挂了，哨兵会启用"选举流程"，在剩下的 Slave 中选出一个作为新的 Master，并让其他 Slave 改去侍奉这位新主子。当旧 Master 醒来（重启）后，哨兵会命令它变成 Slave，不再是从前的老大。

4. 配置提供者 (Configuration Provider)：

   客户端应用在连接 Redis 时，连接的不是 Redis 真实 IP，而是哨兵的 IP。客户端向哨兵询问："谁是现在的 Master？"，哨兵会返回当前 Master 的地址。这样发生故障转移后，客户端能自动感知到新地址。

---

2. 故障转移的详细流程（它是怎么干活的？）

这个过程非常严谨，分为以下几个阶段：

第一阶段：主观下线 (SDOWN - Subjective Down)

• 现象 ：单个哨兵发现 Master 不回 PING 了（超过 down-after-milliseconds 配置的时间）。

• 判定 ：这个哨兵会在心里想："我觉得 Master 挂了"。但这只是它一个人的看法，可能是这个哨兵自己网卡坏了，所以这叫"主观下线"。

第二阶段：客观下线 (ODOWN - Objective Down)

• 沟通：觉得 Master 挂了的哨兵，会跑去问其他哨兵："哎，你们看 Master 还在吗？"

• 判定 ：如果超过半数（或者配置的 Quorum 数量）的哨兵都说"我也连不上 Master"，那么 Master 就被正式判定为"死透了"。这就叫"客观下线"。

• 意义：这一步是为了防止误判（比如只是单个哨兵网络波动）。只有到了 ODOWN 状态，才会触发故障转移。

第三阶段：选举哨兵 Leader

• Redis 不会让所有哨兵一拥而上去操作集群。哨兵们会先在自己内部进行投票，选出一个 Leader（领导者哨兵）。

• 通常是谁先发现故障，谁就更容易当选 Leader。

第四阶段：选出新 Master

Leader 哨兵会在剩下的 Slave 中挑选一个新的 Master。挑选规则极其严格（按顺序判断）：

1. 过滤：剔除掉那些网络断断续续、不健康的 Slave。

2. 看优先级 ：选择 slave-priority 值最小的节点（用户可以手动配置偏好）。

3. 看复制进度 ：选择复制偏移量 (offset) 最大的节点。这意味着该节点的数据最完整，丢数据最少。

4. 看 Run ID：如果以上都一样，就选 Run ID 最小的（随机选一个）。

第五阶段：执行切换

1. Leader 哨兵对被选中的 Slave 发送 SLAVEOF NO ONE 命令，让它独立成为 Master。

2. 通过发布订阅模式，通知其他 Slave："原来的老大挂了，现在听新老大（新 IP）的"。

3. 通知客户端（Client）新的 Master 地址。

4. 如果旧 Master 重新上线，哨兵会把它降级为 Slave。

---

3. 关键概念解释

• Quorum (法定人数)：

  这是在配置哨兵时的一个核心参数（例如 sentinel monitor mymaster 127.0.0.1 6379 2 中的 2）。

  它表示：至少需要几个哨兵认为 Master 挂了，才能标记为 ODOWN 并发起故障转移。

  • 注意：Quorum 只是用来判断"是否需要报警"。真正执行故障转移时，还需要半数以上的哨兵投票选举 Leader。

---

4. 哨兵模式的优缺点

优点	缺点
高可用性：故障自动恢复，不需要人工介入。	配置复杂：相比单机，配置项和维护成本增加。
自动发现：客户端只需要连哨兵，不需要硬编码 Redis 地址。	无法解决容量限制 ：哨兵依然是主从架构，存储容量受限于单台 Master 的内存。如果数据量特别大，哨兵解决不了，需要用 Redis Cluster。
健壮性：由多台哨兵组成的集群，即使哨兵挂了一两个，系统依然能工作。	主从切换有瞬间卡顿：在选举新 Master 的几秒钟内，Redis 集群是无法写入数据的。

---

5. 总结：哨兵就像公司的"董事会"

• Master 是 CEO，负责决策（写入）。

• Slave 是经理，负责执行（读取/备份）。

• Sentinel 是 董事会/监事会。

  • 他们平时不干活，就盯着 CEO 干没干活。

  • 一个董事觉得 CEO 没来上班（SDOWN），不算数。

  • 大家开会都觉得 CEO 跑路了（ODOWN），就投票把一个经理提拔成新 CEO。

  • 外部客户（Client）想找 CEO 谈生意，必须先问董事会"现在谁是 CEO？"。