Redis 主从复制机制里的“时序核心”

 Redis 主从复制机制的“时序核心”——这是理解 Redis 高可用和数据一致性的关键点。我们来一口气梳理一下整个流程的时序细节（特别适合你保存笔记）。

---

✅ Redis 主从复制机制的完整时序流程图解

我们从**主节点（master）和从节点（replica/slave）**的角度，一步步看清楚：

---

🔵 1. 从节点初次连接主节点

• 从节点发送 PSYNC 或 SYNC 请求；

• 主节点收到后，fork 子进程生成 RDB 快照；

• 同时：主节点开启复制缓冲区（replication backlog buffer），记录RDB 开始时刻之后的所有写操作（增量）；

---

🟡 2. 主节点发送 RDB 快照

• 主节点将 RDB 快照通过 socket 发送给从节点；

• 从节点一边接收快照，一边加载数据到内存；

• 主节点仍然不断接受新写操作，并追加到复制缓冲区中。

---

🟢 3. 从节点加载 RDB 完毕，发送 ACK

• 从节点加载完毕后，向主节点发送 ACK 表示准备接收增量同步；

• 主节点收到 ACK 后，立即从复制缓冲区中提取增量写操作（从 fork 到现在的），推送给从节点；

• 从节点接收并执行，直到追上主节点。

---

🟣 4. 进入实时复制阶段（streaming replication）

• 增量同步完成后，主从双方进入实时同步阶段；

• 所有主节点的新写命令，都会实时推送给从节点执行；

• 保证主从数据一致。

---

🧠 核心时序点说明

阶段	主节点动作	从节点状态	缓冲区中的内容	同步是否完成
fork 开始	fork RDB + 开启缓冲	发起 PSYNC	开始记录写操作	❌未完成
RDB 发送中	正常写入业务 + 记录操作	正在加载 RDB	RDB 之后的写入	❌未完成
RDB 加载完成	等待 ACK + 累计写操作	发出 ACK	包含 ACK 前后的写	✅准备完成
ACK 收到	推送缓冲区全部命令	接收 + 执行	实时清理	✅完成
实时同步	实时写入实时推送	实时执行	实时写入进缓冲	✅实时同步中

---

❗重点：为什么主从复制不会漏数据？

因为主节点：

• 在 fork 的那一刻开始，就持续记录了写操作；

• 即使 RDB 生成和加载耗时很久，只要 复制缓冲区没被覆盖掉（默认 1MB，可调），就能准确补齐所有数据；

• 若 backlog 被覆盖，则会自动退回到全量同步。

---

🧩 可选配置说明：

参数名	含义
repl-backlog-size	设置复制缓冲区大小（默认 1MB）
repl-timeout	从节点响应超时时间
min-slaves-to-write	写安全性控制
slave-priority	故障转移优先级

---

✅ 一句话总结：

Redis 主从复制靠的是 fork 时刻 + backlog 缓冲 + ACK 确认 + 实时推送 四部曲，构成完整的“主从数据一致时序模型”。