哨兵模式本身不提供一致性保障，只负责故障转移；其选举新主仅依据slave_repl_offset、slave-priority和runid字典序，不校验数据是否真正落盘或完整接收，主节点宕机前未同步的写入将永久丢失。
哨兵模式本身不提供一致性保障，只做故障转移；所谓“平衡”，其实是通过主从配置参数主动限制写入行为，用可用性换可控的数据丢失窗口。
为什么不能靠哨兵保证一致性
哨兵选举新主节点时，只看 slave_repl_offset、slave-priority 和 runid 字典序，不校验命令是否真正落盘或是否被从节点完整接收。主节点宕机前最后几条写入如果卡在复制缓冲区没发出去，这些数据就永久丢失了——哨兵不会回滚、不会等待、也不会通知你丢了什么。
常见错误现象：
- 主节点网络抖动后恢复，仍能接受写入，而新主已在服务 → 数据分裂（脑裂）
- 从节点
master_link_status显示up，但slave_repl_offset比主节点慢几百MB → 延迟积压严重却无告警 - 哨兵日志里反复出现
+sdown master mymaster又快速恢复 →down-after-milliseconds设得太小
必须改的 Redis 主节点配置项
这些参数不在哨兵配置里，必须在每个主节点的 redis.conf 中显式设置，并执行 CONFIG REWRITE 或重启生效：
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
-
min-replicas-to-write 1：至少 1 个从节点在线才允许写入 -
min-replicas-max-lag 10：该从节点复制延迟不能超过 10 秒（两者必须同时启用才生效） -
repl-backlog-size 128mb：默认仅 1MB，高写入场景下极易溢出，导致从节点断连后只能全量重同步 -
repl-timeout 60：超时后主节点主动断开慢从节点，避免拖垮整体复制链路
注意：min-replicas-to-write 触发时，主节点会直接返回 NOGOODSLAVE 错误，客户端必须能捕获并降级处理，否则请求直接失败。
哨兵部署与客户端配合的关键点
哨兵只是“通知者”和“协调者”，它不干预数据流，也不改变复制逻辑。真正影响可用性的是部署结构和客户端行为：
- 哨兵数量必须 ≥ 3，且跨物理机/可用区部署；
quorum建议设为 2，但绝不能等于哨兵总数（比如 2 个哨兵配quorum 2就是单点风险） -
down-after-milliseconds要基于实测 PING 延迟设定，例如平均 RTT 是 40ms，可设为 200～300ms，而不是盲目用默认 30000 - 客户端不能硬编码主节点地址，必须通过
SENTINEL get-master-addr-by-name或连接池自动发现机制获取当前主节点；Jedis、Lettuce 等主流客户端都支持哨兵模式，但需确认是否启用了sentinel-async-connect等异步初始化选项
最容易被忽略的是：从节点也必须配置 masterauth，否则旧主恢复后无法重新加入复制链路，变成孤立节点。
