redis主从复制通过全量同步和增量同步协同工作：首次连接或偏移量超出缓冲区范围时触发全量同步，由主节点生成rdb并发送+补发积压命令；日常运行及短时断连则依赖replid和offset校验，执行高效增量同步。
Redis 主从复制通过全量同步和增量同步两个阶段协同工作，确保从节点数据既完整又实时。核心逻辑是：首次连接或断连后无法追平时走全量；日常运行和短时断连则靠增量高效补漏。
全量同步：建立初始一致状态
这是从节点“第一次认识”主节点时的重载过程，目标是获得一份完整、准确的数据快照。
- 从节点发送 PSYNC ? -1 请求，表明无历史复制信息，需全量拉取
- 主节点执行 BGSAVE 启动后台子进程生成 RDB 文件，主进程继续服务不阻塞
- RDB 生成期间所有新写命令被暂存进 复制积压缓冲区（repl_backlog）
- RDB 文件传输到从节点后，从节点清空旧数据、加载 RDB，完成基础数据重建
- 主节点再把 repl_backlog 中积攒的命令发给从节点执行，让其追上断档期的变更
增量同步：维持常态数据一致性
全量完成后，主从进入命令传播阶段，靠偏移量（offset）和复制ID（replid）精准识别“差多少”，只传缺失部分。
- 主节点每执行一条写命令，就向所有在线从节点广播该命令，并递增自己的 offset
- 从节点执行命令后也更新本地 offset，定期上报给主节点
- 网络短暂中断后重连，从节点带上当前 replid 和 offset 发起 PSYNC
- 主节点检查：若 replid 匹配且 offset 落在 repl_backlog 可覆盖范围内，直接发送缺失命令段（Partial Resync）
- repl_backlog 是固定大小的环形缓冲区，过小会导致断连稍久就无法增量，被迫回退全量
触发机制：什么时候走哪条路
Redis 不会猜测，而是严格依据两个参数做决策：
- replid 不一致 → 视为全新从节点或主节点重启 → 强制全量同步
- replid 一致但 offset 超出 repl_backlog 范围 → 缓冲区已覆盖旧数据 → 只能全量
- replid 一致且 offset 有效 → 精准定位断点 → 执行增量同步
关键保障设计
整个过程依赖几个底层机制支撑可靠性与性能平衡：
- 异步非阻塞：BGSAVE 和网络传输都不影响主节点处理客户端请求
- 从节点可读：即使正在加载 RDB 或追赶命令，仍可响应读请求（数据可能滞后）
- 一主多从扩展性：主节点只需维护一份 repl_backlog，多个从节点各自按需同步
- backlog 大小可调：通过 repl-backlog-size 配置，越大越能容忍长断连，但占更多内存
