主从切换时写请求被拒绝是防脑裂的主动设计而非故障，核心靠min-slaves-to-write和min-slaves-max-lag双参数协同限流，使主节点在从节点异常时主动拒绝写入并返回MASTERDOWN错误，全程收敛控制在5秒内。

主从切换时写请求被拒绝，是设计使然不是故障

Redis 主从切换本身不直接堵塞进程，但 min-slaves-to-write 和 min-slaves-max-lag 生效后，主节点会主动拒绝写入——这看起来像“性能下降”，其实是防脑裂的必要代价。只要配置合理，这种拒绝是瞬时、可预期的，比丢数据或双主更可控。

• 拒绝写入 ≠ 连接断开或超时，客户端收到的是 MASTERDOWN 或 NOGOODSLAVE 错误，可立即重试或降级
• 若未配这两个参数，主节点在失联期间继续收写，切完才发现数据已不可逆丢失，这才是真性能黑洞
• 拒绝持续时间取决于哨兵检测窗口（down-after-milliseconds）和故障转移耗时（failover-timeout），通常控制在 5 秒内

repl-backlog-size 过小会导致 FULLRESYNC，瞬间拉满 CPU 和带宽

从节点升级为主节点后，若旧主恢复并尝试重连，需靠 repl-backlog 补增量。若缓冲区太小，就会退化为全量同步（FULLRESYNC），触发 bgsave + 网络传输，CPU 和带宽尖峰不可避免。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 默认 repl-backlog-size 1mb 在千兆网下撑不过 2 秒；按实际写入压力估算：QPS × 平均命令大小 × 最大断连时间
• 例如 3k QPS × 80B × 60s ≈ 14.4MB，应设 repl-backlog-size 16mb，且 repl-backlog-ttl 0（永不清空）
• repl-backlog 是环形缓冲区，不占额外内存，只影响断连后能否 PSYNC，务必全局统一配置

哨兵检测参数调得太松，抖动就触发假切换

默认 down-after-milliseconds 30000 配合网络抖动，极易把短暂卡顿判成宕机，引发无谓切换。每次切换都伴随元数据广播、客户端重定向、连接重建，对整体 RT 和吞吐都有可见影响。

• 建议设为 down-after-milliseconds 6000（6 秒），再配合 quorum ≥ 哨兵数一半向上取整（如 3 个哨兵设 quorum 2）
• failover-timeout 必须小于应用层超时（如设为 15000），防止哨兵卡在投票或通知阶段，拖长不可写时间
• 哨兵实例必须与主从节点物理隔离——不能和 Redis 实例共用机器，否则一挂全挂，还放大误判概率

从库执行复杂命令会拖慢复制，间接延长切换窗口

主从延迟（slave_repl_offset 与 master_repl_offset 差值）过大，会让 min-slaves-max-lag 触发写拒绝，或导致哨兵认为该从库不可用，从而排除在候选名单外。

• 避免在从库执行 SORT、KEYS、SDIFFSTORE 等 O(N) 命令；读请求也尽量避开高计算开销操作
• 开启 repl-disable-tcp-nodelay no（即关闭 TCP_NODELAY），让主节点及时推送小包，减少复制 lag，尤其适合同机房低延迟场景
• 监控 INFO replication 中的 slaveX.repl_ack_log 字段，确认 ACK 回传是否滞后——这是 lag 的真实源头，不是 ping 延迟

真正影响性能的从来不是“切换动作”本身，而是切换前未收敛的复制延迟、切换中未约束的全量同步、以及切换后未校准的客户端重连行为。这些点不提前压住，自动切换反而会放大抖动。