Redis 复制过程详解

做者：程序员历小冰
原文：https://mp.weixin.qq.com/s/0VVYTyAI1egfs2Fxcrme3A复制代码

Redis 的复制功能分为同步( sync )和命令传播( command propagate )两个步骤：

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

同步

Redis 使用 psync 命令完成主从数据同步，同步过程分为：全量复制和部分复制。

全量复制：通常用于初次复制场景，它会把主节点所有数据一次性发送给从节点发送给从节点，当数据量较大时，会对主从节点和网络形成很大的开销。

部分复制：用于处理在主从复制中因网络闪断等缘由形成的网络丢失场景，当从节点再次链接上主节点后，若是条件容许，主节点会补发丢失数据给从节点。由于补发的数据远远小于全量数据，能够有效避免全量复制的太高开销。

psync 命令运行须要如下组件支持：

• 主从节点各自复制偏移量
• 主节点复制积压缓冲区
• 主节点运行 id

参与复制的从节点都会维护自身复制偏移量。主节点在处理完写命令后，会把命令的字节长度作累加记录，统计在 info replication 中的 masterreploffset 指标中。从节点在接收到主节点发送的命令后，也会累加记录自身的偏移量，而且会每秒钟上报自身的复制偏移量给主节点。经过对比主从节点的复制偏移量，能够判断主从节点数据是否一致。

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

复制积压缓冲区大小有限，只能保存最近的复制数据，用于部分复制和复制命令丢失时的数据补救。

每一个 Redis 节点启动后都会动态分配一个 40 位的十六进制字符串做为运行 ID。运行 ID 的主要做用是用来惟一标识 Redis 节点，好比说从节点保存主节点的运行 ID 来识别本身正在复制的是哪一个主节点。

全量同步

slaveof 命令的执行

• 1) 从节点发送 psync 命令进行数据同步，因为是第一次进行复制，从节点没有复制偏移量和主节点的运行ID，因此发送的命令是 PSYNC ? -1。
• 2) 主节点根据 PSYNC ? -1 解析出当前为全量复制，回复 + FULLRESYNC 响应。
• 3) 从节点接收主节点的响应数据保存运行 ID 和偏移量 offset。
• 4) 主节点执行 bgsave 保存 RDB 文件到本地，有关 RDB 的知识能够查看《Redis RDB 持久化详解》
• 5) 主节点发送 RDB 文件给从节点，从节点把接收的 RDB 文件保存在本地并直接做为从节点的数据文件，接收完 RDB 后从节点打印相关日志，能够在日志中查看主节点发送的数据量。

须要注意，对于数据量较大的主节点，好比生成的 RDB 文件超过 6GB 以上时要格外当心。若是传输 RDB 的时间超过 repl-timeout 所配置的值，从节点将发起接收 RDB 文件并清理已经下载的临时文件，致使全量复制失败。

• 6) 对于主节点开始保存 RDB 快照到从节点接收完成期间，主节点仍然响应读命令，所以主节点会把这期间写命令保存在复制客户端缓冲区内，当从节点加载完 RDB 文件后，主节点再把缓冲区内的数据发送给从节点，保证主从之间数据一致性。

若是主节点建立和传输 RDB 的时间过长，可能会出现主节点复制客户端缓冲区溢出。默认配置为 client-output-buffer-limit slave 256MB 64MB 60，若是60s内缓冲区消耗持续大于64MB或者直接超过256MB时，主节点将直接关闭复制客户端链接，形成全量同步失败。

• 7) 从节点接收完主节点传送来的所有数据后会清空自身旧数据，该步骤对应以下日志。
• 8) 从节点清空数据后开始加载 RDB 文件，对于加大的 RDB 文件，这一步操做依然比较耗时，能够经过计算日志之间的时间差来判断加载 RDB 的总耗时。
• 9) 收到 SYNC 命令的主服务器执行 BGSAVE 命令，在后台生成一个 RDB 文件，并使用一个缓冲区记录从如今开始执行的全部写命令。
• 10) 当主服务器的 BGSAVE 命令执行完毕时，主服务器会将 GBSAVE 命令生成的 RDB 文件发送给从服务器，从服务器接收并载入这个 RDB 文件，将本身的数据库状态更新至主服务器执行 BGSAVE 命令时的数据库状态。
• 11) 主服务器将记录在缓冲区里边的全部写命令发送给从服务器，从服务器执行这些写命令，将本身的数据库状态更新至主服务器数据库当前所处的状态。

