Redis哨兵不保证原子性，而是通过多数派投票与串行化操作逼近一致性：先选举唯一leader，再由其独占执行选主、重配置等步骤；quorum仅触发客观下线，真正容错依赖多数派授权；网络分区下旧主可能短暂接受写入导致数据丢失，需客户端配合幂等与动态发现机制。
哨兵本身不保证原子性，它靠多数派投票和串行化操作逼近一致性
Redis 哨兵没有实现 Paxos 或 Raft 这类强一致性共识算法，所谓“原子性故障切换”是工程上通过限制并发、依赖法定人数（quorum）和 leader 单点决策达成的近似效果。多个哨兵不会并行执行切换，而是先选出一个 leader，再由它独占完成全部动作：选新主、发 REPLICAOF NO ONE、改其他从库复制关系、更新配置纪元（config-epoch）。整个过程对客户端来说“像原子的”，但底层是带状态协调的串行流程。
quorum 参数不是容错数，而是触发客观下线的最小同意哨兵数
很多人误以为 quorum 是“允许挂掉几个哨兵”，其实它只控制“多少个哨兵说主库挂了，才启动故障转移”。比如配置 sentinel monitor mymaster 10.0.0.10 6379 2，表示只要任意 2 个哨兵达成 SDown 共识，就进入 ODown 状态并开始选举 leader。真正决定能否完成切换的，是后续选举中能否凑够多数派（即 ≥ (N/2 + 1)）来授权 leader 执行操作。三哨兵集群里，quorum 设为 2 是安全下限；设为 1 就退化成单点判断，极易误切。
故障转移期间客户端可能短暂写到旧主，这不是哨兵 bug，而是网络分区下的必然现象
当主库因网络抖动被判定 ODown 并完成切换后，原主库若在网络恢复时还活着，它并不知道自己已被降级——它仍认为自己是主，会继续接受写请求。这时就出现脑裂（split-brain）。哨兵会在旧主重连后强制执行 REPLICAOF 让它变成从库，但在这之间窗口期写入的数据会丢失。避免这点的关键不是调参数，而是：
- 客户端必须用支持 Sentinel 的驱动（如 JedisSentinelPool、redis-py 的 Sentinel class），不能硬编码主库地址
- 写操作前应检查
INFO replication中的role字段，拒绝向非 master 节点写入 - 业务层做好幂等或补偿，别指望哨兵兜底数据一致性
Redis 7.0 的变化：默认启用 replica-announce-ip 和更严格的复制偏移校验
7.0 引入了两个实际影响切换可靠性的改动：
-
replica-announce-ip和replica-announce-port默认开启，让从库主动上报自己对外可连的地址，避免哨兵拿到内网 IP 导致客户端连不上新主 - 在选主阶段，哨兵会优先过滤掉复制偏移（
offset）明显落后的从库，而不是只看runid和在线状态；这个逻辑比 6.x 更严格，减少了数据丢失风险 - 注意：7.0 不再支持
slaveof命令，全部统一为replicaof，配置文件和哨兵日志里看到的都是新命令名
这些不是“增强原子性”，而是收窄故障转移的输入质量，让最终选出来的主更靠谱。
真正容易被忽略的是：哨兵只管 Redis 进程是否响应 PING，不管它内部是否卡在 AOF rewrite 或 RDB save。一次长时间阻塞可能被误判为宕机。所以生产环境必须配合 down-after-milliseconds 和 failover-timeout 的合理设置，而不是盲目压低超时值。
