Redis设计与实现-多机数据库的实现-复制

鸿铭话动漫
138 阅读9分钟

复制

redis中，用户可以通过执行SALAVEOF命令或者设置salveof选项，让一个服务器去复制另一个服务器，被复制的服务器为主服务器，对主服务器进行复制的是从服务器。进行复制中的主从服务器双方的数据库将保存相同的数据，概念上将这种现象称作“数据库一致”。

旧版复制功能的实现

redis的复制功能分为同步和命令传播两个操作：

  • 同步操作将从服务器的数据库状态更新至主服务器当前所处的数据库状态

  • 命令传播操作则用于在主服务器的数据库状态被修改，导致主服务器的数据库状态出现不一致时，让主服务器的数据库重新回到一致状态 同步： 从服务器对主服务器的同步操作需要通过向主服务器发送SYNC命令来完成：

  1. 从服务器向主服务器发送SYNC命令

  2. 收到SYNC命令的主服务器执行BGSAVE命令，在后台生成RDB文件，并使用一个缓冲区记录从现在开始执行的所有命令

  3. 当服务器的BGSAVE命令执行完毕时，主服务器会将BGSAVE命令生成的RDB文件发送给从服务器，从服务器接收并载入这个RDB文件，将自己的数据库状态更新至主服务器执行BGSAVE命令时的数据库状态

  4. 主服务器将记录在缓冲区里面的所有写命令发送给从服务器，从服务器执行这些写命令，将自己的数据库状态主服务器数据库当前的状态

image.png 命令传播： 每当主服务器执行客户端发送的名时，主服务器的数据库就有可能被修改，并导致主从服务器状态不再一致。为了保持一致，主服务器需要对从服务器执行命令传播操作，主服务器将自己执行的写命令，发送给从服务器，从服务器执行那条命令。

旧版复制功能的缺陷：

  1. 初次复制： 从服务器以前没有复制过任何主服务器，或者从服务器当前要复制的主服务器和上一次复制的主服务器不同。

  2. 断线后重复制：处于命令传播阶段的主服务器因为网络原因而中断了复制，但从服务器通过自动重连接重新连接上了主服务器，并继续复制主服务器。

对于初次复制来说，旧版复制功能能够很好地完成任务，但对于断线后重复制来说，旧版复制功能效率很低。

如果主从服务器有一千个相同的数据，这时候从服务器断开连接，主服务器又执行了一条命令操作，从服务重新连接，主从服务器只有一条不同的数据。这时为了让从服务器补足这一小部分缺失的数据，就要重新执行一次SYNC命令(SYNC是一个非常耗时的操作)，无疑是非常低效的。

新版复制功能的实现

redis从2.8版本开始用PSYNC命令代替SYNC命令来执行复制时的同步操作，PSYNC有完整重同步和部分重同步两种模式。

  • 完整重同步用于处理初次复制情况：和SYNC执行步骤一样

  • 部分重同步用于断线后重新复制情况：从服务器重新连接主服务器，主服务器可以将主从服务器连接断开期间执行的写命令发送给从服务器，从服务器只需要接收并执行这些写命令，就可以将数据库更新至主服务器当前状态

image.png

1.3 部分重同步的实现

三部分：主服务器的复制偏移量和从服务器的复制偏移量、主服务器的复制积压缓冲区、服务器的运行ID

复制偏移量: 主从服务器都分别维护一个复制偏移量

主服务器每次向从服务器传播N个字节的数据时，就将自己的复制偏移量的值加上N。

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

image.png

通过对比主从服务器的复制偏移量，程序可以很容易地知道主从服务器是否处于一致态

复制积压缓冲区:是一个由主服务器维护的一个固定长度先进先出队列，默认大小为1MB。主服务器进行命令传播时，不仅会将写命令发送给所有从服务器，还会将写命令入队到复制积压缓冲区。

image.png

因此，主服务器的复制积压缓冲区里面会保存着一部分最近传播的写命令，并且复制积压缓冲区会为队列中的每个字节记录相应的复制偏移量。

image.png

当从服务器重连后，从服务器发送PSYNC命令将自己的复制偏移量offset发送给主服务器，主服务器会根据这个复制偏移量来决定对从服务器执行哪种操作：

  • 如果offset偏移量之后的数据(也即是偏移量offset+1开始的数据)任然存在于复制缓冲区里面，那么主服务器对从服务器执行部分重同步操作，反之，完整重同步。 如图所示的断开操作，以下是执行步骤：

