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 方案中的潜在脑裂问题。

---

总结

问题	关键点
Sentinel 作用	监控 Redis 状态，通知变更，执行故障转移
主观下线 vs 客观下线	SDOWN 由单个 Sentinel 认定，ODOWN 需要多个 Sentinel 认定
故障转移流程	发现 ODOWN → 选出新的 master → 更新配置并通知客户端
Sentinel 集群优势	避免单点故障，提高可靠性，确保故障转移准确性
新 master 选举机制	按 slave-priority、复制进度、运行时间长短等进行筛选
Sentinel Leader 选举	采用 Raft 类似算法，得票最多的 Sentinel 负责 failover
是否防止脑裂	只能缓解，不能完全避免，推荐 Redis Cluster 方案

如果你的 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. 总结

问题	解决方案
网络分区导致的误判	通过 down-after-milliseconds 设置合理的 Sentinel 宕机超时时间
防止脑裂	通过 min-slaves-to-write & min-slaves-max-lag 限制 master 行为
脑裂已发生	重新配置旧 master 为新 master 的 slave，并让它重新同步数据
最佳方案	采用 Redis Cluster，利用多数派选举防止 split-brain

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 负责	✅ 由 Cluster 本身负责
客户端连接方式	需通过 Sentinel 获取 master	直接连接 Redis Cluster
适用于场景	读多写少，单机难以承受压力	高并发、大数据量、分片存储
数据一致性	只保证主从一致性，不防止脑裂	采用多数派选举，防止脑裂

---

结论

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

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