redis的主从复制

[TOC]

同步操作(PSYNC命令)

PSYNC命令具有完整重同步(full resy nchronization)和部分重同步(partial resynchronization)两种模式:

  • 完整重同步:用于处理初次复制情况:完整重同步的执行步骤和SYNC命令的执行步 骤基本一样,它们都是通过让主服务器创建并发送RDB文件,以及向从服务器发送保存在缓 冲区里面的写命令来进行同步
  • 部分重同步:则用于处理断线后重复制情况:当从服务器在断线后重新连接主服务器 时,如果条件允许,主服务器可以将主从服务器连接断开期间执行的写命令发送给从服务 器,从服务器只要接收并执行这些写命令,就可以将数据库更新至主服务器当前所处的状态

完整重同步

  • 概念:当客户端向从服务器发送SLAVEOF命令,要求从服务器复制主服务器时,从服务器首先需要执行同步操作,也即是,将从服务器的数据库状态更新至主服务器当前所处的数据库状态

  • SYNC命令:

    从服务器对主服务器的同步操作需要通过向主服务器发送SYNC命令来完成,以下是SYNC命令的执行步骤:

    • ①从服务器向主服务器发送SYNC命令
    • ②收到SYNC命令的主服务器执行BGSAVE命令,在后台生成一个RDB文件,并使用一 个缓冲区记录从现在开始执行的所有写命令
    • ③当主服务器的BGSAVE命令执行完毕时,主服务器会将BGSAVE命令生成的RDB文件发送给从服务器,从服务器接收并载入这个RDB文件,将自己的数据库状态更新至主服务器 执行BGSAVE命令时的数据库状态
    • ④主服务器将记录在缓冲区里面的所有写命令发送给从服务器,从服务器执行这些写 命令,将自己的数据库状态更新至主服务器数据库当前所处的状态
  • 下图展示了SYNC命令执行期间,主从服务器的通信过程:

img

演示案例

  • 下表展示了一个主从服务器进行同步的例子

img

部分重同步的实现细节

  • 同步功能由以下三个部分构成:
    • 主服务器的复制偏移量(replication offset)和从服务器的复制偏移量
    • 主服务器的复制积压缓冲区(replication backlog)
    • 服务器的运行ID(run ID)

复制偏移量

  • 执行复制的双方——主服务器和从服务器会

    分别维护一个复制偏移量:

    • 主服务器每次向从服务器传播N个字节的数据时,就将自己的复制偏移量的值加上N
    • 从服务器每次收到主服务器传播来的N个字节的数据时,就将自己的复制偏移量的值加上N
  • 通过对比主从服务器的复制偏移量,

    程序可以很容易地知道主从服务器是否处于一致状态:

    • 如果主从服务器处于一致状态,那么主从服务器两者的偏移量总是相同的
    • 相反,如果主从服务器两者的偏移量并不相同,那么说明主从服务器并未处于一致状态
  • 在下图所示的例子中,主从服务器的复制偏移量的值都为10086

img

  • 如果这时主服务器向三个从服务器传播长度为33字节的数据,那么主服务器的复制偏移量将更新为10086+33=10119,而三个从服务器在接收到主服务器传播的数据之后,也会将复制偏移量更新为10119,如下图所示:

img

网络断开重连后的复制偏移量

  • 考虑以下这个例子:假设如上面的图片所示,主从服务器当前的复制偏移量都为10086,但是就在主服务器要向从服务器传播长度为33字节的数据之前,从服务器A断线了,那么主服务 器传播的数据将只有从服务器B和从服务器C能收到,在这之后,主服务器、从服务器B和从 服务器C三个服务器的复制偏移量都将更新为10119,而断线的从服务器A的复制偏移量仍然停留在10086,这说明从服务器A与主服务器并不一致,如下图所示:

