第15章 复制

Posted 2021-11-02 ashoftime

　　复制是Redis集群的基础，Redis主从节点在复制的时候即使从节点因为网络分区暂时无法继续复制，主节点也会继续工作，因此根据CAP理论Redis的集群符合A可用性，不符合C一致性。当网络分区恢复后从节点会继续复制，从而实现最终一致性。

　　以2.8版本为分水岭，Redis复制有两种实现。

15.1 旧版复制功能的实现

　　分为同步(sync)和命令传播(command propagate)两个过程，两个过程以master收到slave的slaveof指令的时间点为分界线。

• 对收到slaveof指令时间点之前master里的内容，生成一个RDB快照。
• 对收到slaveof指令到生成RDB快照之间master执行的指令用存在buffer里，把buffer发给slaver。
• 以上命令执行完毕后sync执行完毕，剩下master所有的修改都以命令传播的方式传播到slaver节点。

15.1.1 同步

1. slaver执行slaverof指令时，会向master发送sync指令
2. master收到sync后执行BGSAVE，在后台生成一个RDB文件
3. 在执行BGSAVE同时用buffer记录在此期间执行的所有修改master的命令
4. master发送RDB给slaver，slaver利用RDB同步数据
5. master发送buffer给slaver，slaver利用buffer继续同步数据

• 整个同步过程slaver共收到两个master传来的数据：RDB文件和buffer

15.1.2 命令传播

　　master继续执行会造成主从不一致，主服务器需要把命令传播给slaver来维护一致性。

15.2 旧版复制功能的缺陷

　　旧版的复制分为两种情况，这两种情况的划分不是根据复制的不同阶段，而是根据主从节点的通信状况即是否发生网络分区来的。

• 初次复制，slaver执行slaverof
• 断线后重复制，处于命令传播阶段的主从服务器因为网络原因中断复制，此时主服务器继续响应请求，一段时间后从服务器重新连上主服务器，并继续复制。

　　当t10091时刻从服务器再次连上主服务器时，会发送一条sync指令，该指令会把t10091时刻之前主服务器所有数据生成RDB文件并传送过来，虽然这个过程并不是必须的，因为从服务器上有t10087前的所有数据。这种一旦断线重连就再次发送sync的策略带来的效率十分低下，因为需要复制的数据仅仅是t10087到t10091之间的数据。

　　而且sync是一个非常耗费资源的操作，资源耗费体现在三个方面

1. 主服务器执行BGSAVA，会消耗CPU和带来大量的IO操作。
2. 传输RDB文件耗费网络带宽。
3. 从服务器恢复RDB文件的时候是阻塞的。

　　

15.3 新版复制功能的实现

　　使用psync代替原有sync，p指的是partial部分。服务器断线后，只复制断线这一阶段没有同步的数据，避免了一旦断线就要全部同步的弊端。

 

15.4 部分重同步的实现