哨兵模式本身不保证高可用，仅提供自动故障转移能力；真正实现高可用需依赖合理配置（如quorum≥2、down-after-milliseconds适配rtt）、≥3个跨网络部署的哨兵节点、主节点启用min-replicas-to-write防脑裂、客户端通过哨兵api动态获取主节点地址，并配合应用层幂等设计降低数据丢失风险。
哨兵模式本身不保证高可用，它只提供自动故障转移能力；真正起作用的是配置、部署和客户端配合的组合效果。
哨兵节点数量必须 ≥ 3 且跨网络部署
单个哨兵是单点故障，2 个哨兵无法防脑裂（比如网络分区时各执一词）。法定票数 quorum 设为 2 时，3 个哨兵才能形成多数派；若只部署 2 个，quorum=2 意味着只要其中一个误判就触发切换。实际生产中建议至少 3 个哨兵，且分在不同物理机或可用区。
-
sentinel monitor mymaster 192.168.1.10 6379 2—— 这里2是最低确认数，不是哨兵总数 - 哨兵之间通过
SENTINEL ckquorum命令互相验证是否达到法定人数 - 如果哨兵全部部署在同一台机器上，主机宕机则整个哨兵集群失效
主观下线阈值 down-after-milliseconds 要匹配网络质量
默认 30000 毫秒（30 秒）太保守，会导致故障转移延迟过高；但设得太小（如 5000）又容易因瞬时抖动误判。关键看 PING 命令的实际 RTT：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
redis-cli -p 26379 ping测试哨兵到主节点的平均延迟 - 建议设为「平均 RTT × 3～5」，例如实测平均 80ms，可设为
3000～5000 - 该参数只影响主观下线，不影响客观下线判定逻辑
主节点必须启用 min-replicas-to-write 防脑裂
否则旧主恢复后仍可接受写入，而新主已在服务，造成数据分裂。这个参数不在哨兵配置里，而在 Redis 主节点的 redis.conf 中：
-
min-replicas-to-write 1：要求至少 1 个从节点在线才允许写入 -
min-replicas-max-lag 10：该从节点复制延迟不能超过 10 秒 - 两者需同时生效，单独设
min-replicas-to-write无意义 - 注意：从节点也需配置
masterauth，否则故障恢复后无法重新同步
客户端必须用哨兵 API 获取主节点，不能硬编码地址
哪怕只改了一行代码——把 redis://127.0.0.1:6379 换成 redis-sentinel://127.0.0.1:26379,127.0.0.1:26380/mymaster，行为就完全不同：
- Jedis 使用
new JedisSentinelPool("mymaster", sentinels) - Lettuce 使用
RedisURI.create("redis-sentinel://...") - 客户端会订阅
+switch-master事件，收到后立即刷新连接池 - 若客户端仍直连旧主 IP，切换后会持续报
READONLY You can't write against a read only slave.
最容易被忽略的是：哨兵不负责数据一致性校验，也不保证切换期间零丢失。主从异步复制 + 故障窗口内的写请求，本身就存在丢数据风险。要降低这个风险，得靠 min-replicas-* 参数 + 客户端重试逻辑 + 应用层幂等设计，而不是指望哨兵“自动兜底”。
