Redis的主从复制架构里，复制积压缓冲区（replication backlog）是一个容易被忽视但非常关键的组件。它本质上是一块在主节点上开辟的环形内存区域，用来循环存储最近一段时间内的写命令。当从节点因为网络抖动出现短暂断连，重新连上主节点时，它会携带自己上次同步到的复制偏移量（offset）发起PSYNC请求。主节点会检查这个偏移量是否还落在积压缓冲区的范围内：如果落在范围内，说明断连期间丢失的数据还在缓冲区里，直接把缺口部分的命令补发给从节点即可，这就是增量同步；如果偏移量已经超出缓冲区覆盖范围，或者复制ID发生了变化，那就只能走全量同步，主节点执行bgsave生成RDB，通过网络传输给从节点重新加载。
repl-backlog-size的底层工作机制
要理解这个参数为什么重要，得先看积压缓冲区是怎么工作的。主节点在接收写命令后，除了传播给所有已连接的从节点，还会把命令字节流追加到积压缓冲区中。由于它是环形结构，写入超过设定大小后，最老的数据会被新数据覆盖。主节点上维护着一个全局的复制偏移量master_repl_offset，每写入一个字节，这个值就加一。从节点也维护着自己的slave_repl_offset，记录它消费到的位置。
从节点重连时发送的PSYNC命令携带复制ID和偏移量。主节点判断能否部分重同步的逻辑很直接：请求的复制ID要和当前主节点的复制ID匹配，并且请求的偏移量不能小于backlog中被覆盖的最早位置。举个例子，如果积压缓冲区大小是1MB，主节点当前的master_repl_offset是100MB，那么从节点只要携带的偏移量大于等于99MB，就能走增量同步；低于这个值，缓冲区里的数据已经不够补齐了，只能全量同步。
这就带来一个很实际的矛盾：缓冲区越大，能容忍的断连时间越长，但占用的内存越多；缓冲区越小，节省内存，但稍有抖动就得全量同步。全量同步的代价非常高，不仅主节点要fork子进程生成RDB，消耗CPU和磁盘IO，RDB传输还会占满网络带宽，从节点加载RDB期间可能阻塞服务，整个过程中主节点还要为它缓存增量写命令。频繁的全量同步足以把一个健康的集群拖垮。
缓冲区大小如何估算和配置
官方文档给出的估算思路是：缓冲区大小应该能够容纳从节点断连到重连这段时间内主节点产生的写命令量。一个经验公式是repl-backlog-size = 平均每秒写流量 × 预期断连时长 × 安全系数。假设你的Redis每秒写入量折算后大约是1MB，预期网络故障恢复时间在60秒左右，取2倍安全余量，那么配置成128MB左右比较稳妥。
怎么知道自己的每秒写流量呢？可以通过INFO stats中的master_repl_offset来观察，间隔一段时间取两个值相减再除以秒数，就能算出每秒产生的复制字节量。也可以用INFO replication查看当前backlog的使用情况。实际生产中，如果写入压力较大，1MB的默认值几乎形同虚设，一次几秒钟的网络闪断就可能把缓冲区冲掉，导致不必要的全量同步。
# 计算每秒写流量 redis-cli INFO stats | grep master_repl_offset # 第一次采样: master_repl_offset:100000000 # 等60秒后再采样: master_repl_offset:106000000 # 每秒写流量 = (106000000 - 100000000) / 60 = 100000 字节/秒 # 修改配置（支持在线动态调整，Redis 2.8以上版本） redis-cli CONFIG SET repl-backlog-size 128mb # 查看当前值 redis-cli CONFIG GET repl-backlog-size
在线调整有个好处，主节点会自动重新分配backlog缓冲区，不需要重启实例。需要注意的是，重新分配后原有的backlog数据会被清空，如果恰好此时有从节点请求部分重同步，也会退化为全量同步，所以调整时机尽量避开业务高峰。
不同场景下的推荐值可以参考：写入量小的缓存场景，16MB到64MB足够；写入频繁的业务（比如计数器、排行榜、消息队列类应用），建议128MB起步；跨机房复制由于网络延迟大、断连概率高，可以给到256MB甚至更高，具体结合机房之间网络故障的平均恢复时间来定。对于内存紧张的实例，还要权衡backlog占用和实际数据占用，backlog内存是额外分配的，不算在maxmemory管控范围内，这一点尤其要注意，别让backlog把机器内存挤爆。
配套参数与常见问题排查
和repl-backlog-size搭配工作的还有一个参数是repl-backlog-ttl。当主节点没有任何从节点连接时，backlog不会一直保留，默认3600秒后释放这块内存。如果你的从节点可能长时间下线后才回来，并且希望它还能走增量同步，就需要调大这个值，甚至设为0表示永不释放。不过从节点下线超过一定时间后，即使backlog还在，全量同步往往也是更可靠的选择，所以这个参数通常保持默认即可。
怎么判断当前配置是否合理？关键看INFO stats里的两个指标：sync_full和sync_partial_ok。sync_full记录了全量同步的次数，sync_partial_ok记录了部分重同步成功的次数。理想状态下，sync_full应该只在从节点首次加入时增长，之后基本不变；如果sync_full持续增长，而sync_partial_ok很少，说明缓冲区不够用或者复制ID频繁变化，需要重点排查。另外sync_partial_err表示部分重同步失败的次数，这个值偏高同样指向backlog过小。
# 观察同步统计指标 redis-cli INFO stats | grep sync # sync_full:3 # sync_partial_ok:25 # sync_partial_err:12 # 复制状态详情 redis-cli INFO replication # role:master # connected_slaves:2 # master_replid:8371b4fb1155b61e4d9d4d... # master_repl_offset:105203418 # repl_backlog_active:1 # repl_backlog_size:134217728 # repl_backlog_first_byte_offset:1
还有一个容易踩的坑：主从切换后复制ID会变化。哨兵或集群模式执行故障转移时，新主节点会生成新的复制ID，并把旧主节点的ID作为次级复制ID保留。这个机制让原本挂在旧主节点上的从节点仍有概率走部分重同步，但如果切换期间写入量太大，超出backlog覆盖范围，依然会全量。因此在自动化运维脚本里，每次故障转移后都应该关注sync_full的变化，必要时评估是否需要扩大backlog。
最后总结一下配置思路：先通过采样测出真实写流量，再按预期断连时长乘以安全系数算出目标大小，通过CONFIG SET动态生效并写入配置文件持久化。配置完成后持续观察sync_full指标，只要全量同步次数不再异常增长，就说明这个值是合适的。对于大多数中等写入压力的业务，128MB是一个兼顾内存和安全性的起点，后续再根据监控数据微调即可。
Redis复制积压缓冲区repl-backlog-size主从复制修改时间：2026-09-03 04:16:41