Redis 复制积压缓冲区怎样降低短暂断线全量同步

Redis 副本只是短暂断线，恢复后却重新接收完整 RDB，通常不是“重连失败”，而是主节点保存的复制积压已经覆盖不到副本缺失的 offset。处理思路是先确认 PSYNC 的历史范围，再按复制流速估算 repl-backlog-size，最后用 INFO replication 观察调整结果。缓冲区只能延长可做部分重同步的窗口，不能替代持久化、故障切换和复制链路监控。

一、先判断为什么短暂断线仍会全量同步

Redis 主节点会持续增加复制 offset，并把最近的复制命令保存在环形积压缓冲区。副本重连时通过 PSYNC 提交旧的复制 ID 和已处理 offset；只有这段历史仍在 backlog 中，主节点才可以补发缺失命令。若缺口早已被新写入覆盖，或者复制 ID 已不再匹配，就会退回全量同步。

全量同步的代价包含生成或传输 RDB、加载数据以及补发期间积累的新命令。因而“断线只有十秒”并不等于一定能部分同步，关键是这十秒里产生了多少复制字节，以及 backlog 能保留多长的历史。

二、按复制流速估算 repl-backlog-size

可以先用业务允许的断线窗口做一个可解释的起点：

目标容量 ≈ 峰值复制字节速率 × 目标断线秒数 × 1.5

# 1.5 只是突发余量示例，生产环境应根据监控分位数调整
# 复制字节速率优先观察连续窗口，而不是拿 QPS 直接代替
repl-backlog-size 256mb

例如监控显示高峰期复制流速约 8 MB/s，希望覆盖 20 秒网络抖动，估算值约为 240 MB，可以把 256 MB 作为试运行起点。这个数字不是 Redis 的默认推荐值，也不适用于所有部署；还要扣除实例内存水位、客户端缓冲和副本数量带来的预算。

若要在线调整，可先读取当前值，再在低风险窗口执行：

# 读取当前配置，确认单位和是否为运行时覆盖值
redis-cli CONFIG GET repl-backlog-size

# 按估算值扩大环形缓冲区；变更前先核对实例剩余内存
redis-cli CONFIG SET repl-backlog-size 256mb

永久配置仍应写回启动使用的 redis.conf，避免重启后回到旧值。调整容量不会让已经丢失的复制历史凭空出现，也不会修复主节点重建复制 ID、副本数据损坏或持久化策略不当造成的全量同步。

三、用 INFO replication 验证缓冲区是否覆盖缺口

变更后不要只看 CONFIG GET。在主节点和问题副本分别采集下面几组字段：

# 只输出复制区，保存两次采样即可比较增长趋势
redis-cli INFO replication | egrep 'role|master_repl_offset|repl_backlog_(active|size|first_byte_offset|histlen)'

# 观察副本实际落后量；这里的地址只是示例占位
redis-cli -h replica.example.invalid INFO replication | egrep 'master_link_status|master_link_down_since_seconds|slave_repl_offset'

如果副本缺失字节数小于 backlog 当前可覆盖范围，恢复后更可能走部分重同步；如果 repl_backlog_first_byte_offset 已经越过副本所需的起点，扩大容量只能帮助下一次故障，当前这次仍可能全量同步。图中的 offset 关系是静态说明，不代表某次真实采样。

四、变更边界与排查清单

上线前按四项检查：一是用峰值复制字节速率而不是平均值估算；二是确认扩容后的内存余量和告警阈值；三是区分 backlog 覆盖不足与复制 ID 变化；四是把一次断线恢复演练和 INFO replication 采样留档。若副本是通过 AOF 重启，官方文档还提示它不能像保留 RDB 复制信息的优雅重启那样直接完成部分同步，因此不能只靠增大缓冲区解决。

相关问题

repl-backlog-size 越大越好吗？

不是。它会占用主节点内存，合理目标是覆盖可接受的断线窗口并留出突发余量，而不是无限增大。

为什么 backlog 足够仍然全量同步？

还要检查复制 ID、故障切换后的历史关系、实例是否重建，以及副本采用的重启方式；容量只是部分重同步的一个条件。

怎样确认这次是部分重同步？

结合主副本 offset、backlog 起始 offset、链路恢复日志和同步状态判断，不要仅凭“重连成功”下结论。