image.png

  1. 从服务器A重连，并发送PSYNC命令，报告自己的复制偏移量10086

  2. 主服务器收到10086这个偏移量，先检查10086是否存在于复制缓冲区，因为存在，所以主服务器向从服务器发送+CONTINUE回复，表示将重同步操作进行数据同步

  3. 接着主服务器会将复制积压缓冲区10086后的书记发送给从服务器

  4. 从服务器接收只收到这33字节的确实数据，就可以回到与主服务器一致的状态

image.png 服务器运行ID： 每个redis服务器，都有自己的运行ID，每个ID在服务器启动时自动生成。

  1. 当从服务器对主服务器进行初次复制时，主服务器会将自己的运行ID传送给从服务器，而从服务器则会将这个运行ID保存下来。从服务器断开重新连接上一个主服务器时，从服务器将向当前连接的主服务器发送之前保存的运行ID

  2. 如果相同，执行部分重同步操作

  3. 如果不同，说明不是刚才的那个服务器，执行完整重同步操作

PSYNC命令的实现

image.png

复制的实现

通过向从服务器发送SL(奴隶)AVEOF命令，我们可以让一个从服务器去复制一个主服务器：

SLAVEOF <master_ip> <master_port>

  1. 设置主服务器的地址和端口：从服务器首先要做的是将客户端给定的主服务器IP地址和端口号保存到服务器状态的masterhost属性和masterport属性里面，slaveof是一个异步命令，在完成这两个属性的设置后，从服务器向发送slaveof命令的客户端返回ok,表示复制指令已经被接收，而实际的复制工作将在OK之后才真正开始执行。

  2. 建立套接字链接：从服务器创建套接字成功，从服务器会为这个套接字关联一个专门用于处理复制工作的文件事件处理器。主服务器接收从服务器的套接字链接后，将为套接字创建相应的客户端状态，将从服务器看成一个主服务器的客户端。

  3. 从服务器发送PING：虽然建立了链接，但是双方未使用该套接字进行过任何通信，可以检查套接字的读写状态是否正常。还可以检查主服务器能否正常处理命令。

  4. 在收到PONG之后，身份验证：如果从服务器设置了masterauth选项，进行身份验证，反之，不验证

image.png

  1. 发送端口信息：从服务器执行命令REPLCONF listening-port ，向主服务器发送从服务器的监听端口号

  2. 同步：从服务器向主服务器发送PSYNC命令，执行同步操作，并将自己的数据库更新至主服务器数据库当前的状态

  3. 命令传播：主服务器将自己执行的写命令发送给从服务器

心跳检测

在命令传播阶段，从服务器会每秒向主服务器发送命令

REPLCONF ACK <replication_offset>

replication_offset是从服务器当前的复制偏移量

作用：

  1. 检测主从服务器网络链接状态：如果主服务器超过1s没有收到从服务器发送来的REPLCONF ACK ，那么主服务器就知道连接出问题了

  2. 复制实现min-slaves选项：可以防止主服务器在不安全的情况下执行写命令

比如向主服务器设置了最小从服务器的数量和最大延迟时间那么，如果在从服务器数量小于3个，或者三个从服务器的延迟（lag）值都大于或者等于10秒时，主服务器将拒绝执行写命令

  1. 检测命令丢失：传播过程中可能因为网络原因丢失一部分写命令，导致主从服务器复制偏移量不同，主服务器再次补发缺失的命令发送给从服务器

注意：补发缺失数据操作在主从服务器没有断线的情况下执行，而部分重同步操作则在主从服务器断线并重连之后执行

小结

  1. Redis 2.8以前的复制功能不能高效地处理断线后重复制情况，但Redis 2.8新添加的部分重同步功能可以解决这个问题。

  2. 部分重同步通过复制偏移量、复制积压缓冲区、服务器运行ID三个部分来实现。

  3. 在复制操作刚开始的时候，从服务器会成为主服务器的客户端，并通过向主服务器发送命令请求来执行复制步骤，而在复制操作的后期，主从服务器会互相成为对方的客户端。

  4. 主服务器通过向从服务器传播命令来更新从服务器的状态，保持主从服务器一致，而从服务器则通过向主服务器发送命令来进行心跳检测，以及命令丢失检测。 其他博客

avatar
文章
阅读
粉丝