Redis主从复制全量同步七步时序与命令传播机制详解

文章目录

前言
阶段一：建立连接阶段
[阶段二：数据同步阶段（核心 7 步流转）](#阶段二：数据同步阶段（核心 7 步流转）)
- [步骤 1：从节点发送 `psync ? -1` 请求同步](#步骤 1：从节点发送 psync ? -1 请求同步)
- [步骤 2：主节点触发 `bgsave` 生成 RDB 文件](#步骤 2：主节点触发 bgsave 生成 RDB 文件)
- [步骤 3：主节点开始缓存期间的写命令](#步骤 3：主节点开始缓存期间的写命令)
- [步骤 4：主节点发送 RDB，从节点清空旧数据并载入](#步骤 4：主节点发送 RDB，从节点清空旧数据并载入)
- [步骤 5：主节点向从节点发送缓冲区中的写命令](#步骤 5：主节点向从节点发送缓冲区中的写命令)
- [步骤 6：从节点执行缓冲命令，追平主节点进度](#步骤 6：从节点执行缓冲命令，追平主节点进度)
- [步骤 7：从节点异步触发 `bgrewriteaof` 重写 AOF](#步骤 7：从节点异步触发 bgrewriteaof 重写 AOF)
阶段三：命令传播阶段（稳态运行）
- 心跳机制与保活
总结

前言

在 Redis 高可用架构中，主从复制（Master-Replica Replication）是实现读写分离和数据冗余的基石。要彻底搞懂主从复制，我们需要将其生命周期拆解为三个阶段：建立连接 、数据同步 和命令传播。

其中，数据同步阶段 的"全量复制"最为核心。本文将结合经典的全量同步时序流程，带你一步步拆解底层的 7 个关键步骤。

阶段一：建立连接阶段

当我们在从节点（Replica）上执行 REPLICAOF <master_ip> <master_port> 命令，或者在配置文件中配置了主节点信息时，从节点会主动向主节点发起 TCP 网络连接。在完成网络握手和身份验证（如果主节点配置了密码）后，主从节点之间正式建立起了常驻的通信管道，从节点做好了接收数据的准备。

阶段二：数据同步阶段（核心 7 步流转）

连接建立成功后，便进入了最关键的数据同步阶段。如果是首次连接，Redis 会触发全量复制 。整个全量复制的底层执行时序，可以完美浓缩为以下 7 个步骤：

步骤 1：从节点发送 `psync ? -1` 请求同步

因为是第一次建立连接，从节点此时不知道主节点的运行 ID（Run ID），也没有任何历史复制偏移量（Offset）。因此，从节点会向主节点主动发送一条 psync ? -1 命令，明确表达："我是全新加入的从节点，请对我进行全量数据同步"。

步骤 2：主节点触发 `bgsave` 生成 RDB 文件

主节点收到 psync ? -1 的全量同步请求后，会在后台异步触发 bgsave 命令。主节点会 fork 出一个子进程，利用操作系统的写时复制（COW）机制，将当前内存中的所有数据 dump 成一份完整的 RDB 快照文件。

步骤 3：主节点开始缓存期间的写命令

在主节点生成 RDB 文件以及随后通过网络传输该文件的这段"时间差"里，主节点依然在对外正常提供写服务。为了防止这期间产生的最新数据丢失，主节点会将这期间收到的所有客户端写命令，统统拦截并暂存到内存的缓冲区中。

步骤 4：主节点发送 RDB，从节点清空旧数据并载入

RDB 快照文件在后台生成完毕后，主节点会通过网络将其发送给从节点。从节点在接收到完整的 RDB 文件后，首先会彻底清空自己内存中的所有旧数据（防止新旧数据冲突），接着开始将 RDB 文件中的数据反序列化加载到内存中。

步骤 5：主节点向从节点发送缓冲区中的写命令

当从节点成功将 RDB 文件载入内存后，它此时的数据状态已经恢复到了主节点当初执行 bgsave 的那个历史时间点。为了追平之后的时间差，主节点会将步骤 3 期间积压在缓冲区里的所有最新写命令，通过长连接源源不断地补发给从节点。

步骤 6：从节点执行缓冲命令，追平主节点进度

从节点接收到主节点补发过来的缓冲区命令后，会严格按照顺序在本地依次执行这些写命令。通过重放这些命令，从节点的数据彻底追上了主节点的当前状态，主从两端的数据达到最终一致。

步骤 7：从节点异步触发 `bgrewriteaof` 重写 AOF

当数据彻底对齐后，如果从节点开启了 AOF 持久化功能，由于前面清空了旧数据并重新载入了庞大的 RDB 基础底座，原有的 AOF 日志已经不再适用且体积虚高。此时，从节点会自动在后台异步触发一次 bgrewriteaof 命令，重新生成一份精简的、与当前内存状态绝对对齐的 AOF 文件，以确保后续持久化的正确性。

阶段三：命令传播阶段（稳态运行）

当经历了数据同步（全量或增量）后，主从节点便进入了长期的正常稳定运行期------命令传播阶段。

在这个阶段，主节点只要执行了任何写命令，就会异步地将该命令同步一份发送给从节点。从节点接收并执行，从而保证在平时的业务运行中，主从数据能够保持实时的对齐。

心跳机制与保活

为了确保命令传播链路的绝对健康，主从之间维持着严密的心跳：

主节点 ➡️ 从节点 ：默认每隔 10 秒发送 PING 命令，测试网络是否畅通。
从节点 ➡️ 主节点 ：默认每隔 1 秒发送 REPLCONF ACK <自己的Offset> 命令。这不仅是向主节点报平安（心跳），更是在实时汇报自己的复制进度，让主节点能够精准监控主从延迟。

总结

Redis 的主从复制设计得非常精妙：

初次连接 时，严格遵循 7步时序流，利用 RDB 快照与写命令缓冲完成底座数据的无缝搬迁与 AOF 的优雅重写。
短暂闪断时，利用环形积压缓冲区进行轻量级的增量补发。
日常运行时：利用轻量级的异步命令传播与每秒心跳反馈维持长期对齐。