Redis 哨兵模式（Sentinel）详解

Redis 哨兵模式（Sentinel）详解

1. 什么是 Redis 哨兵模式（Sentinel）？

Redis 哨兵模式（Sentinel） 是 用于监控 Redis 服务器并实现自动故障转移 的组件，主要用于 高可用架构。哨兵进程会不断监视主节点（Master）和从节点（Slave）的状态，当 主节点宕机 时，会自动将一个从节点提升为新的主节点，并通知其他从节点更新主节点信息。

哨兵的主要功能：

1. 主节点故障检测（Monitoring）：检测 Redis 主节点和从节点是否可用。
2. 自动主从切换（Failover）：当主节点宕机，自动提升一个从节点为新的主节点。
3. 通知与配置更新（Notification & Configuration Update）：通知其他 Redis 客户端新的主节点地址，并更新配置。

2. Redis 哨兵模式的架构

哨兵模式通常由以下几个部分组成：

1. 主节点（Master）：负责处理 写操作，并同步数据到从节点。
2. 从节点（Slave）：负责 读操作，并复制主节点的数据。
3. 哨兵节点（Sentinel）：监控主从状态，执行自动故障转移。

示例架构：

          ┌──────────────────────────┐
          │     Redis Sentinel       │
          └──────────────────────────┘
                    │
        ┌──────────┴──────────┐
        │                     │
    ┌───▼───┐            ┌────▼────┐
    │ Master │  ←——复制—— │  Slave1  │
    └───┬───┘            └────┬────┘
        │                     │
    ┌───▼───┐            ┌────▼────┐
    │ Slave2 │            │  Slave3  │
    └───────┘            └─────────┘

• 正常情况下：Master 负责写入，Slave 复制数据，Sentinel 监控 Master 的健康状态。
• 主节点故障时：Sentinel 选举一个 Slave 提升为新的 Master，并通知其他 Slave 更新主节点信息。

3. Redis 哨兵模式的核心功能

（1）主节点的监控

• Sentinel 进程会定期向 主节点和从节点 发送 PING 命令，检查它们是否正常工作。
• 如果 Master 长时间无响应（默认 1s 超过 down-after-milliseconds），Sentinel 认为它已失联。

（2）自动故障转移

当 Sentinel 发现主节点宕机，会执行以下步骤：

1. 确定 Master 确实宕机（通过多个 Sentinel 进程确认）。
2. 选举一个 Slave 作为新的 Master，并执行 SLAVEOF NO ONE 提升为 Master。
3. 通知其他 Slave 更新配置，让它们重新复制新 Master。
4. 通知 Redis 客户端，更新新的 Master 地址。

（3）通知与配置更新

• 通过 publish-subscribe 机制，Sentinel 可以通知其他 Redis 服务器和客户端新的主节点信息，确保服务的正常运行。

4. Redis 哨兵模式的选举机制

在 Sentinel 发现主节点宕机后，需要选举一个新的主节点，选举流程如下：

1. 检测可用的 Slave：

   • 选择一个数据最完整、延迟最小的从节点。
   • 排除故障的从节点。

2. Sentinel 进程之间进行选举：

   • 多个 Sentinel 进程会 相互通信，使用 Raft 选举算法 来达成一致。
   • 需要超过 半数 Sentinel 同意才能进行故障转移。

3. 推选新的 Master：

   • 选择延迟最小的 Slave，将其转换为新的 Master。

4. 重新配置其他 Slave：

   • 其他 Slave 节点会执行 SLAVEOF <new master>，从新 Master 复制数据。

注意：

• 选举需要 至少 3 个 Sentinel 进行投票，以避免误判（Quorum 机制）。
• 选举过程大约需要 几秒钟，故障切换期间可能会有短暂的服务不可用。

5. Redis 哨兵模式的配置

哨兵模式的配置文件通常命名为 sentinel.conf，基本配置如下：

# 监控主节点 master，IP 为 192.168.1.100，端口 6379
# 2 代表至少 2 个 Sentinel 进程同意才判定主节点故障
sentinel monitor mymaster 192.168.1.100 6379 2

# 多长时间（毫秒）没有响应，Sentinel 认为 Master 挂了（默认 30000 毫秒 = 30 秒）
sentinel down-after-milliseconds mymaster 5000

# 多少个 Sentinel 认为 Master 挂了，才执行故障转移
sentinel parallel-syncs mymaster 1

# 故障转移时，从节点转换为主节点的超时时间
sentinel failover-timeout mymaster 15000

启动哨兵：

redis-server sentinel.conf --sentinel

6. Redis 哨兵模式的优势

✅ 高可用性：自动检测故障并切换主节点。
✅ 自动故障恢复：故障转移后，客户端可继续访问新 Master。
✅ 负载均衡：从节点可分担读取压力，实现 读写分离。
✅ 动态扩展：可以随时增加 Sentinel 进程，提高可靠性。

7. Redis 哨兵模式的缺陷

❌ 短暂的不可用：故障转移需要 几秒钟时间，可能导致服务中断。
❌ 数据一致性问题：在主从复制的 异步模式 下，Master 可能有部分数据 未同步到 Slave，发生数据丢失。
❌ 脑裂问题：如果网络分区，部分 Sentinel 可能误判 Master 故障，导致多个 Master 出现。

解决方案：

1. 调整 down-after-milliseconds 和 failover-timeout，避免误判。
2. 使用 min-slaves-to-write 限制最少 Slave 数量，确保数据同步：

   min-slaves-to-write 2
   min-slaves-max-lag 10
   

3. 结合 Redis Cluster 方案，提供更强的高可用性。

8. Redis 哨兵 vs. Redis Cluster

9. 总结

Redis 哨兵模式适合 小到中型 Redis 部署，如果需要 更强的扩展能力，可以考虑 Redis Cluster！🚀