Redis主从同步原理：从全量同步到增量同步的完整解析

在Redis高可用架构中主从同步是实现数据冗余、读写分离和故障转移的核心机制。很多开发者对主从同步的理解停留在“主节点把数据发给从节点”的层面但实际上Redis通过一套精巧的协议设计在保证数据一致性的同时最大限度地降低了性能开销。本文将深入剖析Redis主从同步的核心原理特别是全量同步与增量同步的触发条件与执行流程。全量同步首次连接的“数据搬家”当从节点Slave首次连接主节点Master时会触发全量同步。这是最消耗资源的同步方式因为它涉及完整数据集的传输。核心元数据在深入流程之前我们需要理解两个关键概念Replication IDreplid数据集的唯一标识。每个Master启动时都会生成一个唯一的40位随机字符串作为replidSlave会继承Master的replid。只有当replid一致时才能说明双方属于同一数据集。Offset偏移量同步进度的标记。Master每发送一个字节的数据自身的offset就会增加Slave每接收一个字节也会更新自己的offset。当Master和Slave的offset相等时说明数据完全同步。全量同步的三个阶段全量同步的过程可以清晰地划分为三个阶段第一阶段连接建立与版本协商从节点执行REPLICAOF命令Redis 5.0之前为SLAVEOF主动与主节点建立TCP连接。连接建立后从节点会发送PSYNC命令携带自身的replid首次为?和offset首次为-1。主节点收到请求后发现replid不匹配或为未知判定这是一次全新的同步请求于是返回FULLRESYNC响应告知从节点自己的replid和当前offset。第二阶段RDB快照生成与传输主节点执行BGSAVE命令在后台异步生成当前内存数据的RDB快照文件。这个过程通过fork子进程完成不会阻塞主节点的正常服务。生成完成后主节点将RDB文件通过网络发送给从节点。从节点接收到RDB文件后会先清空本地所有旧数据然后加载RDB文件到内存中。第三阶段增量命令补发在RDB文件生成和传输的这段时间内主节点依然在接收新的写命令。为了保证数据不丢失主节点会将这些新产生的写命令写入repl_backlog复制积压缓冲区。当从节点加载完RDB文件后主节点会将repl_backlog中缓存的写命令发送给从节点执行。至此从节点的数据状态与主节点完全一致全量同步完成。增量同步断线重连的“精准续传”全量同步虽然可靠但代价高昂。为了避免每次网络抖动都重新传输整个数据集Redis引入了增量同步机制。触发条件当主从连接因网络波动断开后重新连接时从节点会发送PSYNC replid offset命令。主节点收到请求后会进行两个关键检查replid是否匹配确认从节点之前同步的是自己而非另一个重启后的主节点。offset是否在repl_backlog范围内确认从节点缺失的数据是否还在缓冲区内。只有当这两个条件都满足时主节点才会返回CONTINUE响应仅发送从节点缺失的那部分命令实现增量同步。复制积压缓冲区repl_backlog这是一个固定大小的环形缓冲区默认1MB用于存储最近的写命令。它的设计非常巧妙大小配置可以通过repl-backlog-size参数调整。如果业务写入量大或网络不稳定建议适当调大如10MB以上以容纳更多断线期间的命令。环形特性当缓冲区写满后旧数据会被新数据覆盖。如果从节点断线时间过长导致所需数据已被覆盖则只能回退到全量同步。