Redis中的复制功能(一)

复制

概述

在Redis中，用户可以通过执行SLAVEOF命令或者设置slaveof选项，让一个服务器去复制(replicate)另一个服务器，我们称呼被复制的服务器为主服务器(master)，而对主服务器进行复制的服务器则被称为从服务器(slave),如图所示。

例子

举个例子。假设现在有两个Redis服务器，地址分别为127.0.0.1:6379和127.0.0.1:12345，如果我们向服务器127.0.0.1:12345发送以下命令:

127.0.0.1:12345> SLAVEOF 127.0.0.1 6379
OK
1
2

那么服务器127.0.0.1:12345将称为127.0.0.1:6379的从服务器，而服务器6379则会称为12345的主服务器。进行复制中的主从服务器双方的数据库将保存相同的数据，概念上将这种现象乘坐为"数据库状态一致",或者
简称"一致"。比如说，在主服务器上执行以下命令:

127.0.0.1:6379> SET msg "hello world"
OK
1
2

那么我们应该既可以在主服务器上获取msg键的值:

127.0.0.1:6379> GET msg
"hello world"
1
2

又可以在从服务器上获取msg键的值:

127.0.0.1:12345> GET msg
"hello world"
1
2

另一方面，如果我们在主服务器中删除了键msg:

127.0.0.1:6379> DEL msg
(integer) 1
1
2

那么不仅主服务器上的msg键会被删除

127.0.0.1:6379> EXISTS msg
(integer) 0
1
2

从服务器上的msg键也应该会被删除:

127.0.0.1:12345> EXISTS msg
(integer) 0
1
2

旧版复制功能的实现

Redis的复制宫嗯那个分为同步(sync)和命令传播(command propagate)两个操作:

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

同步

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

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

例子

命令传播

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

例子

举个例子，假设一个主服务器和一个从服务器刚刚完成同步操作，它们的数据库都保存了相同的五个键k1至k5,如图所示，如果这是，客户端向主服务器发送命令DEL k3，那么主服务器在执行完这个DEL命令之后，主从服务器的数据库将出现不一致:主服务器的数据库已经不再包含键
k3,但这个键却仍然包含在从服务器的数据库里面，如图所示.

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

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

旧版复制功能的缺陷

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

• 1.初次复制:从服务器以前没有复制过任何主服务器，或者从服务器当前要复制的主服务器和上一次复制的主服务器不同.
• 2.断线后重复制:处于命令传播阶段的主从服务器因为网络原因而中断了复制，但从服务器通过自动重连接重新连上了主服务器，并继续复制主服务器。对于初次复制来说，旧版复制功能能够很好地完成任务，但对于断线后重复制来说，旧版复制功能虽然也能让主服务器重新回到一致状态，但效率却非常低。

例子

举个例子。在时间10091,从服务器终于重新连接上主服务器，因为这是主从服务器的状态已经不再一致，所以从服务器将向主服务器发送SYNC命令，而主服务器会将包含键k1至键k10089的RDB文件发送给从服务器，从服务器通过接收和载入这个RDB文件来将自己的数据库更新至主服务器数据库当前所处的状态。

虽然再次发送SYNC命令可以让主从服务器重新回到一致状态，但如果仔细研究过这个断线重复制过程，就会发现传送RDB文件这一步实际上并不是非做不可的:

• 1.主从服务器在时间T0至T10086中一致处于一致状态，这连个服务器保存的数据大部分都是相同的。
• 2.从服务器想要将自己更新至主服务器当前所处的状态，真正需要的是主从服务器连接中断期间，主服务器新添加的k10086/k10088/k10089三个键的数据
• 3.可惜的是，旧版复制功能并没有利用以上列举的两点条件，而是继续让主服务器生成并向从服务器发送包含键k1至键k10089的RDB文件，但实际上RDB文件包含的键1至键k10086的数据对于从服务器来说都是不必要的。在主从服务器断线期间，主服务器执行的写命令可能会有成百上千之多，而不仅仅是两三个写命令。但总的来说，主从服务器断开的时间
  越短，主服务器在断线期间执行的写命令就越少，而执行少量写命令所产生的数据量通常比整个数据库的数据量要少的多，在这种情况下，为了让从服务器不足一小部分缺失的数据，却要让主从服务器重新再执行一次SYNC命令，这种做法无疑是非常低效的。

注意

SYNC命令是一个非常耗费资源的操作。每次执行SYNC命令主从服务器需要执行以下动作:

• 1.主服务器需要执行BGSAVE命令来生成RDB文件，这个生成操作会耗费主服务器大量的CPU、内存和磁盘IO资源
• 2.主服务器需要将自己生成的RDB文件发送给从服务器，这个发送操作会耗费主从服务器大量的网络资源(带宽和流量),并对主服务器相应命令请求的时间产生影响
• 3.接收到RDB文件的从服务器需要载入主服务器发来的RDB文件，并且在载入期间，从服务器会因为阻塞而么没办法处理命令请求。
  因为SYNC命令是一个如此耗费资源的操作，所以Redis有必要保证在真正有需要时才执行SYNC命令