Redis哨兵机制 | Java后端面试知识库

一句话答案

Sentinel 监控主从节点健康状态，主库故障时自动选举新主库并通知客户端，实现高可用。

核心要点

Sentinel 的三大功能：

功能	说明
监控（Monitoring）	持续检测主从节点是否正常运行
自动故障转移（Failover）	主节点宕机时，自动将某个从节点提升为新主节点
通知（Notification）	故障转移完成后通知客户端新主节点地址

Sentinel 部署架构：

            ┌──────────┐
            │ Sentinel │ (至少 3 个，奇数个)
            │ 集群     │
            └────┬─────┘
                 │ 监控
      ┌──────────┼──────────┐
      ▼          ▼          ▼
  ┌────────┐ ┌────────┐ ┌────────┐
  │ Master │→│ Slave1 │ │ Slave2 │
  └────────┘ └────────┘ └────────┘
      异步复制

主节点下线判断过程：

1. 主观下线（SDOWN）：
   单个 Sentinel 向主节点发送 PING，超过 down-after-milliseconds（默认 30s）未收到有效回复
   → 该 Sentinel 认为主节点"主观下线"（仅是自己的判断）

2. 客观下线（ODOWN）：
   该 Sentinel 询问其他 Sentinel："你也认为主节点下线了吗？"
   如果超过 quorum（法定票数，通常为 Sentinel 总数的一半+1）个 Sentinel 都同意
   → 主节点被标记为"客观下线"（集群共识）
   → 触发故障转移

故障转移流程：

1. Sentinel 选举 Leader：
   在 Sentinel 集群中选出一个 Leader（Raft 算法），由 Leader 执行故障转移

2. 选择新主节点（Leader Sentinel 执行）：
   ① 过滤掉不健康的 Slave（断线时间过长的）
   ② 按优先级排序（slave-priority，值越小优先级越高）
   ③ 优先级相同 → 选复制偏移量最大的（数据最新）
   ④ 偏移量也相同 → 选 runId 最小的

3. 执行切换：
   ① 向选中的 Slave 发送 SLAVEOF NO ONE（提升为 Master）
   ② 向其他 Slave 发送 SLAVEOF <新Master>（重新指向新主）
   ③ 通知客户端新主节点地址（通过 Pub/Sub 频道 +switch-master）

Sentinel 的局限性：

写操作仍集中在单个 Master 节点，无法水平扩展写能力
存储容量受限于单节点内存
故障转移期间有短暂不可用窗口（秒级）
适用于读多写少、数据量可单机承载的场景

追问与易错

追问方向：

哨兵选主规则？
客户端怎么感知主切换？
一个哨兵够吗？

易错点：

❌ 哨兵能防数据丢失——切换期间可能丢部分数据
❌ 哨兵和 Cluster 二选一——职责不同

💡 记忆锚点

哨兵 = 三个裁判看比赛：一个裁判觉得选手倒了(SDOWN主观下线)不算数，超过半数裁判都同意(ODOWN客观下线)才吹哨换人；先选出主裁(Raft选Leader)，再按"优先级>数据新>ID小"选最佳替补上场。

一句话答案 ​

一句话答案