1. 主从复制是Redis集群数据一致性的底座
Redis主从复制，也就是通过replicaof命令在节点之间建立的数据同步关系，是整个Redis高可用体系里最基础也最关键的一块。很多人平时只关注读写性能和缓存命中率，却很少在意主节点后面的从节点是不是跟得上、断线之后能不能续传、一次全量同步会不会把主节点拖垮。这些问题的根源，其实都落在复制协议的三个关键词上：全量复制、增量复制，以及藏在背后的双缓冲区机制。
这篇文章我会把主从复制的完整链路拆开讲。从首次同步的RDB全量传输，到网络抖动时的PSYNC增量续传，再到复制积压缓冲区和客户端输出缓冲区这两个容易混淆但又极其重要的组件，最后附上实际排障时总结的检查方法和参数配置建议。适合正在维护Redis生产环境的运维、需要设计高可用方案的后端开发，以及想搞懂复制原理的初学者。
主从复制要解决的核心问题很直接：让一份数据在多个节点上有副本。有了副本，主节点宕机后可以从节点继续服务；有了副本，读流量可以分发到从节点，减轻主节点压力；有了副本，在集群模式下数据分片之间才能维持一致性。但网络不可靠、节点会重启、机器有故障，副本之间的数据同步必须在各种异常情况下自己恢复。全量复制和增量复制，就是Redis应对这个问题给出的两套方案。
2. 全量复制：第一次握手和兜底重传
2.1 从replicaof到FULLRESYNC，一条连接如何建立
当一个从节点执行replicaof host port时，复制流程并不是一下子就传数据的，它有一套标准的握手过程。
第一步，从节点与主节点建立TCP连接，发送PING确认双方都活着，同时校验版本。第二步，从节点向主节点发送PSYNC命令，带着自己记忆里的复制ID和复制偏移量。如果这是从未同步过的新从节点，它没有历史信息，就会发PSYNC ? -1。第三步，主节点根据收到的复制ID和偏移量做判断：如果完全没听说过这个从节点，或者从节点请求的偏移量已经在自己的复制积压缓冲区里找不到了，就返回+FULLRESYNC <replid> <offset>，表示必须做全量复制。返回的replid和offset会被从节点记住，作为之后断线续传的起点。
全量复制正式开始后，主节点执行BGSAVE，fork出一个子进程来生成RDB快照文件。这里有个关键设计：主进程本身不会被阻塞，fork结束后继续处理正常的读写请求。子进程生成RDB期间，主进程收到的新写入命令并不会丢，它们会先暂存到复制缓冲区里，等RDB传输完成后再补发给从节点。我第一次看源码时没注意这个细节，后来排查一个“全量同步完成后数据少了几秒”的误报警时才彻底理解，RDB只是一个时间点的快照，从节点加载完RDB之后，必须把快照之后产生的增量命令也追上，数据才能真正一致。
从节点收到RDB文件后，先写入本地临时文件，完整接收后开始加载。加载期间从节点会清空旧数据，换上这份新快照。旧版本Redis在加载RDB期间不响应任何请求，新版本通过replica-serve-stale-data参数给了选择：yes可以用旧数据继续服务请求，no则直接返回错误。等从节点加载完RDB，主节点再把手头暂存的增量命令发过来，从节点逐条执行，追上最新的复制偏移量，此时主从状态变为在线同步，全量复制结束。
2.2 为什么快照传输选RDB而不是AOF
很多人会问一个很自然的问题：全量同步为什么不用传输AOF文件？AOF记录的是完整的写命令，看起来不是更直接吗？
实际生产环境中，AOF文件通常比RDB大得多。同样一份数据，RDB是压缩后的二进制快照，AOF可能是其数倍的文本命令；传输大文件意味着更长的同步时间、更高的带宽消耗。加载成本也不一样，RDB加载本质上是直接载入内存的数据结构，比一条条重放AOF命令快一个数量级。另外，AOF文件是追加写入的，传输过程中文件可能还在变化，一致性不好保证。
RDB方案最大的优势是快照一致性。子进程生成RDB时，用的是fork时的内存页副本，配合操作系统写时复制机制，能保证RDB文件对应一个确定的时间点。这也是全量复制能成为“兜底方案”的原因——不管主从之间的数据差距有多大、状态乱成什么样，一份RDB加上后续的增量命令，总能收敛到一致。
不过代价也不容忽视。BGSAVE要fork子进程，实例内存越大fork越慢；写时复制期间如果业务写入多，内存占用会明显上涨；RDB文件本身占磁盘，传输占带宽，从节点加载期间服务能力下降。所以全量复制在Redis里属于“能不做就不做”的操作，后面引入增量复制，就是为了让大多数断线场景不必走到全量这一步。
2.3 全量复制的代价与三项关键调优
既然全量复制这么重，围绕它的优化就特别值得关注。
第一项是repl-diskless-sync。默认情况下主节点生成RDB文件要先写本地磁盘，再把文件发给从节点。如果主节点磁盘IO本来就紧张，这一趟很痛苦。开启无盘同步后，主节点直接把RDB数据通过socket发送给从节点，完全不落盘，适合网络状况好、磁盘吞吐低的场景。配合repl-diskless-sync-delay，可以让多个新从节点在延迟窗口内一起触发同步，主节点只需要生成一次RDB并同时发给多个从节点，比逐个全量同步省太多。
第二项是控制全量同步的时机。给新从节点扩容，尽量选业务低峰期。我之前就见过一个团队在晚高峰给一个40GB的实例加从节点，RDB还没传完，主节点内存因为fork和写时复制涨了十几个GB，直接把maxmemory顶满，触发频繁淘汰和延迟抖动。
第三项是关注磁盘空间。即使关闭了持久化，BGSAVE依然需要临时RDB文件（无盘同步除外）。遇到过主节点磁盘只剩几个GB，一触发全量同步就报磁盘写满，同步反复失败的案例。所以评估全量复制能力时，不能只看实例内存，还要看磁盘可用空间、网络带宽和从节点的加载性能。
3. 增量复制：PSYNC的断点续传
3.1 replid和offset，复制流里的两个坐标
全量复制是兜底，增量复制才是常态。增量复制依赖的是PSYNC协议，核心是两把钥匙：复制ID（replid）和复制偏移量（offset）。
每个Redis主节点在启动时会生成一个唯一的replid，可以理解为复制流的“身份证”。从节点完成一次全量同步后，会记住主节点的replid。此后每次断线重连，从节点在PSYNC命令里会带上这个replid，用来向主节点证明：“我是你之前的从节点，数据流是一致的，请认领我。”
复制偏移量则是字节级的流水位置。主节点每向从节点发送一段复制数据，自己的master_repl_offset就前进多少字节；从节点每应用一段数据，自己的slave_repl_offset也同步前进。两个偏移量就像一个进度条，主节点知道发到哪了，从节点知道收到哪了。断线重连时，从节点把偏移量告诉主节点，主节点一对比，就知道从节点落后了多少、应该补哪些数据。
3.2 增量复制的判定条件与典型触发场景
网络瞬断、从节点临时重启、主节点短暂阻塞，这些场景在主从架构里非常常见。如果没有增量复制，每次抖动都全量同步，生产环境根本扛不住。
增量复制的判定逻辑不复杂。主节点收到PSYNC <replid> <offset>后，首先检查replid是否匹配自己的replid。匹配不上，说明从节点跟的不是自己这条复制流，只能全量。匹配上了，再检查从节点的offset落在哪个区间：如果它大于等于复制积压缓冲区里最早的一个字节的偏移量，小于等于当前最新偏移量，说明它缺的数据还在缓冲区里，主节点返回+CONTINUE，然后从缓冲区里把缺口数据发给从节点。如果offset太小，落后太多，缓冲区里的数据已经被环形覆盖，那就只能走全量。
那从节点的offset怎么会落后太多呢？最常见的原因就是断线时间太长，或者写入量太大，把复制积压缓冲区里的旧数据全部覆盖掉了。所以增量复制能不能成功，很大程度上取决于复制积压缓冲区的大小——这也是双缓冲区机制里最需要重视的参数之一。
主从之间还维持着心跳机制。主节点定期向从节点发PING，从节点每秒通过REPLCONF ACK向主节点上报自己的偏移量。主节点正是靠这个机制感知从节点是否卡住、是否断线，也是靠ACK里的偏移量决定下次增量要发哪些数据。
3.3 repl-backlog-size该配多大：计算方法和误区
复制积压缓冲区的大小由repl-backlog-size决定，默认只有1MB。这个默认值对低写入场景勉强够用，但对高写入业务来说，就是全量复制频繁发生的温床。
我一般这样估算：先观察主节点复制偏移量每秒前进多少字节，也就是写入流量的字节速度，然后乘以你希望容忍的最大断线时长。比如业务峰值时每秒产生20MB的写流量，你希望断线5分钟后能从断点续传而不是全量，那缓冲区至少需要20MB乘以300秒，也就是6GB。考虑到主节点可能同时服务多个从节点、断线后重连也需要时间，我通常还会再留30%到50%的余量。
不过内存是实打实的，6GB的缓冲区占的就是主节点的内存。如果一台机器上还跑着其他实例，或者maxmemory已经比较紧张，盲目配大也不现实。更合理的组合是：backlog配到能覆盖大多数抖动场景的量，同时通过监控及时发现sync_full次数增长，再决定要不要继续调大。
这里有个容易踩坑的细节：动态修改repl-backlog-size时，主节点会清空重建缓冲区，新缓冲区从修改时刻开始重新累积数据。也就是说，修改配置后的一段时间内，缓冲区几乎是空的，如果此时有从节点断线重连，反而更容易触发全量。所以这个操作也要挑低峰期做。
4. 双缓冲区：复制积压缓冲区和客户端输出缓冲区
4.1 两个缓冲区分别解决什么问题
聊到Redis主从复制的“双缓冲区”，这里特指两个东西：复制积压缓冲区（replication backlog buffer）和主节点为从节点准备的客户端输出缓冲区（replica client output buffer）。它们经常被混为一谈，实际上分工完全不同。
复制积压缓冲区是一个主节点全局维护的环形缓冲区，保存的是最近一段时间写入命令的原始字节流。它的职责是让断线重连的从节点能够补数据，相当于主节点侧的一份“历史录像”。任何来过、走过、断过线的从节点，想找回自己的进度，都得靠这份录像。
客户端输出缓冲区则不一样，它是主节点为每一个从节点连接单独分配的内存区，保存的是“已经生成、但还没被从节点消费掉的复制数据”。主节点写入快、从节点网络慢或加载慢时，数据先在输出缓冲区里排队。它相当于“待发货仓库”。从节点消费得快，仓库就空；消费得慢，仓库就堆货。
理解了这个区别，后面很多问题就顺了。backlog管的是“历史能不能补”，输出缓冲区管的是“当前能不能发得出去”。
4.2 复制积压缓冲区的环形结构与内存开销
复制积压缓冲区采用环形结构，固定大小，写满了就覆盖最旧的数据。每个字节在缓冲区里的位置，都和复制偏移量一一对应。主节点当前的master_repl_offset对应最新写到的位置，缓冲区的起始偏移量repl_backlog_first_byte_offset对应还保留着的最老位置，两者之间的差就是repl_backlog_histlen，即缓冲区里还有效的数据长度。
这个结构设计得非常精巧。主节点不需要为每个从节点单独保留一份历史数据，所有从节点共用同一个环形缓冲区。判断某从节点能否增量复制，只需要看它的offset落在repl_backlog_first_byte_offset和master_repl_offset之间还是之外。
但环形结构也意味着“覆盖即永久丢失”。如果主节点同时挂了多个从节点，缓冲区的大小必须按最慢的那个从节点来估。最慢的从节点消费能力差、落后最多，一旦它的offset被甩出缓冲区，它就触发全量复制。全量复制又会带来带宽占用、主节点fork开销，这些反过来又会拖慢其他从节点，形成恶性循环。所以当发现多个从节点轮流全量同步时，优先检查backlog大小和落后最严重的从节点。
还有一点，repl-backlog-ttl控制的是当主节点没有任何从节点连接时，backlog还能保留多久。默认3600秒。这是为了避免主节点长期单机运行时白占内存。一旦主节点有了从节点连接，backlog会立即重新激活。
4.3 客户端输出缓冲区的三类限制与配置陷阱
客户端输出缓冲区其实是Redis客户端连接的通用机制，只不过针对不同类型的连接设了不同的限制。Redis把连接分为三类：普通客户端normal、复制从节点replica、订阅发布pubsub。
复制从节点这一类的配置是client-output-buffer-limit replica <hard> <soft> <soft-seconds>。参数的含义是：如果某个从节点连接的输出缓冲区内存瞬间超过hard限制，主节点立刻断开这个连接；如果持续超过soft限制超过soft-seconds秒，主节点也断开连接。
很多人以为把这个限制调大或者干脆设为0就万事大吉，其实这是个危险的误解。输出缓冲区是每个从节点一份的内存，主节点连接多少从节点，就可能有几份堆积。假设一个主节点挂了20个从节点，每个输出缓冲区堆256MB，那就是5GB内存出去了。更要命的是，输出缓冲区堆积通常意味着从节点已经消费不过来了，继续堆下去主从差距只会越来越大，内存压力也会侵蚀主节点的稳定性。中断连接让从节点重新走增量复制，往往比无限堆积更健康。
不过默认值256MB的hard限制在全量同步场景确实有风险。RDB文件传输给从节点期间，主节点会继续接收新写入，这些增量命令不断往从节点的输出缓冲区里塞。如果RDB传完后从节点加载慢，增量命令堆积很容易冲破限制导致连接断开，而连接断开会中断这次全量同步，从节点重连后如果backlog覆盖不了，又要开启下一轮全量。最终表现为“全量复制反反复复进行”。
在实际生产中，我会根据业务写入量和从节点的加载能力，把replica类型的输出缓冲限制提高到512mb 128mb 60或者更高，同时观察主节点内存是否抗得住。这不是一个固定的推荐值，要在内存和同步稳定性之间权衡。通过CLIENT LIST命令可以实时看到每个从节点连接的输出缓冲占用，omem字段就是答案。
4.4 级联复制和集群场景下的缓冲区叠加
还有一种常见的架构是级联复制。比如主节点A下面挂从节点B，B下面再挂一个从节点C。这时B的角色有点特殊：在A面前它是从节点，在C面前它又是主节点。B作为从节点，要用从A同步来的数据继续为C提供复制流。B自己的内存里同样要有backlog，因为在C看来，B就是它的主节点，C断线后能否增量，取决于B的backlog是否足够。
我发现很多团队架设级联复制时只给顶层主节点配了backlog，中间节点用默认配置，结果C一断线就全量，而C的全部数据其实已经有一部分在B的backlog里，白白浪费了一次全量。这里要记住：只要一个节点有从节点，它自己就应该按主节点的标准配置backlog和输出缓冲区限制。
集群模式下也是一样的逻辑。一个分片的主节点挂从节点，主从复制是数据分片高可用的基础。集群重分片、节点迁移时，复制拓扑还会动态调整，新接入的从节点可能触发全量同步。这种场景尤其要关注全量同步次数和缓冲区配置，否则一次迁移就可能引发连锁的全量复制风暴。
5. 主从切换与PSYNC 2.0：切换后为什么不用大量全量
5.1 主从切换后的复制身份变更
主从切换的高可用场景里，最经典的流程是：主节点A故障，从节点B被提升为新主节点，其他从节点C、D重新指向B执行复制。
这里有个容易被忽略的问题。切换之前，C和D是通过A的复制流与B保持同步的，B被提升后，它自己的replid是新的还是继承A的呢？答案是，B的replid变成了自己新生成的ID，但它会记住一件重要的事：自己是从A这条复制流切换过来的，A的replid和切换时的偏移量被记录下来了。
如果没有这个记忆，C、D向B发起PSYNC时，带着的是A的replid，B一对比发现和自己的replid不匹配，直接返回全量复制。切换后本来就有服务恢复压力，再叠加多个从节点的全量同步，主节点刚上任就要抗fork、扛带宽，非常容易雪崩。
5.2 replid2机制与增量续传的实现
Redis 4.0引入的PSYNC 2.0，核心就是通过replid2和second_repl_offset解决了上面这个问题。
B被提升为主节点时，会把自己的replid替换成新生成的ID，同时把原主节点A的replid存到replid2字段里，把切换发生时自己已同步到的offset记录为second_repl_offset。当C拿着A的replid来请求PSYNC时，B发现自己的replid不匹配，但再一看replid2，正好对上了。接下来再检查C的offset：只要C的offset不小于second_repl_offset，说明C在切换之前的数据都已经同步完了，而C切换后缺的数据，B的backlog里有，于是返回+CONTINUE，继续增量同步。
这一机制让主从切换后的绝大多数从节点不需要全量重建，直接续传即可。实际做故障演练时，通过INFO replication能看到master_replid2和second_repl_offset这两个字段，它们就是切换历史的存档。做高可用平台的人一定要留意：切换后如果大量从节点都走了全量同步，先检查B的backlog大小和C的offset是否合理，不一定是B的错，很可能是backlog本身就配小了。
5.3 从节点持久化对复制恢复的影响
从节点的持久化配置，直接影响它重启后的复制恢复方式。启用了RDB或AOF的从节点，重启后会从本地持久化文件中恢复数据，同时恢复自己之前记录的replid和offset，重新向主节点发起PSYNC。只要主节点的backlog还覆盖这个offset，从节点就能增量续传，不需要全量。
反过来，如果从节点关闭了持久化，重启后内存空空如也，之前记住的replid和offset也都没了，只能向主节点请求全量同步。这也是为什么我一直建议从节点不要轻易关闭持久化，它不只是为了本地数据安全，更是为了降低重建副本的代价。
主节点的情况类似。主节点重启后，只要持久化文件还在，Redis 4.0以后会从持久化文件里恢复replid，而不是生成全新的，这保证了旧从节点在重连时还有希望增量续传。但如果主节点连持久化都关了，重启后replid必然变化，所有从节点都得全量重来。所以你看，持久化在复制链路里扮演的角色，远比“防数据丢失”这四个字要重。
6. 常见问题与排查实录
6.1 间歇性断连反复全量：输出缓冲区的隐形杀手
有一类故障特别让人头疼：从节点每过一段时间就掉线重连，每次重连都触发全量复制，主节点负载飙升，业务延迟抖动。排查到最后，很多人都会忽略输出缓冲区这个点。
当时的情况是：从节点所在机器磁盘IO特别差，加载RDB很慢。全量同步过程中，主节点发送完RDB后，把之后的增量命令不断往从节点的输出缓冲区里塞。从节点迟迟加载不完，缓冲区越堆越高，最终超过client-output-buffer-limit replica的硬限制，主节点强制断开连接。断开后从节点重新发起同步，由于backlog可能覆盖不了断线期间的写入，又走到全量复制，于是陷入死循环。
排查时先看主节点INFO stats里的sync_full、sync_partial_ok、sync_partial_err三个计数。如果sync_full持续增长，说明全量复制频繁发生。再看CLIENT LIST里从节点连接的omem字段，如果它在全量复制期间一路暴涨，基本可以锁定输出缓冲区被打满。
解决办法有两条路：一是提升replica类型的输出缓冲区上限，给从节点留出更多加载时间；二是改善从节点的加载性能，比如换更快的磁盘、避免从节点上跑其他高负载进程。光调大缓冲区不解决从节点处理能力的问题，只是把爆发时间往后拖，两者要配合着来。
6.2 断线续传失败：backlog太小和offset过期
增量复制失败的典型日志长这样：从节点请求PSYNC，主节点回了一条类似“Partial resynchronization not possible”的提示，随后转为全量复制。看到这个日志，第一反应应该是查backlog覆盖范围。
具体排查步骤是：在主节点上执行INFO replication，看repl_backlog_first_byte_offset和master_repl_offset的差距，再对比从节点当前请求的offset。如果从节点的offset比缓冲区起始偏移量还要小，说明它落后的数据在断线期间已经被环形覆盖，增量失败是必然的。
这种情况要么调大repl-backlog-size，要么缩短故障恢复时间。我在实际项目里还遇到过一种隐蔽场景：某主节点写入峰值很高，但平均写入量看起来不大。按平均值配的backlog，在写入高峰时段根本撑不了多久，断线一长就全量。所以配置backlog时要以峰值流速为基础，不是平均值。
6.3 全量复制期间内存暴涨：fork和COW的账要算清
全量复制期间主节点内存上涨，是另一个高频问题。原因主要是两个：fork子进程生成RDB时的内存页复制机制，以及多个从节点输出缓冲区的同时堆积。
在Linux的写时复制机制下，fork那一刻主进程并不复制全部内存，但fork之后的每次写入，只要涉及的页面在父子进程间共享，就会先复制一份再修改。业务写入越猛，复制的页面越多，内存上涨就越明显。一个原本占20GB内存的实例，高峰期fork后可能额外吃掉几个GB甚至十几GB。
排查时看主节点的INFO memory里的used_memory变化趋势，同时看INFO stats里的rdb_bgsave_in_progress。如果内存暴涨和BGSAVE时间高度吻合，基本就是fork和COW导致的。缓解手段包括：开启repl-diskless-sync减少磁盘压力、在低峰期做全量同步、控制实例内存不要太大（单实例几十GB以上fork开销就很可观）。
还有一类容易被忽视的是，主节点如果配置了maxmemory，全量复制时临时内存暴涨可能直接触发内存淘汰或者写入失败。这种场景下，要么给主节点预留足够多的内存余量，要么在业务侧控制单个实例的容量。
6.4 排查命令与监控指标速查
这里整理一份我平时用得最多的排查工具和指标，遇到主从复制问题时按顺序过一遍，大部分问题都能定位。
主节点上执行：
redis-cli info replication：看角色、从节点列表、replid、offset、backlog状态。redis-cli info stats | grep sync_：统计全量同步和增量同步的成功失败次数。redis-cli info memory：看实例内存快照。redis-cli client list | grep flags=S：列出从节点连接，观察omem、obl等输出缓冲指标。
从节点上执行：
redis-cli info replication：看master_link_status、slave_repl_offset、master_last_io_seconds_ago。- 如果
master_link_status是down，记录master_link_down_since_seconds，结合断线时长分析。
常见问题的对应关系可以这样记：
| 现象 | 大概率原因 | 核心检查项 |
|---|---|---|
| sync_full频繁增长 | backlog过小或replid失配 | repl_backlog_histlen与offset关系 |
| 从节点反复断线 | 输出缓冲区打满 | client list的omem、配置限制 |
| 全量复制期间主节点内存涨 | fork写时复制 | INFO stats的rdb_bgsave_in_progress |
| 切换后大量全量同步 | replid2机制未生效或backlog不足 | master_replid2、second_repl_offset |
| 从节点重启后全量 | 从节点未开启持久化 | 持久化配置、RDB/AOF存在性 |
7. 给新手的一线配置建议
7.1 一套可复用的参数模板
结合前面讲的原理，我分享一套自己常用的基础配置模板。它不是万能配方，但可以作为起点，再根据实际写入量和内存情况调整。
# 主节点开启无盘同步，适合网络稳定、磁盘IO有压力的环境 config set repl-diskless-sync yes config set repl-diskless-sync-delay 5 # 复制积压缓冲区，保守估计，按业务峰值写入量调整 config set repl-backlog-size 256mb config set repl-backlog-ttl 3600 # replica输出缓冲区，给全量同步和慢从节点留出余量 config set client-output-buffer-limit "replica 512mb 128mb 60" # 从节点建议配置 config set replica-read-only yes config set replica-serve-stale-data yes config set replica-priority 100如果业务写入峰值不超过每秒几MB，256MB的backlog一般够用；如果是写密集或者大value写入，建议至少配到1GB以上，甚至更高。关键是沉住气观察，不要配完就再也不管。
7.2 长期监控哪几个指标
配置完之后，真正决定系统稳定性的其实是监控。我最看重三个指标：sync_full的增长趋势、repl_backlog_histlen和master_repl_offset的差值、从节点连接在CLIENT LIST里的omem长期值。
sync_full哪怕一个月只涨一次，也要认真复盘是为什么涨。因为那一次全量复制背后，可能已经对业务产生了几秒到几十秒的延迟影响。master_repl_offset和从节点slave_repl_offset的差值能够反映主从之间的实时差距，这个值如果长期在高位，说明同步链路有隐患，不只是瞬时抖动。omem则能提前预警输出缓冲区堆积风险。
我自己做运维这些年，踩过最疼的坑就是全量复制风暴。一次在主从切换后，多个从节点同时触发全量同步，主节点在几分钟内fork了数次，服务直接不可用。后来把backlog和输出缓冲区的配置规范下来，再也没出过类似事故。Redis主从复制这套机制本身并不复杂，难的是把每个参数背后的代价算清楚，并根据真实业务量做权衡。希望这篇文章能把这条路给你指明白。
