sentinel monitor 三要素（master-name、ip、port）必须准确，缺一不可，否则哨兵无法发现主从拓扑；quorum 是触发投票的最小同意数，非哨兵总数；密码需三端一致（requirepass/masterauth/auth-pass），acl还需配置masteruser；down-after-milliseconds宜设3000–5000ms防误判；启动前须确保主从就绪，否则从节点被误标sdown。
sentinel monitor 配置项必须写对三要素，少一个就监控失败
配置哨兵第一步不是启动，而是让 sentinel monitor 正确指向主节点——它不是“建议”，是哨兵发现整个主从拓扑的唯一入口。写错 IP、端口或名字，哨兵压根不会拉取从节点信息，后续所有自动故障转移都成空谈。
-
master-name是自定义标识符，必须全集群唯一；多个主从组共存时（比如同时管mymaster和cache2），重名会导致配置覆盖或监控混乱 -
ip和port必须是主节点当前可连通的地址——不能写127.0.0.1或localhost，哨兵进程和 Redis 实例不在同一台机器时必连不上 -
quorum不是哨兵总数，而是“触发投票所需的最小同意数”；3 个哨兵就填2，5 个哨兵填3；填1等于放弃仲裁，极易误判宕机
主节点带密码？sentinel auth-pass 必须同步配，否则同步直接静默断开
哨兵要和主节点通信、要让从节点去复制主节点，这两处都校验密码。只在 redis.conf 里设了 requirepass，但没在哨兵配置里加 sentinel auth-pass，现象是：哨兵日志里几乎不报错，INFO SENTINEL 显示 master0:status=odown，但从节点始终无法完成全量同步，数据一直为空。
- 密码必须完全一致：主节点的
requirepass、从节点的masterauth、哨兵的sentinel auth-pass <master-name><password></password></master-name>三者值相同 - 如果主节点用 ACL（Redis 6+），还需额外加
sentinel masteruser <username></username>，否则认证失败 - 测试是否生效：用
redis-cli -p 26379连哨兵，执行SENTINEL get-master-addr-by-name mymaster；返回正常地址才说明认证链跑通
down-after-milliseconds 设太小，内网抖动就被判“主观下线”
默认 30 秒太保守，生产环境一般调到 5000（5 秒）；但别无脑缩到 1000 以下——局域网偶尔丢一两个心跳包很常见，sentinel down-after-milliseconds 设太小，会导致哨兵频繁发起“主观下线”判定，进而触发不必要的选举，从节点反复切换角色，客户端连接抖动。
- 合理值参考：内网稳定环境设
3000–5000；跨机房或高延迟链路不低于10000 - 这个参数只影响“主观下线”，真正触发故障转移还要看
quorum是否达成“客观下线”，所以它本质是灵敏度调节阀 - 配合
SENTINEL masters命令观察last-ok-ping-reply字段，能直观看到哨兵上次收到主节点响应的时间戳，比盲调参数更靠谱
启动前必须确认主从已就绪，否则哨兵会把健康的从节点也标记为 sdown
哨兵启动时会立即尝试连接配置的主节点，并通过主节点的 INFO REPLICATION 获取从节点列表。如果此时主节点还没起来，或者从节点虽运行但尚未完成复制握手（slave0:state=connect 或 state=syncreply），哨兵会把那些“连不上主”的从节点统一标为 sdown（主观下线），后续即使主从恢复，也要等 failover-timeout 超时后才重新评估。
- 正确顺序：先启主节点 → 再启从节点并确认
INFO REPLICATION中role:slave且master_link_status:up→ 最后启哨兵 - 验证命令：
redis-cli -p 26379 SENTINEL slaves mymaster返回的每个从节点状态应为ok，而非disconnected或noaddr - 容器化部署时尤其注意：别用单个
docker-compose up启全部，要用depends_on+ 健康检查，或分两阶段启动
quorum 多写一个 1，或 down-after-milliseconds 少设 200 毫秒，在流量高峰时都可能让一次网络抖动演变成服务中断。 
