Redis 的主从复制（Master-Slave Replication）是构建高可用缓存架构的基石。无论是哨兵模式（Sentinel）还是集群模式（Cluster），底层都依赖主从复制来实现数据冗余和故障转移。理解其工作原理，尤其是全量同步的每一个步骤，是面试中高频且区分度较高的考点。本文将从核心机制出发，逐层拆解全量同步的完整流程，并对比增量同步的差异，帮助你建立系统化的认知。
一、主从复制的核心作用
在展开流程之前，先明确主从复制解决的核心问题：
- 数据冗余：从节点作为主节点的热备，避免单点故障导致数据丢失。
- 读扩展：主节点处理写请求，从节点分担读请求，提升整体吞吐量。
- 故障恢复：主节点宕机后，可从从节点中选举新主，快速恢复服务。
- 高可用基础：哨兵和集群的自动故障转移均以主从复制为前提。
二、复制过程的三个关键阶段
Redis 主从复制并非一蹴而就，而是分为三个递进阶段：
- 建立连接与握手：从节点主动连接主节点，交换身份信息。
- 全量同步（Full Resynchronization）：首次连接或数据差异过大时，主节点生成 RDB 快照发送给从节点。
- 增量同步（Partial Resynchronization）：全量同步后，主节点持续将写命令传播给从节点，维持数据一致。
其中，全量同步是面试中最常被追问的环节，下面重点展开。
三、全量同步的完整流程
全量同步的触发条件通常有两个：从节点首次连接主节点；或从节点与主节点的复制偏移量差异过大，积压缓冲区无法容纳缺失的命令。其流程可拆解为以下步骤：
1. 从节点发起连接
从节点启动后，根据配置（replicaof 或 slaveof）向主节点发起 TCP 连接，并发送 PING 命令确认主节点可达。随后发送 AUTH（若设置了密码）和 REPLCONF listening-port，告知主节点自己的监听端口。
2. 身份验证与能力协商
主节点收到 REPLCONF 后，从节点继续发送 REPLCONF capa eof capa psync2，声明自己支持的复制能力（如 PSYNC2 协议、EOF 标记等）。主节点回复 +OK，双方完成能力协商。
3. 从节点发送 PSYNC 命令
从节点发送 PSYNC ? -1，其中 ? 表示未知主节点 runid，-1 表示首次同步。主节点收到后判断无法进行增量同步，决定执行全量同步。
4. 主节点生成 RDB 快照
主节点执行 BGSAVE 命令，fork 出一个子进程在后台生成 RDB 文件。注意：fork 过程会短暂阻塞主线程，这是全量同步对主节点性能影响最大的时刻。生成期间，主节点继续处理客户端写命令，并将这些写命令写入复制缓冲区（Replication Buffer），同时也会写入 AOF 缓冲区（若开启 AOF）。
5. 发送 RDB 文件
RDB 生成完毕后，主节点将 RDB 文件通过 socket 发送给从节点。发送期间，主节点依然将新的写命令追加到复制缓冲区。从节点收到 RDB 后，先清空自身旧数据，再加载 RDB 文件到内存。
6. 发送复制缓冲区中的写命令
RDB 发送完成后，主节点将复制缓冲区中积压的写命令发送给从节点。从节点执行这些命令，使自身数据追平主节点在 RDB 生成期间产生的变更。
7. 同步完成，进入命令传播阶段
至此，全量同步结束。主节点将自身 runid 和复制偏移量发送给从节点，从节点记录这些信息。此后，主节点每执行一条写命令，都会异步传播给从节点，从节点持续执行，维持最终一致。
四、全量同步中的关键概念
理解以下概念，能让你在面试中回答得更深入：
- 复制偏移量（Replication Offset）：主从双方各自维护一个偏移量，主节点每传播 N 字节命令，偏移量增加 N；从节点每接收 N 字节，偏移量也增加 N。通过对比偏移量可判断数据是否一致。
- 复制积压缓冲区（Replication Backlog）：主节点维护的一个固定大小环形缓冲区，默认 1MB。用于支持增量同步，若从节点断线时间较短，可从缓冲区中补发缺失命令。
- runid：每个 Redis 实例启动时生成的唯一标识。从节点通过比对 runid 判断主节点是否发生过变更。
- PSYNC2：Redis 4.0 引入的改进协议，支持从节点在故障转移后与新主节点进行部分同步，减少全量同步开销。
五、全量同步 vs 增量同步
| 对比维度 | 全量同步 | 增量同步 |
|---|---|---|
| 触发条件 | 首次连接或偏移量差异过大 | 短暂断线后重连 |
| 数据传输 | RDB 文件 + 缓冲区命令 | 仅缺失的写命令 |
| 资源开销 | 高（fork、磁盘 IO、网络传输） | 低 |
| 阻塞风险 | fork 时短暂阻塞主线程 | 几乎无阻塞 |
| 适用场景 | 初始化从节点 | 网络抖动后的快速恢复 |
六、面试常见追问与回答要点
追问 1：全量同步期间主节点阻塞吗？
fork 子进程时主线程会短暂阻塞，阻塞时间与实例内存大小正相关。RDB 生成和发送过程由子进程和后台线程完成，主节点不阻塞，但复制缓冲区的写入会占用内存。
追问 2：为什么从节点加载 RDB 前要清空数据？
避免旧数据与新数据混合导致不一致。从节点在全量同步前会执行 FLUSHALL，确保以主节点数据为准。
追问 3：复制缓冲区溢出怎么办？
若从节点断线时间过长，复制缓冲区被写满后，主节点会强制断开与从节点的连接。从节点重连后只能再次发起全量同步。
追问 4：如何优化全量同步性能？
- 适当调大
repl-backlog-size，减少全量同步触发概率。 - 控制单实例内存大小（建议不超过 10GB），降低 fork 耗时。
- 使用无盘复制（
repl-diskless-sync yes），避免磁盘 IO 瓶颈。 - 在低峰期添加从节点，减少对主节点的影响。
七、总结
Redis 主从复制的全量同步流程可概括为：握手协商 → PSYNC 请求 → BGSAVE 生成 RDB → 发送 RDB → 补发缓冲区命令 → 进入命令传播。其中，复制偏移量、复制积压缓冲区和 runid 是理解增量同步与故障转移的关键。掌握这些细节，不仅能从容应对面试，更能在实际运维中快速定位复制延迟、全量同步频繁触发等问题。建议结合 INFO replication 命令观察主从状态，加深对理论知识的理解。
未经允许不得转载：任鹏个人博客 » Redis 主从复制的工作原理和全量同步流程
