深入学习Redis高可用的基石：主从复制

2018-07-07

深入学习Redis高可用的基石：主从复制

在 Redis 的持久化中曾提到，Redis 高可用的方案包括持久化、主从复制（及读写分离）、哨兵和集群。

其中持久化侧重解决的是 Redis 数据的单机备份问题（从内存到硬盘的备份）；而主从复制则侧重解决数据的多机热备。此外，主从复制还可以实现负载均衡和故障恢复。

我将从以下几个部分详细介绍 Redis 主从复制的方方面面：

主从复制概述
如何使用主从复制
主从复制的实现原理
应用中的问题
总结

主从复制概述

主从复制，是指将一台 Redis 服务器的数据，复制到其他的 Redis 服务器。前者称为主节点(master)，后者称为从节点(slave)；数据的复制是单向的，只能由主节点到从节点。

默认情况下，每台 Redis 服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

主从复制的作用主要包括：

数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写 Redis 数据时应用连接主节点，读 Redis 数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高 Redis 服务器的并发量。
高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是 Redis 高可用的基础。

如何使用主从复制

为了更直观的理解主从复制，在介绍其内部原理之前，先说明我们需要如何操作才能开启主从复制。

建立复制

需要注意，主从复制的开启，完全是在从节点发起的；不需要我们在主节点做任何事情。

从节点开启主从复制，有 3 种方式：

在从服务器的配置文件中加入：slaveof <masterip> <masterport>。
redis-server 启动命令后加入 --slaveof <masterip> <masterport>。
Redis 服务器启动后，直接通过客户端执行命令：slaveof <masterip> <masterport>，则该 Redis 实例成为从节点。

上述 3 种方式是等效的，下面以客户端命令的方式为例，看一下当执行了 slaveof 后，Redis 主节点和从节点的变化。

实例

准备工作：启动两个节点。为了方便起见，实验所使用的主从节点是在一台机器上的不同 Redis 实例。

其中主节点监听 6379 端口，从节点监听 6380 端口；从节点监听的端口号可以在配置文件中修改：

启动后可以看到：

两个 Redis 节点启动后（分别称为6379节点和6380节点），默认都是主节点。

建立复制：此时在 6380 节点执行 slaveof 命令，使之变为从节点。

观察效果：下面验证一下，在主从复制建立后，主节点的数据会复制到从节点中。

首先在从节点查询一个不存在的 key：

然后在主节点中增加这个 key：

此时在从节点中再次查询这个 key，会发现主节点的操作已经同步至从节点：

然后在主节点删除这个 key：

此时在从节点中再次查询这个 key，会发现主节点的操作已经同步至从节点：

断开复制

通过 slaveof <masterip> <masterport> 命令建立主从复制关系以后，可以通过 slaveof no one 断开。

需要注意的是，从节点断开复制后，不会删除已有的数据，只是不再接受主节点新的数据变化。

从节点执行 slaveof no one 后，打印日志如下图所示；可以看出断开复制后，从节点又变回为主节点。

主节点打印日志如下：

主从复制的实现原理

上面一节中，我们介绍了如何操作可以建立主从关系；本小节将介绍主从复制的实现原理。

主从复制过程大体可以分为 3 个阶段：

连接建立阶段（即准备阶段）
数据同步阶段
命令传播阶段

连接建立阶段

该阶段的主要作用是在主从节点之间建立连接，为数据同步做好准备。

步骤 1：保存主节点信息

从节点服务器内部维护了两个字段，即 masterhost 和 masterport 字段，用于存储主节点的 ip 和 port 信息。

需要注意的是，slaveof 是异步命令，从节点完成主节点 ip 和 port 的保存后，向发送 slaveof 命令的客户端直接返回 OK，实际的复制操作在这之后才开始进行。

这个过程中，可以看到从节点打印日志如下：

步骤 2：建立 Socket 连接

从节点每秒 1 次调用复制定时函数 replicationCron()，如果发现了有主节点可以连接，便会根据主节点的 ip 和 port，创建 socket 连接。

如果连接成功，则：

