复制即主服务器向从服务器的数据同步，REDIS的实现具有参考意义，尤其对于有主从同步需求，数据量不是特别大，可以用内存存储，其中巧妙之处在于 offset和缓冲区的配对使用，让主服务器能够很快的知道应该同步哪些数据，即使面对多个从服务器可以做到处理流程一样。
书中分析了老版本和新版本在复制过程中，断链发生时的不同处理，来描述复制的过程。
老版本复制主要2个方式：
1. 从服务器主动发送SYNC给主服务器，主服务器启动BGSAVE，生成一个DB文件，传给从服务器，从服务器加载DB文件，然后主服务器将这个过程中接收到的写命令也同步给从服务器，从服务器也执行这些写命令，同步结束。
SYNC的过程是非常耗费资源的，CPU,内存，带宽都会在不同时期被占用
2. 主从服务器DB相同，主服务器执行了写命令，主动同步给从服务器，称之为命令传播
老版本的bug：上面第2点，假如主服务器和从服务器断链，主服务器无法感知，依然进行命令传播，将主服务器上的写命令传送给从服务器，而从服务器接收不到，最后建连后数据就不一致了。
当然，建链后可以直接来一次SYNC，不过这样过于耗费资源。
新版本：
有了PSYNC命令，断链后，等到建链，从服务器发送PSYNC给主服务器，主服务器会将断链时间段的所有写命令同步给从服务器。
下图中+CONTINUE回复标识开始部分同步。
二 部分复制的实现细节：
1. 首先，主从服务器都会记下同步的字节数，所谓复制偏移量，主服务器上记录 同步多少字节给从服务器，从服务器记录接收到主服务器同步多少个字节，下图15-7中同步了10086字节的数据
如果断链后恢复，从服务器发送PSYNC给主服务器，带上本地的复制偏移量，主服务器比较后发现和本地的不一样，就意味着主从数据不一致，需要进行数据同步。
2. 主服务发现本地的offset和从服务器的offset不一致，意味着要进行数据同步，怎么同步呢？
主服务器中会有一个固定长度(1MB)的FIFO的复制积压缓冲区，每个复制到从服务器的字节，都会储存在这个缓冲区中，每个字节都对应到一个offset.
当从服务器发送PSYNC，带来自己的offset，主服务器会在复制积压缓冲区中查找，如果offset+1依然在缓冲区中，没有被挤压出队列（固定长度FIFO，存储最新的命令，如果队列满，最老的命令会被挤压出队列），就可以执行部分复制。否则就要进行全部复制，即SYNC
2.服务器运行ID，从服务器会存储主服务器的运行ID，此ID是全局唯一的。如果断链再建联，主服务器发现从服务器发来的主服务器运行ID(伴随PSYNC命令)和自己的不一样，那么就要进行完整的复制，如果ID一致，可以选择进行部分复制。
原文：http://www.cnblogs.com/jiangz222/p/6696744.html