PSYNC2退化为全量同步的根本原因是repl-backlog-size过小或repl-timeout过短：前者导致断连期间主节点缓冲区循环覆盖，offset丢失；后者因网络抖动或BGSAVE卡顿引发误断连，重连时offset已失效。
Redis 7.0 默认启用 PSYNC2，但全量同步仍频繁发生——根本原因几乎总是 repl-backlog-size 不够大，或 repl-timeout 设置过短导致误判断连。
为什么 PSYNC2 还会退化成全量同步
PSYNC2 协议本身支持跨主节点的部分重同步，但能否真正触发部分同步，不取决于协议，而取决于主节点是否还能在 repl-backlog 中找到从节点请求的 offset 起始位置。一旦该 offset 被新写入数据覆盖，哪怕只差 1 字节，主节点就只能返回 FULLRESYNC。
- 常见错误现象：
INFO replication显示master_repl_offset比从节点上报的 offset 大很多，但日志里反复出现"Full resync requested by slave" - 真实原因不是协议没生效，而是
repl-backlog已被循环覆盖 —— 它是个定长环形缓冲区，不是无限队列 - 另一个隐蔽诱因：
repl-timeout设为默认 60 秒，而网络抖动叠加 BGSAVE 卡顿（尤其大实例 fork 耗时 >5s），导致心跳 ACK 延迟超限，主节点主动断连，重连后 offset 已失效
如何计算并设置合理的 repl-backlog-size
不能拍脑袋设 100MB 或 1GB，必须按实际写入压力和最大容忍断连时间推算：
- 先用
redis-cli info stats | grep instantaneous_ops_per_sec观察峰值 QPS，再结合平均 key 大小估算带宽（例如：50k ops/s × 2KB/req ≈ 100MB/s） - 用
redis-cli info replication | grep "master_repl_offset"每 10 秒采样一次，计算 offset 增长速率（单位：bytes/s） - 预估最大可能断连时间：跨机房链路建议按 300–600 秒（5–10 分钟）计，云上跨可用区按 120–300 秒计
- 公式：
repl-backlog-size ≥ 带宽（MB/s）× 最大断连时间（s）× 1.5（冗余系数）；例如 80MB/s × 300s × 1.5 = 36000MB → 建议设为4096mb - 注意：
repl-backlog-size是字节单位，配置时写4096mb比4294967296更安全，避免整数溢出
如何验证当前同步确实是 PSYNC2 部分重同步
光看 INFO replication 输出毫无意义，它不记录本次同步类型。必须交叉验证三个信号：
- 主节点日志（
redis-server.log）中搜索"Partial resynchronization request accepted"—— 这是唯一可信依据；若看到"Starting BGSAVE for SYNC"或"Full resync"，说明已退化 - 从节点执行
ROLE命令，返回数组第二项为"stable_sync"表示已进入稳定增量同步；若为"connect"或"connecting"，说明还在握手阶段，尚未开始数据传输 - 监控
instantaneous_ops_per_sec：部分同步启动瞬间会有 1–3 秒脉冲式飙升（主节点读 backlog + 发送命令流），全量同步则伴随长达数十秒的bgsave和磁盘 IO 尖峰
别忽略 repl-timeout 和系统层 TCP keepalive 的协同
repl-timeout 控制的是应用层心跳超时，但它依赖底层 TCP 连接不被中间设备（如 NAT、防火墙、LB）静默中断。两者不匹配会导致“假断连”：
- 默认
repl-timeout 60，意味着主节点每 30 秒收一次REPLCONF ACK，超 60 秒无响应即断连 - 但 Linux 默认
tcp_keepalive_time是 7200 秒（2 小时），远长于repl-timeout，中间设备可能在 600 秒后就清空连接表，导致 TCP RST，而 Redis 还没感知到 - 解决方案：调低系统级 keepalive，例如
echo 600 > /proc/sys/net/ipv4/tcp_keepalive_time，并确保repl-timeout>tcp_keepalive_time / 3（留出重传窗口） - 同时开启
tcp-keepalive 60（redis.conf 中），让 Redis 主动发 TCP keepalive 包，比依赖内核更可控
PSYNC2 的能力上限，由 repl-backlog-size 和 repl-timeout 共同决定；协议再先进，缓冲区一空、心跳一断，就退回原始 SYNC。生产环境里最常被忽略的，是把 repl-backlog-size 当成“越大越好”，却没配对应的内存预留（maxmemory 不影响 backlog，但 OS OOM Killer 可能杀掉 redis 进程）——调大之前，先确认宿主机剩余内存是否足够扛住这个缓冲区+主进程自身开销。
