哨兵不会自动识别主从拓扑变化，必须手动配置sentinel monitor指令指定监控目标，否则无法感知、同步或故障转移；其“自动”仅限于已明确配置后的状态协同。
哨兵（Sentinel）不会自动识别并同步主从拓扑变化，必须显式配置监控目标和故障转移规则，否则它只维持自身进程运行，不触发任何切换或状态同步。
为什么 sentinel monitor 必须手动配置
哨兵本身不扫描网络或自动发现 Redis 实例。它依赖配置文件中明确声明的 sentinel monitor 指令来知道“该管谁”。漏配、拼写错误、IP 或端口写错，都会导致哨兵对某组主从完全无感知。
-
sentinel monitor mymaster 127.0.0.1 6379 2中的mymaster是自定义别名，后续所有命令（如sentinel get-master-addr-by-name）都依赖它，不能动态推导 - 如果主节点后来通过
SLAVEOF no one变成新主，旧哨兵仍按原配置盯老主地址，不会自动更新监控目标 - 哨兵间通过
hello消息交换已知主节点信息，但前提是至少一个哨兵已通过sentinel monitor知道该主节点
sentinel down-after-milliseconds 设太小会导致误判
这个参数控制哨兵判定主节点“主观下线”的超时时间。设为 3000ms 在高延迟网络或瞬时 GC 停顿场景下极易触发假故障转移。
- 生产环境建议 ≥ 10000（10 秒），且需结合实际网络 RTT 和 Redis 响应波动调整
- 多个哨兵的该值最好一致，否则可能出现部分哨兵已投票、部分仍在等待的情况
- 它只影响主观下线判断，不等于客观下线（需要多数哨兵达成一致），但过短会显著增加误投票概率
哨兵 + Redis 集群混用时同步失效
哨兵管理的是传统主从架构（单 master + 多 replica），而 Redis Cluster 是分片模型，二者协议层不兼容。在 Cluster 模式下启用哨兵，sentinel monitor 无法正确解析集群节点角色，sentinel failover 会失败并报 NOGOODSLAVE 或 MASTERDOWN。
- 确认 Redis 运行模式：
redis-cli info server | grep redis_mode，输出redis_mode:standalone才适合哨兵 - Cluster 模式下应使用
CLUSTER FAILOVER命令或让集群自身处理故障，哨兵仅能作为旁路监控，不能干预 - 若误将 Cluster 节点加入哨兵监控，哨兵日志会出现大量
+sdown master mymaster ...后又快速-sdown的抖动记录
哨兵的“自动”是有限条件下的状态协同，不是无配置的即插即用。最常被忽略的是：所有哨兵实例必须配置完全一致的 sentinel monitor，且首次启动前主从关系必须稳定——否则同步起点就错了。
