Redis 断线后如何通过 PSYNC 部分重同步？

副本与主节点短暂断开后，不一定重新复制整个数据集。Redis 通过复制历史标识、复制偏移量与 replication backlog判断是否可以补发遗漏的复制流，能够续接时执行部分重同步。

三个信息分别解决什么？#

复制 ID 用于标识一段复制历史；offset 表示在该历史的复制流中推进了多少字节；主节点的 backlog 是保存近期复制流的缓冲区。只有 ID 能衔接，且副本缺失的内容仍保留在缓冲区，才有条件续传。

例如主节点偏移量已到 1,000,000，副本断线时处理到 900,000。重连后副本请求后续内容。如果 backlog 仍覆盖这个起点，主节点补发缺少的字节流；若缓冲只保留了 950,000 之后的内容，中间出现无法补齐的空洞，就需要全量复制。

backlog 的大小是共享复制历史容量，不是给每个副本单独保存无限的未确认日志。副本自身的输出缓冲和复制连接还有其他内存与限制，不能混为一谈。Redis 的 PSYNC2 还会维护第二复制 ID 等信息，使某些主从切换后的历史能够衔接，细节应以版本实现为准。

可按峰值复制流量乘以希望容忍的断线时间，再留一定余量。这里的流量是实际复制字节量，不是 Key 数或数据库总大小。过小会频繁触发全量复制，过大则占用内存；还需关注 repl-backlog-ttl 等生命周期配置。

必须结合复制 ID。来自不同复制历史的相同 offset 没有相同含义，就像两个不同文件中的同一字节位置。

不是。它服务于复制续传，通常是内存中的近期历史；AOF 服务于本节点持久化，不能直接用 AOF 替代 PSYNC 的 backlog。

不能一概而论。是否能够保持所需复制历史与元数据，取决于重启、持久化及版本条件。设计可用性时应接受部分场景回退到全量同步。

不是。网络、CPU、慢命令和快照加载都可能让应用复制流的速度落后。要检查复制状态和进度，而不只看连接是否建立。