哨兵模式下故障转移真正生效需验证主节点宕机后能否在设定时间内完成选举、提升从节点为主并更新客户端路由，仅哨兵进程运行不代表高可用；常见错误包括未配置down-after-milliseconds导致不触发下线、parallel-syncs为0致同步卡死；生产环境须部署≥3个跨可用区哨兵，配置announce-ip/port确保通信可达；客户端须集成哨兵发现逻辑（如lettuce或jedissentinelpool），否则无法自动适配主节点切换；数据一致性依赖repl-backlog-size等复制参数调优，避免因复制延迟导致丢数据。
哨兵模式下故障转移是否真正生效
光看哨兵进程在跑，不代表它能接管故障。必须验证主节点宕机后，哨兵能否在设定时间内完成选举、提升从节点为主、更新客户端路由信息。常见错误是配置了 sentinel monitor 却没配 sentinel down-after-milliseconds，导致哨兵永远不认为主节点宕机；或者 sentinel parallel-syncs 设为 0，从节点同步卡死，新主节点数据不全。
实操建议：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 手动 kill 主节点进程（
kill -9 $(pgrep -f "redis-server.*6379")），用redis-cli -p 26379 sentinel get-master-addr-by-name mymaster每 5 秒查一次，确认地址在 30 秒内变更 - 检查哨兵日志（默认输出到 stdout 或指定
logfile），搜索+switch-master和+failover-end，两者时间差应 ≤failover-timeout - 用
redis-cli -p 6379 info replication登录新主节点，确认role:master且connected_slaves≥ 1
哨兵自身是否构成单点风险
单个哨兵进程就是单点——它挂了，整个故障转移机制就停摆。生产环境至少要部署 3 个哨兵实例，且必须跨物理机或可用区，否则一台宿主机宕机就全军覆没。容易被忽略的是哨兵之间的通信依赖 sentinel announce-ip 配置：若没设，它会自动上报内网 IP，而客户端或其它哨兵可能无法访问该地址，导致集群视图分裂。
实操建议：
- 哨兵配置中强制设置
sentinel announce-ip和sentinel announce-port，值必须是其它节点可直连的地址 - 用
redis-cli -p 26379 sentinel masters查所有哨兵看到的主节点状态，确保quorum字段值等于你设定的法定票数（如sentinel monitor mymaster 127.0.0.1 6379 2中的2） - 逐个 kill 哨兵进程，观察剩余哨兵是否仍能维持
ok状态并继续监控主从
客户端能否自动适配主节点切换
很多应用连接 Redis 时只写死一个地址（如 127.0.0.1:6379），哨兵切主后，客户端还在往旧地址发请求，直接报 READONLY 或连接拒绝。这不是哨兵问题，而是客户端没集成哨兵发现逻辑。Lettuce 支持自动重定向，Jedis 则需用 JedisSentinelPool，且必须传入全部哨兵地址，不能只写一个。
实操建议：
- Java 应用用 Lettuce 时，URI 必须形如
redis-sentinel://192.168.1.10:26379,192.168.1.11:26379/mymaster?sentinelPassword=xxx - Jedis 初始化
JedisSentinelPool时，sentinels参数必须是 Set，包含全部哨兵地址，不是单个字符串 - 压测期间模拟主节点宕机，用
tcpdump -i lo port 6379抓包，确认客户端在收到MOVED或ASK响应后，是否发起新连接到新主节点
持久化与复制延迟如何影响恢复一致性
哨兵只管“谁当主”，不管“数据齐不齐”。如果主节点宕机前最后一秒的写命令还没同步给从节点，新主节点就会丢数据。RDB/AOF 虽能落盘，但异步刷盘 + 复制积压区（replication backlog）大小不足，都会放大这个问题。尤其在高写入场景下，repl-backlog-size 默认 1MB，几万 QPS 下几秒就溢出，从节点断连重连后只能全量同步，加剧恢复延迟。
实操建议：
- 主节点配置增大
repl-backlog-size（如 100MB），并调大repl-backlog-ttl（如 3600），延长从节点断连后增量同步窗口 - 用
redis-cli info replication检查master_repl_offset和各从节点的slave_repl_offset差值，持续 > 10000 就说明复制滞后严重 - 配合
redis-benchmark -c 50 -n 100000 -t set,get压测时，同时运行redis-cli --latency -h 127.0.0.1 -p 6379监控主从延迟毛刺
