必须部署3个哨兵节点而非2个，因投票需多数派原则：2节点时单点失联即无法达成共识，3节点可容忍1节点故障且2票即可触发故障转移。
Redis哨兵模式在生产环境能实现自动故障转移，但必须满足“一主二从三哨兵”且哨兵与Redis实例物理隔离（或至少网络分区独立），否则脑裂风险极高，quorum配置错误或密码不一致会直接导致故障转移失败。
为什么必须部署3个哨兵节点而不是2个
哨兵通过投票达成“客观下线”共识，投票机制依赖多数派原则。2个哨兵需要2票才能确认故障，一旦其中1个因网络抖动失联，剩余1个无法达到法定票数，整个故障检测系统卡死；3个哨兵只需2票即可达成共识，容忍1个节点临时不可用。实际运维中，我们遇到过因误配sentinel monitor mymaster 192.168.1.10 6379 1（quorum=1）导致单哨兵误判就触发切换的事故——这完全违背高可用设计初衷。
- quorum值必须 ≤ 哨兵总数且 ≥ ⌊N/2⌋ + 1，推荐固定设为
2（3节点场景） - 所有哨兵节点的
sentinel auth-pass必须与对应Redis实例的requirepass严格一致，大小写敏感 - 哨兵之间需能双向通信：每个哨兵必须能
ping通其他哨兵的26379端口，防火墙常被忽略
哨兵配置里最容易填错的三个参数
哨兵配置文件（如sentinel.conf）中，sentinel monitor、sentinel down-after-milliseconds和sentinel failover-timeout这三个参数出错率最高，直接影响故障响应质量。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
sentinel monitor mymaster 192.168.1.10 6379 2：第三个参数是quorum值，不是哨兵数量；IP必须指向当前主节点（非域名，DNS解析失败会导致监控中断） -
sentinel down-after-milliseconds mymaster 5000：建议设为5000~10000ms，太小（如1000ms）会在网络瞬时抖动时频繁误标SDOWN -
sentinel failover-timeout mymaster 180000：必须大于主从复制全量同步耗时，否则新主未同步完就被客户端连上，造成数据丢失
客户端如何正确连接哨兵集群
客户端不能直连某个哨兵，而应提供全部哨兵地址列表，并启用自动发现机制。以rueidis为例，NewSentinelClient会主动订阅+switch-master频道，实时感知主节点变更；若使用redis-cli测试，必须用redis-cli -p 26379 -a sentinel_pass连哨兵后执行SENTINEL get-master-addr-by-name mymaster获取当前主地址，硬编码IP等于放弃哨兵价值。
- 初始化时传入全部哨兵地址：
InitAddrs: []string{"192.168.1.10:26379", "192.168.1.11:26379", "192.168.1.12:26379"} - 禁止在代码里缓存主节点IP超过30秒，哨兵故障转移后旧IP可能已失效
- Java客户端（Lettuce）需启用
StaticMasterReplicaTopology并配置refreshPeriod，否则DNS缓存会导致连接僵死
验证故障转移是否真正生效的关键检查点
模拟主节点宕机后，不能只看哨兵日志里有没有+failover-detected，必须逐层验证数据链路是否完整恢复。我们在线上踩过最深的坑是：哨兵成功切换了主从，但客户端因未重连新主的ACL权限不足，持续返回NOAUTH Authentication required错误，表面看服务“活着”，实则写请求全失败。
- 检查新主节点的
role是否为master（INFO replication）、connected_slaves是否≥1 - 确认新主的
requirepass与客户端使用的密码一致，且sentinel auth-pass已在哨兵配置中声明 - 用
redis-cli -h 新主IP -a 密码 SET test:failover ok写入后，立刻在任一从节点执行GET test:failover验证复制延迟是否在毫秒级
哨兵模式真正的复杂点不在部署，而在故障发生时各组件状态的耦合性——主节点、从节点、三个哨兵、客户端SDK、网络策略、认证配置，任意一环不匹配都会让自动切换变成“自动失联”。上线前务必用redis-cli --cluster failover手动触发一次，全程抓包看客户端重连行为，别信日志里的“success”。