经过分析全量复制的全部流程，读者会发现全量复制是一个很是耗时费力的操做。它时间开销主要包括：

• 主节点 bgsave 时间
• RDB 文件网络传输时间
• 从节点清空数据时间
• 从节点加载 RDB 的时间
• 可能的 AOF 重写时间

全量同步过程当中不只会消耗大量时间，还会进行屡次持久化相关操做和网络数据传输，这期间会大量消耗主从节点所在服务器的 CPU、内存和网络资源。因此，除了第一次复制是采用全量同步没法避免，其余场景应该规避全量复制，采起部分同步功能。

部分同步

部分复制主要是 Redis 针对全量复制的太高开销作出的一种优化措施，使用 psync {runId} {offset} 命令实现。当从节点正在复制主节点时，若是出现网络闪断或者命令丢失等异常状况时，从节点会向主节点要求补发丢失的命令数据，若是主节点的复制积压缓冲区存在这部分数据则直接发送给从节点，这样就保证了主从节点复制的一致性。补发的这部分数据通常远远小于全量数据，因此开销很小。

• 1) 当主从节点之间网络出现中断时，若是超过了 repl-timeout 时间，主节点会认为从节点故障并中断复制链接。
• 2) 主从链接中断期间主节点依然响应命令，但因复制链接中断命令没法发送给从节点，不过主节点内部存在复制积压缓冲区( repl-backlog-buffer )，依然能够保存最近一段时间的写命令数据，默认最大缓存 1MB。
• 3) 当主从节点网络恢复后，从节点会再次连上主节点。
• 4) 当主从链接恢复后，因为从节点以前保存了自身已复制的偏移量和主节点的运行ID。所以会把它们做为 psync 参数发送给主节点，要求进行补发复制操做。
• 5) 主节点接到 psync 命令后首先核对参数 runId 是否与自身一致，若是一致，说明以前复制的是当前主节点；以后根据参数 offset 在自身复制积压缓冲区查找，若是偏移量以后的数据存在缓冲区中，则对从节点发送 +CONTINUE 响应，表示能够进行部分复制。
• 6) 主节点根据偏移量把复制积压缓冲区里的数据发送给从节点，保证主从复制进入正常状态。

• 加q群：478052716 免费领取（Java架构资料，视频资料，BATJ面试资料）

心跳检测

主从节点在创建复制后，它们之间维护着长链接并彼此发送心跳命令，以下图所示。

主从心跳判断机制以下所示：

• 1) 主从节点彼此都有心跳检测机制，各自模拟成对方的客户端进行通讯，经过 client list 命令查看复制相关客户端信息，主节点的链接状态为 flags=M，从节点链接状态为 flags=S。
• 2) 主节点默认每隔 10 秒对从节点发送 ping 命令，判断从节点的存活性和链接状态。能够经过参数 repl-ping-slave-period 控制发送频率。
• 3) 从节点在主线程中每隔 1 秒发送 replconf ack { offset } 命令，给主节点上报本身当前的复制偏移量。

replconf 命令不只能实时监测主从节点网络状态，还能上报从节点复制偏移量。主节点会根据从节点上传的偏移量检查复制数据是否丢失，若是从节点数据丢失，再从主节点的复制缓存区中拉取丢失的数据发送给该从节点。

异步复制和命令传播

主节点不但负责数据读写，还负责把写命令同步给从节点。写命令的发送过程是异步完成，也就是说主节点自身处理完写命令后直接返回给客户端，并不等待从节点复制完成。

这个异步过程由命令传播来处理，它不只会将写命令发送给全部从服务器，还会将写命令入队到复制积压缓冲区里边。