复制积压缓冲区被覆盖的条件是断连期间写入总量超过其容量，需实测avg_cmd_size（如用慢日志统计set value均值+协议开销），再按公式repl-backlog-size ≥ peak_master_qps × avg_cmd_size × max_expected_reconnect_time计算并留20%余量。
复制积压缓冲区（repl-backlog）到底多大会被覆盖？
覆盖只发生在写入速度持续超过 repl-backlog-size 且从节点断连时间 > repl-backlog-size / (master_write_qps × avg_cmd_size) 时。不是“一写就丢”，而是“断连期间写入总量 > backlog 容量”才丢命令。关键变量是平均命令大小，不是纯 QPS。
怎么算出业务真实的 avg_cmd_size？
不能拍脑袋估，得用 redis-cli --latency-dist 或 redis-cli monitor 抓真实流量（注意别在生产高峰长期开 monitor）。更稳妥的是开启慢日志 + AOF 解析：
-
CONFIG SET slowlog-log-slower-than 0开启全量慢日志 - 用
SLOWLOG GET 1000拿最近命令，统计GET/SET/HSET等高频命令的参数长度均值 - 重点看
SET key value中value的平均字节数 —— 这占大头
例如：若 70% 是 SET，平均 value 长 240 字节，加上协议开销（约 30–50 字节/命令），avg_cmd_size ≈ 300 是合理起点。
backlog-size 设多少才不丢？给个可落地的公式
目标是让断连窗口内产生的增量数据 ≤ backlog 容量。公式为：
repl-backlog-size ≥ (peak_master_qps × avg_cmd_size) × max_expected_reconnect_time
其中：
-
peak_master_qps取最近 7 天监控峰值（不是平均值），比如 12000 -
avg_cmd_size来自上一步实测，比如 300 -
max_expected_reconnect_time是网络抖动或从节点重启最长容忍时间，常见设 60–300 秒
代入：12000 × 300 × 120 = 432MB → 建议直接设 repl-backlog-size 536870912（512MB）。别设 432MB，留 20% 余量防突发。
设太大或太小会怎样？这些坑很多人踩过
设太小：主从断连稍久就触发全量同步（SYNC），CPU 和带宽尖峰，从节点长时间不可用；设太大：repl-backlog 占用主节点固定内存（即使没从节点），且 Redis 启动时会预分配，可能触发 OOM。
- 线上曾见把
repl-backlog-size设成 2GB，结果主节点 RSS 内存多占 2GB，和maxmemory冲突，触发频繁淘汰 - 另一个常见错误是只按平均 QPS 算，结果大促峰值 QPS 翻 3 倍，backlog 5 分钟就被冲垮
- 注意：Redis 6.2+ 支持
repl-backlog-ttl，但设成 0（永不过期）≠ 安全，只是避免空闲时释放 —— 覆盖风险仍在
真正难的不是算数字，是确认那个 max_expected_reconnect_time —— 它取决于你的运维响应链路，不是技术参数。网络抖动、K8s pod 重建、云厂商底层故障，都可能让这个时间远超预期。
