PSYNC 2.0是Redis 4.0引入的核心复制优化，解决主从切换或从节点重启时强制全量同步问题；通过双replication ID和精确偏移比对实现部分重同步，大幅缩短故障恢复时间并降低带宽压力。
PSYNC 2.0 是 Redis 4.0 引入的，不是 6.0 新增的
很多人误以为 PSYNC 2.0 是 Redis 6.0 的特性，其实它早在 Redis 4.0 就已落地。Redis 6.0 并未重构复制协议，只是沿用并稳定了 PSYNC 2.0 的行为。关键区别不在 6.0，而在 4.0 相比 2.8/3.x 的跃迁。
PSYNC 2.0 解决的核心问题是：从节点在主节点故障切换后（比如 Sentinel 提升 B 为新主），或自身重启后，能否避免强制全量同步。旧版 PSYNC 1.0 无法识别“新主是否继承了旧主的复制上下文”，只能退回到 PSYNC ? -1 触发全量 RDB 同步；而 PSYNC 2.0 引入双 replication ID（master_replid 和 master_replid2）和更精确的偏移量比对逻辑，使部分同步成为默认可行路径。
- Redis 2.8–3.2：仅支持 PSYNC 1.0，链式复制中 A→B→C，A 宕机后 C 必须全量同步 B
- Redis 4.0+：启用 PSYNC 2.0 后，C 可基于 B 的
master_replid2和second_repl_offset判断是否能做部分同步 - Redis 6.0/7.0：无新复制协议，但默认开启
replica-announce-ip等网络发现优化，不影响 PSYNC 行为本身
replicaof 替代 slaveof 是 5.0 开始的语法变更
Redis 5.0 起，slaveof 命令和配置项被标记为 deprecated，正式替换为 replicaof。这不是机制变化，而是术语去敏感化——Redis 社区统一使用 “replica” 替代 “slave”。6.0 完全移除了 slaveof 的运行时支持。
这意味着：如果你在 Redis 6.0 配置文件里还写 slaveof 127.0.0.1 6379，启动会报错 Unknown directive or bad number of arguments for 'slaveof'；必须改成 replicaof 127.0.0.1 6379。命令行也同理：replicaof no one 才能断开复制。
- Redis 4.0：仍完全兼容
slaveof，但文档已提示未来弃用 - Redis 5.0：
slaveof可用但警告日志，replicaof为推荐写法 - Redis 6.0+：
slaveof彻底不可用，解析失败直接拒绝启动
复制积压缓冲区（repl-backlog）的行为在 4.0 后更健壮
虽然 repl-backlog-size 参数自 2.8 就存在，但 Redis 4.0 起对其使用逻辑做了关键修正：从节点重启后，只要其记录的旧主 run_id 匹配当前主节点的 master_replid 或 master_replid2，且偏移量落在积压缓冲区内，就能触发部分同步——不再依赖“连接未断”这一脆弱前提。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
这直接影响运维操作：你在 Redis 4.0+ 上滚动重启从节点，只要 repl-backlog-size 设置合理（例如 128MB），基本不会触发全量同步；而在 3.2 及之前，哪怕只断开 1 秒，都大概率导致 PSYNC ? -1 和 RDB 传输。
- 建议值：生产环境至少设为
repl-backlog-size 10485760（10MB），大流量场景建议 50–100MB - 验证方式：执行
INFO replication，检查repl_backlog_histlen是否长期接近repl_backlog_size - 注意：该缓冲区是主节点全局共享的，不按从节点分配，所以 size 要覆盖所有从节点可能的断连窗口
Redis 6.0 没有改变复制机制，但强化了安全性与可观测性
Redis 6.0 引入 ACL（访问控制列表）后，主从复制的认证环节多了层校验：从节点连接时，除了传统 requirepass 密码，还可指定用户名（通过 replica-auth-user 和 replica-auth-pass 配置）。若主节点启用了 ACL，且未给复制用户赋予 REPLICA 权限，复制会直接失败，错误日志出现 NOAUTH Authentication required 或 NOPERM this user has no permissions to run the command。
同时，INFO replication 输出新增了 replica_announced、master_failover_state 等字段，便于监控故障转移状态。但底层数据同步流程、RDB/AOF 交互、命令传播方式，与 Redis 4.0 完全一致。
- 容易踩的坑：升级到 6.0 后主节点启用 ACL，却忘了给 replica 用户加
+repl权限，导致从节点反复重连失败 - 另一个坑：把
repl-diskless-sync yes和repl-diskless-sync-delay 5一起配，但主节点内存不足，fork 失败后卡在等待，表现为master_sync_in_progress:1长时间不更新
真正影响复制稳定性的，从来不是版本号里的数字，而是你有没有在 Redis 4.0+ 之后，正确设置 repl-backlog-size、禁用 slave-read-only no 这类危险配置、以及在启用 ACL 时同步授权 replica 用户。