从节点：为该 socket 建立一个专门处理复制工作的文件事件处理器，负责后续的复制工作，如接收 RDB 文件、接收命令传播等。
主节点：接收到从节点的 socket 连接后（即 accept 之后），为该 socket 创建相应的客户端状态，并将从节点看做是连接到主节点的一个客户端，后面的步骤会以从节点向主节点发送命令请求的形式来进行。

这个过程中，从节点打印日志如下：

步骤 3：发送 Ping 命令

从节点成为主节点的客户端之后，发送 ping 命令进行首次请求，目的是：检查 socket 连接是否可用，以及主节点当前是否能够处理请求。

从节点发送 ping 命令后，可能出现 3 种情况：

返回pong：说明 socket 连接正常，且主节点当前可以处理请求，复制过程继续。
超时：一定时间后从节点仍未收到主节点的回复，说明 socket 连接不可用，则从节点断开 socket 连接，并重连。
返回 pong 以外的结果：如果主节点返回其他结果，如正在处理超时运行的脚本，说明主节点当前无法处理命令，则从节点断开 socket 连接，并重连。

在主节点返回 pong 情况下，从节点打印日志如下：

步骤 4：身份验证

如果从节点中设置了 masterauth 选项，则从节点需要向主节点进行身份验证；没有设置该选项，则不需要验证。

从节点进行身份验证是通过向主节点发送 auth 命令进行的，auth 命令的参数即为配置文件中的 masterauth 的值。

如果主节点设置密码的状态，与从节点 masterauth 的状态一致（一致是指都存在，且密码相同，或者都不存在），则身份验证通过，复制过程继续；如果不一致，则从节点断开 socket 连接，并重连。

步骤 5：发送从节点端口信息

身份验证之后，从节点会向主节点发送其监听的端口号（前述例子中为 6380），主节点将该信息保存到该从节点对应的客户端的 slave_listening_port 字段中。

该端口信息除了在主节点中执行 info Replication 时显示以外，没有其他作用。

数据同步阶段

主从节点之间的连接建立以后，便可以开始进行数据同步，该阶段可以理解为从节点数据的初始化。

具体执行的方式是：从节点向主节点发送 psync 命令（Redis 2.8 以前是 sync 命令），开始同步。

数据同步阶段是主从复制最核心的阶段，根据主从节点当前状态的不同，可以分为全量复制和部分复制。

需要注意的是，在数据同步阶段之前，从节点是主节点的客户端，主节点不是从节点的客户端；而到了这一阶段及以后，主从节点互为客户端。

原因在于：在此之前，主节点只需要响应从节点的请求即可，不需要主动发请求，而在数据同步阶段和后面的命令传播阶段，主节点需要主动向从节点发送请求（如推送缓冲区中的写命令），才能完成复制。

命令传播阶段

数据同步阶段完成后，主从节点进入命令传播阶段；在这个阶段主节点将自己执行的写命令发送给从节点，从节点接收命令并执行，从而保证主从节点数据的一致性。

在命令传播阶段，除了发送写命令，主从节点还维持着心跳机制：PING 和 REPLCONF ACK。

由于心跳机制的原理涉及部分复制，因此将在介绍了部分复制的相关内容后单独介绍该心跳机制。

延迟与不一致：需要注意的是，命令传播是异步的过程，即主节点发送写命令后并不会等待从节点的回复；因此实际上主从节点之间很难保持实时的一致性，延迟在所难免。

数据不一致的程度，与主从节点之间的网络状况、主节点写命令的执行频率、以及主节点中的 repl-disable-tcp-nodelay 配置等有关。

repl-disable-tcp-nodelay no：该配置作用于命令传播阶段，控制主节点是否禁止与从节点的 TCP_NODELAY；默认 no，即不禁止 TCP_NODELAY。

当设置为 yes 时，TCP 会对包进行合并从而减少带宽，但是发送的频率会降低，从节点数据延迟增加，一致性变差；具体发送频率与 Linux 内核的配置有关，默认配置为 40ms。

当设置为 no 时，TCP 会立马将主节点的数据发送给从节点，带宽增加但延迟变小。

一般来说，只有当应用对 Redis 数据不一致的容忍度较高，且主从节点之间网络状况不好时，才会设置为 yes；多数情况使用默认值 no。

数据同步阶段：全量复制和部分复制

