Redis哨兵原理

一、前言：为什么需要 Redis 哨兵？

在 Redis 主从架构中，主节点宕机 = 服务不可写。
若依赖人工干预（如手动升从为主），恢复时间可能长达数分钟，无法满足高可用要求。

Redis Sentinel（哨兵） 就是为解决这一问题而生 —— 它是一个分布式、高可用的监控与自动故障转移系统。

本文将带你：
✅ 深入 Sentinel 的核心工作机制
✅ 理解 主观下线（SDOWN） 与 客观下线（ODOWN）
✅ 掌握 Leader 选举 与 故障转移流程
✅ 避免常见配置陷阱

二、Sentinel 架构概览

2.1 基本组成

• Redis 主从集群：1 主 + N 从（至少 1 个从）
• Sentinel 集群：至少 3 个 Sentinel 节点（奇数，防脑裂）

✅ 关键点：

• Sentinel 不存储数据，只负责监控与协调
• Sentinel 之间通过 Gossip 协议 通信
• 客户端通过 Sentinel 获取 当前主节点地址

三、Sentinel 核心功能

四、故障检测：SDOWN 与 ODOWN

4.1 主观下线（Subjectively Down, SDOWN）

• 单个 Sentinel 认为某节点不可达
• 判定条件：连续 down-after-milliseconds 毫秒 ping 不通

  sentinel down-after-milliseconds mymaster 30000 # 30秒

⚠️ SDOWN 不会触发故障转移！

4.2 客观下线（Objectively Down, ODOWN）

• 足够多的 Sentinel（≥ quorum）都认为主节点 SDOWN
• 此时集群达成共识：主节点确实宕机

sentinel monitor mymaster 192.168.1.100 6379 2
# quorum = 2：至少 2 个 Sentinel 同意才 ODOWN

🔑 quorum 作用：

• 控制 ODOWN 门槛（非投票数！）
• 实际 Leader 选举需 多数派（> N/2）

五、Leader 选举：谁来执行故障转移？

当主节点 ODOWN 后，并非所有 Sentinel 都能执行故障转移，需先选举一个 Leader。

5.1 选举机制（基于 Raft 简化版）

✅ 举例：3 节点 Sentinel

• quorum = 2 → 需 2 个 Sentinel 认为 ODOWN
• Leader 选举需 ≥ 2 票（多数派）

六、故障转移全流程（6 步详解）

假设主节点 M1 宕机，从节点 S1、S2 正常。

步骤 1：选择新主节点

Leader Sentinel 按以下优先级选新主：

📌 最终选出 S1 作为新主。

步骤 2：升主

向 S1 发送 SLAVEOF NO ONE，使其成为主节点。

步骤 3：重配其他从节点

向 S2 和原主 M1（若恢复）发送：

SLAVEOF <new_master_ip> <new_master_port>

→ 所有从节点指向新主。

步骤 4：更新 Sentinel 配置

Sentinel 集群同步新主信息，持久化到 sentinel.conf。

步骤 5：通知客户端

• 客户端通过 SENTINEL get-master-addr-by-name mymaster 获取新主地址
• 或订阅 +switch-master 事件（Pub/Sub）

步骤 6：原主恢复后处理

• 原主 M1 重启后，自动变为 从节点，同步新主数据
• 不会自动抢回主身份（避免震荡）

七、关键配置参数详解

# 监控名为 mymaster 的主节点，quorum=2
sentinel monitor mymaster 192.168.1.100 6379 2

# 主节点无响应 30 秒标记 SDOWN
sentinel down-after-milliseconds mymaster 30000

# 故障转移超时（包括升主、重配从等）
sentinel failover-timeout mymaster 180000

# 并行同步从节点数（故障转移后）
sentinel parallel-syncs mymaster 1

# 客户端通知脚本（可选）
sentinel notification-script mymaster /etc/redis/notify.sh

💡 最佳实践：

• Sentinel 节点数 ≥ 3（部署在不同机器）
• quorum ≤ Sentinel 数量 / 2 + 1
• failover-timeout 要大于整个故障转移流程时间

八、客户端如何连接 Sentinel？

8.1 Java（Jedis 示例）

Set<String> sentinels = Set.of("192.168.1.11:26379", "192.168.1.12:26379");
JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels);

try (Jedis jedis = pool.getResource()) {
jedis.set("key", "value"); // 自动路由到当前主节点
}

8.2 Spring Boot

spring:
redis:
sentinel:
master: mymaster
nodes: 192.168.1.11:26379,192.168.1.12:26379

✅ 客户端会自动发现主节点变化，无需重启！

九、常见误区与避坑指南

❌ 误区 1：Sentinel 节点越多越好

正解：3 节点足够，5 节点用于跨机房部署。过多节点增加通信开销。

❌ 误区 2：quorum = 多数派

正解：quorum 仅用于 ODOWN 判定，Leader 选举仍需多数派（> N/2）

❌ 误区 3：Sentinel 能防止脑裂

正解：Sentinel 不能完全避免脑裂！若网络分区导致多数派分裂，仍可能双主。
建议：结合 客户端写确认 或 Proxy 层 增强一致性。

✅ 避坑建议

十、结语

感谢您的阅读！如果你有任何疑问或想要分享的经验，请在评论区留言交流！