目录
前言
一、旧版复制功能的实现
1. 同步
2. 命令传播
二、旧版复制功能的缺陷
三、新版复制功能的实现
四、部分重同步的实现
4.1 复制偏移量
4.2 复制积压缓冲区
4.3 服务器运行ID
五、PSYNC命令的实现
六、复制的实现
6.1 步骤1:设置主服务器的地址和端口
6.2 步骤2:建立套接字连接
6.3 步骤3: 发送PING命令
6.4 步骤4: 身份验证
6.5 步骤5:发送端口信息
6.6 步骤6: 同步
七、心跳检测
7.1 检测主从服务器的网络连接状态
7.2 辅助实现min-slaves配置选项
7.3 检测命令丢失
八、重点回顾
参考
在Redis中，用户可以通过执行SLAVEOF或者设置slaveof选项，让一个服务器去复制（replicat）另一个服务器。我们称被复制的服务器为主服务器（master），对主服务器进行复制的服务器成为从服务器（slave）。
127.0.0.1:6379> KEYS * 1) "hi" 2) "school" 3) "age" 4) "name"
127.0.0.1:12345> KEYS *
(empty list or set)
127.0.0.1:12345> SLAVEOF 127.0.0.1 6379 OK
127.0.0.1:12345> KEYS * 1) "hi" 2) "name" 3) "age" 4) "school"
127.0.0.1:6379> DEL hi (integer) 1
127.0.0.1:12345> KEYS * 1) "name" 2) "age" 3) "school"
一、旧版复制功能的实现
Redis的复制功能分为同步（sync）和命令传播（command propagate）两个操作：
同步操作用于将从服务器的数据库状态更新至主服务器当前所处的数据库状态；命令传播操作则用于在主服务器的数据库状态被修改，导致主从服务器的数据库状态出现不一致时，让主从服务器的数据库重新回到一致状态。当客户端向从服务器发送SLAVEOF命令，要求从服务器复制主服务器时，从服务器首先要执行同步操作。
从服务器向主服务器发送SYNC；主服务器执行BGSAVE命令，在后台生成RDB文件，并用一个缓冲区记录从现在开始执行的所有写命令；主服务器会将BGSAVE命令生成的RDB文件发送给从服务器，从服务器接收并载入这个RDB文件，将自己的数据库状态更新至主服务器执行BGSAVE命令时的数据库状态；主服务器将记录在缓冲区里面的所有写命令发送给从服务器，从服务器执行这些写命令，将自己的数据库状态更新至主服务器当前的状态。每当主服务器执行客户端发送的写命令时，主服务器的数据库就有可能被修改，导致主从服务器状态不一致。
为了让主从服务器再次回到一致状态，主服务器需要对从服务器执行命令传播操作：主服务器会将自己执行的写命令，发送给从服务器执行，当从服务器执行了相同的写命令之后，主从服务器将再次回到一致状态。
复制的两种情况：
初次复制：从服务器以前没有复制过任何主服务器，或者从服务器当前要复制的主服务器和上一次复制的主服务器不同；断线后重复制：处于命令传播阶段的主从服务器因为网络原因中断了复制，从服务器重连上主服务器后，继续复制主服务器。对于初次复制，旧版复制功能能够很好的完成任务，但对于断线后重复制，旧版复制状态效率却非常低。
SYNC是一个非常耗费资源定的操作。
每次SYNC，主从服务器需要执行：
主服务器需要执行BGSAVE生成RDB文件，这个生成操作会耗费主服务器大量的CPU、内存和磁盘I/O；主服务器将生成的RDB文件发给从服务器，会耗费主动服务器大量的网络资源（带宽、流量），并对主服务器响应命令的时间产生影响；接收到RDB文件的从服务器需要载入主服务器发来的RDB文件，并且在载入期间，从服务器会阻塞。Redis从2.8版本开始，使用PSYNC命令代替SYNC。
PSYNC命令具有完整重同步和部分重同步两种模式：
完整重同步用于初步复制：和SYNC命令的执行步骤基本一样，都是通过让主服务器创建并发送RDB文件，以及向从服务器发送保存在缓冲区里的写命令来进行同步；部分重同步用于处理断线后重复制情况：当从服务器在断线后重新连接主服务器时，如果条件允许，主服务器将连接断开期间执行的写命令发送给从服务器。PSYNC部分重同步模式解决了旧版复制功能在处理断线后重复制时出现的低效情况。
构成：
主服务器端的复制偏移量（replication offset）和从服务器的复制偏移量；主服务器的复制积压缓冲区（replication backlog）；服务器的运行ID（run ID）。执行复制的双方——主服务器和从服务器分别维护一个复制偏移量：
主服务器每次向从服务器传播N个字节时，将自己的复制偏移量加N；从服务器每次收到主服务器传播定的N个字节后，也将自己的复制偏移量加N。通过对比主从服务器端的复制偏移量，可以知道主从服务器是否处于一致状态。
假设从服务器断线后立即重连主服务器，从服务器将向主服务器发送PSYNC命令，报告从服务器当前的复制偏移量。那么这时，主服务器应该对从服务器执行完整重同步还是部分重同步呢？如果执行部分重同步的话，主服务器又如何补偿从服务器在断线期间丢失的数据呢？
复制积压缓冲区是由主服务器维护的一个固定长度先进先出的队列，默认1MB。
当主服务器进行命令传播时，不仅会将写命令发送给所有从服务器，还会将写命令入队到复制积压缓冲区。
因此，主服务器端的复制积压缓冲区里面会保存一部分最近传播的写命令，并且复制积压缓冲区会为队列中的每个字节记录相应的复制偏移量。
当从服务器重新连上主服务器时，从服务器会通过PSYNC命令将自己的复制偏移量offset发送给主服务器，主服务器会根据这个复制偏移量来决定对从服务器执行何种同步操作：
如果offset偏移量之后的数据仍然存在于复制积压缓冲区，那么主服务器将对从服务器执行部分重同步操作；相反，主服务器将对从服务器执行完整重同步。根据需要调整复制积压缓冲区的大小
复制积压缓冲区的最小大小可以根据公式second*write_size_per_second来估算：
second为从服务器断线后重新连上主服务器所需的平均时间（以秒计算）；而write_size_per_second是主服务器平均每秒产生的写命令数据量（协议格式的写命令的长度总和）。为了安全起见，将复制积压缓冲区的大小设为2*second*write_size_per_second，这样可以保证绝大部分断线情况都能用部分重同步来处理。
至于复制积压缓冲区大小的修改方法，可以参考配置文件repl-backlog-size选项。
run ID：
每个Redis服务器，都有自己运行ID；运行ID在服务器启动时自动生成，由40个随机的十六进制字符组成。当从服务器对主服务器进行初次复制时，主服务器将自己的运行ID传送给从服务器，而从服务器则会将这个运行ID保存起来。
当从服务器断线并重新连上一个主服务器时，从服务器将向当前连接的主服务器发送之前保存的运行ID：
如果从服务器保存的运行ID和当前连接的主服务器的运行ID相同，说明从服务器断线之前复制的就是当前连接的这个主服务器，主服务器可以继续尝试执行部分重同步操作；相反的，说明从服务器断线之前复制的主服务器并不是当前连接的这个主服务器，主服务器将对从服务器执行完整重同步。PSYNC命令的调用方法有两种：
如果从服务器以前没有复制过任何主服务器，或者之前执行过SLAVEOF no one命令，那么从服务器在开始一次新的复制时将向主服务器发送PSYNC ？-1命令，主动请求主服务器进行完整重同步（这时不可能执行部分重同步）；相反的，如果从服务器已经复制过某个主服务器，那么从服务器在开始一次新的复制时将向主服务器发送PSYNC <runid> <offset>：其中runid是上一次复制的主服务器的运行ID，而offset是从服务器当前的复制偏移量，接收到这个命令的主服务器会通过这两个参数来判断应该对从服务器执行哪种同步操作。根据情况，接收到PSYNC命令的主服务器会向从服务器返回以下三种回复的一种：
如果主服务器返回+FULLRESYNC <runid> <offset>回复，那么表示主服务器将与从服务器执行完整重同步操作，runid是主服务器的运行ID，offset是主服务器当前的的复制偏移量;如果主服务器返回+CONTINUE，表示主服务器将与从服务器执行部分重同步；如果主服务器返回-ERR回复，表示主服务器的版本低于Redis2.8，它识别不了PSYNC，从服务器将向主服务器发送SYNC，并与主服务器完整同步。当客户端向从服务器发送以下命令时：
127.0.0.1:12345> SLAVEOF 127.0.0.1 6379 OK
从服务器首先将客户端给定的主服务器IP地址127.0.0.1 和端口6379保存到服务器状态的masterhost
和masterport属性里：
SLAVEOF命令是一个异步命令，在完成masterhost和masterport属性的设置工作之后，从服务器将向发送SLAVEOF命令的客户端返回OK，表示命令已被接收，而复制工作将在OK返回之后执行。
从服务器先根据命令设置的IP和端口，创建连向主服务器的套接字连接。
如果从服务器创建的套接字能成功连接到主服务器，那么从服务器将为这个套接字关联一个专门用于处理复制工作的文件时间处理器，这个处理器将负责执行后续的复制工作，比如接收RDB文件，以及接收主服务器传播的写命令等。
而主服务器在接受从服务器的套接字连接后，将为该套接字创建相应的客户端状态，并将从服务器看作一个连接到主服务器的客户端来对待。这时从服务器将同时具有服务器和客户端两个身份：从服务器可以向主服务器发送命令请求，而主服务器则会向从服务器返回命令回复。
从服务器成为主服务器的客户端之后，第一向主服务器发送一个PING命令。
PING命令有两个作用：
虽然主从服务器成功建立起套接字连接，但双方并未使用该套接字进行过任何通信，通过发送PING命令可以检查套接字的读写状态是否正常；因为复制工作接下来的几个步骤都必须在主服务器可以正常处理命令请求的状态下进行，通过发送PING命令可以检查主服务器能否正常处理命令请求。从服务器在发送PING之后会遇到以下三种情况的一种：
如果主服务器向从服务器返回一个命令回复，但从服务器timeout，表示主从服务器之间的网络连接状态不佳。这时，从服务器断开并重新创建连向主服务器的套接字；如果主服务器向从服务器返回一个错误，表示主服务器无法处理从服务器的命令请求。这时，从服务器断开并重新创建连向主服务器的套接字；如果从服务器读取到PONG回复，那么表示主从服务器之间的网络连接状态正常，并且主服务器可以正常处理从服务器发送的命令请求。这样，从服务器可以继续执行复制工作的下个步骤。从服务器在收到主服务器返回的PONG回复后，下一步要做的就是决定是否进行身份验证：
如果从服务器设置了masterauth，那么进行身份验证；如果从服务器没有设置masterauth，那么不进行身份验证。在需要进行身份验证的情况下，从服务器将向主服务器发送一条AUTH，命令参数为从服务器masterauth选项的值。
从服务器在身份验证阶段可能遇到的情况如下：
如果主服务器没有设置requirepass，并且从服务器也没有设置masterauth，那么主服务器将继续执行从服务器发送的命令，复制工作可以继续进行；如果从服务器通过AUTH命令发送的密码和主服务器requirepass选项所设置的密码相同，那么主服务器将继续执行从服务器发送的命令，复制工作可以继续进行；反之，主服务器返回一个invalid password错误；如果主服务器设置了requirepass，但从服务器却没有设置masterauth，那么主服务器将返回NOAUTH错误。如果主服务器没有设置requirepass，但从服务器却设置了masterauth，那么主服务器将返回no password is set错误。所有错误都会令从服务器中止目前的复制工作，并从创建套接字开始重新执行复制，直到身份验证通过，或者从服务器放弃执行复制为止。
在身份验证步骤之后，从服务器将执行命令REPLCONF listening-port <port-number>， 向主服务器发送从服务器的监听端口号。
主服务器在接收到这个命令后，将端口号记录在从服务器所对应的客户端状态slave_listening_port中。
slave_listening_port目前唯一的作用就是主服务器执行INFO replication命令时打印出从服务器的端口号。
从服务器向主服务器发送PSYNC命令，执行同步操作，并将自己的数据库更新至主服务器当前的状态。
在同步操作执行之前，只有从服务器是主服务器的客户端，但是在执行同步操作之后，主服务器也会成为从服务器的客户端：
如果PSYNC命令执行的是完整重同步，那么主服务器需要成为从服务器的客户端，才能将保存在缓冲区里面的写命令发送给从服务器执行；如果PSYNC命令执行的是部分重同步，那么主服务器需要成为从服务器的客户端，才能向从服务器发送保存在复制积压缓冲区里面的写命令。因此，在同步操作执行之后，主从服务器双方都是对方的客户端，他们可以互相向对方发送命令请求，或者互相向对方返回命令回复。
在命令传播阶段，从服务器默认会以每秒一次的频率，向主服务器发送命令：
REPLCONF ACK <replication_offset>
其中replication_offset是从服务器当前的复制偏移量。
作用：
检测主从服务器的网络连接状态；辅助实现min-slaves；检测命令丢失。主从服务器可以通过发送和接收REPLCONF ACK来检查两者之间的网络连接是否正常。
通过向主服务器发送INFO replication，在列出的从服务器列表的lag一栏中，可以看到相应从服务器最后一次向主服务器发送REPLCONF ACK命令距离现在过了多少秒。
Redis的min-replicas-to-write和min-replicas-max-lag可以防止主服务器在不安全的情况下执行写命令。
min-replicas-to-write 3 min-replicas-max-lag 10
在从服务器的数量少于3个，或者三个从服务器的延迟值都大于等于10秒时，主服务器将拒绝执行写命令。
如果因为网络故障，主服务器传播给从服务器的写命令丢失，那么当从服务器向主服务器发送REPLCONF ACK时，主服务器将发现从服务器的复制偏移量少于自己的复制偏移量，然后主服务器就会根据从服务器提交的复制偏移量，在复制积压缓冲区里面找到从服务器缺少的数据，并将这些数据重新发送给从服务器。
注意，主服务器向从服务器补发确实数据这一操作的原理和部分重同步操作的原理非常相似，区别在于补发缺失数据在主从服务器没有断线时执行，而部分重同步则在主从服务器断线并重连之后执行。
1. 复制官方文档 https://redis.io/topics/replication （中文http://www.redis.cn/topics/replication.html）
