PSYNC2比PSYNC1更适合高延迟网络，因其将replication offset与run_id分离管理，支持跨主节点故障切换后的部分重同步；而PSYNC1依赖run_id+offset绑定，主节点变更即触发全量同步。
PSYNC2 协议为什么比 PSYNC1 更适合高延迟网络
Redis 7.0 默认启用 PSYNC2，它把复制偏移量（replication offset）和主节点运行 ID（run_id）拆开管理，支持从多个不同主节点（比如故障切换后的新的 master）无缝续传。PSYNC1 只靠 run_id + 偏移量匹配，一旦主节点重启或 failover 后 run_id 变更，从节点就只能全量同步（SYNC），哪怕只断了 1 秒。
实际中，跨机房、云上跨可用区部署时网络抖动频繁，PSYNC2 能显著降低全量同步概率。但前提是主节点的复制缓冲区（repl-backlog）够大——否则即使协议支持部分重同步，数据早被覆盖，照样退化为全量。
-
repl-backlog-size建议设为带宽 × 预估最大断连时间；例如主从间平均延迟 200ms，峰值写入 50MB/s，则至少预留50 * 0.2 = 10MB，再加冗余建议设为16MB -
repl-backlog-ttl默认 1 小时，若从节点长期离线（如维护窗口），该缓冲区会被释放，此时无法部分重同步——需确保关键从节点不长期失联 - 从节点发起 PSYNC2 请求时，会带上自己的
master_replid和offset；主节点用这两个值查repl-backlog是否可覆盖，而不是比对当前run_id
如何确认当前是否真正走 PSYNC2 部分重同步
光看 INFO replication 输出不够——它只显示 master_replid 和 master_repl_offset，不反映本次同步类型。得结合日志和客户端行为判断。
主节点日志里出现 "Partial resynchronization request accepted" 才是 PSYNC2 成功的部分重同步；若看到 "Full resync requested by slave" 或 "Starting BGSAVE for SYNC"，说明退化为全量。
- 开启
loglevel verbose或debug级别日志（生产慎用），搜索PSYNC关键字 - 在从节点执行
ROLE命令，返回数组第二项是当前复制状态：若为["slave", "127.0.0.1", 6379, "stable_sync"]，表示已进入稳定部分同步阶段；若为"connect"或"connecting"，说明还在握手 - 监控指标
instantaneous_ops_per_sec在同步开始瞬间飙升，且持续数秒而非数分钟，大概率是部分同步；全量同步通常伴随长时间的bgsave和大量磁盘 IO
repl-diskless-sync 和 repl-diskless-sync-delay 的取舍
Redis 7.0 仍默认关闭无磁盘同步（repl-diskless-sync no），但高吞吐场景下开启它能避免 fork + bgsave 导致的内存拷贝和磁盘瓶颈。不过它依赖 TCP socket 直接发送 RDB 流，对网络稳定性更敏感。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
关键不是“开或不开”，而是配合 repl-diskless-sync-delay 控制竞争窗口：该参数让主节点等待若干秒，看是否有其他从节点也准备同步，从而复用同一个 RDB 流（即“sync group”）。但延迟过长会拖慢首个从节点的同步启动。
- 单个从节点或网络极稳（如同机房），可设
repl-diskless-sync yes+repl-diskless-sync-delay 0 - 多从节点 + 跨网络，建议
repl-diskless-sync yes+repl-diskless-sync-delay 5（默认值），平衡复用率与延迟 - 若观察到主节点 CPU 飙升、
latest_fork_usec持续 > 100ms，且rdb_changes_since_last_save较低，说明频繁 fork 小 RDB 是瓶颈，应优先考虑 diskless
从节点配置里容易被忽略的两个性能开关
多数人只调主节点参数，但 Redis 7.0 中从节点的行为对整体复制效率影响变大——尤其在级联复制或读写分离架构下。
repl-disable-tcp-nodelay no 是关键：默认关闭意味着从节点接收 RDB 或命令流时，TCP Nagle 算法生效，可能攒包导致几十毫秒延迟；开启后强制立即发包，提升命令传播实时性，代价是略微增加小包数量。
另一个是 replica-serve-stale-data：设为 no 时，从节点在断连期间拒绝所有读请求（返回错误），这看似“严谨”，实则放大业务抖动——不如保持 yes 并配合适当监控告警，让应用层决定是否降级。
- 级联场景（A → B → C）下，B 节点务必开启
repl-disable-tcp-nodelay yes，否则 A→B 的微小延迟会被 B→C 放大 -
repl-timeout建议设为网络 P99 RTT 的 3–5 倍（如 P99 是 300ms，则设1500），太短易误判断连，太长导致故障发现滞后 - 7.0 新增
replica-priority不影响同步本身，但影响 Sentinel 故障转移选主逻辑；若某从节点硬件较弱，应调低该值（如设为10），避免被错误提拔为主
PSYNC2 的价值不在协议本身多炫酷，而在于它让“断连后快速续传”这件事变得可预期；但缓冲区大小、diskless 启用时机、从节点网络参数这些细节，才是压住全量同步尾巴的关键。线上出问题时，先盯日志里的 Partial resynchronization 是否出现，再查 repl-backlog 是否被绕过——别一上来就怀疑协议没生效。
