Redis 主从复制全解析：从 PSYNC 协议到复制积压缓冲区的故障切换边界-北京尧图网络

Redis 主从复制全解析从 PSYNC 协议到复制积压缓冲区的故障切换边界1. 先从一个真实困惑说起为什么主节点挂了从节点还是旧数据假设你负责一个电商秒杀系统Redis 采用一主两从部署主节点 M 处理所有写请求从节点 S1、S2 通过复制保持数据一致。某个大促凌晨M 所在机器宕机Sentinel 在几秒内把 S1 提升为新主。运维在监控上看复制延迟只有 50ms理论上最多丢 50ms 的数据。但业务核查时发现某件商品的库存扣减记录丢失了近 3 秒的写入量——用户付款成功库存却没扣。问题不在于 Sentinel 切换慢而在于主从复制从来不是「主节点写完从节点立刻就有」的强一致模型。它是一套异步复制协议主节点写入本地内存后立即返回客户端再把写命令异步推给从节点。M 在宕机前那几秒产生的写命令如果还没被 S1 收到切换后就永久丢失了。而「那几秒」的边界恰恰由一个容易被忽视的结构决定——复制积压缓冲区repl_backlog。这篇文章不会一上来就丢出 PSYNC 的状态机而是先把整个复制体系拆成几个角色和一条数据流让你能用自己的话复述一遍然后再逐个机制钻进去。目标很明确读完你能回答三个问题——复制到底怎么同步的、backlog 到底决定了什么边界、故障切换时会丢多少数据。2. 一句话模型与整体框架谁在跟谁说话先用一句普通中文记住核心模型Redis 主从复制就是从节点连上主节点后先领一份全量数据快照之后持续接收主节点推送的增量写命令并用一个不断增长的偏移量来标记「我收到哪儿了」。把整体拆成三部分先看它们怎样串起来写命令传播写命令客户端 ---- [主节点 Master] ----------------- [从节点 Replica 1] | | ^ | | 传播写命令 | | ------------------------- [从节点 Replica 2] | | 维护: runid / master_repl_offset | 维护: repl_backlog (环形缓冲) | 维护: 每个从节点的 ack 偏移量角色: Master : 接受写、生成复制流、记录 backlog Replica : 发起 PSYNC、接收 RDB 或增量流、周期性上报 ack offset Sentinel/Cluster : 观测主从状态在故障时执行切换三个角色分工如下角色核心职责关键状态主节点 Master执行写命令、生成复制流、维护 backlogrunid、master_repl_offset、repl_backlog从节点 Replica连接主节点、接收数据、上报确认偏移master_link_status、slave_repl_offset哨兵/集群 Sentinel/Cluster监控、判定客观下线、执行故障切换主观下线、客观下线、quorum、epoch一个请求/数据的完整流转顺序是客户端写主节点 → 主节点执行并追加到 backlog → 主节点把命令异步推给所有从节点 → 从节点执行并更新自己的偏移量 → 从节点周期性向主节点上报 ack 偏移量。任何环节中断复制就可能退化为全量重同步。下一节开始我们按这个顺序逐个拆解。3. 复制偏移量复制世界里的「打卡进度」3.1 偏移量到底标记了什么复制偏移量replication offset是最容易理解、也最容易被忽视的概念。可以先把它理解成一条不断增长的字节流上的「打卡点」主节点每产生一个字节的复制流就把它自己的偏移量加一从节点每接收并应用一个字节就把自己的偏移量加一。两者之差就是通常说的复制延迟以字节计不直接等于时间。一个最小数字例子时刻 T1: 主节点执行 SET k1 v1复制流增加 30 字节 master_repl_offset 1000 replica_repl_offset 1000 (从节点已跟上差值为 0) 时刻 T2: 主节点连续执行 5 条写命令复制流增加 200 字节 master_repl_offset 1200 replica_repl_offset 1000 (从节点还没收到差值 200)差值 200 并不等于「丢了 200 字节的数据」它只表示从节点暂时落后。只要主节点还活着复制流会继续推送从节点最终会追到 1200。真正危险的是主节点在这段落后期间宕机——从节点永远停在 1000而主节点最后那 200 字节的写命令就可能丢失。3.2 偏移量与故障切换的关系故障切换时Sentinel 或 Cluster 会优先选择偏移量最大的从节点作为新主因为它「收到的最多」。这就解释了为什么复制延迟过大的从节点不应该被优先提升它的数据更旧。最容易误解的一点是偏移量相等不代表数据完全一致。如果从节点在应用命令过程中出错或者主节点曾发生过角色转换导致 runid 变化偏移量相同也可能指向不同的数据历史。所以偏移量只能作为「量」的参考判断一致性还要结合复制 IDreplid / runid一起看。4. PSYNC 协议握手阶段决定了走哪条同步路径4.1 为什么需要 PSYNC而不是每次全量如果每次从节点重连都要主节点做一次全量快照RDB并传输那么网络抖动、从节点短暂重启都会引发巨额开销。为此 Redis 在 2.8 引入了 PSYNCPartial SYNC部分同步协议从节点在连接时告诉主节点「我曾经同步到哪个 runid 和哪个偏移量」主节点据此判断能否只补发缺失的那一小段命令。PSYNC 的核心交互可以概括成三个分支从节点: PSYNC replid offset 主节点判断: 分支 A: replid 匹配且 offset 在 backlog 覆盖范围内 - CONTINUE只补发缺失命令 (部分重同步) 分支 B: replid 不匹配或第一次连接 - FULLRESYNC new_replid offset走全量 (全量重同步) 分支 C: replid 匹配但 offset 太旧已被 backlog 覆盖掉 - FULLRESYNC也只能走全量第一次连接时从节点发的是PSYNC ? -1问号表示「我不知道之前的 replid」-1 表示「我不知道偏移量」。主节点一律回FULLRESYNC。4.2 一次 PSYNC 完整握手示例可以用redis-cli直连主节点手工模拟一次握手来观察响应这是调试复制时非常有用的手段# 目标: 观察主节点对一次 PSYNC 请求的响应分支# 前置: 本机启动一个 Redis 实例端口 6379redis-cli-p6379# 先看看当前主节点的复制 ID 和偏移量INFO replication# 手工发送 PSYNC用当前 replid 和当前 offset模拟一次正常重连PSYNC当前replid当前offset# 预期: CONTINUE然后开始接收主节点后续推送的命令流# 再试一个明显过旧的 offset例如 1模拟 backlog 已被覆盖PSYNC当前replid1# 预期: FULLRESYNC replid offset随后主节点开始传输 RDB关键点在于CONTINUE和FULLRESYNC是两条完全不同的路径。前者只补差量代价很小后者要 fork 子进程做 RDB 快照、传输全量数据、从节点清空并加载——在数据量大的实例上这可能耗时几十秒甚至几分钟。所以工程上真正要争取的是让重连尽量走CONTINUE。而这个「能不能补差量」的判据就落在下一节的 backlog 上。常见错误手工执行 PSYNC 后如果直接退出了交互会话主节点会保留一个未完成的从节点连接一段时间可能污染INFO replication的从节点计数。调试完记得断开或直接重启该实例。5. repl_backlog决定能不能「只补一点」的环形缓冲5.1 backlog 是什么为什么是环形的复制积压缓冲区replication backlog是主节点上的一块内存区域用来暂存最近推送过的复制流。当从节点断线重连并请求部分同步时主节点就从 backlog 里找出从节点缺失的那一段补给它。可以把它理解成一个「最近 N 条命令的录音带」只保留最近的一部分。它被实现成环形缓冲区ring buffer固定大小写满后从头覆盖旧数据。这意味着 backlog 只能覆盖「最近一段时间」的命令更早的会被挤掉。概念含义典型配置repl-backlog-sizebacklog 的字节容量默认 1MB生产常调大到 64MB 或更多repl-backlog-ttl最后一个从节点断开后backlog 保留多久默认 3600 秒覆盖范围backlog 能容纳的复制流秒数取决于写入速率写入越快覆盖时间越短5.2 backlog 命中与未命中的边界backlog 是否命中决定了一次重连是全量还是增量。用数字说明假设某实例写入速率是 2MB/sbacklog 配置为 64MB那么 backlog 大约能覆盖 32 秒的复制流。场景一: 从节点断线 5 秒后重连缺失复制流约 10MB 64MB - backlog 命中 - CONTINUE - 秒级恢复场景二: 从节点断线 60 秒后重连缺失复制流约 120MB 64MB - backlog 未命中 - FULLRESYNC - 全量传输这就是 backlog 的核心价值它把「网络抖动导致的短时断连」这种高频、低代价的场景从全量重同步里救了出来。反过来backlog 太小会让频繁抖动的集群不断触发全量同步backlog 太大则白占内存。工程上的经验公式是所需容量 ≈ 平均写入速率 × 可容忍的最长断线时间 × 安全系数。最容易误解的是调大 backlog 并不能减少故障切换时的数据丢失。它只影响「断线重连能否走增量」而切换时数据丢多少取决于从节点 ack 的偏移量和主节点实际写入偏移量的差是另一回事。这两个概念经常被混为一谈。6. 全量重同步一次昂贵但必要的快照传输6.1 全量同步的完整过程当 PSYNC 判定无法部分同步时主节点会触发全量重同步。整个过程按时间顺序如下从节点主节点 | | |--- PSYNC ? -1 -------------- | | | fork 子进程生成 RDB 快照 |-- FULLRESYNC replid off | |-- RDB 文件数据 ------------ | 同时把 fork 之后的写命令 | | 缓存到 repl_backlog / 客户端缓冲 | 清空本地数据加载 RDB | | | |--- 加载完成 ----------------- | |-- 补发 fork 期间的写命令 ---- | |-- 持续增量复制流 ---------- |注意两个细节第一主节点在 fork 生成 RDB 期间会继续接受写请求这些新命令被缓存起来等 RDB 传完后补发给从节点第二从节点加载 RDB 时会先清空自己的旧数据所以全量同步期间从节点对外是不可用的取决于配置一般对外只读。6.2 fork 与 copy-on-write 的代价全量同步的昂贵不只在于网络传输更在于主节点的fork操作和随之而来的写时复制copy-on-write。fork 会短暂阻塞主线程如果实例内存很大比如 32GBfork 的页表复制本身就可能造成几十到几百毫秒的卡顿。同时fork 后主节点的写操作会触发物理页复制内存可能膨胀到接近两倍。下面这个最小可复现脚本用来观察全量同步时的内存与耗时变化#!/usr/bin/env bash# 目标: 观察一次全量重同步期间主节点的内存峰值与从节点状态# 前置: 已有一主一从主节点端口 6379从节点端口 6380set-euopipefail# 在主节点写入约 200MB 数据制造一定内存规模redis-cli-p6379flushallforiin$(seq1200);doredis-cli-p6379-xsetbig:$i/dev/urandom|head-c1048576/dev/null||truedone# 打印从节点当前状态应看到 master_link_status:down 之前是 upredis-cli-p6380info replication|grep-Emaster_link_status|slave_repl_offset# 在从节点执行全量重同步并计时/usr/bin/time-vredis-cli-p6380replicaof127.0.0.1637921|tail-5# 观察主节点内存与 fork 相关指标redis-cli-p6379info memory|grep-Eused_memory_human|mem_fragmentation_ratioredis-cli-p6379info stats|grep-Elatest_fork_usecredis-cli-p6379info replication|grep-Emaster_repl_offset|repl_backlog运行后重点看三项latest_fork_usec反映 fork 耗时持续偏大说明实例内存过重、used_memory在同步期间是否接近翻倍说明 CoW 页复制严重、从节点master_link_status从 down 变 up 的耗时即全量同步总时长。适用场景是容量评估与故障演练边界在于该脚本会清空数据绝不能在生产实例执行应放在隔离的测试环境。7. 故障切换偏移量、backlog 与切换策略怎么共同决定丢多少数据7.1 切换时数据丢失的定量理解故障切换failover的数据丢失边界可以用一个不等式表达可能丢失的数据量 ≤ 主节点最后成功写入的偏移量 — 被提升从节点最后 ack 的偏移量这里的「被提升从节点」是 Sentinel/Cluster 选出的那个偏移量最大的从节点。也就是说即使系统里有三个从节点能保住的数据也只取决于最「新」的那一个。如果那个从节点本身落后主节点 2 秒那这 2 秒就得丢。影响因素对丢数据的影响可调手段从节点复制延迟延迟越大丢失上限越高网络优化、从节点算力、避免大 Key 阻塞主节点写入速率同样延迟下速率越高丢得越多业务层限流、写命令合并backlog 大小不影响切换丢失只影响重连路径主要作用是减少全量同步min-replicas-to-write强制至少有 N 个从节点 ack 才允许写可显著降低丢失但会牺牲可用性7.2 用 min-replicas 把「异步」变成「有条件的半同步」Redis 提供了一组配置让主节点在从节点数量或延迟不满足条件时拒绝写入从而给异步复制加一道「准同步」护栏# redis.conf 关键片段 # 至少有 2 个从节点的复制延迟不超过 10 秒主节点才接受写 min-replicas-to-write 2 min-replicas-max-lag 10含义是如果当前健康从节点少于 2 个或它们落后超过 10 秒主节点直接对写命令返回错误。这能在一定程度上把「丢 10 秒数据」的概率压下去代价是当从节点集体抖动时主节点会拒绝写入可用性下降。它不能保证零丢失只是把丢失窗口约束住。7.3 时序一次完整切换里发生了什么时间轴 Sentinel 视角 t0 Master 正常Replica 持续 ack t1 Sentinel 主观下线 Masterping 超时 t2 Sentinel 向其他 Sentinel 询问达到 quorum - 客观下线 t3 选举 Leader Sentinel基于 epoch 和 Raft 式投票 t4 Leader 从 Replica 中挑选 offset 最大、优先级最高者 t5 向该 Replica 发送 REPLICAOF NO ONE提升为新 Master t6 其余 Replica 转向新 Master 复制 t7 旧 Master 恢复后被降级为新 Master 的从节点从 t1 到 t5 这段时间是数据丢失窗口主节点若在 t0 之后、t1 之前仍接受了写入这些写入只有那些已被从节点收到的部分能保住。所以工程上要监控的核心指标是「从节点 ack 偏移量和主节点偏移量的差值」在故障窗口内的最大值。8. Java 工程实践用 Spring Boot 观察复制状态并做写保护8.1 最小示例读取复制状态目标在 Spring Boot 应用中通过RedisConnection读取主从复制信息便于在健康检查里暴露复制延迟。前置环境Spring Boot 3.xspring-boot-starter-data-redis本机一主一从。packagecom.example.replication;importorg.springframework.boot.SpringApplication;importorg.springframework.boot.autoconfigure.SpringBootApplication;importorg.springframework.context.ConfigurableApplicationContext;importorg.springframework.data.redis.connection.RedisConnection;importorg.springframework.data.redis.connection.RedisConnectionFactory;importjava.util.Properties;SpringBootApplicationpublicclassReplicationProbeApplication{publicstaticvoidmain(String[]args){try(ConfigurableApplicationContextctxSpringApplication.run(ReplicationProbeApplication.class,args)){RedisConnectionFactoryfactoryctx.getBean(RedisConnectionFactory.class);try(RedisConnectionconnfactory.getConnection()){Propertiesinfoconn.info(replication);Stringroleinfo.getProperty(role);Stringoffsetinfo.getProperty(master_repl_offset);StringlinkStatusinfo.getProperty(master_link_status);StringslaveOffsetinfo.getProperty(slave_repl_offset);System.out.println(rolerole, master_offsetoffset, linklinkStatus, slave_offsetslaveOffset);if(slave.equals(role)){longmasterLong.parseLong(offset);longslaveLong.parseLong(slaveOffset);longlagmaster-slave;System.out.println(复制延迟字节数lag);if(lag20*1024*1024){System.err.println(警告: 复制延迟超过 20MB故障切换可能丢失较多数据);}}}}}}关键步骤conn.info(replication)返回的 Properties 里master_repl_offset是主节点偏移量slave_repl_offset是从节点已应用偏移量。预期输出类似roleslave, master_offset1200, linkup, slave_offset1000并打印延迟字节数。适用场景是健康检查与告警容易改错的地方是从节点上master_repl_offset字段在部分版本里也可能是主节点的偏移快照务必以INFO replication实际输出为准不要想当然按字段名解析。8.2 结合 Redisson 的分布式锁与复制延迟目标演示在复制延迟存在时分布式锁可能出现的边界问题。前置Redisson 客户端连接一主两从。packagecom.example.replication;importorg.redisson.Redisson;importorg.redisson.api.RLock;importorg.redisson.api.RedissonClient;importorg.redisson.config.Config;importjava.util.concurrent.TimeUnit;publicclassLockWithReplicationRisk{publicstaticvoidmain(String[]args)throwsInterruptedException{ConfigconfignewConfig();config.useSingleServer().setAddress(redis://127.0.0.1:6379);RedissonClientclientRedisson.create(config);RLocklockclient.getLock(order:lock:1001);try{booleanlockedlock.tryLock(3,10,TimeUnit.SECONDS);if(!locked){System.out.println(未获取到锁放弃处理);return;}System.out.println(获取锁成功处理订单扣减);// 模拟业务处理Thread.sleep(500);}catch(InterruptedExceptione){Thread.currentThread().interrupt();System.err.println(加锁过程被中断);}finally{if(lock.isHeldByCurrentThread()){lock.unlock();}client.shutdown();}}}这段代码本身正确但要理解它在主从复制下的边界Redisson 的锁依赖主节点写入。如果主节点在锁写入后、同步到从节点前宕机而故障切换又选了一个没有这条锁记录的从节点那么新主上锁就不存在第二个线程可能同时拿到锁。缓解手段是对强一致要求的场景用 Redlock 或基于min-replicas-to-write的写保护或改用带共识的协调服务如 etcd、ZooKeeper。这里的关键结论是基于单主异步复制的 Redis 锁天然存在故障切换时的互斥失效窗口不能用于对正确性要求极高的资金类互斥。适用场景是并发度控制、幂等辅助不适用场景是严格串行的资金操作。9. Sentinel 与 Cluster 下的复制边界对比很多团队把 Sentinel 和 Cluster 的复制行为混为一谈其实两者在「一个分片内的复制」上是同一套 PSYNC backlog 机制差别在故障切换的触发和范围。维度Sentinel 模式Cluster 模式复制单位整个主节点每个分片的主节点切换触发Sentinel 集群判定客观下线分片内节点投票集群总线切换范围全局所有从节点跟随仅该分片其他分片不受影响数据丢失边界提升偏移最大的从节点同样但只影响该分片的数据backlog 角色断线重连走增量同左且分片间独立常见风险脑裂、切换期间写丢失分片倾斜、跨分片事务不可用结论化的选择当数据量不大、需要全局原子操作如 KEYS、事务、Lua 跨 Key时选 Sentinel当数据量大、需要水平扩展且能接受分片语义时选 Cluster。两者都不能消除异步复制的丢失窗口只能通过min-replicas和合理的从节点布局来收窄它。10. 常见误区与实际表现误区实际表现正确理解「主从复制是强一致」切换后数据回退异步复制只保证最终一致「调大 backlog 能防丢数据」切换照样丢backlog 只影响重连是否增量「偏移量相同就数据一致」极端情况下不一致还需核对 replid 与历史「从节点越多越安全」切换只认最新的那个关键是最大偏移从节点的状态「Sentinel 切换是瞬时的」秒级到十几秒主观下线投票需要时间11. 生产实践建议与排障清单11.1 监控指标master_repl_offset与从节点slave_repl_offset的差值按实例和时间趋势告警。master_link_status必须持续为up出现down立即排查。latest_fork_usec持续超过 100ms 说明实例内存过重考虑调整持久化与内存结构。repl_backlog_size与历史最大断线时长的乘积用于校验 backlog 是否够大。11.2 排障清单从节点master_link_status为down检查网络连通、主节点是否设置了requirepass、密码配置是否一致。频繁全量重同步检查 backlog 是否过小、从节点是否频繁重启、网络是否存在周期性抖动。切换后大量数据回退核对被提升从节点的 ack 偏移量、切换窗口内主节点的写入量。复制延迟持续增长排查大 Key、慢命令、从节点磁盘或内存瓶颈。12. 面试与复盘问题为什么 Redis 需要复制积压缓冲区它和全量重同步是什么关系PSYNC 的三种响应分支分别对应什么条件故障切换时的数据丢失上限由哪两个偏移量决定min-replicas-to-write能否保证零丢失它的代价是什么单主异步复制下的分布式锁在什么条件下会失去互斥性Sentinel 与 Cluster 的切换范围差异对业务一致性有什么影响13. 总结用一张决策清单收束需要判断一次复制行为会走哪条路: 1) 从节点首次连接? - 全量重同步 2) replid 不匹配? - 全量重同步 3) 缺失偏移在 backlog 内? - 部分重同步 (CONTINUE) 4) 缺失偏移超出 backlog? - 全量重同步需要评估故障切换会丢多少数据: 1) 被提升从节点的最后 ack 偏移 2) 主节点最后成功写入的偏移两者之差即为丢失上限backlog 大小不直接参与该计算。需要降低丢失窗口: 1) 减小复制延迟网络、从节点算力、避免大 Key 2) 配置 min-replicas-to-write 与 min-replicas-max-lag 3) 对强一致场景改用带共识的组件或让写等待至少一个从节点确认回到开头的秒杀事故如果当时配置了min-replicas-to-write 1且从节点延迟小于 1 秒那么主节点在从节点跟不上时会拒绝写入虽然会损失部分可用性但能把这 3 秒的库存丢失压到很小。Redis 主从复制的所有配置本质上都是在「可用性」和「一致性」之间调参而 PSYNC、backlog、偏移量这三个概念就是调节这个旋钮时你必须看懂的刻度盘。14. 参考资料Redis 官方文档Replicationhttps://redis.io/docs/management/replication/Redis 官方文档Sentinelhttps://redis.io/docs/management/sentinel/Redis 官方文档Redis Clusterhttps://redis.io/docs/management/scaling/Redis 官方文档INFO commandhttps://redis.io/commands/info/Redisson 官方文档https://redisson.org/documentation.htmlSpring Data Redis 参考文档https://docs.spring.io/spring-data/redis/reference/《Redis 设计与实现》黄健宏著机械工业出版社

Redis 主从复制全解析：从 PSYNC 协议到复制积压缓冲区的故障切换边界

相关推荐

开源扫地机器人全栈拆解：从SLAM到电机PID的机器人工程实战

MRAM + PIC18F85J10：工业设备掉电数据不丢失的存储方案解析

Java 加解密组件再设计

更多资讯

【八个月网安课程】第八周·周六：靶场命令/代码执行漏洞综合通关——从单点利用到攻击链

从IDE到ADE：智能体开发环境的核心技术与落地实践

Cursor插件开发核心机制与避坑指南

90DaysOfDevOps 第 30 天：Microsoft Azure 安全模型——身份、目录、RBAC 与 Azure Policy 实战

DeepSeek Harness桌面端安装部署与插件Skill机制全解析

用Qt实现鼠标自动点击：从GetCursorPos到mouse_event的完整配置

今日更新

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？