Redis Sentinel 哨兵如何实现故障转移？为什么仍可能丢数据？

知识点详解：从怀疑故障，到客户端恢复，发生了哪些事

先区分 Sentinel 和数据节点

假设部署一主两从，另外有三台 Sentinel 监控它们。业务数据在主从实例里；Sentinel 维护监控与拓扑信息，不是第四份业务数据。

客户端向 Sentinel 查询当前主库，再连接数据节点发送命令。不是 GET、SET 都先经过 Sentinel 转发。

三台 Sentinel 还应放在能独立故障的环境。把三个进程放同一台机器，数字是三，故障隔离仍然只有一份。

一个观察者说故障，不足以马上切换

Sentinel 在一段配置时间内拿不到合格回复，会产生自己的主观下线判断。它可能遇到局部网络故障，不能因此认定全系统都无法访问主库。

主库达到 quorum 对应的协同判断条件，进入客观下线。随后负责切换的 Sentinel 还需要授权。五台 Sentinel、quorum 为二时，两台认为不可达可以满足故障判断，但授权仍需要至少三台；quorum 更大时还要满足更高要求。

因此“quorum 等于选举票数”不准确。它们相关，却不是可以随意替换的配置概念。

选副本，也不是只看谁的 offset 最大

要先排除不合适副本，再按优先级、复制进度等规则选择。配置为零的副本优先级表示不参与晋升；其他候选中，优先级在进度之前影响选择。

晋升后，还要通知其余副本跟随新主库。旧主库重新可达，也需要按新拓扑处理。

这不保证每个客户端已经立即更新。客户端要处理旧连接、角色变化、连接失败和重新发现，恢复链路才算闭合。

高可用验收，需要检查数据和请求语义

默认异步复制下，旧主库有些已响应的写入可能没到新主库。网络分区期间，部分旧客户端还可能访问旧节点，进一步产生风险。

可以结合写入条件约束、确认机制和业务重建能力降低风险，但必须说明代价和边界。Sentinel 本身不是强一致复制协议。

演练应记录恢复时间、成功但丢失的写入、重复重试、客户端重连和旧主隔离，而不是只看最终 INFO 显示新主库。

本题机制参考：Sentinel、Sentinel 客户端规范、复制。

面试官继续追问

Sentinel 可以把数据容量横向扩展吗？

不能。它管理主从的高可用，不做自动键分片；分片能力属于 Cluster 等方案。

quorum 设置为 1 就能单机完成高可用吗？

不能据此承诺。实际切换仍有授权门槛，也需要可用副本和故障域；降低判断门槛不会创造可靠冗余。

从库很多就保证不丢写入吗？

不保证。要看复制进度和选择到的副本，数量不能替代一致性与持久化规则。

面试速记卡

• 职责：监控、切换、通知和主库发现。
• SDOWN：单个观察；ODOWN：达到 quorum 的判断。
• 授权：切换还需多数等要求，不等同 quorum。
• 客户端：支持发现、重连与旧地址处理。
• 边界：高可用不是分片，也不等于零丢失。