当前位置：首页 > news >正文

【Redis从入门到精通】第40篇：旧版复制的硬伤——Redis 2.8之前为什么会反复全量同步

news 2026/6/2 23:24:57

上一篇【第39篇】Redis主从复制——数据如何在主从节点间同步
下一篇【第41篇】PSYNC登场——Redis复制协议的进化之路（明日更新，敬请期待）

上一篇文章我们讲了主从复制的基本用法。你可能会想："这不挺好的吗，RDB一发，增量一传，主从就同步了。"但如果我告诉你，在Redis 2.8之前，从库哪怕只是断开了几秒钟的网络，重新连上后主库也要从头给你整个RDB，你会不会觉得Redis的作者在开玩笑？很不幸，这是真的。而且这个"玩笑"在生产环境结结实实地坑了不少人。

旧版SYNC的全量同步流程

在Redis 2.8之前，复制只有一条命令：SYNC。它的工作方式可以概括为"不管三七二十一，先来一份RDB"：

SYNC 命令全量同步流程（旧版复制） 从库 主库 │ │ │──── SYNC ───────────────────→│ 1. 从库发送SYNC │ │ "我是一张白纸" │ │ │ ┌────▼─────────────────┐ │ │ 2. 主库 fork 子进程 │ │ │ BGSAVE 生成 RDB │ │ │ 期间新写入的命令 │ │ │ → 记录到客户端缓冲区 │ │ └────┬─────────────────┘ │ │ │ │ 3. fork 和 RDB 生成 │ │ 对主库的性能影响： │ │ - fork 时占用内存翻倍(近似) │ │ - 写 RDB 消耗大量CPU │ │ │ ←─── RDB文件 ─────────────── │ 4. 发送 RDB 文件 │ (几百MB到几十GB) │ 占用大量网络带宽 │ │ │ 5. 从库清空自身数据 │ │ (FLUSHALL) │ 6. 发送"传输期间" │ │ 积累的命令 │ 7. 载入RDB │ │ (LOADING状态，不可读) │ │ │ │ ←─── 缓冲命令 ────────────── │ │ │ │ 8. 执行缓冲命令 │ │ 追平时间差 │ │ │ │ 9. 全量同步完成 │ │ 进入命令传播阶段 │ │ │

这个过程在逻辑上没有太大问题。但问题在于——无论从库断线前已经同步到了什么程度，只要断开重连，主库都视为"全新的从库"，从头来一遍全量同步。

旧版SYNC的三大致命缺陷

缺陷一：断线重连也全量——浪费感情的"重新认识"

想象一下这个场景：

致命缺陷：断线重连触发全量同步 时间线： t=0min 主库:1GB数据 从库:已全量同步，offset=XXXXX t=5min 从库网络闪断（交换机重启，持续30秒） t=5min30s 从库重新连上主库 你能想到的合理做法： "主库，我从offset=XXXXX之后丢了半分钟的数据，你把那半分钟的命令补给我就行。" 旧版SYNC的实际做法： "主库，我……" "闭嘴，先接RDB！" (1GB全量重新传) 从库内心：我tm已经有的那1GB数据是假数据吗？？？

这太荒谬了。从库可能只丢了0.01%的数据（30秒的写入量），却要重新接收100%的数据（全量RDB）。带宽浪费了多少？主库CPU、内存、磁盘IO浪费了多少？

缺陷二：每次全量同步都要fork和写RDB——对主库的反复"拷问"

BGSAVE是有代价的：

// BGSAVE 的 fork 开销intrdbSaveBackground(char*filename,rdbSaveInfo*rsi){pid_tchildpid;// fork 操作：copy-on-write// 父进程的整个地址空间被"标记"为只读// 如果主库有10GB内存，fork的瞬间需要足够的剩余内存if((childpid=redisFork())==0){// 子进程：遍历所有数据，写入RDB// 这个过程中，父进程的任何写操作都触发缺页中断// 产生内存副本（copy-on-write）rdbSave(filename,rsi);exitFromChild(0);}else{// 父进程：继续处理请求// 但每次写都会触发COW，分配新内存页// 极端情况下，内存使用会翻倍（所有内存页都被修改）}}

fork的代价：

如果Redis占用10GB内存，fork需要足够的剩余物理内存（建议至少保留50%）
fork本身不是瞬间完成的（10GB页表的复制可能需要几百毫秒）
fork期间Redis会短暂暂停

写RDB的代价：

