哨兵模式不参与写入路径，所有写操作直连主节点；其CPU升高与写性能无关，故障转移期间的写失败是服务不可用窗口期所致，非哨兵拖慢。
哨兵模式本身不参与写入路径
Redis 哨兵（Sentinel）只是监控、故障发现和自动故障转移的协调者，它不代理客户端请求，也不处理任何 SET、INCR 等写命令。所有写操作仍直连主节点，路径和单机 Redis 完全一致。
常见错误现象：看到哨兵进程 CPU 升高，就怀疑写变慢 —— 实际上哨兵 CPU 高通常是因为配置了过短的 down-after-milliseconds 或监控了过多实例，和写性能无关。
- 哨兵只通过
INFO命令定期拉取主从状态，频率默认每 10 秒一次，可调但不影响数据链路 - 故障转移期间（主从切换），客户端短暂无法写入是因连接中断或重试延迟，不是哨兵“拖慢”了写，而是服务不可用窗口期
- 若使用了带哨兵的客户端库（如
redis-py的SentinelConnectionPool），首次获取主节点需多一次 Sentinel 查询，但仅发生在连接初始化或主节点变更后，不构成持续开销
真正影响写入性能的哨兵相关配置
哨兵不处理写，但某些配置会间接放大故障时的写失败感知，或误导排查方向：
-
failover-timeout设得太小（如 500ms），可能导致网络抖动时频繁触发无谓的故障转移，造成主节点被强制降级、客户端连接重定向混乱 -
quorum设置过高（比如 5 个哨兵要求 4 票才允许 failover），在部分哨兵失联时，故障转移被阻塞，主节点虽正常，但客户端因 DNS 缓存或本地配置未更新而持续往旧地址发请求，表现为“写超时”而非“写慢” - 客户端未正确实现哨兵发现逻辑（例如硬编码主节点地址），故障转移后仍往已下线的旧主 IP 发
SET，返回READONLY You can't write against a read only replica.错误，容易误判为写能力异常
压测时为什么有时看到写 QPS 下降？
这不是哨兵导致的性能损耗，而是系统在应对故障转移过程中的自然行为：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 主节点宕机瞬间，新主尚未完成
SLAVEOF no one和数据加载，这段时间所有写请求失败（连接拒绝或 timeout） - 客户端重连新主前，可能有重试退避（如指数退避），导致请求堆积、吞吐暂时下降
- 若开启了
protected-mode yes且哨兵配置未同步更新 bind 地址，新主启动后可能拒绝外部连接，表现为写请求卡住，日志里出现Connection refused
这种下降是瞬态的、事件驱动的，和哨兵是否启用无关 —— 即使手动切主，也会出现同样现象。
验证哨兵是否真成了瓶颈的最快方法
别猜，直接绕过它测：
- 用
redis-cli -h -p直连当前主节点，压测SET key value，观察 QPS 和延迟 - 再用哨兵客户端（如
redis-py的StrictRedis.from_url("sentinel://...")）走完整发现流程压测，对比两者结果 - 如果两者 QPS 和 p99 延迟基本一致（误差
真实线上环境里，哨兵进程常年维持在几 MB 内存、不到 5% CPU，远低于 Redis 实例本身。它的存在感，只在主节点挂掉那几十秒里最强烈。
