Redis哨兵模式通过至少3个独立哨兵进程协同监控、投票选举、自动故障转移实现高可用，要求主从复制稳定且客户端须用Sentinel方式连接以动态获取主节点。
Redis 通过哨兵（Sentinel）模式实现高可用和自动故障转移，核心不在于“配置一个开关”，而是一套协同工作的机制：哨兵集群持续监控、达成共识、执行切换，并让客户端自动适配新主节点。整个过程无需人工干预，业务基本无感。
哨兵集群必须先跑起来
哨兵本身是独立进程（redis-sentinel），不是 Redis 服务的插件。要让它起作用，至少得部署 3 个哨兵实例（推荐奇数，避免投票平局），运行在不同物理机或容器中。每个哨兵的配置文件（如 sentinel.conf）需包含一致的监控指令：
-
sentinel monitor mymaster 192.168.1.100 6379 2：声明监控名为
mymaster的主节点，法定票数为 2（即至少 2 个哨兵同意才触发故障转移） - sentinel down-after-milliseconds mymaster 5000：单个哨兵连续 5 秒没收到响应，就标记该节点为主观下线（SDOWN）
- sentinel failover-timeout mymaster 60000：一次故障转移最长等待 60 秒，超时则重试
- 如果主节点有密码，还要加 sentinel auth-pass mymaster yourpassword
启动后，哨兵会互相发现（日志出现 +sentinel）、同步主从拓扑（每 10 秒发 INFO）、心跳探测（每 2 秒发 PING）。只有全部就绪，才算真正“上岗”。
主从复制必须稳定在线
哨兵只负责“决策和通知”，数据同步靠 Redis 自身的主从机制。所以故障转移能成功，前提是主从已正常工作：
- 主节点
role:master，从节点role:slave且master_link_status:up - 从节点不能处于
loading或长时间connecting状态 - 建议配置
replica-priority（旧版叫slave-priority）来指定从节点升级优先级，值越小越可能被选为新主
若主从断连频繁，哨兵可能反复触发无效切换，甚至误判脑裂。
客户端必须用支持 Sentinel 的方式连接
Java、Python、Node.js 等客户端都有原生 Sentinel 支持，关键不是直连某个 IP，而是告诉客户端：“去问哨兵，当前谁是主”。例如：
-
Java（Jedis）：用
JedisSentinelPool初始化，传入哨兵地址列表和逻辑主名（如mymaster），后续所有getResource()都自动拿到最新主节点连接 -
Python（redis-py）：用
Sentinel(...).master_for('mymaster')获取主客户端，它内部会缓存并定期刷新主节点地址 - 不要硬编码
192.168.1.100:6379—— 那样故障后连接直接失败，哨兵就白搭了
故障转移过程是自动完成的
当主节点宕机，哨兵按以下流程动作：
- 单个哨兵发现主节点 SDOWN → 向其他哨兵发送
is-master-down-by-addr查询 - 多数哨兵（≥法定票数）也判定为 SDOWN → 升级为客观下线（ODOWN）→ 开始选举
- 选出领头哨兵 → 按优先级、复制偏移量、runid 顺序选出最优从节点 → 执行
SLAVEOF NO ONE晋升 - 通知其余从节点指向新主 → 更新所有哨兵的内部状态 → 通过 Pub/Sub 或客户端查询接口通知外部
整个过程通常在 10–30 秒内完成。只要客户端使用正确方式获取连接，代码完全不用改，就能继续读写。
