哨兵节点至少需部署3个且分属不同物理机或可用区，quorum值须满足过半原则；配置中down-after-milliseconds建议设为10000ms并据网络rtt微调；客户端必须通过哨兵列表动态获取主库地址，禁用dns/ip缓存。
哨兵节点必须至少部署3个，且不能全在一台机器上
单个哨兵进程只是监控和故障转移的执行者，它本身也是单点。如果只配1个哨兵，它挂了整个高可用机制就失效；配2个也不行——当主库宕机时，两个哨兵可能因网络分区无法达成多数派（quorum），无法触发failover。官方明确要求 quorum 值 ≤ 哨兵总数，且建议哨兵数为奇数（3/5/7），其中3是最小可行规模。
实操建议：
- 3个哨兵分别部署在不同物理机或不同可用区的虚拟机上，避免共用电源、网络设备或宿主机
- 每个哨兵配置里
sentinel monitor mymaster 192.168.1.10 6379 2中的2表示“至少2个哨兵同意才判定主库客观下线”，该值必须 ≤ 哨兵总数且 > 总数/2（即满足过半原则） - 不要把哨兵和Redis实例混部在同一台机器上——资源争抢可能导致哨兵心跳超时误判
哨兵配置中 sentinel down-after-milliseconds 设置太短会频繁误切
这个参数定义哨兵认为主库“主观下线”的毫秒阈值。设得太小（比如 3000ms），网络抖动或Redis瞬时阻塞（如bgsave卡住）就会触发误判；设得太大（如 30000ms），真实故障又不能及时响应。
推荐做法：
- 生产环境建议从
10000（10秒）起步，在压测和观测网络RTT后微调 - 同时检查
sentinel failover-timeout（默认180000ms），它控制两次failover之间的最小间隔，避免反复切换——若你设了较短的down-after-milliseconds，这个值最好同步加大，否则可能刚切完主库，哨兵又因未完成同步而再次发起选举 - 所有哨兵节点的该参数必须一致，否则投票逻辑混乱
客户端必须用哨兵地址初始化连接，不能硬编码主库IP
很多团队把应用里的Redis连接写成 redis://192.168.1.10:6379，等哨兵切主后，旧主变从、新主换IP，客户端还在往老地址发请求，直接报 READONLY You can't write against a read only replica 或连接拒绝。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
正确姿势：
- 使用支持哨兵的客户端库（如Jedis的
JedisSentinelPool、StackExchange.Redis的SentinelConfiguration），传入的是哨兵列表，例如["192.168.1.11:26379", "192.168.1.12:26379", "192.168.1.13:26379"] - 客户端会自动向任一哨兵发送
SENTINEL get-master-addr-by-name mymaster获取当前主库地址，并监听+switch-master事件做动态更新 - 务必禁用客户端的DNS缓存或IP缓存——某些SDK默认缓存主库地址长达几分钟，需查文档关掉
cacheMasterAddress类似开关
哨兵日志里出现 +sdown master mymaster 但没后续 +odown，说明quorum未达成
+sdown 是主观下线，+odown 才是客观下线（多数哨兵确认）。如果只看到前者，意味着至少有一个哨兵没跟其他哨兵通信成功，常见于防火墙拦截、端口未开放或配置了错误的 sentinel announce-ip。
排查重点：
- 确认所有哨兵的
port 26379对彼此开放（不仅是客户端连哨兵，哨兵之间也要能互相连通） - 检查是否启用了
sentinel announce-ip：若哨兵运行在Docker或NAT后，它上报给其他哨兵的IP可能是容器内网地址，导致通信失败，此时必须显式配置该选项为宿主机可路由的IP - 用
redis-cli -p 26379 SENTINEL sentinels mymaster登录任一哨兵，看返回的哨兵列表是否完整、状态是否为ok
哨兵之间靠定期 INFO 和 PING 同步状态，一旦网络延迟超过 down-after-milliseconds 的一半，就容易失联。这不是配置问题，而是基础设施层的真实约束。