在 Redis 2.8 以前，从节点向主节点发送 sync 命令请求同步数据，此时的同步方式是全量复制。

在 Redis 2.8 及以后，从节点可以发送 psync 命令请求同步数据，此时根据主从节点当前状态的不同，同步方式可能是全量复制或部分复制。后文介绍以 Redis 2.8 及以后版本为例。

全量复制：用于初次复制或其他无法进行部分复制的情况，将主节点中的所有数据都发送给从节点，是一个非常重型的操作。

部分复制：用于网络中断等情况后的复制，只将中断期间主节点执行的写命令发送给从节点，与全量复制相比更加高效。

需要注意的是，如果网络中断时间过长，导致主节点没有能够完整地保存中断期间执行的写命令，则无法进行部分复制，仍使用全量复制。

全量复制

Redis 通过 psync 命令进行全量复制的过程如下：

从节点判断无法进行部分复制，向主节点发送全量复制的请求；或从节点发送部分复制的请求，但主节点判断无法进行全量复制；具体判断过程需要在讲述了部分复制原理后再介绍。
主节点收到全量复制的命令后，执行 bgsave，在后台生成 RDB 文件，并使用一个缓冲区（称为复制缓冲区）记录从现在开始执行的所有写命令
主节点的 bgsave 执行完成后，将 RDB 文件发送给从节点；从节点首先清除自己的旧数据，然后载入接收的 RDB 文件，将数据库状态更新至主节点执行 bgsave 时的数据库状态。
主节点将前述复制缓冲区中的所有写命令发送给从节点，从节点执行这些写命令，将数据库状态更新至主节点的最新状态
如果从节点开启了 AOF，则会触发 bgrewriteaof 的执行，从而保证 AOF 文件更新至主节点的最新状态。

下面是执行全量复制时，主从节点打印的日志；可以看出日志内容与上述步骤是完全对应的。

主节点的打印日志如下：

从节点打印日志如下图所示：

其中，有几点需要注意：

从节点接收了来自主节点的 89260 个字节的数据。
从节点在载入主节点的数据之前要先将老数据清除。
从节点在同步完数据后，调用了 bgrewriteaof。

通过全量复制的过程可以看出，全量复制是非常重型的操作：

主节点通过 bgsave 命令 fork 子进程进行 RDB 持久化，该过程是非常消耗 CPU、内存(页表复制)、硬盘 IO 的；关于 bgsave 的性能问题，可以参考深入学习Redis（2）：持久化。
主节点通过网络将 RDB 文件发送给从节点，对主从节点的带宽都会带来很大的消耗。
从节点清空老数据、载入新 RDB 文件的过程是阻塞的，无法响应客户端的命令；如果从节点执行 bgrewriteaof，也会带来额外的消耗。

部分复制

由于全量复制在主节点数据量较大时效率太低，因此 Redis 2.8 开始提供部分复制，用于处理网络中断时的数据同步。

部分复制的实现，依赖于三个重要的概念：

复制偏移量：主节点和从节点分别维护一个复制偏移量（offset），代表的是主节点向从节点传递的字节数。

主节点每次向从节点传播 N 个字节数据时，主节点的 offset 增加 N；从节点每次收到主节点传来的 N 个字节数据时，从节点的 offset 增加 N。

offset 用于判断主从节点的数据库状态是否一致：如果二者 offset 相同，则一致；如果 offset 不同，则不一致，此时可以根据两个 offset 找出从节点缺少的那部分数据。

例如，如果主节点的 offset 是 1000，而从节点的 offset 是 500，那么部分复制就需要将 offset 为 501-1000 的数据传递给从节点。

而 offset 为 501-1000 的数据存储的位置，就是下面要介绍的复制积压缓冲区。

复制积压缓冲区：复制积压缓冲区是由主节点维护的、固定长度的、先进先出(FIFO)队列，默认大小 1MB。

当主节点开始有从节点时创建，其作用是备份主节点最近发送给从节点的数据。注意，无论主节点有一个还是多个从节点，都只需要一个复制积压缓冲区。

在命令传播阶段，主节点除了将写命令发送给从节点，还会发送一份给复制积压缓冲区，作为写命令的备份；除了存储写命令，复制积压缓冲区中还存储了其中的每个字节对应的复制偏移量（offset）。

