一、前言：全量同步 ≠ 简单“拷贝数据”
在 Redis 主从架构中，全量同步（Full Resynchronization） 是从节点首次连接或断连太久后的兜底机制。
虽然现代 Redis 通过 PSYNC2 大幅减少了全量同步频率，但在以下场景仍不可避免：
- 🆕 从节点首次上线
- 🔌 主从网络中断超过 repl-backlog-size 覆盖范围
- 🔄 主节点重启（旧版 Redis）
- 🧨 执行 SLAVEOF NO ONE 后重新绑定
本文将深入剖析：
✅ 全量同步的完整执行流程
✅ 何时触发全量而非增量同步
✅ 性能瓶颈与生产优化建议
二、全量同步 vs 增量同步：关键区别
| 触发条件 | 首次连接 or PSYNC 失败 | 网络闪断 + replid 匹配 + offset 在 backlog 内 |
| 数据传输量 | 整个数据库（GB 级） | 仅缺失命令（KB~MB 级） |
| 对主节点影响 | 高（fork + 磁盘 IO + 网络带宽） | 低（仅发送缓存命令） |
| 从节点恢复时间 | 秒~分钟级 | 毫秒~秒级 |
⚠️ 全量同步是性能敏感操作，应尽量避免频繁发生！
三、全量同步的完整执行流程
3.1 触发阶段：从节点发起请求
从节点连接主节点后，发送：
PSYNC ? -1
- ? 表示未知主节点 replid
- -1 表示无有效偏移量
3.2 主节点响应：启动 BGSAVE
主节点收到后，回复：
+FULLRESYNC <master_replid> <master_repl_offset>
并立即执行以下操作：
步骤 1：执行 BGSAVE 生成 RDB 快照
- fork 子进程（主线程短暂阻塞）
- 子进程遍历内存，生成临时 RDB 文件（如 temp-rdb-12345.rdb）
步骤 2：创建“复制客户端”并缓存增量命令
- 从 BGSAVE 开始，所有新写入的命令会被额外复制一份到：
- 客户端输出缓冲区（client output buffer）
- 复制积压缓冲区（replication backlog）
✅ 目的：确保 RDB 生成期间的数据不丢失！
3.3 数据传输阶段
3.4 收尾阶段
- 主节点原子重命名临时 RDB 文件（如有配置 rdb-del-sync-files yes 则删除）
- 从节点更新自身状态：
master_replid = <主节点 replid>
master_repl_offset = <主节点 offset>
四、什么情况下会触发全量同步？
4.1 必然触发
| 首次连接 | 从节点无 replid 和 offset |
| 执行 REPLICAOF 切换主节点 | replid 不匹配 |
| 主节点执行 DEBUG RELOAD | replid 重置 |
4.2 条件触发（PSYNC 失败）
| replid 不匹配 | 主节点重启（Redis < 4.0）或主从切换 |
| offset 超出 backlog 范围 | 网络中断太久，repl-backlog-size 不足 |
| 主节点 backlog 被清空 | 执行 CONFIG REWRITE 或主节点内存压力大 |
🔍 如何判断是否因 backlog 不足？
查看主节点 INFO replication：
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1000
若从节点的 offset < repl_backlog_first_byte_offset → 必全量同步
五、全量同步的性能瓶颈与优化
5.1 主要瓶颈点
| fork 耗时 | 主线程阻塞，QPS 下降 | 升级内核、关闭透明大页（THP） |
| 磁盘 IO | RDB 写入慢 | 使用 SSD、开启 repl-diskless-sync |
| 网络带宽 | 传输 RDB 慢 | 千兆/万兆网络、压缩（需应用层） |
| 从节点加载 | 内存不足 or 磁盘 swap | 增加从节点内存、关闭 THP |
5.2 关键配置优化
# 1. 增大复制积压缓冲区（减少全量触发）
repl-backlog-size 100mb # 默认 1mb，建议 100~500mb
# 2. 启用无盘复制（避免磁盘 IO）
repl-diskless-sync yes
repl-diskless-sync-delay 5 # 等待更多从节点连接（秒）
# 3. 限制从节点输出缓冲区（防 OOM）
client-output-buffer-limit replica 512mb 256mb 60
# 4. 持久化 replid（Redis 4.0+ 默认开启）
# 确保 RDB 文件包含 replid（无需额外配置）
💡 无盘复制（Diskless Replication）原理：
RDB 数据不写磁盘，直接通过 socket 流式发送给从节点，大幅降低磁盘压力。
六、生产环境最佳实践
✅ 避免频繁全量同步
- 监控 latest_fork_usec（fork 耗时）
- 监控主从 lag（延迟），设置告警阈值（如 > 30s）
- 定期检查 repl_backlog_histlen 是否接近 repl_backlog_size
✅ 安全上线从节点
- 预热：先在低峰期添加从节点
- 限流：使用 client-output-buffer-limit 防止主节点 OOM
- 验证：同步完成后，对比主从 INFO keyspace 是否一致
✅ 故障排查命令
# 主节点查看从节点状态
127.0.0.1:6379> INFO replication
# 从节点查看同步进度
127.0.0.1:6379> INFO replication
# 检查 RDB 文件是否包含 replid（Redis 4.0+）
strings dump.rdb | grep repl
七、全量同步与 RDB/AOF 的关系
- RDB 是全量同步的载体：无论是否开启 AOF，全量同步都使用 RDB 格式
- AOF 不参与主从同步：从节点同步的是命令效果，不是 AOF 文件
- 混合持久化不影响同步：主节点 RDB 头部含 replid，从节点可正常解析
📌 重要：即使你只开了 AOF，主从同步依然依赖 RDB 快照！
八、结语
感谢您的阅读！如果你有任何疑问或想要分享的经验，请在评论区留言交流！
