Redis Sentinel 和主从故障切换怎么理解

很多团队第一次做 Redis 高可用时，往往会把 Sentinel 理解成一句话：

“主挂了，自动切从。”

这句话不算错，但太粗了。真正线上容易出问题的是下面这些细节：

• 谁来判断主节点真的挂了
• 多个 Sentinel 怎么达成一致
• 切主之后客户端怎么感知新主
• 为什么切换成功了，业务还在报错

先说结论

• Sentinel 解决的是 Redis 主从架构里的故障发现、选主和配置通知问题
• 它不是数据强一致方案，也不是分片方案
• 故障切换成功，不等于业务无感；客户端路由、复制延迟、旧主回归都要处理
• 如果数据量大、写流量高、节点很多，仅靠 Sentinel 不一定够，可能要评估 Redis Cluster

Sentinel 到底干什么

Sentinel 主要做三件事：

1. 监控: 周期性检查主从实例是否健康
2. 通知: 发现异常时发出告警和事件
3. 自动故障转移: 主节点判定不可用时，选举新主并通知客户端

所以它是“高可用控制面”，不是“数据面”。

主从故障切换的基本角色

一套典型架构里会有：

• 1 个 master
• 多个 replica
• 3 个或以上 Sentinel

为什么 Sentinel 通常要奇数个？

因为涉及主观下线、客观下线、leader 选举和 failover 仲裁，多数派能减少脑裂误判。

主观下线和客观下线怎么理解

主观下线

单个 Sentinel 在一定时间内没有收到目标实例响应，就会认为它“疑似下线”。

这个判断是单点视角，因此叫主观下线。

客观下线

当足够多的 Sentinel 都认为主节点失联，达到配置的 quorum，才会进入客观下线。

只有到这个阶段，才可能触发真正的故障转移。

这一步的意义是防止单台 Sentinel 网络抖动导致误切主。

故障转移大致怎么发生

当 master 被判定为客观下线后，大致流程是：

1. Sentinel 集群选出一个 leader Sentinel
2. leader 从可用副本中挑选新的 master
3. 向被选中的 replica 发送 SLAVEOF NO ONE
4. 其他 replica 重新复制新 master
5. 通过发布订阅和配置更新通知客户端

选新主时，一般会参考：

• replica 优先级
• 复制偏移量
• 与 master 的断连时长

这也是为什么平时要关注 replica 的复制延迟和健康度。

客户端为什么仍然可能报错

很多人以为 Sentinel 切换完，业务自然无感。
现实里，下面几个点经常出问题。

1. 客户端没有正确接入 Sentinel

如果客户端还写死老 master 地址，那 Sentinel 再聪明也没用。
客户端必须能通过 Sentinel 发现当前主节点。

2. 连接池里还保留旧连接

切主后，连接池里的旧连接、旧 DNS、旧路由可能还在继续发请求。

3. 复制延迟导致新主数据不全

原主宕机前最后一段写入可能尚未同步到某个 replica。
被提升为新主后，业务可能看到“最近几秒数据丢失”。

所以 Sentinel 提供的是高可用，不是强一致。

Sentinel 和 Cluster 不要混用概念

Sentinel 适合什么

• 单主多从
• 关注高可用
• 数据规模和热点还能承载在单主上

Cluster 适合什么

• 既要高可用，又要分片扩展容量
• 多主分片
• 数据量和吞吐单主扛不住

如果你的核心问题已经是：

• 单机内存打满
• 热点集中在单主
• 写流量远超单主能力

那光靠 Sentinel 已经不够了。

工程上最该关注的点

1. Sentinel 节点部署位置

不要都和 Redis 实例放在同一台机器或同一可用区，否则一起挂掉就失去仲裁价值。

2. quorum 和超时配置

配置太激进容易误切，太保守又会恢复慢。
要结合你实际网络波动和容忍故障时间来定。

3. 客户端重连与发现机制

真正决定业务恢复速度的，往往不是 Sentinel 自己，而是客户端多久能切到新主。

4. 旧主回归策略

旧主恢复后通常应该作为 replica 加回去，而不是直接重新抢主。
否则极易出现角色混乱。

常见误区

1. 把 Sentinel 当成数据不丢失方案

错。
只要复制是异步的，切主就可能丢失最后一小段还没复制完成的数据。

2. 只配 Sentinel，不做演练

没有真正做过 failover 演练的高可用，往往只是“配置上的高可用”。

3. 忽视客户端行为

很多线上恢复慢，不是 Sentinel 没切成功，而是应用连接池、SDK 或代理层没有及时刷新路由。

一套简单的落地建议

• 至少 3 个 Sentinel，跨机器或跨可用区部署
• 明确客户端接入方式，确认支持 Sentinel 感知
• 定期做主节点宕机演练
• 关注复制延迟和角色切换时长
• 大容量或高吞吐场景及时评估 Cluster

总结

Sentinel 的价值不是“自动化”三个字，而是把主从高可用里最脆弱的几件事标准化了：

• 发现故障
• 达成多数派判断
• 选出新主
• 通知客户端

但它只负责把系统“拉起来”，不负责替你兜住所有一致性和客户端细节。