由于复制积压缓冲区定长且是先进先出，所以它保存的是主节点最近执行的写命令；时间较早的写命令会被挤出缓冲区。

由于该缓冲区长度固定且有限，因此可以备份的写命令也有限，当主从节点 offset 的差距过大超过缓冲区长度时，将无法执行部分复制，只能执行全量复制。

反过来说，为了提高网络中断时部分复制执行的概率，可以根据需要增大复制积压缓冲区的大小(通过配置repl-backlog-size)。

例如如果网络中断的平均时间是 60s，而主节点平均每秒产生的写命令(特定协议格式)所占的字节数为 100KB，则复制积压缓冲区的平均需求为 6MB。

保险起见，可以设置为 12MB，来保证绝大多数断线情况都可以使用部分复制。

从节点将 offset 发送给主节点后，主节点根据 offset 和缓冲区大小决定能否执行部分复制：

如果 offset 偏移量之后的数据，仍然都在复制积压缓冲区里，则执行部分复制。
如果 offset 偏移量之后的数据已不在复制积压缓冲区中（数据已被挤出），则执行全量复制。

服务器运行 ID(runid)：每个 Redis 节点(无论主从)，在启动时都会自动生成一个随机 ID(每次启动都不一样)，由 40 个随机的十六进制字符组成；runid 用来唯一识别一个 Redis 节点。

通过 info Server 命令，可以查看节点的 runid：

主从节点初次复制时，主节点将自己的 runid 发送给从节点，从节点将这个 runid 保存起来；当断线重连时，从节点会将这个 runid 发送给主节点。

主节点根据 runid 判断能否进行部分复制：

如果从节点保存的 runid 与主节点现在的 runid 相同，说明主从节点之前同步过，主节点会继续尝试使用部分复制(到底能不能部分复制还要看 offset 和复制积压缓冲区的情况)。
如果从节点保存的 runid 与主节点现在的 runid 不同，说明从节点在断线前同步的 Redis 节点并不是当前的主节点，只能进行全量复制。

psync 命令的执行：在了解了复制偏移量、复制积压缓冲区、节点运行 id 之后，本节将介绍 psync 命令的参数和返回值，从而说明 psync 命令执行过程中，主从节点是如何确定使用全量复制还是部分复制的。

psync 命令的执行过程可以参见下图：

首先，从节点根据当前状态，决定如何调用 psync 命令：

如果从节点之前未执行过 slaveof 或最近执行了 slaveof no one，则从节点发送命令为 psync ? -1，向主节点请求全量复制。
如果从节点之前执行了 slaveof，则发送命令为 psync <runid> <offset>，其中 runid 为上次复制的主节点的 runid，offset 为上次复制截止时从节点保存的复制偏移量。

主节点根据收到的psync命令，及当前服务器状态，决定执行全量复制还是部分复制：

如果主节点版本低于 Redis 2.8，则返回 -ERR 回复，此时从节点重新发送 sync 命令执行全量复制。
如果主节点版本够新，且 runid 与从节点发送的 runid 相同，且从节点发送的 offset 之后的数据在复制积压缓冲区中都存在，则回复 +CONTINUE，表示将进行部分复制，从节点等待主节点发送其缺少的数据即可。
如果主节点版本够新，但是 runid 与从节点发送的 runid 不同，或从节点发送的 offset 之后的数据已不在复制积压缓冲区中(在队列中被挤出了)，则回复 +FULLRESYNC <runid> <offset>，表示要进行全量复制。

其中 runid 表示主节点当前的 runid，offset 表示主节点当前的 offset，从节点保存这两个值，以备使用。

部分复制演示：在下面的演示中，网络中断几分钟后恢复，断开连接的主从节点进行了部分复制；为了便于模拟网络中断，本例中的主从节点在局域网中的两台机器上。

网络中断一段时间后，主节点和从节点都会发现失去了与对方的连接（关于主从节点对超时的判断机制，后面会有说明）。

此后，从节点便开始执行对主节点的重连，由于此时网络还没有恢复，重连失败，从节点会一直尝试重连。

主节点日志如下：