Redis Sentinel 详解

Redis Sentinel 详解

1. 什么是 Redis Sentinel？有什么用？

Redis Sentinel（哨兵） 是 Redis 官方提供的高可用性解决方案，主要用于监控、通知和自动故障转移。当 Redis 主节点（master）发生故障时，Sentinel 能够自动选举新的 master，并通知客户端以保证 Redis 集群的高可用性。

Redis Sentinel 主要提供以下功能：

1. 监控（Monitoring）： 定期检查 Redis 主从（master-slave）实例的可用性。
2. 通知（Notification）： 当某个实例出现故障时，Sentinel 会向系统管理员或其他应用程序发送通知。
3. 自动故障转移（Automatic Failover）： 发现主节点不可用后，自动从从节点（slave）中选举新的 master，并让其他 slave 重新复制新的 master。
4. 配置管理（Configuration Provider）： 客户端可以连接 Sentinel，获取当前可用的 Redis master 地址，减少手动维护的复杂度。

2. Sentinel 如何检测节点是否下线？

Sentinel 通过定期发送 PING 命令检测 Redis 节点的状态：

• 如果某个 Redis 节点长时间没有响应 PING（超时），Sentinel 认为它可能下线，并标记为主观下线（Subjectively Down，简称 SDOWN）。
• 如果多个 Sentinel 对该节点都判断为主观下线，并且达成一致意见，Sentinel 便标记其为客观下线（Objectively Down，简称 ODOWN），然后进行故障转移。

检测机制

Sentinel 通过 sentinel.conf 配置文件中的 down-after-milliseconds 参数设置超时时间。例如：

sentinel down-after-milliseconds mymaster 5000

表示 Sentinel 如果 5 秒内未收到 PONG 响应，就认为该节点主观下线（SDOWN）。

3. 主观下线（SDOWN）与客观下线（ODOWN）的区别

• 主观下线（SDOWN，Subjectively Down）
  • 单个 Sentinel 认为某个 Redis 节点不可用，仅基于自己 PING 的响应情况得出结论。
  • 由于网络问题，可能是 Sentinel 误判，因此不会立即触发故障转移。
• 客观下线（ODOWN，Objectively Down）
  • 需要多个 Sentinel 经过投票一致认为某个 Redis 节点确实不可用，才会标记其为 ODOWN。
  • 只有当 Sentinel 认定 master 为 ODOWN 后，才会触发故障转移。

4. Sentinel 是如何实现故障转移的？

当 Sentinel 发现 Redis 主节点 ODOWN 后，故障转移（failover）流程如下：

1. 选举新的 master
   • Sentinel 选出一个可用的 slave 作为新的 master。
   • 其他 slave 重新配置，开始同步新的 master。
2. 更新 Sentinel 配置
   • Sentinel 更新集群配置，并通知其他 Sentinel、客户端新的 master 地址。
3. 通知客户端
   • 客户端可以从 Sentinel 处获取新的 master 地址，继续正常工作。

5. 为什么建议部署多个 Sentinel 节点（哨兵集群）？

部署多个 Sentinel 主要是为了提高可靠性，避免单点故障，并增强故障转移的准确性：

1. 避免单点故障：单个 Sentinel 可能宕机，导致无法监测 Redis 状态，因此需要多个 Sentinel 互相监控。
2. 提高判断准确性：多个 Sentinel 通过投票机制决定 master 是否真的 ODOWN，避免误判（如网络抖动）。
3. 支持故障转移：Sentinel 需要多个节点达成共识后才能执行 failover，以保证一致性。

一般建议至少部署 3 个 Sentinel，以保证投票机制能够生效。

6. Sentinel 如何选择出新的 master（选举机制）？

当 Redis master 被判定 ODOWN 后，Sentinel 需要从 slave 里选出新的 master，遵循以下原则：

1. 优先级（Priority）：优先选择 slave-priority 值最低的从节点（值越小，优先级越高）。
2. 复制进度（Replication Offset）：如果多个 slave 的优先级相同，则选择数据同步最完整（复制偏移量最大的）slave。
3. 运行时长（Run ID）：如果前两个条件仍然无法区分，Sentinel 选择 runid 字典序最小的 slave。
4. 可用性：确保 slave 可用，并且能够成功被转换为 master。

一旦选出新的 master，Sentinel 会执行 SLAVEOF NO ONE 命令，将其转换为 master，并让其他 slave 重新同步该 master。

7. 如何从 Sentinel 集群中选择出 Leader？

当多个 Sentinel 发现 master ODOWN 后，需要选举一个 Sentinel 作为Leader，负责执行故障转移。Leader 选举流程如下：

1. Sentinel 通过 Raft 算法类似的 Leader 选举机制 进行投票：
   • 每个 Sentinel 都可以提议自己为 Leader。
   • 其他 Sentinel 如果尚未投票，可能会投票给它。
   • 如果某个 Sentinel 获得超过一半的投票，它就被选为 Leader。
2. Leader 负责执行故障转移
   • 选举出新的 master，并通知其他 Sentinel 进行更新。

如果 Leader 在 failover 过程中宕机，其他 Sentinel 会重新选举新的 Leader，继续执行 failover。

8. Sentinel 可以防止脑裂（Split-Brain）吗？

部分情况下，Sentinel 机制可以缓解脑裂问题，但无法完全避免。例如：

1. 避免单机多主（Multiple Masters）
   • Sentinel 通过投票机制，确保只有一个 master 存在，防止多个 Sentinel 误判后产生多个 master。
