前言
Redis持久化机制在一定程度上缓解了宕机/重启带来的业务数据丢失问题，但当单实例所在的物理节点发生不可恢复故障时，如何保证业务数据不丢以及如何在故障期间迅速的恢复对应业务数据的可用性成为单点结构的挑战。
在分布式系统中为了解决单点问题，Redis通常会把数据复制多个副本部署到其他机器，满足故障恢复和负载均衡等需求。
1复制流程
Redis根据版本的不同，提供了两个命令分别是：sync和psync，其中当Redis版本小于2.8时，只能使用sync命令实现全量复制，而当Redis版本大于等于2.8时，可以使用psync命令实现全量复制和部分复制，因此完全可以使用psync命令替代sync命令，因为psync命令提供的部分复制，能够有效的减少数据创传输开销。接下来我们分别来看下这两个命令的具体实现原理。
1.1sync
Redis包含master和slave两种节点，master节点对外提供读写服务，slave节点拥有master节点的全量数据，对外不提供写服务。主被复制由slave主动触发，流程如下
另外需要注意的是，如果有多个slave节点发送sync命令给master，只要第二个slave的sync命令发生在master完成bgsave之前，第二个slave将收到和第一个slave相同的快照和后续backlog。否则，第二个slave的sync将触发master的第二次bgsave。
1.2psync
从节点使用psync命令完成部分复制和全量复制功能，命令格式
psync {runid} {offset},其中runid是从节点复制主节点的运行id；offset是当前从节点已复制的数据偏移量。流程如下
master节点根据psync参数和自身数据情况决定相应结果：
- 如果回复+FULLRESYNC，那么从节点将触发全量复制流程。
- 如果回复+CONTINUE，那么从节点将触发部分复制流程。
- 如果回复-ERR，说明Redis版本低于2.8，无法识别psync命令，从节点将发送旧版本的sync命令触发全量复制流程。
2.总结
本文主要讲了Redis提供的两种复制流程：全量复制和部分复制，全量复制需要同步master节点的全部数据，大量消耗资源。而部分复制能够有效减少因网络异常等原因造成的不必要全量复制情况。
3.参考资料
《Redis开发与运维》《深入分布式缓存》