redis 简单整理——复制的原理[二十三]

前言

简单介绍一下复制的原理。

正文

在从节点执行slaveof命令后，复制过程便开始运作，下面详细介绍建立复制的完整流程。

1）保存主节点（master）信息。

执行slaveof后从节点只保存主节点的地址信息便直接返回，这时建立复制流程还没有开始，在从节点6380执行info replication可以看到如下信息：

master_host:127.0.0.1 master_port:6379 master_link_status:down

从统计信息可以看出，主节点的ip和port被保存下来，但是主节点的连接状态（master_link_status）是下线状态。执行slaveof后Redis会打印如下日志：

SLAVE OF 127.0.0.1:6379 enabled (user request from 'id=65 addr=127.0.0.1:58090 fd=5 name= age=11 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free= 32768 obl=0 oll=0 omem=0 events=r cmd=slaveof')

通过该日志可以帮助运维人员定位发送slaveof命令的客户端，方便追踪和发现问题。

2）从节点（slave）内部通过每秒运行的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与该节点建立网络连接.

从节点会建立一个socket套接字，例如图6-8中从节点建立了一个端口为 24555的套接字，专门用于接受主节点发送的复制命令。从节点连接成功后打印如下日志：

* Connecting to MASTER 127.0.0.1:6379 

* MASTER <-> SLAVE sync started

如果从节点无法建立连接，定时任务会无限重试直到连接成功或者执行 slaveof no one取消复制

关于连接失败，可以在从节点执行info replication查看 master_link_down_since_seconds指标，它会记录与主节点连接失败的系统时间。从节点连接主节点失败时也会每秒打印如下日志，方便运维人员发现问题：

# Error condition on socket for SYNC: {socket_error_reason}

3）发送ping命令。

连接建立成功后从节点发送ping请求进行首次通信，ping请求主要目的如下：

·检测主从之间网络套接字是否可用。

·检测主节点当前是否可接受处理命令.

如果发送ping命令后，从节点没有收到主节点的pong回复或者超时，比如网络超时或者主节点正在阻塞无法响应命令，从节点会断开复制连接，下次定时任务会发起重连

从节点发送的ping命令成功返回，Redis打印如下日志，并继续后续复制流程：

Master replied to PING, replication can continue...

4）权限验证。如果主节点设置了requirepass参数，则需要密码验证，从节点必须配置masterauth参数保证与主节点相同的密码才能通过验证；如果验证失败复制将终止，从节点重新发起复制流程。

5）同步数据集。主从复制连接正常通信后，对于首次建立复制的场景，主节点会把持有的数据全部发送给从节点，这部分操作是耗时最长的步骤。Redis在2.8版本以后采用新复制命令psync进行数据同步，原来的sync命令依然支持，保证新旧版本的兼容性。

6）命令持续复制。当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。接下来主节点会持续地把写命令发送给从节点，保证主从数据一致性。

数据同步

Redis在2.8及以上版本使用psync命令完成主从数据同步，同步过程分为：全量复制和部分复制。

·全量复制：一般用于初次复制场景，Redis早期支持的复制功能只有全量复制，它会把主节点全部数据一次性发送给从节点，当数据量较大时，会对主从节点和网络造成很大的开销。

·部分复制：用于处理在主从复制中因网络闪断等原因造成的数据丢失场景，当从节点再次连上主节点后，如果条件允许，主节点会补发丢失数据给从节点。因为补发的数据远远小于全量数据，可以有效避免全量复制的过高开销。

部分复制是对老版复制的重大优化，有效避免了不必要的全量复制操作。因此当使用复制功能时，尽量采用2.8以上版本的Redis。

psync命令运行需要以下组件支持：

·主从节点各自复制偏移量。

·主节点复制积压缓冲区。

·主节点运行id。

1.复制偏移量

参与复制的主从节点都会维护自身复制偏移量。主节点（master）在处理完写入命令后，会把命令的字节长度做累加记录，统计信息在inforelication中的master_repl_offset指标中：

从节点（slave）每秒钟上报自身的复制偏移量给主节点，因此主节点也会保存从节点的复制偏移量，统计指标如下：

从节点在接收到主节点发送的命令后，也会累加记录自身的偏移量。统计信息在info relication中的slave_repl_offset指标中：

通过对比主从节点的复制偏移量，可以判断主从节点数据是否一致。