2. 可能的脑裂场景
   • 如果 master 因网络分区短暂失联，Sentinel 可能会选出新的 master，但原 master 仍在运行，导致出现两个 master（脑裂）。
   • 解决方案：
     • 采用 min-slaves-to-write 和 min-slaves-max-lag 配置，确保 master 只有在足够多 slave 连接时才允许写入。
     • 使用 Redis Cluster，避免 Sentinel 方案中的潜在脑裂问题。

总结

如果你的 Redis 需要高可用性，Sentinel 是一个不错的选择，但要谨慎处理脑裂问题和网络分区情况。

拓展阅读

1. 什么是网络分区（Network Partition）？

网络分区（Network Partition） 指的是 由于网络故障，导致集群中部分节点之间无法通信。网络分区不会直接让节点宕机，而是让它们变成孤立的“孤岛”，互相无法感知对方的状态。

在 Redis Sentinel 方案中，网络分区可能导致：

• Sentinel 误判 master 失联，触发故障转移（但原 master 仍然运行）。
• 多个 Sentinel 彼此之间无法沟通，导致 split-brain（脑裂）问题。

2. 什么是脑裂（Split-Brain）？

脑裂（Split-Brain） 指的是由于网络分区，导致多个 master 节点并存，这会引发数据不一致、数据丢失等严重问题。

场景示例：

1. 网络分区发生：
   • Redis 主节点（master）与大部分 Sentinel 失去联系（但仍然存活）。
   • 这时，Sentinel 误认为 master 已宕机，触发故障转移，选举新的 master。
2. 原 master 继续提供服务：
   • 由于原 master 仍然存活，客户端可能仍然在写入它的数据，而新的 master 也在接受写入。
   • 这样，就会产生两个 master，各自接受不同的数据。
3. 网络恢复后：
   • 原 master 重新连接 Sentinel，但 Sentinel 发现新的 master 已经存在。
   • 由于两个 master 的数据不同，Redis 无法自动合并数据，可能导致部分数据丢失。

3. 脑裂发生后如何解决？

脑裂发生后，通常需要手动干预来恢复一致性。常见的解决方案包括：

方法 1：配置 slave 强制下线（min-slaves-to-write & min-slaves-max-lag）

在 Redis 主从架构中，可以通过 min-slaves-to-write 和 min-slaves-max-lag 参数确保 master 只在有足够 slave 存活时才允许写入：

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

• 作用：如果 master 发现自己没有足够的 slave，或者 slave 的同步滞后超过 10 秒，它就会拒绝写入。
• 效果：如果 master 因网络分区变成孤立节点，它将自动进入只读模式，避免脑裂。

方法 2：手动干预

如果脑裂已经发生，可以执行以下步骤：

1. 检测当前集群状态

   • 运行 INFO replication 查看 master 和 slave 角色。
   • 运行 SENTINEL master <master-name> 检查 Sentinel 认为的 master 是谁。

2. 强制废弃旧 master

   • 如果原 master 变成了孤立的 master（split-brain 发生），可以执行：

     redis-cli -h old-master -p 6379 SLAVEOF new-master-host new-master-port
     

   • 这样，原 master 重新作为 slave，从新 master 同步数据。

方法 3：使用 Redis Cluster

Redis Sentinel 主要解决的是“高可用性”问题，但无法彻底解决脑裂问题。
Redis Cluster 采用了Gossip 协议和数据分片机制，能够更好地防止脑裂：

• 多数派写入（Quorum Writes）：只有当大多数节点存活时，Redis Cluster 才允许写入。
• 自动数据迁移：当某个 master 失联后，集群会选举新的 master，并重新分配数据。

因此，对于分布式环境（多数据中心），Redis Cluster 比 Sentinel 更能避免脑裂问题。

4. 总结

Redis Sentinel 适用于小型架构，但如果要保证高可用性和一致性，Redis Cluster 更可靠。

Redis Sentinel 使用场景？

Redis Sentinel 仅适用于主从（Master-Slave）模式，不能用于 Redis Cluster。它的主要目的是监控主从架构中的 master 和 slave，自动进行故障转移（failover），保证高可用性。

Sentinel 适用的 Redis 部署模式

✅ 主从（Master-Slave）模式

• 主节点（master）负责读写，多个从节点（slave）负责读取并复制主节点数据。
• Sentinel 负责监控 master 是否存活，并在故障时将某个 slave 选举为新的 master。

✅ 哨兵模式（Sentinel Cluster）

• 多个 Sentinel 组成哨兵集群，监控 Redis 主从实例，通过投票决定故障转移。

Sentinel 不能用于哪些场景？

❌ Redis Cluster（分片集群模式）

• Redis Cluster 本身已经支持高可用，采用数据分片和 Gossip 协议，不需要 Sentinel。
• 在 Redis Cluster 中，节点间通过投票机制进行主节点选举，而 Sentinel 不能管理 Cluster。

❌ 单机 Redis

• 没有 slave 的情况下，Sentinel 无法执行故障转移，它的主要作用是监控主从结构。
• 如果只有一个 Redis 实例（单点），可以考虑使用 Keepalived + VIP 来做高可用。

如何选择 Sentinel 还是 Redis Cluster？

结论

• 如果你使用 Redis 主从模式 并希望实现高可用性，那么 Sentinel 是一个不错的选择。
• 如果你希望数据分片、扩展性更强，并且 不想依赖外部高可用组件，应该选择 Redis Cluster。

简单理解：
✅ 小型业务，主从读多写少 → 用 Sentinel
✅ 高并发、大规模数据 → 用 Redis Cluster