本文中的复制，指的是主从结构的复制。
命令：slaveof 127.0.0.1 6379
表示当前redis会成为127.0.0.1：6379的slave（从服务器）
slaveof的实现分为两个阶段
- 数据同步：将slave的状态更新为master（主服务器）的数据状态
- 命令传播：master状态被修改时，让slave和master保持一致。
一、数据同步（sync）：
1）从服务器向主服务器发送sync命令
2）主服务器执行bgSave，生成rdb文件，并用一个缓冲区记录从现在开始执行的写命令。
3）master将rdb文件发给slave，slave载入此文件
4）master将缓冲区中的命令发给slave，slave执行以后和master状态相同
二、命令传播（command propagate）
同步完成后，主服务器把执行的写命令发给slave
这种同步机制有一个缺点。假设在命令传播阶段，主从服务器断开连接，那么等双方重新连接以后，会重新执行复制操作。这种做法非常低效，原因有以下几点：
1）主服务器执行bgsave，会消耗大量的CPU，内存和硬盘；
2）发送rdb文件，消耗大量带宽
3）从服务器加载rdb文件会发生阻塞，加重主服务器的负担
上述问题的解决方法是命令psync（部分重同步）。master开辟一个复制积压缓冲区，这个缓冲区是一个FIFO的队列，主服务器除了将命令发给从服务器，还写入该缓冲区，主从服务器都有复制偏移量replication offset（字节的偏移量）。
每个redis都有自己的run ID（40位十六进制数），当主从服务器进行初次复制时，主服务器会把自己的run ID发给从服务器，从服务器会保存起来。
等主从服务器短线并且重连以后，从服务器会把run ID和offset发给主服务器，如果这个run ID和主服务器的runID相同，那么会尝试部分重同步，如果缺失的数据不在缓冲区中或者run ID不同，那么会进行完全重同步。
在命令传播阶段，从服务器会向主服务器发送心跳（每秒一次），除了检测主从服务器的网络连接状态，还告知自己的复制偏移量，如果从服务器的offset较小，那么补发从服务器所缺失的部分数据。检测命令丢失和部分重同步的区别是，前者是在主从服务器没有断线时执行，而后者是在主从服务器断线且重连以后执行。
2017-12-26阅：
redis复制的设计菁华在于可靠性：假如断线重连以后，那么丢失的数据怎么办？
这就涉及到一个全量同步和增量同步的问题。解决方案是使用缓冲区。
2019-07-25
同步，重同步，心跳，命令丢失检测