主库的子进程会把所有数据遍历一遍写入磁盘
IO密集型操作，会抢占磁盘带宽
10GB数据写RDB可能需要几分钟

如果一个从库反复断线重连，主库就得反复地fork、写RDB、传RDB。主库本应该专心服务客户端，结果被这个不稳定的从库拖成了"专属RDB生成器"。

缺陷三：多个从库同时请求——“惊群效应”

更可怕的场景：主库重启或网络波动导致多个从库同时断开。当网络恢复时：

惊群效应 主库刚刚恢复，5个从库同时重连： 从1: SYNC! 从2: SYNC! ─┐ 从3: SYNC! ├──→ 主库收到5个SYNC请求 从4: SYNC! ─┘ 排队生成5个RDB！ 从5: SYNC! 结果： - 主库需要连续fork 5次 - 每次fork都要占用大量内存（COW叠加） - 5份RDB文件连续生成和传输 - 主库CPU 100%，内存飙升 - 正常客户端请求响应变慢或超时 - 可能触发OOM Killer

这就是"惊群效应"（thundering herd）——多个从库同时请求全量同步，把主库压垮。

一个真实案例：反复全量同步引发的血案

某创业团队的Redis部署：

主库：8核16GB，存储约3GB数据
3个从库（做读写分离）
网络环境：同机房，千兆内网

某天，运维同学在做网络割接时，交换机重启造成了约10秒的网络中断。3个从库全部断开。10秒后网络恢复，从库重新连上主库。

此时触发了什么？

事故时间线 t=0秒 网络中断，3个从库与主库断开连接 t=10秒 网络恢复，3个从库重连 t=10秒 从库1发送SYNC t=10秒 从库2发送SYNC t=10秒 从库3发送SYNC ↑ 同时发出！ t=10~20秒 主库fork第1次，生成RDB（约5秒） t=20~35秒 主库fork第2次，生成RDB（约7秒，内存压力增大） t=35~55秒 主库fork第3次，生成RDB（约10秒，内存快爆了） t=15~60秒 主库向3个从库传输RDB（3GB × 3 = 9GB） 内网带宽被占满！ t=15~120秒 客户端请求大量超时： - SET超时率：35% - GET超时率：20% - 主库CPU：95%+（6个核心在写RDB，2个在处理请求） - 主库内存：峰值14.2GB（接近16GB上限） t=180秒 所有同步完成，服务恢复正常 总影响时长：3分钟 数据量丢失：网络中断10秒内的写操作（约5000条） 根本原因：3GB数据，本应只需补传10秒的命令（KB级） 实际传输了9GB（3 × 3GB RDB） 浪费率：99.99%

这个团队痛定思痛，在事故复盘时发现：如果使用Redis 2.8+的PSYNC，断线10秒后的重连只需要增量同步，主库只需要从复制积压缓冲区中取出这10秒的命令发给从库（可能只有几十KB），整个过程不超过1秒。

用数据说话：全量同步到底有多重

数据量	fork时间	RDB生成时间	传输时间(千兆)	从库载入时间	总耗时
100MB	~50ms	1~2s	~1s	3~5s	₅8s
500MB	~150ms	3~8s	~4s	15~30s	₂₃42s
1GB	~300ms	8~15s	~8s	30~60s	₄₇83s
5GB	~1.5s	30~60s	~40s	2~5min	3~7min
10GB	~3s	60~120s	~80s	5~10min	7~14min
50GB	~15s	5~10min	~7min	30~60min	43~78min

每断线一次，就重来一遍。如果从库所在机器网络不稳，一天断个3-5次，主库一天要花大量时间在生成和传输RDB上。

为什么旧版不能增量同步？——技术根因

旧版复制不能增量同步，不是因为Redis的作者"没想到"，而是因为缺少两个关键基础设施：

旧版 vs 新版：增量同步需要什么 ┌───────────────────────────────────────────────────────┐ │ │ │ 增量同步的前提条件 │ │ │ │ 条件1：复制偏移量 (replication offset) │ │ ┌─────────────────────────────────────────┐ │ │ │ 主库和从库各自维护一个"已处理了多少"计数器 │ │ │ │ 主库 offset = 12345 │ │ │ │ 从库 offset = 12300 │ │ │ │ 差 = 45 → 传45字节的命令即可 │ │ │ └─────────────────────────────────────────┘ │ │ │ │ 条件2：复制积压缓冲区 (replication backlog) │ │ ┌─────────────────────────────────────────┐ │ │ │ 主库维护一个固定大小的FIFO环形缓冲区 │ │ │ │ 所有写命令都append到缓冲区 │ │ │ │ 从库重连时，如果offset还在缓冲区内 │ │ │ │ → 增量同步，只补差异部分 │ │ │ │ 如果offset已经在缓冲区外 │ │ │ │ → 退回全量同步（缓冲区不够大） │ │ │ └─────────────────────────────────────────┘ │ │ │ │ 旧版：两个都没有 → 只能全量同步 │ │ 新版：两个都有 → 可以增量同步 │ │ │ └───────────────────────────────────────────────────────┘

