如何评估Redis哨兵模式的整体稳定性？

哨兵模式下故障转移真正生效需验证主节点宕机后能否在设定时间内完成选举、提升从节点为主并更新客户端路由，仅哨兵进程运行不代表高可用；常见错误包括未配置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，从节点同步卡死，新主节点数据不全。

实操建议：

1. 手动 kill 主节点进程（kill -9 $(pgrep -f "redis-server.*6379")），用 redis-cli -p 26379 sentinel get-master-addr-by-name mymaster 每 5 秒查一次，确认地址在 30 秒内变更
2. 检查哨兵日志（默认输出到 stdout 或指定 logfile），搜索 +switch-master 和 +failover-end，两者时间差应 ≤ failover-timeout
3. 用 redis-cli -p 6379 info replication 登录新主节点，确认 role:master 且 connected_slaves ≥ 1

哨兵自身是否构成单点风险

单个哨兵进程就是单点——它挂了，整个故障转移机制就停摆。生产环境至少要部署 3 个哨兵实例，且必须跨物理机或可用区，否则一台宿主机宕机就全军覆没。容易被忽略的是哨兵之间的通信依赖 sentinel announce-ip 配置：若没设，它会自动上报内网 IP，而客户端或其它哨兵可能无法访问该地址，导致集群视图分裂。

实操建议：

1. 哨兵配置中强制设置 sentinel announce-ip 和 sentinel announce-port，值必须是其它节点可直连的地址
2. 用 redis-cli -p 26379 sentinel masters 查所有哨兵看到的主节点状态，确保 quorum 字段值等于你设定的法定票数（如 sentinel monitor mymaster 127.0.0.1 6379 2 中的 2）
3. 逐个 kill 哨兵进程，观察剩余哨兵是否仍能维持 ok 状态并继续监控主从

客户端能否自动适配主节点切换

很多应用连接 Redis 时只写死一个地址（如 127.0.0.1:6379），哨兵切主后，客户端还在往旧地址发请求，直接报 READONLY 或连接拒绝。这不是哨兵问题，而是客户端没集成哨兵发现逻辑。Lettuce 支持自动重定向，Jedis 则需用 JedisSentinelPool，且必须传入全部哨兵地址，不能只写一个。

实操建议：

1. Java 应用用 Lettuce 时，URI 必须形如 redis-sentinel://192.168.1.10:26379,192.168.1.11:26379/mymaster?sentinelPassword=xxx
2. Jedis 初始化 JedisSentinelPool 时，sentinels 参数必须是 Set<String>，包含全部哨兵地址，不是单个字符串
3. 压测期间模拟主节点宕机，用 tcpdump -i lo port 6379 抓包，确认客户端在收到 MOVED 或 ASK 响应后，是否发起新连接到新主节点

持久化与复制延迟如何影响恢复一致性

哨兵只管“谁当主”，不管“数据齐不齐”。如果主节点宕机前最后一秒的写命令还没同步给从节点，新主节点就会丢数据。RDB/AOF 虽能落盘，但异步刷盘 + 复制积压区（replication backlog）大小不足，都会放大这个问题。尤其在高写入场景下，repl-backlog-size 默认 1MB，几万 QPS 下几秒就溢出，从节点断连重连后只能全量同步，加剧恢复延迟。

实操建议：

1. 主节点配置增大 repl-backlog-size（如 100MB），并调大 repl-backlog-ttl（如 3600），延长从节点断连后增量同步窗口
2. 用 redis-cli info replication 检查 master_repl_offset 和各从节点的 slave_repl_offset 差值，持续 > 10000 就说明复制滞后严重
3. 配合 redis-benchmark -c 50 -n 100000 -t set,get 压测时，同时运行 redis-cli --latency -h 127.0.0.1 -p 6379 监控主从延迟毛刺

真实线上环境里，哨兵稳定性最常崩在「配置漂移」和「网络分区」上：比如 Docker 容器重启后 IP 变了，哨兵却还记着旧地址；或者云厂商内网 DNS 解析偶尔超时，哨兵间心跳失败误判为宕机。这些细节不会出现在任何最新文档的显眼位置，但每天都在发生。