Redis的数据复制过程详解

怎么入门数据库编程？需要学习哪些知识点？这是新手们刚接触编程时常见的问题；下面golang学习网就来给大家整理分享一些知识点，希望能够给初学者一些帮助。本篇文章就来介绍《Redis的数据复制过程详解》，涉及到复制、redis数据，有需要的可以收藏一下

介绍 Redis 的复制

Redis 的复制功能分为同步（sync）和命令传播（command propagate）这两个操作

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

如果主从服务器双方的数据库保存相同的数据，我们称主从服务器的数据库状态一致

当从服务器第一次连接主服务器时，Redis 使用全量复制进行数据同步。

当从服务器在断线后重新连接主服务器时，Redis 使用增量复制进行数据同步。

完整重同步

全量复制，也被称为完整重同步。

当客户端向从服务器发送 slaveof 命令，要求从服务器复制主服务器时，从服务器首先需要执行同步操作，将从服务器的数据库状态更新至主服务器当前所处的数据库状态。

从服务器对主服务器的完整重同步操作，需要通过向主服务器发送 psync 命令来完成。psync 的命令为：psync ? -1

psync 命令在完整重同步模式下的的执行步骤：让主服务器创建并发送 RDB 文件，以及主服务器向从服务器发送保存在缓冲区里面的写命令来进行同步。

• 从服务器向主服务器发送 psync 命令。
• 主服务器收到 psync 命令后，主服务器执行 bgsave 命令，在后台生成一个 RDB 文件，并使用一个缓冲区（replication buffer）记录从现在开始执行的所有写命令。
• 主服务器给从服务器同步数据：当主服务器的 bgsave 命令执行完毕时，主服务器会将 bgsave 命令生成的 RDB 文件发送给从服务器，从服务器接收并载入这个 RDB 文件，将自己的数据库状态更新至主服务器执行 bgsave 命令时的数据库状态。
• 主服务器给从服务器发送缓冲区里面的所有写命令：主服务器将记录在缓冲区里面的所有写命令发送给从服务器， 从服务器执行这些写命令，将自己的数据库状态更新至主服务器数据库当前所处的状态。

需要注意的是：

从库在开始和主库进行数据复制前，可能保存了其他数据。为了避免之前数据的影响，从库在收到主库发送的 RDB 文件后，会先把自己当前的数据库清空。

介绍 偏移量 & 积压缓冲区 & 运行ID

部分重同步功能通过以下三个部分来实现：

• 主服务器的复制偏移量 和 从服务器的复制偏移量（replication offset）
• 主服务器的复制积压缓冲区（replication backlog buffer）
• 服务器的运行 ID（run ID）

复制偏移量

主服务器和从服务器会分别维护一个复制偏移量：

• 主服务器每次向从服务器传播 N 个字节的数据时，就将自己的复制偏移量的值加上 N。
• 从服务器每次收到主服务器传播来的 N 个字节的数据时，就将自己的复制偏移量的值加上 N。

通过对比主从服务器的复制偏移量，程序可以很容易地知道主从服务器是否处于一致状态：

• 如果主从服务器两者的偏移量总是相同，那么说明主从服务器处于一致状态。
• 如果主从服务器两者的偏移量并不相同，那么说明主从服务器并未处于一致状态。

复制积压缓冲区

复制积压缓冲区（repl_backlog_buffer）是由主服务器维护的一个固定长度的先进先出（FIFO）队列。

固定指的是，当入队元素的数量大于队列长度时，最先入队的元素会被弹出，而新元素会被放入队列。或者理解复制积压缓冲区为一个环形缓冲区。

当主服务器进行命令传播时，它不仅会将写命令发送给所有从服务器，还会将写命令入队到复制积压缓冲区里面。

因此，主服务器的复制积压缓冲区里面会保存着一部分最近传播的写命令，并且复制积压缓冲区会为队列中的每个字节记录相应的复制偏移量。

当从服务器在断线后重新连接主服务器时，从服务器会通过 psync 命令将自己的复制偏移量 offset 发送给主服务器，主服务器会根据这个复制偏移量来决定对从服务器执行完整重同步还是部分重同步操作：

• 如果 offset 偏移量之后的数据（也即是偏移量 offset+1 开始的数据）仍然存在于复制积压缓冲区里面，那么主服务器将对从服务器执行部分重同步操作。
• 如果 offset 偏移量之后的数据已经不存在于复制积压缓冲区，那么主服务器将对从服务器执行完整重同步操作。

复制积压缓冲区的大小

Redis 为复制积压缓冲区设置的默认大小为 1MB，如果主服务器需要执行大量的写命令，又或者主从服务器断线后重连接所需的时间比较长，那么这个大小也许并不合适。我们可以通过 repl-backlog-size 选项修改复制积压缓冲区的大小。

