转自https://www.cnblogs.com/wind-snow/p/11396446.html

 

Redis 中，可以通过执行 savleof 命令或者设置 slaveof 选项，让一个服务器去复制另一个服务器，我们称被复制的服务器为主服务器，而对主服务器进行复制的服务器则被称为从服务器。

命令示例：   127.0.0.1:12345>SLAVEOF 127.0.0.1 6379

Redis 2.8 之前复制功能的实现

Redis 中的复制分为同步和命令传播两个操作。

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

同步

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

从服务器对主服务器的同步操作是通过向主服务器发送 sync 命令来完成，执行步骤如下：

  1. 从服务器向主服务器发送 sync 命令。
  2. 收到 sync 命令的主服务器执行 bgsave 命令，在后台生成一个 RDB 文件，并用一个缓冲区记录从现在开始执行的所有写命令。
  3. 当主服务器 BGSAVE 命令执行完毕时，主服务器会将 BGSAVE 命令生成的 RDB 文件发送给从服务器，从服务器接收并载入这个 RDB 文件，将自己的数据库状态更新至主服务器执行 BGSAVE 命令时的数据库状态。
  4. 主服务器将记录在缓冲区里面的所有写命令发送给从服务器，从服务器执行这些写命令，将自己的数据库状态更新至主服务器数据库当前所处的状态。
    sync 命令执行期间，主从服务器的通信过程如下图所示（出自《Redis设计与实现第二版》第十五章：复制）：

Redis--主从复制（Sync，PSYNC）

命令传播

命令传播是指：在同步之后，主服务器会将同步期间缓冲区保存的写命令，发送给从服务器执行，当从服务器执行了相同的写命令之后，主从服务器将再次回到一致状态。

Redis 2.8 之前复制功能的缺陷

在 Redis 中，从服务器对主服务器的复制分为两种情况：

  • 初次复制：从服务器以前没有复制过主服务器。
  • 断线后重新复制：从服务器因为网络原因中断了复制，但从服务器通过自动重连接重新连接上了主服务器，并继续复制主服务器。

对于初次复制来说，旧版复制功能能够很好的完成任务，但对于断线后重新复制来说，旧版复制功能虽然也能让主从服务器数据一致（重新发起SYNC请求,主服务器重新生成RDB文件进行同步），但效率却非常低（可能主从断开连接过程中主服务器只执行了一条写命令却要重新生成整个RDB文件，耗费CPU，再传输给从服务器，耗费网络带宽）。

Redis 2.8 之后复制功能的实现

为了解决旧版复制功能在处理断线重新复制情况下的低效问题，Redis 从 2.8 版本开始，使用 psync命令代替了 sync 命令来执行复制时的同步操作。

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

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

部分重同步的执行过程如下图所示（出自《Redis设计与实现第二版》第十五章：复制）：

Redis--主从复制（Sync，PSYNC）

部分重同步的实现

部分重同步功能包含三个部分：

  • 主服务器的复制偏移量和从服务器的复制偏移量。
  • 主服务器的复制积压缓冲区。
  • 服务器的运行 ID。

复制偏移量

执行复制的双方——主服务器和从服务器会分别维护一个复制偏移量。

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

对比主从服务器的复制偏移量可知：

  • 如果主从服务器的复制偏移量相等，则说明主从服务器数据一致；
  • 相反，如果主从服务器两者的偏移量不等，则说明主从服务器中的数据不一致。

复制积压缓冲区

复制积压缓冲区是由主服务器维护的一个固定长度的先进先出（FIFO）队列，默认大小为 1MB。

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

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

当从服务器重新连上主服务器时，从服务器会通过 PSYNC 命令将自己的复制偏移量， offset 发送给主服务器，主服务器会根据这个复制偏移量来决定对从服务器执行何种同步操作：

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

注意：建议根据下述公式调整复制积压缓冲区的大小为：2 * second * write_size_per_second

  • 其中 second 为从服务器断线后重新连接上主服务器所需的平均时间（单位秒）。
  • write_size_per_second 是主服务器平均每秒产生的写命令数据量。
  • 对应redis-service.conf的配置项repl-backlog-size

服务器运行 ID

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

当从服务器对主服务器进行初次复制时，主服务器会将自己的运行 ID 传送给从服务器，而从服务器会将这个运行 ID 保存起来，

当从服务器断线并重新连上主服务器时，从服务器将向当前连接的主服务器发送之前保存的运行 ID：

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

心跳检测

在命令传播阶段，从服务器默认会以每秒一次的频率，向主服务器发送命令：

REAPCONF ACK <replication_offset>

其中 replication_offset 是代表从服务器当前的复制偏移量。

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

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

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

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

辅助实现 min-slaves 选项

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

比如，如果我们向主服务器提供以下设置：

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

那么在从服务器的数量少于3个或者3个从服务器的延迟（lag）值都大于或等于 10s 时，主服务器将拒绝执行写命令。

检测命令丢失

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