主从复制是 Redis 高可用的基石。它看起来像“主库写，从库跟”，但真正的问题在网络抖动和节点重连之后：从库还能不能接着追？
Redis 用 replid、offset 和 replication backlog 判断是否可以部分重同步。如果从库断开时间太久，缺失的数据已经不在 backlog 里，就只能重新全量同步。
先把机制边界说清楚
这一篇讨论普通复制和 PSYNC，不讨论 Sentinel 或 Cluster 的故障转移。复制解决冗余和读扩展，不自动提供强一致。
整体路径
上面这张图先把主线铺开：backlog 留得住缺口，就部分同步；留不住，就全量同步。读 Redis 这类系统，最重要的是别只停在命令接口，要继续追问它在内存里是什么形状、在主线程上走多远、失败时会留下什么状态。
底层机制
- 初次同步通常要生成或传输 RDB，让从库建立数据基线。
- 主库持续把写命令传播给从库，并维护复制 offset。
- replication backlog 是环形缓冲区，保存最近一段写命令。
- 从库重连时，如果 offset 仍在 backlog 内，就可以部分重同步。
这些机制放在一起看，就能把「这个命令能不能用」改成「这个命令在当前数据规模下还便不便宜」。Redis 的很多坑，不是命令本身错了，而是数据规模和访问方式已经越过了它的舒适区。
取舍与边界
复制提升可用性，但异步复制天然有延迟窗口。WAIT 可以提高写入被副本确认的概率，但不能把 Redis 变成强一致系统。
典型问题：用机制化例子排查
- 监控
master_repl_offset、slave_repl_offset和复制延迟。 - 根据写入量和网络抖动设置足够的
repl-backlog-size。 - 避免多个从库同时断线重连造成全量同步风暴。
- 读从库要接受延迟读，强一致读回主库或上游数据库。
收束：一句判断
复制的关键不是有没有从库，而是从库断开后还能不能接着追。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 Redis」，欢迎关注公众号 「十三Tech」。后续会继续按数据结构、底层机制、持久化、高可用和实战排查这条线更新。