如果复制积压缓冲区的大小设置得不恰当，那么 psync 命令的部分重同步复制就不能正常发挥作用。因此，正确估算和设置复制积压缓冲区的大小非常重要。

为了保证主从服务器断线并重连接后可以使用部分重同步功能，我们需要保证复制积压缓冲区的大小足够大。复制积压缓冲区的最小大小可以根据公式 second * write_size_per_second 来估算：

• second 是从服务器断线后重新连接上主服务器所需的平均时间（以秒计算）。
• write_size_per_second 是主服务器平均每秒产生的写命令数据量（协议格式的写命令的长度总和）。

例如，如果主服务器平均每秒产生1 MB的写数据，而从服务器断线之后平均要 5 秒才能重新连接上主服务器，那么复制积压缓冲区的大小就不能低于 5 MB。

为了安全起见，可以将复制积压缓冲区的大小设为： 2 * second * write_size_per_second，这样可以保证绝大部分断线情况都能用部分重同步来处理。

服务器运行 ID

每个 Redis 服务器，不论主服务器还是从服务，都会有自己的运行 ID。运行 ID 在服务器启动时自动生成，由 40 个随机的十六进制字符组成，例如：53b9b28df8042fdc9ab5e3fcbbbabff1d5dce2b3。

当从服务器对主服务器进行初次复制时，主服务器会将自己的运行 ID 发送给从服务器，而从服务器会将主服务器的这个运行 ID 保存起来。 当从服务器断线并重新连上一个主服务器时，从服务器将向当前连接的主服务器发送之前保存的主服务器的运行 ID：

• 如果从服务器保存的主服务器的运行 ID 和当前连接的主服务器的运行 ID 相同，那么说明从服务器断线之前复制的就是当前连接的这个主服务器， 主服务器可以继续尝试执行部分重同步操作。
• 如果从服务器保存的主服务器的运行 ID 和当前连接的主服务器的运行 ID 并不相同，那么说明从服务器断线之前复制的主服务器并不是当前连接的这个主服务器，主服务器将对从服务器执行完整重同步操作。

部分重同步

增量复制，也被称为部分重同步。

在 Redis 中，从库对主库的复制可以分为以下两种情况：

• 初次复制：从库以前没有复制过任何主库，或者从库当前要复制的主服务器和上一次复制的主服务器不同。
• 网络断线重连后复制：处于命令传播阶段的主从库因为网络原因而中断了复制，但从库通过自动重连接重新连上了主库，并继续复制主服。

在 Redis 2.8 之前，如果主从库在命令传播时出现了网络中断，那么在断线重连后，从库会和主库重新进行一次全量复制，开销非常大。

从 2.8 版本开始，Redis 引入了部分重同步功能。部分重同步指的是，从服务器只同步主服务器的部分数据。当从服务器在断线后重新连接主服务器时，如果条件允许，主服务器可以将主从服务器连接断开期间执行的写命令发送给从服务器，从服务器只要接收并执行这些写命令，就可以将数据库更新至主服务器当前所处的状态。

执行部分重同步是有前提条件的。

• offset 偏移量
• 运行 ID

当从服务器对主服务器进行初次复制时，主服务器会将自己的运行 ID 发送给从服务器，而从服务器会将主服务器的这个运行 ID 保存起来。 当从服务器断线并重新连上一个主服务器时，从服务器会通过 psync 命令将自己的复制偏移量 offset 和 之前保存的主服务器的运行 ID 发送给主服务器。

主服务器会根据这个复制偏移量 和 运行ID 来决定对从服务器执行完整重同步还是部分重同步操作：

• 如果从服务器保存的主服务器的运行 ID 和当前连接的主服务器的运行 ID 相同，那么说明从服务器断线之前复制的就是当前连接的这个主服务器， 主服务器可以继续尝试执行部分重同步操作。
• 如果从服务器保存的主服务器的运行 ID 和当前连接的主服务器的运行 ID 并不相同，那么说明从服务器断线之前复制的主服务器并不是当前连接的这个主服务器，主服务器将对从服务器执行完整重同步操作。
• 如果 offset 偏移量之后的数据（也即是偏移量 offset+1 开始的数据）仍然存在于复制积压缓冲区里面，那么主服务器将对从服务器执行部分重同步操作。
• 如果 offset 偏移量之后的数据已经不存在于复制积压缓冲区，那么主服务器将对从服务器执行完整重同步操作。

从服务器对主服务器的部分重同步操作，需要通过向主服务器发送 psync 命令来完成。psync 命令为：psync

psync 命令

