Redis复制积压缓冲区（repl-backlog）是主节点环形内存区域，核心作用是支持断线重连时优先增量同步（PSYNC）而非全量同步；其生效需满足从节点offset在缓冲区内，依赖合理设置repl-backlog-size、确保repl_backlog_active=1，并配合repl-backlog-ttl等参数协同优化。
Redis 复制积压缓冲区（repl-backlog）是主节点上的一块固定大小的环形内存区域，它的核心作用就是在从节点断线重连时，**避免全量同步，优先走增量同步（PSYNC）**。只要从节点断连期间主节点产生的命令还保留在这个缓冲区里，重连后就能直接续传，不丢数据、不耗资源。
它怎么参与断线重连过程
主从双方各自维护一个复制偏移量（master_repl_offset 和 slave_repl_offset）。断连时，从节点的 offset 停在断开那一刻；主节点继续写，offset 持续增长。重连发起 PSYNC 时，从节点带上自己的 offset，主节点做三件事：
- 比对从节点的 runID 是否匹配当前主节点（确认是“老熟人”）
- 检查该 offset 对应的数据是否还在 repl-backlog 中——即：是否满足 slave_repl_offset ≥ repl_backlog_first_byte_offset
- 若满足，就从该 offset 开始，把 backlog 里后续的数据发给从节点，完成增量同步
- 若不满足（说明缓冲区已循环覆盖），则只能触发 fullresync（全量同步）
为什么它容易失效
失效不是因为坏了，而是因为设计上就是“有限容量 + 环形覆盖”。常见原因包括：
- repl-backlog-size 设置太小：默认仅 1MB，高写入场景几秒就刷满
- 从节点断连时间过长：比如跨机房网络抖动持续 2 分钟，而缓冲区只存了 30 秒数据
- 主节点写入速率突增：如批量导入、大 key 更新，短时间内写入远超日常均值
- 缓冲区未激活：INFO replication 显示 repl_backlog_active: 0，说明还没任何从节点完成过一次同步，主节点不会分配这块内存
怎么让它真正起作用
光设个大值不够，得配合实际使用节奏：
- 用 redis-cli --stat 或监控系统，统计过去 1 小时内每秒写入字节数的峰值（例如 2.8 MB/s）
- 结合业务能容忍的最长断连时间（比如 3 分钟 = 180 秒），算出最低需求：2.8 × 1024 × 1024 × 180 ≈ 516 MB
- 生产环境再加 40% 余量，最终设为 720 MB（754974720 字节）
- 同步修改 redis.conf 并执行 CONFIG REWRITE，避免重启后丢失
- 确保 repl-backlog-ttl 足够长（如设为 7200），防止空闲时缓冲区被提前释放
验证它是否生效
重连后别只看日志有没有 “Partial resync”，要查真实指标：
- 主节点执行 INFO replication，确认 repl_backlog_active: 1
- 观察 repl_backlog_histlen（当前实际使用长度），理想状态是 repl_backlog_size 的 40%–60%：太低说明冗余，太高说明仍吃紧
- 对比 master_repl_offset − slave_repl_offset 和 repl_backlog_size，前者长期明显小于后者，说明增量同步稳定运行
