为什么缓存层也需要高可用

Redis 常被用于会话存储、热点数据缓存、排行榜与限流计数等场景。一旦主节点因硬件故障、进程崩溃或网络中断而不可用，依赖它的业务请求可能大量失败，甚至引发数据库被击穿。传统做法是人工发现故障后手动执行 REPLICAOF 切换，不仅耗时长，还容易在夜间或流量高峰时造成更严重的业务损失。

Redis 官方提供的 Sentinel（哨兵） 机制，正是为解决这一问题而设计：它通过一组独立进程持续监控主从节点，在主节点确认不可用时自动完成故障转移，把某个从节点提升为新的主节点，并通知客户端连接到新地址。

哨兵系统的四大职责

1. 监控（Monitoring）

每个哨兵进程会定期向主节点、从节点以及其他哨兵发送 PING 命令，通过返回结果判断实例是否存活、是否处于正常复制状态。

2. 通知（Notification）

当被监控的实例出现异常时，哨兵可以通过事件订阅或脚本触发的方式，将告警信息传递给运维平台或值班人员。

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

主节点被判定为客观下线后，哨兵之间会选举出一个领导者哨兵，由它挑选合适的从节点执行提升操作，并让其余从节点改为复制新主节点。

4. 配置提供者（Configuration Provider）

客户端连接哨兵集群并订阅指定主节点名称，哨兵会返回当前主节点地址。故障转移完成后，客户端可重新获取新地址，无需修改配置或重启服务。

故障转移的关键流程

1. 主观下线（SDOWN）：单个哨兵在 down-after-milliseconds 配置的时间内未收到有效响应，先将该节点标记为主观下线。
2. 客观下线（ODOWN）：该哨兵向其他哨兵询问意见，当认为节点下线的哨兵数量达到配置的 quorum（法定票数）时，判定为主观下线升级为客观下线。
3. 领导者选举：哨兵之间基于类 Raft 的投票机制选出领导者，只有领导者才能发起本次故障转移。
4. 选择新主节点：优先考虑复制偏移量较大、优先级较高、复制连接正常的从节点，尽量保证数据损失最小。
5. 执行切换：向被选中的从节点发送 REPLICAOF NO ONE 使其升级为主节点，再向其他从节点发送 REPLICAOF 指向新主节点。
6. 更新并广播配置：把新的主节点信息发布到 +switch-master 频道，客户端据此重新建立连接。

部署哨兵时容易被忽略的要点

• 使用奇数个哨兵实例：通常建议至少 3 个，并分布在不同物理机或可用区，避免单点同时失效导致无法形成多数派。
• quorum 与多数派是两回事：quorum 只决定何时判定客观下线，真正执行故障转移还需要领导者选举获得多数哨兵支持。
• 客户端必须支持哨兵：Jedis、Lettuce、redis-py 等主流客户端均提供哨兵连接模式，业务代码应通过哨兵地址而非直连主节点 IP。
• 注意脑裂与数据丢失风险：可结合 min-replicas-to-write 与 min-replicas-max-lag 限制主节点在缺少足够从节点确认时接受写入。
• 哨兵自身不存储数据：它是独立进程，不应与 Redis 数据实例混部在同一台机器上，以免故障时相互影响。
• 合理设置超时参数：down-after-milliseconds 过小容易误判，过大则延长故障恢复时间，需结合业务容忍度调整。

哨兵模式与集群模式如何选择

哨兵模式结构清晰、改造成本低，适合数据量在单机内存可承载范围内、以读写分离和故障自动恢复为主要诉求的业务。若数据规模超出单机内存，或需要水平扩展分片能力，则可考虑 Redis Cluster。两者并不冲突，部分架构会先用哨兵保障核心缓存，再逐步向集群模式演进。

结语

缓存服务的高可用不是单纯多部署几个实例，而是监控、判定、切换、通知与客户端重连形成闭环。合理规划哨兵节点数量与部署位置，配合支持哨兵的客户端和必要的写入保护参数，才能让自动故障转移真正落地，把主节点故障对业务的影响压缩到尽可能小的范围。建议定期通过演练验证切换流程，确保告警链路与应急预案同样处于可用状态。