2.数据库状态一致
主从复制，服务器双方数据库将保存相同的数据，这种现象称为“数据库状态一致”
3.执行方式
>>>slaveof 127.0.0.1 6379
4.旧版复制功能的实现（2.8以前的版本）
复制功能都分为两个基本步骤：同步和命令传播
同步：将从服务器的数据库状态更新至主服务器当前所处的数据库状态。
命令传播：主服务器的数据库状态被修改，导致主从服务器的数据库状态不一致，让主从服务器数据库重新回到一致状态。
1.同步
当客户端向从服务器发送slaveof命令，要求从服务器复制主服务器时，从服务器首先需要执行同步操作，也就是将从服务器的数据库状态更新至主服务器当前所处的数据库状态。而从服务器对主服务器的同步操作需要通过向主服务器发送SYNC命令来完成。
从服务器发送SYNC命令的执行步骤：
a.从服务器向主服务器发送SYNC命令。
b.收到SYNC命令的主服务器执行BGSAVE命令，在后台生成一个RDB文件，并使用一个缓冲区记录从现在开始执行的所有写命令。
c.当主服务器的BGSAVE命令执行完毕时，主服务器会将BGSAVE命令生成的RDB文件发送给从服务器，从服务器接收接收并载入这个RBD文件，将自己的数据库状态更新至主服务器执行BGSAVE命令时的数据库状态。
d.主服务器将记录在缓冲区里面的所有写命令发送给从服务器，从服务器执行这些写命令，将自己的数据库状态更新至主服务器当前所处的状态。
2.命令传播
在执行完同步操作以后，如果客户端又再次向主服务器发送写命令，如果此时该命令没有传播到从服务器，那么主从服务器的数据库状态必然会不一样，因此，在执行完同步操作以后，还必须得执行命令传播，用来传播主服务器接收到的新的命令请求。
为了让主从服务器再次回到一致状态，主服务器需要对从服务器执行命令传播操作：主服务器会将自己执行的那条写命令，发送给从服务器，当从服务器执行了相同的写命令之后，主从服务器将再次回到一致状态。
3.旧版复制存在的缺陷
从服务器对主服务器的复制分为以下两种：
初次复制：从服务器没有复制任何主服务器，或者从服务器当前要复制的主服务器和上一次复制的主服务器不同。
断线后重复制： 处理命令传播阶段的主从服务器因为网络原因而中断了复制，但从服务器通过自动重连接重新连接上主服务器，并继续复制主服务器 。
当主从服务器断开以后，从服务器通过自动重连连上主服务器，然后从服务器向主服务器发送SYNC命令，进行同步操作，但是主服务器此时会将数据库状态写入到RDB文件中，如上述红色方框（重复复制了许多键值对），这部分就是旧版复制存在的缺陷。
4.旧版复制问题的解决方案
为了解决旧版复制功能在处理断线重复复制情况时的低效问题，redis从2.8以后，使用PSYNC命令代替SYNC命令来执行复制时的同步操作。
psync命令具有完整重同步和部分重同步两种模式。
完整重同步：用以解决初次复制的问题。执行操作与sync一模一样。
部分重同步：用于处理断线后重复制情况：当从服务器在断线后重新连上主服务器时，如果条件允许，主服务器可以将主从服务器连接断开期间执行的写命令发送给从服务器，从服务器只要接收并执行这些写命令，就可以将数据更新至主服务器当前所处的状态。
PSYNC命令的部分重同步解决了旧版复制功能在处理断线后重复复制时出现的低效情况。
主从服务器执行部分重同步的过程：
5.部分重同步的实现
要实现部分重同步，必须解决以下三个问题：
1.当前主从服务器各复制了多少数据？？
2.如果主从服务器断线以后，主服务器新接收到的命令请求，该如何处理？
3.如果在一个集群系统中，如何找到上一次复制的那个主服务器呢？
部分重同步功能由以下三个部分构成：
a.主服务器的复制偏移量和从服务器的复制偏移量
b.主服务器的复制积压缓冲区
c.服务器的运行ID
typedef struct redisClient {
// 复制状态
int replstate; /* replication state if this is a slave */
// 用于保存主服务器传来的 RDB 文件的文件描述符
int repldbfd; /* replication DB file descriptor */
// 读取主服务器传来的 RDB 文件的偏移量
off_t repldboff; /* replication DB file offset */
// 主服务器传来的 RDB 文件的大小
off_t repldbsize; /* replication DB file size */
sds replpreamble; /* replication DB preamble. */
// 主服务器的复制偏移量
long long reploff; /* replication offset if this is our master */
// 从服务器最后一次发送 REPLCONF ACK 时的偏移量
long long repl_ack_off; /* replication ack offset, if this is a slave */
// 从服务器最后一次发送 REPLCONF ACK 的时间
long long repl_ack_time;/* replication ack time, if this is a slave */
// 主服务器的 master run ID
// 保存在客户端，用于执行部分重同步
char replrunid[REDIS_RUN_ID_SIZE+1]; /* master run id if this is a master */
// 从服务器的监听端口号
int slave_listening_port; /* As configured with: SLAVECONF listening-port */
// 最后被写入的全局复制偏移量
long long woff; /* Last write global replication offset. */
} redisClient;
下面我们对上面三个部分一一解释一下：
复制偏移量
执行复制的双方---主从服务器都会维护一个复制偏移量。
主服务器每次向从服务器传播N个字节的数据时，就将自己的复制偏移量的值加上N。
从服务器每次接收到主服务器传播来的N个字节的数据时，就将自己的复制偏移量加上N。
通过对比主从服务器的复制偏移量，程序很容易知道主从服务器是否处于一致状态。
主从状态一致：
主从状态不一致：
作者：Java邵先生
链接：https://www.jianshu.com/p/882d18ebc6db