chapter15 复制

15.1 旧版复制功能的实现

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

• 其中，同步操作用于将从服务器的数据库状态更新至主服务器当前所处的数据库状态。
• 而命令传播操作则用于在主服务器的数据库状态被修改，导致主从服务器的数据库状态出现不一致时，让主从服务器的数据库重新回到一致状态。

15.1.1 同步

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

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

1. 从服务器向主服务器发送 SYNC 命令。
2. 收到 SYNC 命令的主服务器执行 BGSAVE 命令，在后台生成一个 RDB 文件，并使用一个缓冲区记录从现在开始执行的所有写命令。
3. 当主服务器的 BGSAVE 命令执行完毕时，主服务器会将 BGSAVE 命令生成的 RDB 文件发送给从服务器，从服务器接收并载入这个 RDB 文件，将自己的数据库状态更新至主服务器执行 BGSAVE 命令时的数据库状态。
4. 主服务器将记录在缓冲区里面的所有写命令发送给从服务器，从服务器执行这些写命令，将自己的数据库状态更新至主服务器数据库当前所处的状态。

图 IMAGE_SYNC 展示了 SYNC 命令执行期间，主从服务器的通信过程。

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

时间	主服务器	从服务器
T0	服务器启动。	服务器启动。
T1	执行 SET k1 v1 。
T2	执行 SET k2 v2 。
T3	执行 SET k3 v3 。
T4		向主服务器发送 SYNC 命令。
T5	接收到从服务器发来的 SYNC 命令，执行 BGSAVE 命令，创建包含键 k1 、 k2 、 k3的 RDB 文件，并使用缓冲区记录接下来执行的所有写命令。
T6	执行 SET k4 v4 ，并将这个命令记录到缓冲区里面。
T7	执行 SET k5 v5 ，并将这个命令记录到缓冲区里面。
T8	BGSAVE 命令执行完毕，向从服务器发送 RDB 文件。
T9		接收并载入主服务器发来的 RDB 文件 ，获得 k1 、 k2 、 k3 三个键。
T10	向从服务器发送缓冲区中保存的写命令SET k4 v4 和 SET k5 v5 。
T11		接收并执行主服务器发来的两个 SET 命令，得到 k4 和 k5 两个键。
T12	同步完成，现在主从服务器两者的数据库都包含了键k1 、 k2 、 k3 、 k4 和k5 。	同步完成，现在主从服务器两者的数据库都包含了键k1 、 k2 、 k3 、 k4 和k5 。

15.1.2 命令传播

    在同步操作执行完毕之后，主从服务器两者的数据库将达到一致状态，但这种一致并不是一成不变的 ——每当主服务器执行客户端发送的写命令时，主服务器的数据库就有可能会被修改，并导致主从服务器状态不再一致。

    举个例子，假设一个主服务器和一个从服务器刚刚完成同步操作，它们的数据库都保存了相同的五个键 k1 至 k5 ，如图 IMAGE_CONSISTENT 所示。

    如果这时，客户端向主服务器发送命令 DEL k3 ，那么主服务器在执行完这个 DEL 命令之后，主从服务器的数据库将出现不一致：主服务器的数据库已经不再包含键 k3 ，但这个键却仍然包含在从服务器的数据库里面，如图 IMAGE_INCONSISTENT 所示。

    为了让主从服务器再次回到一致状态，主服务器需要对从服务器执行命令传播操作：主服务器会将自己执行的写命令 —— 也即是造成主从服务器不一致的那条写命令 —— 发送给从服务器执行，当从服务器执行了相同的写命令之后，主从服务器将再次回到一致状态。

    在上面的例子中，主服务器因为执行了命令 DEL k3 而导致主从服务器不一致，所以主服务器将向从服务器发送相同的命令 DEL k3 ：当从服务器执行完这个命令之后，主从服务器将再次回到一致状态 ——现在主从服务器两者的数据库都不再包含键 k3 了，如图 IMAGE_PROPAGATE_DEL_k3 所示。

