Redis主从同步原理(全量复制、增量复制)

Redis主从复制中的全量同步与增量同步详解

在Redis的高可用架构中,主从复制(Master-Slave Replication) 是实现数据冗余、读写分离以及后续哨兵(Sentinel)和集群(Cluster)机制的基础。其中,主节点与从节点之间的数据同步机制 分为两种:全量同步(Full Resynchronization)增量同步(Partial Resynchronization)

本文将带你深入理解这两种同步机制的工作原理、触发时机、底层实现细节,以及它们在实际应用中的优缺点和注意事项。


一、Redis主从复制的基本流程

当一个从节点第一次连接到主节点时,会发送一条 PSYNC 命令来请求同步数据。主节点收到请求后,会根据从节点的状态判断是进行全量同步还是增量同步。

📌 提示:Redis 的 PSYNC 命令是用于主从同步的核心命令,其语法格式为:

复制代码
PSYNC <runid> <offset>

其中 runid 是主节点的运行ID,offset 是当前复制偏移量。

二、全量同步(Full Sync)

1. 触发条件

  • 从节点首次连接主节点。
  • 从节点请求增量同步时,主节点发现其偏移量不在 repl_backlog 缓存范围内。
  • 主节点重启导致 runid 变化,无法识别从节点。

2. 同步过程详解

(1)从节点发送同步请求

从节点发送 PSYNC ? -1 表示请求全量同步。

(2)主节点执行 BGSAVE 生成 RDB 文件

主节点接收到全量同步请求后,会调用 BGSAVE 命令 fork 出一个子进程,异步地将当前内存中的数据保存为 RDB 文件。

在此期间,所有新的写操作会被记录到一个叫做 repl_backlog 的环形缓冲区中,以防止在 RDB 文件传输过程中丢失数据。

(3)主节点发送 RDB 文件给从节点

RDB 文件生成完成后,主节点会将其通过网络发送给从节点。这个过程可能会比较耗时,尤其是数据量较大的情况下。

(4)从节点加载 RDB 文件并进入同步阶段

从节点接收完 RDB 文件后,会清空自己的本地数据,并加载 RDB 文件中的数据。加载完成后,从节点会向主节点发送一个确认消息。

(5)主节点发送 backlog 中的数据

主节点将之前缓存在 repl_backlog 中的写操作命令继续发送给从节点,确保从节点数据完全同步至主节点的最新状态。

(6)进入命令传播阶段

完成全量同步后,主节点会持续将新产生的写命令转发给从节点,从而保持主从数据的一致性。


三、增量同步(Partial Sync)

1. 触发条件

  • 从节点已经进行过一次同步(非首次连接)。
  • 从节点因网络波动等原因断开连接后重新连接主节点。
  • 主节点仍然保有从节点上次同步位置之后的操作日志(即 offset 在 repl_backlog 范围内)。

2. 同步过程详解

(1)从节点发送 PSYNC 请求

从节点发送 PSYNC <runid> <offset>,其中:

  • runid 是主节点上一次同步时返回的运行ID。
  • offset 是从节点最后一次成功接收到的偏移量。
(2)主节点验证请求是否有效

主节点检查:

  • 当前 runid 是否与从节点请求的 runid 相同。
  • 请求的 offset 是否仍在 repl_backlog 缓存范围内。

如果都满足,则可以进行增量同步;否则仍需进行全量同步。

(3)主节点发送 backlog 中的命令

主节点从 repl_backlog 中提取从 offset 开始的所有写命令,发送给从节点。

(4)从节点执行这些命令并更新 offset

从节点依次执行这些命令,更新本地数据,并更新自己的复制偏移量(offset)。

(5)进入命令传播阶段

与全量同步类似,此后主节点将继续把新的写命令实时发送给从节点。


四、关键组件解析

1. repl_backlog 环形缓冲区

  • repl_backlog 是一个固定大小的环形缓冲区,默认大小为 1MB
  • 所有主节点在进行主从同步时的写操作都会先被记录到该缓冲区中。
  • 它的存在是为了支持增量同步,避免每次断线都要进行全量同步。
  • 如果缓冲区太小,在主从断开时间较长或写入频繁的情况下,旧的 offset 数据可能已经被覆盖,从而导致无法进行增量同步。

2. runid(主节点运行ID)

  • 每次主节点启动时都会生成一个新的 runid。
  • 从节点在同步时会记住主节点的 runid,用于后续同步的身份验证。
  • 如果主节点重启,runid 会变化,从节点即使携带之前的 offset 也无法匹配,必须进行全量同步。

3. 复制偏移量(replication offset)

  • 主节点和从节点各自维护一个偏移量,表示已处理的字节数。
  • 主节点每发送一个命令,就会增加偏移量。
  • 从节点每接收并处理一个命令,也会更新自己的偏移量。
  • 通过对比偏移量,可以判断主从之间是否存在延迟或断连。

五、全量同步 vs 增量同步对比

特性 全量同步 增量同步
触发条件 初次连接 / repl_backlog 不足 断线重连且 offset 有效
数据传输方式 发送完整 RDB 文件 + backlog 数据 仅发送 backlog 中的部分数据
性能消耗 较大(涉及 RDB 生成和传输) 较小(仅传输部分命令)
对网络影响 高(大量数据传输) 低(少量数据传输)
适用场景 初次同步 / 主节点重启 / 长时间断连 短暂断连后的快速恢复
相关推荐
科技小花7 小时前
数据治理平台架构演进观察:AI原生设计如何重构企业数据管理范式
数据库·重构·架构·数据治理·ai-native·ai原生
一江寒逸7 小时前
零基础从入门到精通MySQL(中篇):进阶篇——吃透多表查询、事务核心与高级特性,搞定复杂业务SQL
数据库·sql·mysql
D4c-lovetrain7 小时前
linux个人心得22 (mysql)
数据库·mysql
阿里小阿希8 小时前
CentOS7 PostgreSQL 9.2 升级到 15 完整教程
数据库·postgresql
荒川之神8 小时前
Oracle 数据仓库雪花模型设计(完整实战方案)
数据库·数据仓库·oracle
做个文艺程序员8 小时前
MySQL安全加固十大硬核操作
数据库·mysql·安全
不吃香菜学java8 小时前
Redis简单应用
数据库·spring boot·tomcat·maven
一个天蝎座 白勺 程序猿9 小时前
Apache IoTDB(15):IoTDB查询写回(INTO子句)深度解析——从语法到实战的ETL全链路指南
数据库·apache·etl·iotdb
不知名的老吴9 小时前
Redis的延迟瓶颈:TCP栈开销无法避免
数据库·redis·缓存
YOU OU9 小时前
三大范式和E-R图
数据库