Redis 的哨兵机制

Redis 的哨兵机制（Sentinel） 是 Redis 官方提供的高可用性（High Availability, HA）解决方案，用于实现 Redis 主从架构的自动故障转移和监控。哨兵的核心目标是确保在主节点（Master）发生故障时，系统能够自动将一个从节点（Slave）提升为新的主节点，并让其他从节点切换到复制新主节点，从而保证服务的持续可用。

哨兵机制的核心功能

1. 监控（Monitoring）

   • 哨兵会持续检查主节点和从节点的运行状态（是否在线、响应时间等）。
   • 通过周期性发送 PING 命令检测节点的存活状态。

2. 通知（Notification）

   • 当某个 Redis 节点发生故障时，哨兵可以通过 API 或 Pub/Sub 机制向管理员或其他系统发送告警。

3. 自动故障转移（Automatic Failover）

   • 如果主节点被判定为不可用（如宕机、网络中断），哨兵会启动故障转移流程：
     1. 选举一个从节点作为新的主节点。
     2. 让其他从节点复制新主节点的数据。
     3. 通知客户端切换连接到新主节点。

4. 配置提供（Configuration Provider）

   • 客户端可以通过哨兵获取当前的主节点地址，无需硬编码主节点信息。

哨兵的工作原理

1. 故障检测

• 主观下线（Subjectively Down, SDOWN）
  单个哨兵节点认为某个 Redis 节点不可用（如连续未收到 PING 响应）。
• 客观下线（Objectively Down, ODOWN）
  多个哨兵节点（通常需超过半数）达成共识，确认主节点不可用。此时触发故障转移。

2. 选举领头哨兵（Leader Sentinel）

• 哨兵集群通过 Raft 算法 选举一个领头哨兵，由其负责执行故障转移操作。

3. 选择新主节点

• 领头哨兵根据以下规则选择一个从节点作为新主节点：
  • 优先级（slave-priority 配置）。
  • 数据同步偏移量（复制数据最新的从节点）。
  • 运行 ID（字典序较小的节点）。

4. 切换主节点

• 将选中的从节点提升为主节点。
• 向其他从节点发送 SLAVEOF 命令，使其复制新主节点。
• 更新客户端连接信息。

哨兵集群的高可用性

• 哨兵自身的高可用
  哨兵以集群形式部署（至少 3 个节点），避免自身成为单点故障。
• 分布式共识
  哨兵节点之间通过 Gossip 协议通信，确保故障检测和故障转移的准确性。

哨兵部署建议

1. 最少部署 3 个哨兵节点
   避免因网络分区导致误判（如 2 个哨兵可能因网络隔离无法达成共识）。
2. 哨兵与 Redis 节点分离部署
   避免资源竞争或单点故障。
3. 合理配置超时参数
   例如 down-after-milliseconds（判定节点失效的等待时间）。

示例：哨兵架构

+----------+       +----------+       +----------+
| Sentinel |       | Sentinel |       | Sentinel |
|  Node 1  |<----->|  Node 2  |<----->|  Node 3  |
+----------+       +----------+       +----------+
      |                  |                  |
      v                  v                  v
+----------+       +----------+       +----------+
|  Master  |<----->|  Slave1  |<----->|  Slave2  |
+----------+       +----------+       +----------+

哨兵的局限性

1. 数据丢失问题
   主从切换期间，可能丢失未同步到从节点的数据（异步复制导致）。
2. 配置复杂性
   需要合理部署哨兵集群并监控其状态。
3. 不解决水平扩展问题
   Redis 哨兵仅解决高可用问题，数据分片需依赖 Redis Cluster。

总结

Redis 哨兵机制通过自动化故障转移和监控，显著提升了 Redis 主从架构的可用性。对于中小规模的应用，哨兵是简单有效的 HA 方案；对于超大规模数据，建议结合 Redis Cluster（支持分片和多主节点）。