15.2 旧版复制功能缺陷

    在Redis2.8以前,从服务器对主服务器的复制可以分为以下两种情况:

• 初次复制:从服务器以前没有复制过任何主服务器,或者从服务器当前要复制的主服务器和上一次复制的主服务器不同。
• 断线后重复制:处于命令传播阶段的主从服务器因为网络原因而中断了复制,但从服务器通过自动重连接重新连接上了主服务器,并继续复制主服务器。

• 主从服务器再时间T0至时间T10086中一直处于一致状态,这两个服务器保存着的数据大部分都是相同的。
• 从服务器想要将自己更新至主服务器当前所处的状态,真正需要的是主从服务器连接中断期间,主服务器新添加的k10087,k10088,k10089三个键的数据。
• 可惜的是,旧版复制功能并没有利用以上列举的的两点条件,而是继续让主服务器生成并向从服务器发送包含键k1至键k10089的RDB文件,但实际上RDB文件包含的键k1至键k10086的数据对于从服务器来说都是不必要的。

15.3 新版复制功能的实现

    为了解决旧版复制功能在处理断线复制情况时的低效问题,Redis从2.8版本开始,使用PSYNC命令代替SYNC命令来执行复制时的同步操作。

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

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

15.4 部分重同步的实现

    部分重同步功能由以下三个部分构成:

• 主服务器的复制偏移量(replication offset)和从服务器的复制偏移量。
• 主服务器的复制积压缓冲区(replication backlog)。
• 服务器的运行ID(run ID)。

15.4.1 复制偏移量

15.4.2 复制积压缓冲区

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

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

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

    当从服务器重新连上主服务器时,从服务器会通过PSYNC命令将自己的复制偏移量offset发送给主服务器,主服务器会根据这个复制偏移量来决定对从服务器执行何种同步操作:

15.4.3 服务器运行ID

    当从服务器对主服务器初次复制时,主服务器会将自己的运行ID传送给从服务器,而从服务器则会将这个运行ID保存起来。

    当从服务器断线并重新连上一个主服务器时,从服务器将向当前连接的主服务器发送之前保存的运行ID:

• 如果从服务器保存的运行ID和当前连接的主服务器的运行ID相同,那么说明从服务器断线之前复制的就是当前的这个主服务器,主服务器可以继续尝试执行部分重同步操作。
• 相反地,如果从服务器保存的运行ID和当前连接的主服务器的运行ID并不相同,那么说明从服务器断线之前复制的主服务器并不是当前连接的这个主服务器,主服务器将对从服务器执行完整重同步操作。

15.5 PSYNC命令的实现

15.6 复制的实现

    通过向从服务器发送SLAVEOF命令,我们可以让一个从服务器复制一个主服务器:

SLAVEOF <master_ip> <master_port>

15.6.1 步骤1:设置主服务器的地址和端口

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

127.0.0.1:12345>SLAVEOF 127.0.0.1 6379
OK

    从服务器首先要做的就是将客户端给定的主服务器IP地址127.0.0.1以及端口6379保存到服务器状态的masterhost属性和masterport属性里面:

    SLAVEOF命令执行后,表示复制指令已经被接收,而实际的复制工作将在OK返回之后才真正执行。

15.6.2 步骤2:建立套接字连接

    如果从服务器创建的套接字能成功连接(connect)到主服务器,那么从服务器将为这个套接字关联一个专门用于处理复制工作的文件事件处理器,这个处理器将负责执行后续的复制工作,比如接收RDB文件,以及接收主服务器传播来的命令。

    而主服务器在接受(accept)从服务器的套接字连接之后,将为套接字创建相应的客户端状态,并将从服务器看做是一个连接到主服务器的客户端对待,这时从服务器将同时具有服务器(server)和客户端(client)两个身份:从服务器可以向主服务器发送命令请求,而主服务器则会向从服务器返回命令回复。

15.6.3 步骤3:发送PING命令

    PING命令有两个作用:

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

15.6.4 步骤4:身份验证

    从服务器在收到主服务器返回的"PONG"回复之后,下一步要做的就是决定是否进行身份验证:

