Redis Sentinel哨兵模式可实现秒级自动容灾切换，通过主观下线（SDOWN）、客观下线（ODOWN）、Leader选举、优先级筛选（slave-priority、replica-offset、runid）等机制完成故障转移，并要求客户端主动调用SENTINEL命令刷新主节点地址，部署需至少3个哨兵且配置一致。
Redis Sentinel 哨兵模式能实现单点缓存集群的秒级自动容灾切换，关键在于它把“监控—判定—选举—切换”闭环自动化，不依赖人工干预。整个过程通常在 10～30 秒内完成，前提是配置合理、网络稳定、节点状态健康。
哨兵如何快速发现主节点故障
哨兵不是靠一次超时就下结论，而是分两级判断：
-
主观下线（SDOWN）：单个哨兵每秒向主节点发 PING，若连续
down-after-milliseconds（默认 30s）未收到有效响应，就标记该主节点为 SDOWN -
客观下线（ODOWN）：当至少
quorum个哨兵（例如配置为 2）都报告同一主节点 SDOWN，该主节点即被认定为 ODOWN，触发故障转移流程
注意：quorum 不是多数派，只是启动决策的最小同意数；真正执行切换的哨兵需通过类 Raft 的选举成为 Leader，避免多个哨兵同时操作导致冲突。
新主节点是怎么选出来的
故障转移不是随机挑一个从节点升级，而是按明确优先级筛选：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先剔除
slave-priority = 0的从节点（明确禁止升主） - 保留复制偏移量（
replica-offset）最接近原主节点的从节点（数据最新） - 若 offset 相同，选
runid字典序最小的（保证结果可预期、可复现） - 还要满足断连时长 ≤
failover-timeout（默认 180 秒），否则视为数据过旧被排除
建议生产环境统一配置 slave-priority，避免靠 runid 随机决定，影响客户端连接习惯和故障后恢复一致性。
客户端怎么及时感知并连接新主
哨兵本身不主动推送地址变更，客户端必须主动刷新拓扑：
- 连接任意一台哨兵，执行
SENTINEL get-master-addr-by-name <master-name>获取当前主节点真实 IP:PORT - 拿到地址后，应直连 Redis 实例，而不是继续连哨兵
- 常见错误是客户端缓存首次查到的地址，后续不再轮询，导致切主后持续写入旧主（报错
READONLY You can't write against a read only replica） - 推荐封装带缓存与重试机制的
getMasterAddress()工具函数，或直接使用支持 Sentinel 的客户端库（如 JedisSentinelPool、redis-py 的 SentinelConnectionPool、go-redis 的 SentinelClient）
部署与配置要点
要让秒级切换真正落地，基础配置不能出错：
- 哨兵节点至少部署 3 台（奇数），防止单点失效和脑裂
- 所有哨兵的
down-after-milliseconds值必须一致，否则容易误判 - 主从节点需开启
slave-read-only yes和replica-serve-stale-data yes，确保从节点可用且行为可控 - 主从间网络必须互通，哨兵与主从、哨兵与哨兵之间也要能通信（尤其注意防火墙和安全组）
- 从节点密码需与主节点一致（若启用 auth），否则故障转移时无法同步认证
