目录
1.背景：
2.新版复制
2.1PSYNC
3.复制的实现
3.1设置主服务器的地址和端口
3.2建立套接字连接
3.3发送ping命令
3.4身份验证
3.5发送端口信息
3.6同步
3.7命令传播
1.背景：
举例1：假设现在有两个Redis服务器，地址分别为127.0.0.1:6379和 127.0.0.1:12345，如果我们向服务器127.0.0.1:12345发送以下命令
127.0.0.1:12345> SLAVEOF 127.0.0.1 6379
OK举例二：如果我们在主服务器上执行以下命令：
127.0.0.1:6379> SET msg "hello world"
OK那么我们应该既可以在主从服务器上获取msg键的值：
127.0.0.1:6379> GET msg
"hello world“127.0.0.1:12345> GET msg
"hello world2.新版复制
背景：
在Redis中，从服务器对主服务器的复制可以分为以下两种情况：
·初次复制：从服务器以前没有复制过任何主服务器，或者从服务 器当前要复制的主服务器和上一次复制的主服务器不同。
·断线后重复制：处于命令传播阶段的主从服务器因为网络原因而 中断了复制，但从服务器通过自动重连接重新连上了主服务器，并继续 复制主服务器。
对于初次复制来说，旧版复制功能能够很好地完成任务，但对于断线后重复制来说，旧版复制功能虽然也能让主从服务器重新回到一致状态，但效率却非常低
2.1PSYNC
PSYNC命令具有完整重同步（full resynchronization）和部分重同步 （partial resynchronization）两种模式
1.其中完整重同步用于处理初次复制情况：完整重同步的执行步骤 和SYNC命令的执行步骤基本一样，它们都是通过让主服务器创建并发 送RDB文件，以及向从服务器发送保存在缓冲区里面的写命令来进行同 步
2.·而部分重同步则用于处理断线后重复制情况：当从服务器在断线后重新连接主服务器时，如果条件允许，主服务器可以将主从服务器连 接断开期间执行的写命令发送给从服务器，从服务器只要接收并执行这 些写命令，就可以将数据库更新至主服务器当前所处的状态
举例说明 psync
总结： 部分重同步只需要将从服务器缺少的写命令 发送给从服务器执行就可以了
3.复制的实现
1.基本的命令
SLAVEOF <master_ip> <master_port>3.1设置主服务器的地址和端口
当客户端向从服务器发送以下命令时：
127.0.0.1:12345> SLAVEOF 127.0.0.1 6379
OK从服务器首先要做的就是将客户端给定的主服务器IP地址127.0.0.1 以及端口6379保存到服务器状态的masterhost属性和masterport属性里面
struct redisServer {
// ...
//
主服务器的地址
char *masterhost;
//
主服务器的端口
int masterport;
// ...
};
SLAVEOF命令是一个异步命令，在完成masterhost属性和masterport 属性的设置工作之后，从服务器将向发送SLAVEOF命令的客户端返回 OK，表示复制指令已经被接收，而实际的复制工作将在OK返回之后才 真正开始执行
3.2建立套接字连接
在SLAVEOF命令执行之后，从服务器将根据命令所设置的IP地址 和端口，创建连向主服务器的套接字连接
note1：如果从服务器创建的套接字能成功连接（connect）到主服务器，那 么从服务器将为这个套接字关联一个专门用于处理复制工作的文件事件 处理器，这个处理器将负责执行后续的复制工作，比如接收RDB文件， 以及接收主服务器传播来的写命令
note2：主服务器在接受（accept）从服务器的套接字连接之后，将为该 套接字创建相应的客户端状态，并将从服务器看作是一个连接到主服务 器的客户端来对待，这时从服务器将同时具有服务器（server）和客户 端（client）两个身份：从服务器可以向主服务器发送命令请求，而主 服务器则会向从服务器返回命令回复
3.3发送ping命令
从服务器成为主服务器的客户端之后，做的第一件事就是向主服务 器发送一个PING命令
note3（ping的作用）：
1.虽然主从服务器成功建立起了套接字连接，但双方并未使用该套接字进行过任何通信，通过发送PING命令可以检查套接字的读写状态是否正常
2.·因为复制工作接下来的几个步骤都必须在主服务器可以正常处理 命令请求的状态下才能进行，通过发送PING命令可以检查主服务器能 否正常处理命令请求
对于服务器而言在发送PING命令之后将遇到以下三种情况的其中一种
1.·如果主服务器向从服务器返回了一个命令回复，但从服务器却不能在规定的时限（timeout）内读取出命令回复的内容，那么表示主从服 务器之间的网络连接状态不佳，不能继续执行复制工作的后续步骤。当出现这种情况时，从服务器断开并重新创建连向主服务器的套接字
2.·如果主服务器向从服务器返回一个错误，那么表示主服务器暂时 没办法处理从服务器的命令请求，不能继续执行复制工作的后续步骤。 当出现这种情况时，从服务器断开并重新创建连向主服务器的套接字
3,如果从服务器读取到"PONG"回复，那么表示主从服务器之间的网 络连接状态正常，并且主服务器可以正常处理从服务器（客户端）发送 的命令请求，在这种情况下，从服务器可以继续执行复制工作的下个步骤
3.4身份验证
1.设置密码
config set masterauth "lenovo20!&"从服务器在收到主服务器返回的"PONG"回复之后，下一步要做的 就是决定是否进行身份验证： ·
如果从服务器设置了masterauth选项，那么进行身份验证。
·如果从服务器没有设置masterauth选项，那么不进行身份验证。
在需要进行身份验证的情况下，从服务器将向主服务器发送一条 AUTH命令，命令的参数为从服务器masterauth选项的值。
举个例子，如果从服务器masterauth选项的值为10086，那么从服务 器将向主服务器发送命令AUTH 10086
从服务器在身份验证阶段可能遇到的情况有以下几种：
1.如果主服务器没有设置requirepass选项，并且从服务器也没有设置 masterauth选项，那么主服务器将继续执行从服务器发送的命令，复制工作可以继续进行。
2.·如果从服务器通过AUTH命令发送的密码和主服务器requirepass选 项所设置的密码相同，那么主服务器将继续执行从服务器发送的命令， 复制工作可以继续进行。与此相反，如果主从服务器设置的密码不相同，那么主服务器将返回一个invalid password错误。
3.·如果主服务器设置了requirepass选项，但从服务器却没有设置 masterauth选项，那么主服务器将返回一个NOAUTH错误。另一方面， 如果主服务器没有设置requirepass选项，但从服务器却设置了masterauth 选项，那么主服务器将返回一个no password is set错误
图解:
3.5发送端口信息
在身份验证步骤之后，从服务器将执行命令REPLCONF listening port<port-number> ，向主服务器发送从服务器的监听
例如：
从服务器的监听端口为12345，那么从服务 器将向主服务器发送命令REPLCONF listening-port 12345
主服务器在接收到这个命令之后，会将端口号记录在从服务器所对 应的客户端状态的slave_listening_port属性中
typedef struct redisClient {
// ...
//
从服务器的监听端口号
int slave_listening_port;
// ...
} redisClient;
3.6同步
在这一步，从服务器将向主服务器发送PSYNC命令，执行同步操 作，并将自己的数据库更新至主服务器数据库当前所处的状态。
值得一提的是，在同步操作执行之前，只有从服务器是主服务器的 客户端，但是在执行同步操作之后，主服务器也会成为从服务器的客户 端
如果PSYNC命令执行的是完整重同步操作，那么主服务器需要成为从服务器的客户端，才能将保存在缓冲区里面的写命令发送给从服务器执行。
·如果PSYNC命令执行的是部分重同步操作，那么主服务器需要成 为从服务器的客户端，才能向从服务器发送保存在复制积压缓冲区里面 的写命令
正因为主服务器成为了从服务器的客户端，所以主服务器才可以通 过发送写命令来改变从服务器的数据库状态，不仅同步操作需要用到这 一点，这也是主服务器对从服务器执行命令传播操作的基础。
3.7命令传播
当完成了同步之后，主从服务器就会进入命令传播阶段，这时主服 务器只要一直将自己执行的写命令发送给从服务器，而从服务器只要一 直接收并执行主服务器发来的写命令，就可以保证主从服务器一直保持 一致了