• 如果从服务器设置了masterauth选项,那么进行身份验证。
• 如果从服务器没有设置masterauth选项,那么不进行身份验证。
  

15.6.5 步骤5:发送端口信息

    在身份验证之后,从服务器将执行命令REPLCONF listening-port <port-number>,向主服务器发送从服务器的监听端口号。

    主服务器在接收到这个命令之后,会将端口号记录在从服务器所对应的客户端状态的slave_listening_port属性中:

15.6.6 步骤6:同步

    在这一步,从服务器将向主服务器发送PSYNC命令,执行同步操作,并将自己的数据库更新至主服务器库当前所处的状态。

    值得一提的是,在同步操作执行之前,只有从服务器是主服务器的客户端,但是在执行同步操作之后,主服务器也会成为从服务器的客户端:

15.6.7 步骤7:命令传播

    当完成了同步之后,主从服务器就会进入命令传播阶段,这时主服务器只要一直将自己执行的写命令发送给从服务器,而从服务器只要一直接收并执行主服务器发来的写命令,就可以保证主从服务器一直保持一致了。

15.7 心跳检测

    在命令传播阶段,从服务器默认会以每秒一次的频率,向主服务器发送命令:

REPLCONF ACK <replication_offset>

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

    发送REPLCONF ACK命令对于主从服务器有三个作用:

• 检测主从服务器的网络连接状态。
• 辅助实现min-slaves选项。
• 检测命令丢失。

15.7.1 检测主从服务器的网络连接状态

    主从服务器可以通过发送和接收REPLCONF ACK命令来检查两者之间的网络连接是否正常:如果主服务器超过一秒钟没有收到从服务器发来的REPLCONF ACK命令,那么主服务器就知道主从服务器之间的连接出现问题了。

15.7.2 辅助实现min-slaves配置选项

    Redis的min-slaves-to-write和min-slaves-max-lag两个选项可以防止主服务器在不安全的情况下执行写命令。

min-slaves-to-write 3
min-slaves-max-lag 10

    那么在从服务器的数量少于3个,或者三个从服务器的延迟(lag)值都大于或等于10秒时,主服务器将拒绝执行写命令,这里的延迟就是上面提到的INFO replication命令的lag值。

15.7.3 检测命令丢失

    如果这时主服务器执行了命令 SET key value （协议格式的长度为 33 字节）， 将自己的复制偏移量更新到了 233 ， 并尝试向从服务器传播命令 SET key value ， 但这条命令却因为网络故障而在传播的途中丢失， 那么主从服务器之间的复制偏移量就会出现不一致： 主服务器的复制偏移量会被更新为 233 ， 而从服务器的复制偏移量仍然为 200 ， 如图 15-24 所示。

    在这之后， 当从服务器向主服务器发送 REPLCONF ACK 命令的时候， 主服务器会察觉从服务器的复制偏移量依然为 200 ， 而自己的复制偏移量为 233 ， 这说明复制积压缓冲区里面复制偏移量为 201 至 233 的数据（也即是命令 SET key value ）在传播过程中丢失了， 于是主服务器会再次向从服务器传播命令 SET key value ， 从服务器通过接收并执行这个命令可以将自己更新至主服务器当前所处的状态， 如图 15-25 所示。

15.8 重点回顾

• Redis 2.8 以前的复制功能不能高效地处理断线后重复制情况，但 Redis 2.8 新添加的部分重同步功能可以解决这个问题。
• 部分重同步通过复制偏移量、复制积压缓冲区、服务器运行 ID 三个部分来实现。
• 在复制操作刚开始的时候，从服务器会成为主服务器的客户端，并通过向主服务器发送命令请求来执行复制步骤，而在复制操作的后期，主从服务器会互相成为对方的客户端。
• 主服务器通过向从服务器传播命令来更新从服务器的状态，保持主从服务器一致，而从服务器则通过向主服务器发送命令来进行心跳检测，以及命令丢失检测。