从服务器对主服务器的同步操作，需要通过向主服务器发送 psync 命令来完成。

psync 命令具有完整重同步（full resynchronization）和部分重同步 （partial resynchronization）两种模式：

• 完整重同步用于，处理初次复制情况；
• 部分重同步用于，处理断线后重复制情况：当从服务器在断线后重新连接主服务器时，如果条件允许，主服务器可以将主从服务器连 接断开期间执行的写命令发送给从服务器，从服务器只要接收并执行这 些写命令，就可以将数据库更新至主服务器当前所处的状态。

psync 命令的调用方法有两种：

• 如果从服务器以前没有复制过任何主服务器，或者之前执行过 slaveof no one 命令，那么从服务器在开始一次新的复制时将向主服务器发送 psync ? -1 命令，主动请求主服务器进行完整重同步。
• 如果从服务器已经复制过某个主服务器，那么从服务器在开始一次新的复制时将向主服务器发送 psync 命令：其中 runid 是上一次复制的主服务器的运行 ID，而 offset 则是从服务器当前的复制偏移量，接收到这个命令的主服务器会通过这两个参数来判断应该对从服务器执行哪种同步操作。

根据情况，接收到 psync 命令的主服务器会向从服务器返回以下三种回复的其中一种：

• 如果主服务器返回 +fullresync 回复，那么表示主服务器将与从服务器执行完整重同步操作：其中 runid 是这个主服务器的运行 ID，从服务器会将这个 ID 保存起来，在下一次发送 psync 命令时使用；而 offset 则是主服务器当前的复制偏移量，从服务器会将这个值作为自己的初始化偏移量。
• 如果主服务器返回 +continue 回复，那么表示主服务器将与从服务器执行部分重同步操作，从服务器只要等着主服务器将自己缺少的那部分数据发送过来就可以了。
• 如果主服务器返回 -err 回复，那么表示主服务器的版本低于 Redis2.8，它识别不了 psync 命令，从服务器将向主服务器发送 sync 命令，并与主服务器执行完整同步操作。

命令传播

主服务器通过向从服务器传播命令来更新从服务器的状态，保持主从服务器一致。

当完成了同步之后， 主从服务器就会进入命令传播阶段， 这时主服务器只要一直将自己执行的写命令发送给从服务器， 而从服务器只要一直接收并执行主服务器发来的写命令， 就可以保证主从服务器一直保持一致了。

主服务器进行命令传播时，它不仅会将写命令发送给所有从服务器，还会将写命令入队到复制积压缓冲区里面。

心跳检测

从服务器通过向主服务器发送命令来进行心跳检测，以及命令丢失检测。

在命令传播阶段，从服务器默认会以每秒一次的频率，向主服务器发送命令：replconf ack 。其中 replication_offset 是从服务器当前的复制偏移量。

发送 replconf ack 命令对于主从服务器有三个作用：

• 检测主从服务器的网络连接状态。
• 辅助实现 min-slaves 选项。
• 检测命令丢失。

检测主从服务器的网络连接状态。

主从服务器可以通过发送和接收 replconf ack 命令来检查两者之间的网络连接是否正常：如果主服务器超过一秒钟没有收到从服务器发来的 replconf ack 命令，那么主服务器就知道主从服务器之间的连接出现问题了。

通过向主服务器发送 info replication 命令，在列出的从服务器列表的 lag 一栏中，我们可以看到相应从服务器最后一次向主服务器发送 replconf ack 命令距离现在过了多少秒。在一般情况下，lag 的值应该在 0 秒或者 1 秒之间跳动，如果超过 1 秒的话，那么说明主从服务器之间的连接出现了故障。

辅助实现 min-slaves 选项。

Redis 的 min-slaves-to-write 和 min-slaves-max-lag 两个选项可以防止主服务器在不安全的情况下执行写命令。

举个例子，如果我们向主服务器提供以下设置：

• min-slaves-to-write 3
• min-slaves-max-lag 10

那么在从服务器的数量少于 3 个，或者 3 个从服务器的延迟（lag）值都 ≥ 10 秒时，主服务器将拒绝执行写命令，这里的延迟值就是上面提到的 info replication 命令的 lag 值。

检测命令丢失。

如果因为网络故障，主服务器传播给从服务器的写命令在半路丢失，那么当从服务器向主服务器发送 replconf ack 命令时，主服务器将发觉从服务器当前的复制偏移量少于自己的复制偏移量，然后主服务器就会根据从服务器提交的复制偏移量，在复制积压缓冲区里面找到从服务器缺少的数据，并将这些数据重新发送给从服务器。

参考资料

《Redis设计与实现》

本篇关于《Redis的数据复制过程详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于数据库的相关知识，请关注golang学习网公众号！