redis哨兵通过心跳检测、主观下线（sdown）、客观下线（odown）和多数派选举实现自动故障转移，需严格配置down-after-milliseconds和quorum参数，并要求客户端使用哨兵api动态获取主节点地址。
Redis 哨兵（Sentinel）不是靠“猜”主节点是否挂了，而是通过一套可配置、可验证、需共识的机制来监控和切换——核心在于心跳检测 + 主观下线 + 客观下线 + 多数派选举，整个过程全自动，但前提是配置必须严谨。
监控主节点：每秒 PING，超时即标记 SDOWN
每个 Sentinel 进程会以 1 秒一次的频率 向主节点发送 PING 命令。如果主节点在 down-after-milliseconds（如设为 30000ms）内连续未返回有效 PONG，该 Sentinel 就把它标记为主观下线（SDOWN）。
这个阈值很关键：
- 设太小（如 5000ms），网络抖动就可能误判；
- 设太大（如 60000ms），故障发现延迟高；
- 生产环境推荐 30000ms，若主节点启用了
tcp-keepalive且系统net.ipv4.tcp_keepalive_time设为 60 秒，可酌情下调至 20000ms，但要同步检查防火墙长连接超时。
触发自动故障转移：必须达成 ODOWN 共识
单个 Sentinel 认为主节点挂了，不等于真挂——它只是 SDOWN。真正触发故障转移的前提是：至少 quorum 个 Sentinel 同意该主节点已 SDOWN，此时它被升级为客观下线（ODOWN）。
-
quorum是sentinel monitor mymaster 192.168.1.100 6379 2中的第四个参数； - 它不是 Sentinel 总数，而是“需要多少个 Sentinel 投赞成票才算数”；
- 若部署 3 个 Sentinel，
quorum至少设为 2（多数派）；设为 1 会丧失防脑裂能力； - 所有 Sentinel 必须能通过
__sentinel__:hello频道互通，且主节点 IP 不能是127.0.0.1，否则其他 Sentinel 和客户端无法直连。
故障转移执行：选举新主 + 重配从库 + 通知客户端
一旦确认 ODOWN，哨兵集群会选出一个 Leader（需过半数同意），由它执行以下动作：
- 从健康从节点中按优先级选举新主：先看
replica-priority（越小越优先），再比复制偏移量（越大说明数据越新），最后比 runid（字典序最小）； - 对选中的从节点执行
slaveof no one，提升为主节点； - 向其余从节点发送
slaveof <new-master-ip><port></port></new-master-ip>，让它们同步新主； - 更新内部配置，并通过 Pub/Sub 或客户端查询接口，对外暴露新的主节点地址。
客户端必须配合：不能直连旧地址，得问哨兵要主库
自动故障转移再快，客户端不配合也白搭：
- Java 用
JedisSentinelPool，传入哨兵地址列表和 master 别名（如mymaster）； - Python 用
Sentinel().master_for('mymaster')，它会自动缓存并定期刷新主节点； - 绝对不要硬编码
redis://192.168.1.100:6379——主节点一挂，连接直接失败，哨兵完全没机会介入。
不复杂但容易忽略