img

  • 假设从服务器A在断线之后就立即重新连接主服务器,并且成功,那么接下来,从服务器将向主服务器发送PSYNC命令,报告从服务器A当前的复制偏移量为10086,那么这时, 主服务器应该对从服务器执行完整重同步还是部分重同步呢?如果执行部分重同步的话,主 服务器又如何补偿从服务器A在断线期间丢失的那部分数据呢?以上问题的答案都和复制积压缓冲区有关

复制积压缓冲区

  • 复制积压缓冲区是由主服务器维护的一个固定长度(fixed-size)先进先出(FIFO)队列,默认大小为1MB

img

  • 当主服务器进行命令传播时,它不仅会将写命令发送给所有从服务器,还会将写命令入队到复制积压缓冲区里面,如下图所示:

img

  • 因此,主服务器的复制积压缓冲区里面会保存着一部分最近传播的写命令,并且复制积压缓冲区会为队列中的每个字节记录相应的复制偏移量,就像下表展示的那样

img

  • 当从服务器重新连上主服务器时,从服务器会通过PSYNC命令

    将自己的复制偏移量offset发送给主服务器

    ,主服务器会根据这个复制偏移量来决定对从服务器执行何种同步操 作:

    • 如果offset偏移量之后的数据(也即是偏移量offset+1开始的数据)仍然存在于复制积压缓冲区里面,那么主服务器将对从服务器执行部分重同步操作
    • 相反,如果offset偏移量之后的数据已经不存在于复制积压缓冲区,那么主服务器将对从服务器执行完整重同步操作

img

\演示案例:**

  • 回到之前上面图片所展示的断线后重连接例子:

img

  • 当从服务器A断线之后,它立即重新连接主服务器,并向主服务器发送PSYNC命令,报告自己的复制偏移量为10086
  • 主服务器收到从服务器发来的PSYNC命令以及偏移量10086之后,主服务器将检查偏移量10086之后的数据是否存在于复制积压缓冲区里面,结果发现这些数据仍然存在,于是主服务器向从服务器发送+CONTINUE回复,表示数据同步将以部分重同步模式来进行
  • 接着主服务器会将复制积压缓冲区10086偏移量之后的所有数据(偏移量为10087至 10119)都发送给从服务器
  • 从服务器只要接收这33字节的缺失数据,就可以回到与主服务器一致的状态,如下图所示

img

服务器运行ID

  • 除了复制偏移量和复制积压缓冲区之外,

    实现部分重同步还需要用到服务器运行ID(run ID):

    • 每个Redis服务器,不论主服务器还是从服务,都会有自己的运行ID
    • 运行ID在服务器启动时自动生成,由40个随机的十六进制字符组成,例如 53b9b28df8042fdc9ab5e3fcbbbabff1d5dce2b3
  • 当从服务器对主服务器进行初次复制时,主服务器会将自己的运行ID传送给从服务器, 而从服务器则会将这个运行ID保存起来

  • 当从服务器断线并重新连上一个主服务器时,

    从服务器将向当前连接的主服务器发送之前保存的运行ID:

    • 如果从服务器保存的运行ID和当前连接的主服务器的运行ID相同,那么说明从服务器 断线之前复制的就是当前连接的这个主服务器,主服务器可以继续尝试执行部分重同步操 作
    • 相反地,如果从服务器保存的运行ID和当前连接的主服务器的运行ID并不相同,那么 说明从服务器断线之前复制的主服务器并不是当前连接的这个主服务器,主服务器将对从服 务器执行完整重同步操作
  • 举个例子,假设从服务器原本正在复制一个运行ID为 53b9b28df8042fdc9ab5e3fcbbbabff1d5dce2b3的主服务器,那么在网络断开,从服务器重新连 接上主服务器之后,从服务器将向主服务器发送这个运行ID,主服务器根据自己的运行ID是 否53b9b28df8042fdc9ab5e3fcbbbabff1d5dce2b3来判断是执行部分重同步还是执行完整重同步