可以这么理解：旧版复制就像是"每通电话都重新介绍自己是谁"，而新版有了"来电显示"和"通话记录"。

复制积压缓冲区的工作原理

// 复制积压缓冲区（新版引入的核心数据结构）structreplBacklog{char*buf;// 环形缓冲区longlongsize;// 缓冲区大小（默认1MB，可配置）longlongoffset;// 缓冲区的起始偏移量longlongidx;// 下一个要写入的位置};// 默认大小// repl-backlog-size 1mb// 主库每执行一条写命令，就追加到缓冲区voidfeedReplicationBacklog(void*ptr,size_tlen){// 如果缓冲区满了，覆盖最旧的数据// 环形写入}

这个缓冲区的核心思想是"用空间换时间"：维护一个固定大小的历史命令缓冲，只要从库的落后量在这个缓冲区内，就能增量同步。

对比：旧版SYNC vs 新版PSYNC

维度	旧版 SYNC（< 2.8）	新版 PSYNC（>= 2.8）
命令	`SYNC`	`PSYNC replicationid offset`
断线重连	永远全量同步	如offset在积压缓冲区内，增量同步
复制偏移量	不支持	主从各维护offset
复制积压缓冲区	不支持	主库维护环形缓冲区
断线1秒后重连	传输全量RDB	传输几KB命令
网络依赖	极高（断线代价大）	较低（断线可快速恢复）
主库资源消耗	从库不稳定时反复fork	大部分场景无需fork
多从库场景	惊群效应明显	大部分增量，偶有全量

这些硬伤如何推动进化

旧版复制的三大缺陷直接催生了Redis 2.8的PSYNC命令。Redis的作者Salvatore Sanfilippo（antirez）在设计PSYNC时，核心目标就是解决这三个问题：

引入复制偏移量（offset）：让主从知道"同步到哪了"。
引入复制积压缓冲区（backlog）：让主库记住"最近说了什么"。
引入复制ID（replication ID）：让从库知道"我连的是哪个主库"，防止主从切换后数据混乱。

进化之路 Redis 2.6及以前 Redis 2.8+ Redis 4.0+ ┌─────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ SYNC │ │ PSYNC (v1) │ │ PSYNC2 │ │ 全量复制 │ ────→ │ 支持增量复制 │ ────→│ 故障转移后仍可 │ │ 断线即全量 │ │ 断线可增量 │ │ 部分增量同步 │ │ 无offset │ │ 依赖runid │ │ 依赖replication │ │ 无backlog │ │ 切换主库需全量 │ │ ID (非runid) │ └─────────────┘ └─────────────────┘ └─────────────────┘

PSYNC1（Redis 2.8~3.x）：引入了offset和backlog，但以runid（服务器运行ID）作为复制身份的标识。一旦发生主从切换（主库重启或Sentinel故障转移），runid变了，从库必须再次全量同步。

PSYNC2（Redis 4.0+）：引入了replication ID替代runid。replication ID可以在主从切换时"继承"，大幅减少了故障转移后的全量同步。

这些演进将在下一篇文章中详细展开。

总结

旧版复制的"硬伤"可以总结为三个字：全、全、全——无论什么情况，都是全量同步。

缺陷	表现	后果
断线重连全量	丢了几KB数据，要传几GB的RDB	带宽和CPU严重浪费
反复fork写RDB	每次全量都fork子进程	主库性能下降，内存压力大
惊群效应	多从库同时重连	主库被压垮，正常服务受影响

这些缺陷不是Redis作者的技术失误，而是Redis演进过程中的必经阶段。先有简单可用的SYNC，再用PSYNC逐步完善，这是务实的工程选择。

如果你还在用Redis 2.6，这篇文章希望能说服你升级。如果你在用Redis 2.8+，你应该知道PSYNC帮你省了多少心。下一篇文章，我们将深入PSYNC的内部机制，看看这个"革命性"的改进是如何实现的。