redis 4.0起启用psync2协议，通过分离master_replid与run_id解决主节点切换后强制全量同步问题，其生效关键在于repl-backlog-size需匹配业务写入带宽与断连时长。
Redis 4.0 是 PSYNC2 协议的起点，5.0 完全继承并默认启用它；两者在主从复制行为上没有本质差异，真正的分水岭是 PSYNC1（2.8–3.2）到 PSYNC2（4.0+）的协议升级——不是版本号决定能力，而是配置与运行时实际协商结果。
PSYNC2 如何解决主节点切换后的全量同步问题
旧版 PSYNC1 把主节点身份和数据进度强绑定在同一个 run_id 上：只要主节点重启或 Sentinel 切换出新 master，run_id 必然变更，所有从节点立刻退化为全量同步。
PSYNC2 拆开了这个耦合：
- 引入独立的
master_replid（主复制 ID），可由管理员手动设置或故障转移时继承 - 偏移量
offset单独校验，只要还在主节点的repl-backlog范围内，就能续传 - 链式复制（A→B→C）中，A 故障后 B 提升为新主，C 向 B 发起
PSYNC请求时，B 可用自己的master_replid和 C 提供的offset查缓冲区，无需全量
注意：PSYNC2 不自动“继承”旧主的 master_replid，Sentinel 或 Redis Cluster 需显式配置 replica-announce-ip 和正确传播 replid —— 否则从节点仍会因 ID 不匹配 fallback 到全量。
如何确认当前连接走的是 PSYNC2 部分同步
仅看 INFO replication 输出里的 master_replid 和 master_repl_offset 不够，它们只是状态快照，不反映本次同步类型。
必须结合三项证据交叉判断：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 主节点日志中出现
"Partial resynchronization request accepted"—— 这是唯一权威信号 - 从节点执行
ROLE命令，返回数组第二项为"stable_sync"（不是"connect"或"loading"） - 监控
instantaneous_ops_per_sec：部分同步只触发少量命令重放，瞬时 OPS 尖峰持续数秒；全量同步伴随BGSAVE，OPS 长时间归零，磁盘 IO 暴涨
生产环境禁用 loglevel debug，但至少应设为 verbose 并定期 greb PSYNC 关键字。
repl-backlog-size 设置不当会导致 PSYNC2 形同虚设
PSYNC2 能否生效，不取决于协议是否启用，而取决于主节点的复制缓冲区是否还存着从节点断连期间的写操作。
默认 repl-backlog-size 1mb 在多数场景下完全不够：
- 计算公式：建议值 = 峰值写入带宽（MB/s） × 最大预期断连时间（s） × 1.5 冗余
- 例如：主从跨可用区，平均延迟 300ms，峰值写入 80MB/s → 至少预留 80 × 0.3 = 24MB，建议设为
repl-backlog-size 32mb -
repl-backlog-ttl默认 3600 秒，若从节点离线超 1 小时，缓冲区被释放，即使网络恢复也无法部分同步
缓冲区是环形队列，写满即覆盖旧数据；一旦 offset 被覆盖，PSYNC2 请求直接降级为全量 —— 此时日志里会显示 "Full resync requested by slave"，而非报错，极易被忽略。
真正难调的不是协议开关，而是 repl-backlog-size 与业务写入节奏、网络稳定性的匹配。很多团队开了 PSYNC2 却没改 backlog，默认值撑不过一次 GC 暂停或网络抖动，结果还是每小时一次全量同步，白白消耗带宽和内存。
