Redis设计与实现总结--多机数据库的实现

1、复制

1.1 旧版复制功能的实现

        Redis复制功能分为 同步（sync）和命令传播（command propagate）两个操作；

• 同步（sync）:将slave数据库状态更新至master所处的数据状态;(全量操作)
• 命令传播（command propagate）：当master执行写命令，导致主从数据不一致时。将写命令传播到slave，从而达到一致状态；

1.1.1 同步

        当slave接受到salveof命令，从服务首先同步操作，即像master发送SYNC命令，执行流程如下：

• slave向master发送SYNC命令；
• master收到SYNC命令后执行BGSAVE命令，在后台生成RDB文件，并用一个缓冲区记录从现在开始的所有写命令；
• master的BGSAVE执行完毕后，master将生成的RDB文件发送给slave；
• slave收到RDB文件后，将数据重做到slave中；
• master将步骤2中缓冲区记录的命令发送给salve。从而达到master和slave数据一致；

1.1.2 命令传播

        同步完成后，当maser再次执行写命令，还会导致master和slave数据的不一致；为了让master和slave数据保持一致，master在执行写命令时，master会将写命令发送给slave，slave执行写命令后，使master和slave数据保持一致；

1.2 旧版复制功能的缺陷

       在断线后重复制时，为了让从服务器补足一小部分缺失的数据，缺要让主从服务器执行一次SYNC命令，这种做法无疑是非常低效的。SYNC命令事一个非常耗费资源的操作:

• BGSAVE生成RDB文件会耗费大量CPU、内存、磁盘I/O资源；
• RDB文件传输给slave会消耗大量的网络资源（带宽和流量）；
• slave接受RDB文件，载入期间 从服务器会堵塞，无法接受命令请求；

1.3 新版复制功能的实现

        为了解决旧版处理断线重复复制的低效问题。redis从2.8使用PSYNC来替代SYNC命令；

• 完整同步（full resynchronization）：完整重同步执行和SYNC执行步骤基本一致
• 部分重同步（partial resynchronization）:部分重复制用于处理断线后重复复制状况；当slave断线后重新连接主服务器时，如果条件允许，主服务器可以将从服务器断线期间的命令发送给slave，slave只要接收并执行这些写命令，就可以将数据库更新至主服务器当前所处的状态。

1.4 部分重同步的实现

1.4.1复制偏移量

        master和slave都维护了一个复制偏移量；

• master每次向slave发送N个字节数据时，master的偏移量就会加上N；
• 同理 slave每次接收到master的N个字节数据时，slave的偏移量也会加上N；
• 如果master和slave的偏移量是相同的，那么主从数据处于一致的状态；

1.4.2 复制积压缓冲区

        复制积压缓冲区是主服务器维护的一个固定长度的先进先出队列（默认1MB）；当master向slave传播命令时，会将命令写入到复制积压缓冲区；因此复制积压缓冲区记录了最近向slave传播的命令；并且为每个字节记录了相应的复制偏移量。当slave断线后重新连接master时，向master发送PSYNC命令 会将自己的复制偏移量发送给master，master会根据这个偏移量决定对slave执行部分同步还是完全同步；

• slave的偏移量在复制积压缓冲区，执行部分同步 ；
• slave的偏移量不在复制积压缓冲区，则执行完成同步；

1.4.3 服务器运行ID

        每个服务器都有自己的运行id，不论主从；slave对master初次复制时，会保存master的运行id；当slave重新连接到master时，slave向master发送之前保存的mater run id；如果slave保存的master run id和重新连接的master run id不一致（换了master），则执行完全同步。

1.5 PSYNC命令的实现

        PSYNC命令的调用方法有两种：

• 如果从服务器以前没有复制过任何主服务器，或者之前执行过SLAVEOF no one命令，那么从服务器在开始一次新的复制时将向主服务器发送PSYNC ? -1命令，主动请求主服务器进行完整重同步（因为这时不可能执行部分重同步）；
• 相反地，如果从服务器已经复制过某个主服务器，那么从服务器在开始一次新的复制时将向主服务器发送PSYNC <runid> <offset>命令：其中runid是上一次复制的主服务器的运行ID，而offset则是从服务器当前的复制偏移量，接收到这个命令的主服务器会通过这两个参数来判断应该对从服务器执行哪种同步操作。

        根据情况，接收到PSYNC命令的主服务器会向从服务器返回以下三种回复的其中一种：

• 如果主服务器返回+FULLRESYNC <runid> <offset>回复，那么表示主服务器将与从服务器执行完整重同步操作：其中runid是这个主服务器的运行ID，从服务器会将这个ID保存起来，在下一次发送PSYNC命令时使用；而offset则是主服务器当前的复制偏移量，从服务器会将这个值作为自己的初始化偏移量；
• 如果主服务器返回+CONTINUE回复，那么表示主服务器将与从服务器执行部分重同步操作，从服务器只要等着主服务器将自己缺少的那部分数据发送过来就可以了；
• 如果主服务器返回-ERR回复，那么表示主服务器的版本低于Redis 2.8，它识别不了PSYNC命令，从服务器将向主服务器发送SYNC命令，并与主服务器执行完整同步操作。

1.6 复制的实现 

1.6.1 步骤1：设置主服务器的地址和端口

        当客户端向从服务器发送以下命令时：

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返回之后才真正开始执行。

struct redisServer {
    // ...
    // 主服务器的地址
    char *masterhost;
    // 主服务器的端口
    int masterport;
    // ...
};

1.6.2 步骤2：建立套接字连接

        在SLAVEOF命令执行之后，从服务器将根据命令所设置的IP地址和端口，创建连向主服务器的套接字连接。

1.6.3 步骤3：发送PING命令

        从服务器成为主服务器的客户端之后，做的第一件事就是向主服务器发送一个PING命令。

主要是为了：

• 通过发送PING命令检查套接字的读写状态；
• 通过PING命令可以检查主服务器能否正常处理命令。

1.6.4 步骤4：身份验证

        从服务器在收到主服务器返回的"PONG"回复之后，下一步要做的就是决定是否进行身份验证，如果从服务器设置了masterauth选项，那么进行身份验证；否则不进行身份认证。

1.6.5 步骤5：发送端口信息

       从服务器将执行命令REPLCONF listening-port <port-number>，向主服务器发送从服务器的监听端口号。主服务器在接收到这个命令之后，会将端口号记录在从服务器所对应的客户端状态的slave_listening_port属性中，slave_listening_port属性目前唯一的作用就是在主服务器执行INFO replication命令时打印出从服务器的端口号。

typedef struct redisClient {
    // ...
    // 从服务器的监听端口号
    int slave_listening_port;
    // ...

｝redisClient;

1.6.6 步骤6：同步

        在这一步，从服务器将向主服务器发送PSYNC命令，执行同步操作，并将自己的数据库更新至主服务器数据库当前所处的状态。需要注意的是在执行同步操作前，只有从服务器是主服务器的客户端。但是执行同步操作之后，主服务器也会称为从服务器的客户端：

• 如果PSYNC命令执行的是完整同步操作，那么主服务器只有成为了从服务器的客户端才能将保存在缓冲区中的写命令发送给从服务器执行；
• 如果PSYNC命令执行的是部分同步操作，那么主服务器只有成为了从服务器的客户端才能将保存在复制积压缓冲区中的写命令发送给从服务器执行；

 1.6.7 步骤7：命令传播

        当完成了同步之后，主从服务器就会进入命令传播阶段，这时主服务器只要一直将自己执行的写命令发送给从服务器，而从服务器只要一