在Redis高可用架构中，主从同步是实现数据冗余、读写分离和故障转移的核心机制。很多开发者对主从同步的理解停留在"主节点把数据发给从节点"的层面，但实际上，Redis通过一套精巧的协议设计，在保证数据一致性的同时，最大限度地降低了性能开销。本文将深入剖析Redis主从同步的核心原理，特别是全量同步与增量同步的触发条件与执行流程。
全量同步：首次连接的"数据搬家"
当从节点（Slave）首次连接主节点（Master）时，会触发全量同步。这是最消耗资源的同步方式，因为它涉及完整数据集的传输。
核心元数据
在深入流程之前，我们需要理解两个关键概念：
- Replication ID（replid）：数据集的唯一标识。每个Master启动时都会生成一个唯一的40位随机字符串作为replid，Slave会继承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以上），以容纳更多断线期间的命令。- 环形特性：当缓冲区写满后，旧数据会被新数据覆盖。如果从节点断线时间过长，导致所需数据已被覆盖，则只能回退到全量同步。