Redis主从复制

2.8之前的版本

2.8之前的版本的redis在主从复制的时候主要包括如下两个步骤：

• 同步
• 命令传播
  

同步给我的感觉就是从服务器在初始化进行的流程，其流程图如上图所示：

• 从服务器启动的时候，向主服务器发送sync命令。
• 主服务器收到sync命令后，执行BGSAVE命令，生成RDB文件；在生成RDB文件的期间，对于源源不断写数据的命令会划分一个缓冲区进行存放。
• 主服务器发送RDB文件，从服务器进行接收并进行更新。
• 主服务器再将缓冲区的写命令发送给从服务器，从服务器执行这些写命令，将数据库状态更新到和主服务器的数据库状态一致。

命令传播则是在同步之后，因为主服务器用于写，每当主服务器的数据发生变更（删除了、更新了），为了保持主从的一致性，需要将这些命令发送给从服务器。

2.8及之后的版本

以上的主从复制看似完美，却还有那么点遗憾~在从机断线重新连接后，会同步主机所有数据（包括之前已经同步过的数据），为了追求性能的极致，有了如下方式：

• 从机同步主机的数据时，用PSYNC命令代替了SYNC命令。
• PSYNC包括两种模式，完整同步和部分同步。
• 完整同步和老版本的同步流程大差不差，都是在初始化时，向主机发送sync命令，主机发送RDB文件后，再发送缓冲区的写命令。
• 部分同步则是用于从机断连后，重新上线时，条件允许的情况下，主机只需要发送从机断开期间的写命令到从机。

部分同步

部分同步的执行，是需要条件允许的，在此之前需要了解它包括了3个方面的内容：

• 服务器运行id
• 主服务器的复制积压缓冲区
• 主服务器的复制偏移量和从服务器的复制偏移量

复制偏移量，个人理解就是某个时刻，复制到某个数据的位置。

复制积压缓冲区，主机在进行命令传播的时候，不仅会将写命令发送给从机，还会将写命令写入到主机的一个缓冲区里面，这个缓冲区也叫复制积压缓冲区。

如图所示：

• 主从开始命令传播，offset起始的偏移量都为10085，在主机发送<s1,s2>（一个字节）的数据后，将offset偏移量更新为10086（10085 + 1），从机写入数据后，也更新offset为10086。
• 然后，主机发送<s3,s4>，还没到从机时，从机断开了。但主机的offset已经更新为10087（10086+1），此时，主机的offset偏移量就不一致了。
• 如果此时，有客户端继续向主机写入数据，譬如<s5,s6>，主机还是会进行命令传播，并更新主机的offset=10088。
• 在offset=10088的时候，从机恢复了，向主机发送PSYNC指令，并报告自己的偏移量为offset=10086。
• 主机会在复制积压缓冲区里面检查offset=10086及之后的数据是否存在，如果依然存在，则会回复++CONTINUE，表示允许部分同步的方式进行，反之，则是完整同步（也是上文所说的条件允许）。
• 主机将复制积压缓冲区里面offset=10086之后的数据发送给从机，从机进行写入即可。

关于服务器运行id，它是redis启动的时候随机生成的40位字符，从机在初次复制的时候，主机会将自己的运行id发送过去，然后从机会进行保存。

当从机挂掉，重连后，会再发送之前保存过的运行id，如果这个运行id和当前的主服务器的运行id相同表示，从机之前就同步过这台主机的数据了。主机可以依此判断是否有必要执行部分同步。（或完全同步）