可以通过主节点的统计信息，计算出master_repl_offset-slave_offset字节量，判断主从节点复制相差的数据量，根据这个差值判定当前复制的健康度。如果主从之间复制偏移量相差较大，则可能是网络延迟或命令阻塞等原因引起。

2.复制积压缓冲区

复制积压缓冲区是保存在主节点上的一个固定长度的队列，默认大小为 1MB，当主节点有连接的从节点（slave）时被创建，这时主节点（master）响应写命令时，不但会把命令发送给从节点，还会写入复制积压缓冲区.

由于缓冲区本质上是先进先出的定长队列，所以能实现保存最近已复制数据的功能，用于部分复制和复制命令丢失的数据补救。复制缓冲区相关统计信息保存在主节点的info replication中：

根据统计指标，可算出复制积压缓冲区内的可用偏移量范围： [repl_backlog_first_byte_offset， repl_backlog_first_byte_offset+repl_backlog_histlen]。

每个Redis节点启动后都会动态分配一个40位的十六进制字符串作为运行ID。

运行ID的主要作用是用来唯一识别Redis节点，比如从节点保存主节点的运行ID识别自己正在复制的是哪个主节点。

如果只使用ip+port的方式识别主节点，那么主节点重启变更了整体数据集（如替换RDB/AOF文件），从节点再基于偏移量复制数据将是不安全的，因此当运行ID变化后从节点将做全量复制。

可以运行info server命令查看当前节点的运行ID：

需要注意的是Redis关闭再启动后，运行ID会随之改变，例如执行如下命令：

如何在不改变运行ID的情况下重启呢？

当需要调优一些内存相关配置，例如：hash-max-ziplist-value等，这些配置需要Redis重新加载才能优化已存在的数据，这时可以使用debug reload命令重新加载RDB并保持运行ID不变，从而有效避免不必要的全量复制。命令如下：

提示:debug reload命令会阻塞当前Redis节点主线程，阻塞期间会生成本地 RDB快照并清空数据之后再加载RDB文件。因此对于大数据量的主节点和无法容忍阻塞的应用场景，谨慎使用。

从节点使用psync命令完成部分复制和全量复制功能，命令格式： psync{runId}{offset}，参数含义如下：

runId：从节点所复制主节点的运行id。

offset：当前从节点已复制的数据偏移量。

1）从节点（slave）发送psync命令给主节点，参数runId是当前从节点保存的主节点运行ID，如果没有则默认值为，参数offset是当前从节点保存的复制偏移量，如果是第一次参与复制则默认值为-1。

2）主节点（master）根据psync参数和自身数据情况决定响应结果：

·如果回复+FULLRESYNC{runId}{offset}，那么从节点将触发全量复制流程。

·如果回复+CONTINUE，从节点将触发部分复制流程。

·如果回复+ERR，说明主节点版本低于Redis2.8，无法识别psync命令，从节点将发送旧版的sync命令触发全量复制流程。

全量复制

全量复制是Redis最早支持的复制方式，也是主从第一次建立复制时必须经历的阶段。触发全量复制的命令是sync和psync.

这里主要介绍psync全量复制流程，它与2.8以前的sync全量复制机制基本一致。

流程说明：

1）发送psync命令进行数据同步，由于是第一次进行复制，从节点没有复制偏移量和主节点的运行ID，所以发送psync-1。

2）主节点根据psync-1解析出当前为全量复制，回复+FULLRESYNC响应。

3）从节点接收主节点的响应数据保存运行ID和偏移量offset，执行到当前步骤时从节点打印如下日志：

Partial resynchronization not possible (no cached master) Full resync from master: 92d1cb14ff7ba97816216f7beb839efe036775b2:216789

4）主节点执行bgsave保存RDB文件到本地

主节点bgsave相关日志如下：

Redis3.0之后在输出的日志开头会有M、S、C等标识，对应的含义是： M=当前为主节点日志，S=当前为从节点日志，C=子进程日志，我们可以根据日志标识快速识别出每行日志的角色信息。

5）主节点发送RDB文件给从节点，从节点把接收的RDB文件保存在本地并直接作为从节点的数据文件，接收完RDB后从节点打印相关日志，可以在日志中查看主节点发送的数据量：

16:24:03.057 * MASTER <-> SLAVE sync: receiving 24777842 bytes from master

