深入学习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,从节点保存这两个值,以备使用。

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

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

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

主节点日志如下:

从节点日志如下:

网络恢复后,从节点连接主节点成功,并请求进行部分复制,主节点接收请求后,二者进行部分复制以同步数据。

主节点日志如下:

从节点日志如下:

命令传播阶段:心跳机制

在命令传播阶段,除了发送写命令,主从节点还维持着心跳机制:PING 和 REPLCONF ACK。心跳机制对于主从复制的超时判断、数据安全等有作用。

主->从:PING

每隔指定的时间,主节点会向从节点发送 PING 命令,这个 PING 命令的作用,主要是为了让从节点进行超时判断。

PING 发送的频率由 repl-ping-slave-period 参数控制,单位是秒,默认值是 10s。

关于该 PING 命令究竟是由主节点发给从节点,还是相反,有一些争议;因为在 Redis 的官方文档中,对该参数的注释中说明是从节点向主节点发送 PING 命令,如下图所示:

但是根据该参数的名称(含有 ping-slave),以及代码实现,我认为该 PING 命令是主节点发给从节点的。

相关代码如下:

从->主:REPLCONF ACK

在命令传播阶段,从节点会向主节点发送 REPLCONF ACK 命令,频率是每秒 1 次;命令格式为:REPLCONF ACK {offset},其中 offset 指从节点保存的复制偏移量。

REPLCONF ACK 命令的作用包括:

实时监测主从节点网络状态:该命令会被主节点用于复制超时的判断。此外,在主节点中使用 info Replication,可以看到其从节点的状态中的 lag 值,代表的是主节点上次收到该 REPLCONF ACK 命令的时间间隔。

在正常情况下,该值应该是 0 或 1,如下图所示:

检测命令丢失:从节点发送了自身的 offset,主节点会与自己的 offset 对比,如果从节点数据缺失(如网络丢包),主节点会推送缺失的数据(这里也会利用复制积压缓冲区)。

注意,offset 和复制积压缓冲区,不仅可以用于部分复制,也可以用于处理命令丢失等情形;区别在于前者是在断线重连后进行的,而后者是在主从节点没有断线的情况下进行的。

辅助保证从节点的数量和延迟:Redis 主节点中使用 min-slaves-to-write 和 min-slaves-max-lag 参数,来保证主节点在不安全的情况下不会执行写命令;所谓不安全,是指从节点数量太少,或延迟过高。

例如 min-slaves-to-write 和 min-slaves-max-lag 分别是 3 和 10,含义是如果从节点数量小于 3 个,或所有从节点的延迟值都大于 10s,则主节点拒绝执行写命令。

而这里从节点延迟值的获取,就是通过主节点接收到 REPLCONF ACK 命令的时间来判断的,即前面所说的 info Replication 中的 lag 值。

应用中的问题

读写分离及其中的问题

在主从复制基础上实现的读写分离,可以实现 Redis 的读负载均衡。

由主节点提供写服务,由一个或多个从节点提供读服务(多个从节点既可以提高数据冗余程度,也可以最大化读负载能力);在读负载较大的应用场景下,可以大大提高 Redis 服务器的并发量。

下面介绍在使用 Redis 读写分离时,需要注意的问题。

延迟与不一致问题

YWSOS.COM 平台代运维解决方案

 评论
 发表评论
姓   名:

Powered by AKCMS