上周做 Redis 故障演练，主节点 A 宕机后从节点 B 升级为新主。话说回来，A 恢复上线后我原以为它会只同步缺失的数据——毕竟 B 的缓冲区足够大。A 的偏移量也在可接受范围内。但日志显示却是全量同步，这让我很困惑。其实，

如果你也遇到过类似现象。或者单纯好奇 Redis 主从复制在故障转移后到底如何决定同步方式——这篇文章就是为你写的。我们不背八股文，而是从这次排查经历出发，把背后的设计逻辑彻底理清楚。

先理解主要问题：主从复制到底在解决什么？其实，

Redis 的主从复制。本质上是在多节点之间保持数据一致。话说回来，一个主节点负责写操作。多个从节点复制主节点的数据，以提供读服务或作为容灾备份。

但复制并非一次性的。它面临两个主要挑战：

1. 从网络闪断来看，从节点与主节点短暂断开后重连，是不是就要全量同步？
2. 说到故障转移，主节点挂掉后从节点升为新主；当旧主恢复后该怎么处理，

这两个问题引出了 Redis 复制机制中最主要的两个概念——复制 ID和复制偏移量。

复制 ID 与偏移量：数据历史的身份证和页码

复制偏移量的观点是。精确记录同步进度

偏移量是一个不断递增的字节数，代表已发送的数据位置。

• master_repl_offset主节点维护一个全局偏移量，记录自己总共产生了多少字节的写命令。
• slave_repl_offset每个从节点维护自己的偏移量，记录自己已接收并应用了多少数据。不过，

通过比较自身与各个从节点的偏移量。主节点可以精确判断落后的程度，从而决定是否需要增量同步。老实说，

复制 ID：数据历史的身份证

复制 ID 是一个随机字符串。用来标识一份数据集的历史版本。

• 每个 Redis 实例启动时都会生成一个唯一的复制 ID。
• 从节点完成全量同步后会继承并使用该 ID。
• 在同一复制拓扑中，所有节点最终拥有相同的复制 ID。

ID 的作用是当一个从节点重连时它会把自己记录下来的 runid发送给主端；若两边匹配，则可以进行增量同步，否则只能走全量方法。

P SYNC：从全量到增量的进化

至于注意，

⚠️ **常见误区** - 把 PSYNC 当作“永远只增量”的万能方案；- 忽略缓冲区大小导致实际无法完成增量传输。

• P SYNC1：仅支持全量同步，一旦断线就重新拉取全部数据。
• P SYNC2：支持部分同步，引入 runid 与 offset 参数以决定是否能做增量传输。说到但仍有局限，

•   从 node 重启后内存里的 runid 和 offset 全部丢失，只能走全量方法；
•   故障转移场景下新主生成新的 runid；旧主带着老 runid 请求 sync 时新主根本无法识别，就被迫执行全量同步。

P SYNC2：加入 Copy ID 的双层保护机制

P SYNC1 在 .8 前被废弃。在 .8 开始采用 P SYNC，但它仍然使用 runid。为了更好地处理故障转移和提高容错性，于 .0 引入了 P SYNC2，并用 copy id 替代了 runid。同时保留原 master 的 copy id 信息，让旧 master 在恢复时不会与新 master 冲突。

P SYNC1 与 P SYNC2 的关键差异：

• P SYNC1： runid 用于识别同一实例起始点；按理说，但无论何时只要 runid 匹配就允许增量。即使旧 master 已经跑到了比新 master 更前的位置，也会尝试继续增量，这可能导致冲突。
• P SYNC2： 新 master 会保留旧 master 的 copy id 并记录对应 offset。当旧 master 回来时它携带的是旧 copy id + 偏移。如果这些信息超出了 new master's 缓冲区范围，就强制走全局重建。
• A 强制走全体。同步过程更安全、耗时更长，却保证了无分叉风险！

P SYNC1 工作流程示例：

#

PSYNC1+PSYNC0 vs PSYNC0+PSYNC0 场景对比：

P SYNC 模式概述图示：

注意点的观点是。

• 如果您想让某些客户端在高延迟环境下尽可能减少 ping/pong 带来的消耗，请考虑关闭 REPL_PING_INTERVAL 或设置较低值，但请注意可能导致网络异常检测变慢。
• 如果您想让某些客户端能够在高并发环境下尽可能减少 CPU 消耗。请考虑关闭 REPL_PING_INTERVAL 或设置较低值，但请注意可能导致网络异常检测变慢。

  ---

  **** Redis 主从切换中的“旧 Master 恢复触发全局重建”其实是一条有意识、经过深思熟虑、基于一致性优先于效率原则而制定的新规则**。
  • 对于落后的 Slave。程序会尽力帮其补齐差距，实现快速追赶；老实说，
  • 对于跑得更前面的 Old Master。程序视其为“可疑”，强制执行 full sync，以彻底清除潜在冲突。

  这不是 “不近人情”，而是分布式程序中避免出现不可调和的数据分叉所必须遵循的一条底线。

  如果你 遇到类似情况。不必慌张——它不是 bug，而是 Redis 为保障一致性所做出的设计取舍。在排查过程中，请关注：

  • replication IDs；
  • 是否有 new-master‑old-master 间交叉；
  • 缓冲区大小是否足够满足延迟补齐需求。

  通过正确理解 PSYNC 系列协议。你就能快速定位原因，并采取合适措施防止未来 出现类似混乱情形。