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会被从节点记住作为之后断线续传的起点。全量复制正式开始后主节点执行BGSAVEfork出一个子进程来生成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协议核心是两把钥匙复制IDreplid和复制偏移量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下面挂从节点BB下面再挂一个从节点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的replidB一对比发现和自己的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 flagsS列出从节点连接观察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如果业务写入峰值不超过每秒几MB256MB的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主从复制这套机制本身并不复杂难的是把每个参数背后的代价算清楚并根据真实业务量做权衡。希望这篇文章能把这条路给你指明白。