Redis 如何处理单点故障与主从故障转移？

核心回答

Redis 的单点故障要通过副本冗余、故障检测、自动切换和客户端发现一起处理。主从复制先让从节点持续保存主节点的数据；非分片部署通常用 Sentinel 监测故障并提升一个从节点，分片部署可由 Redis Cluster 完成对应分片的故障转移。客户端也必须感知新主节点并重建连接。

故障切换不等于数据绝不丢失。Redis 默认异步复制，主节点确认但尚未传到副本的写入可能在切换时丢失；RDB/AOF 负责持久化恢复，不能代替故障转移。缓存数据可从数据库重建，队列或关键状态还要单独评估持久性与业务补偿。

Sentinel 怎样切换

一个 Sentinel 在规定时间内收不到有效响应，先作主观下线判断；收集到配置的 quorum 个下线意见后，可将主节点标为客观下线。随后某个 Sentinel 还需获得足够的多数派授权，成为本次故障转移的执行者。

执行者从合格副本中选出新主节点，再让其他副本跟随它，公布新的主节点地址。旧主节点恢复后应按新拓扑作为副本加入。quorum 用于故障判断，多数派用于授权切换，两者不能混为一个投票阈值。

从节点的数据主要在正常运行期间通过复制得到。故障发生后，原主节点可能已完全无法访问，所以不能描述成“先从已宕机主节点拷贝全部数据，再启动新主节点”。

Cluster 与恢复边界

Redis Cluster 同时负责槽位分片和副本切换，相关副本在满足故障判定与选举条件后接管槽位；它不是外面再套一层 Sentinel。设计时要让副本和参与判断的节点分散在合适的故障域，避免一个机房或一台宿主机同时带走主从和观察者。

切换期间连接失败与短暂不可用仍可能出现。客户端设置合理超时与有限退避，写请求通过幂等标识或业务状态确认处理“结果未知”；缓存回源需限流与合并重建，防止 Redis 恢复过程拖垮数据库。

常见追问

• WAIT 能保证零丢失吗？ 它可以要求一定数量副本确认接收，降低丢失概率，但不把 Redis 变成强一致的共识存储，也不能忽略副本持久化和故障组合。
• 重启与切换一样吗？ 单实例重启从持久化文件恢复；故障转移由已有副本接管服务。两者可以配合，但恢复时间和丢失窗口不同。
• 用 Redis 做消息队列是否只部署主从就够？ 不够，还需确认消息持久化、消费确认、未完成消息接管和业务幂等，并评估该队列的故障语义是否符合要求。

参考资料