需要注意，对于数据量较大的主节点，比如生成的RDB文件超过6GB以上时要格外小心。传输文件这一步操作非常耗时，速度取决于主从节点之间网络带宽，通过细致分析Full resync和MASTER<->SLAVE这两行日志的时间差，可以算出RDB文件从创建到传输完毕消耗的总时间。如果总时间超过 repl-timeout所配置的值（默认60秒），从节点将放弃接受RDB文件并清理已经下载的临时文件，导致全量复制失败，此时从节点打印如下日志：

针对数据量较大的节点，建议调大repl-timeout参数防止出现全量同步数据超时。例如对于千兆网卡的机器，网卡带宽理论峰值大约每秒传输 100MB，在不考虑其他进程消耗带宽的情况下，6GB的RDB文件至少需要60秒传输时间，默认配置下，极易出现主从数据同步超时。

关于无盘复制：为了降低主节点磁盘开销，Redis支持无盘复制，生成的RDB文件不保存到硬盘而是直接通过网络发送给从节点，通过repl- diskless-sync参数控制，默认关闭。无盘复制适用于主节点所在机器磁盘性能较差但网络带宽较充裕的场景。注意无盘复制目前依然处于试验阶段，线上使用需要做好充分测试。

6）对于从节点开始接收RDB快照到接收完成期间，主节点仍然响应读写命令，因此主节点会把这期间写命令数据保存在复制客户端缓冲区内，当从节点加载完RDB文件后，主节点再把缓冲区内的数据发送给从节点，保证主从之间数据一致性。如果主节点创建和传输RDB的时间过长，对于高流量写入场景非常容易造成主节点复制客户端缓冲区溢出。

默认配置为client- output-buffer-limit slave256MB64MB60，如果60秒内缓冲区消耗持续大于 64MB或者直接超过256MB时，主节点将直接关闭复制客户端连接，造成全量同步失败。对应日志如下：

因此，运维人员需要根据主节点数据量和写命令并发量调整client- output-buffer-limit slave配置，避免全量复制期间客户端缓冲区溢出。

对于主节点，当发送完所有的数据后就认为全量复制完成，打印成功日志：Synchronization with slave127.0.0.1：6380succeeded，但是对于从节点全量复制依然没有完成，还有后续步骤需要处理。

7）从节点接收完主节点传送来的全部数据后会清空自身旧数据，该步骤对应如下日志：

8）从节点清空数据后开始加载RDB文件，对于较大的RDB文件，这一步操作依然比较耗时，可以通过计算日志之间的时间差来判断加载RDB的总耗时，对应如下日志：

对于线上做读写分离的场景，从节点也负责响应读命令。如果此时从节点正出于全量复制阶段或者复制中断，那么从节点在响应读命令可能拿到过期或错误的数据。

对于这种场景，Redis复制提供了slave-serve-stale-data参数，默认开启状态。

如果开启则从节点依然响应所有命令。

对于无法容忍不一致的应用场景可以设置no来关闭命令执行，此时从节点除了info和slaveof 命令之外所有的命令只返回“SYNC with master in progress”信息。

9）从节点成功加载完RDB后，如果当前节点开启了AOF持久化功能，它会立刻做bgrewriteaof操作，为了保证全量复制后AOF持久化文件立刻可用

通过分析全量复制的所有流程，读者会发现全量复制是一个非常耗时费力的操作。它的时间开销主要包括：

·主节点bgsave时间。

·RDB文件网络传输时间。

·从节点清空数据时间。

·从节点加载RDB的时间。

·可能的AOF重写时间

例如我们线上数据量在6G左右的主节点，从节点发起全量复制的总耗时在2分钟左右。因此当数据量达到一定规模之后，由于全量复制过程中将进行多次持久化相关操作和网络数据传输，这期间会大量消耗主从节点所在服务器的CPU、内存和网络资源。所以除了第一次复制时采用全量复制在所难免之外，对于其他场景应该规避全量复制的发生。正因为全量复制的成本问题，Redis实现了部分复制功能。

部分复制

部分复制主要是Redis针对全量复制的过高开销做出的一种优化措施，使用psync{runId}{offset}命令实现。当从节点（slave）正在复制主节点（master）时，如果出现网络闪断或者命令丢失等异常情况时，从节点会向主节点要求补发丢失的命令数据，如果主节点的复制积压缓冲区内存在这部分数据则直接发送给从节点，这样就可以保持主从节点复制的一致性。补发的这部分数据一般远远小于全量数据，所以开销很小。