Redis主从复制原理

Note

本文基于 Redis 5，其 slave 名词和配置项已经被官方改为 replica，都指从节点。

Redis复制

在生产环境中，Redis通过持久化功能（RDB和AOF技术）保证了即使在服务器重启的情况下也不会损失（或少量损失）数据。但是由于数据是存储在一台服务器上的，如果这台服务器出现硬盘故障等问题（生产环境中多次遇到），也会导致数据丢失，为了避免单点故障，通常的做法是将数据库复制多个副本以部署在不同的服务器上，这样即使有一台服务器出现故障，其他服务器依然可以以最快的速度提供服务。为此，Redis提供了复制（replication）功能，可以实现当一台数据库中的数据更新后，自动将更新的数据同步到其他数据库上。

在复制的概念中，数据库分为两类，一类是主数据库（master），另一类是从数据库（slave）。主数据库可以进行读写操作，当写操作导致数据变化时自动将数据同步给从数据库。而从数据库一般是只读的，并接受主数据库同步过来的数据。一个主数据库可以拥有多个从数据库。

Redis 复制很简单易用，它通过配置允许slave Redis Servers或者Master Servers的复制品。接下来有几个关于redis复制的非常重要特性：

• 一个Master可以有多个Slaves。
• Slaves能通过和其他slave的链接，除了可以接受同一个master下面slaves的链接以外，还可以接受同一个结构图中的其他slaves的链接。
• redis复制是在master段是非阻塞的，这就意味着master在同一个或多个slave端执行同步的时候还可以接受查询。
• 复制在slave端也是非阻塞的，假设你在redis.conf中配置redis这个功能，当slave在执行的新的同步时，它仍可以用旧的数据信息来提供查询，否则，你可以配置当redis slaves去master失去联系是，slave会给发送一个客户端错误。
• 为了有多个slaves可以做只读查询，复制可以重复2次，甚至多次，具有可扩展性（例如：slaves对话与重复的排序操作，有多份数据冗余就相对简单了）。
• 通过复制可以避免master全量写硬盘的消耗：只要配置 master 的配置文件redis.conf来“避免保存”（注释掉所有”save”命令），然后连接一个用来持久化数据的slave即可。但是这样要确保masters 不会自动重启（更多内容请阅读下段）

Redis复制配置

在Redis中使用复制功能非常容易，只需要在从数据库的配置文件中加入“slaveof 主数据复制 主数据库端口”即可。主数据库无需进行任何配置。下面先来看看一个最简化的复制系统，我们在一台服务器上启动两个redis示例，监听在不同的端口，其中一个作为主数据库，另一个作为从数据库。首先我们不加任何参数来启动一个redis实例作为主数据库：

该实例默认监听6379端口，然后加上slaveof参数启动另一个redis实例作为从数据库，并让其监听6380端口：

查看一下实例的启动情况：

此时在主数据库中的任何数据变化都会自动同步到从数据库中，我们打开redis-cli实例A并连接到数据库：

再打开redis-cli实例B并连接到从数据库：

这时我们使用INFO命令来分别在实例A和实例B中获取replication的相关信息。

可以看到，实例A的角色（role）是master，即主数据库，同时已连接的从数据库（connectd_slaves）的个数为1个。

同样在实例B中获取响应的信息为：

可以看到，实例B的role是slave，即从数据库，同时其主数据库的地址为127.0.0.1，端口为6379。

然后我们在实例A中使用SET命令设置一个键的值：

此时在实例B中就可以获得该值了：

证明两个Redis实例的复制功能已经可用了。默认情况，从数据库是只读的，如果直接修改从数据库的数据会出现错误，如下：

但也可以通过设置从数据库的配置文件中的slave-read-only=no，以使从数据库可写，但是因为对从数据库的任何更改都不会同步给任何其他数据库，并且一旦主数据库中的更新了赌赢的数据就会覆盖从数据库中的改动，所以通常场景下不应该设置从数据库可写，以免导致易被忽略的潜在应用逻辑错误。

配置多台从数据库的方法也一样，在所有的从数据库的配置文件中都加上salveof参数指向同一个主数据库即可。除了通过配置文件或命令行参数设置slaveof参数外，还可以在运行时使用slaveof命令修改，下面我们再添加一个实例C（6381）：

如果该数据库已经是其他主数据库的从数据库了，slaveof命令会停止和原来数据库的同步转而和新数据库同步，此外对于从数据库来说，还可以使用slaveof no one命令来使当前数据库停止接收其他数据库的同步并转换成为主数据库。如下测试，在从库实例C上写入数据时时不允许的，然后使用slaveof no one将此数据库转换为主数据库，然后再写入数据就没有问题了。一般用于但主节点挂掉的时候，立刻把从节点切换为主节点提供数据操作服务。

复制常用参数

slaveof <masterip> <masterport>

将当前server做为slave，并为其指定master信息。

masterauth <master-password>

以认证的方式连接到master，如果master中使用了”密码保护”，slave必须交付正确的授权密码，才能连接成功。”requirepas”配置项指定了当前server的密码。此配置项中<master-password>值需要和master机器的”requirepas”保持一致。此参数配置在slave端。

slave-serve-stale-data yes

如果当前server是slave，那么当slave与master失去通讯时，是否继续为客户端提供服务，”yes”表示继续,”no”表示终止。在”yes”情况下，slave继续向客户端提供只读服务，有可能此时的数据已经过期。在”no”情况下，任何向此server发送的数据请求服务(包括客户端和此server的slave)都将被告知”error”。

slave-read-only yes

slave是否为”只读”，强烈建议为”yes”。

repl-ping-slave-period 10

slave向指定的master发送ping消息的时间间隔(秒)，默认为10。

repl-timeout 60

slave与master通讯中，最大空闲时间，默认60秒，超时将导致连接关闭。

repl-disable-tcp-nodelay no

slave与master的连接，是否禁用TCP nodelay选项。”yes”表示禁用，那么socket通讯中数据将会以packet方式发送(packet大小受到socket buffer限制)，可以提高socket通讯的效率(tcp交互次数)，但是小数据将会被buffer，不会被立即发送，对于接受者可能存在延迟。”no”表示开启tcp nodelay选项，任何数据都会被立即发送，及时性较好，但是效率较低。建议为”no”。

slave-priority 100

适用Sentinel模块(unstable，M-S集群管理和监控)，需要额外的配置文件支持。slave的权重值，默认100。当master失效后，Sentinel将会从slave列表中找到权重值最低(>0)的slave，并提升为master。如果权重值为0，表示此slave为”观察者”，不参与master选举。

Redis复制原理

了解 Redis 复制的原理对运维 Redis 过程中有很大的帮助，包括如何规划节点，如果处理节点故障等。

master 与 replica 复制的基本流程

当 master 和 replica 连接稳定时，master 持续进行增量同步（partial resync），发送增量数据给 replica，replica 接受到数据后更新自己的数据，并以每秒 REPLCONF ACK PING 给 master 报告处理的情况。

如果 replica 与 master 断开再重连时，replica 尝试发送 PSYNC 命令给 master，如果条件满足（比如引用的是已知的历史副本，或 backlog 积压足够）则触发继续增量同步（partial resync）。否则将触发一次 master 向该 replica 全量同步（full resync）。

从以上基本流程中，我们可以看出来如果网络存在问题，我们可以会导致全量同步（full resync），这样会严重影响从replica追赶master的数据进度。 那么如何解决呢？ 可以从两个方面：主从响应时间策略、主从空间堆积策略。

主从响应时间策略

1. 每 repl-ping-replica-period（默认值 10s）秒 PING 一次 master，检测 master 是否挂了。
2. replica 和 master 之间的复制超时时间，默认为60s。
   1. replica 角度，在全量同步 SYNC 期间，没有收到 master 传输的 RDB 数据。
   2. replica 角度，没有收到 master 发送的数据包或者 replica 发送的 PING 响应。
   3. master 角度，没有收到 replica 的 REPCONF ACK PINGs（复制偏移量 offset），当 Redis 检测到 repl-timeout 超时（默认值 60s），将会关闭主从之间的连接，replica 发起重新建立主从连接的请求。

主从空间堆积策略

master 在接受数据写入后，会写到 replication buffer（这个主要用于主从复制的数据传输缓冲），同时也写到 replication backlog（复制积压缓冲）。 当 replica 断开重连 PSYNC （包含 replication ID，和目前已处理的 offset），如果 replication backlog 中可以找到历史副本，则触发增量同步（partial resync），否则将触发 一次 master 向该 replica 全量同步（full resync）。

replication backlog

设置复制积压（replication backlog）的大小，backlog 是一个缓冲区，当复制体断开连接一段时间后，它将积累复制数据的缓冲区，这样当一个复制想重新连接时，往往不需要完全重新同步，而只需要部分重新同步就够了，只需要传递复制在断开连接时错过的那部分数据即可。断开的数据。

复制积压缓冲越大，那么支持复制体断开的时间就可以越久，执行部分重新同步。

只有在至少一个 replica 连接的情况下，才会分配 replication backlog 空间。

即当所有主从数据库与主数据断开连接后，经过多久时间可以释放积压队列的内存空间，默认时间是1小时。

当一个 replica 启动后，会向 master 发送 PSYNC 命令。

Redis 从 2.8 版本开始，使用 PSYNC 命令代替 SYNC 命令来执行复制时的同步操作。PSYNC 命令具有完整重同步（full resynchronization）和部分重同步（partial resynchronization）两种模式。PSYNC 命令的部分重同步模式解决了旧版复制功能在处理断线后重复制时出现的低效情况。

其中完整重同步用于处理初次复制情况：完整重同步的执行步骤和 SYNC 命令的执行步骤基本一样，它们都是通过让主服务器创建并发送 RDB 文件，以及向从服务器发送保存在缓冲区里面的写命令来进行同步。

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

master 接收到 PSYNC 命令后会开始在后台保存快照（即 RDB 持久化的过程），并将保存快照期间接收到的命令缓存起来，当快照完成后，master 会将快照文件发送给 replica 数据库，replica 收到后，会载入快照文件。之后 master 会以 Redis 命令协议的格式，将写命令缓冲区中积累的所有内容都发送给 replica 服务器。以上过程称为复制初始化，复制初始化结束后，主数据库每当收到写命令时就会将命令同步给从数据库，从而保证主从数据库数据一致。

你可以通过 telnet 命令来亲自验证这个同步过程：首先连上一个正在处理命令请求的 Redis 服务器，然后向它发送 SYNC 命令，过一阵子，你将会看到 telnet 会话接收到服务器发来的大段数据（RDB文件），之后还会看到，所有的服务器执行过的写命令，都会重新发送到 telnet 会话来。

当主从数据库之间的连接断开重连后，Redis 2.6 以及之前的版本会重新进行复制初始化（即主数据库重新保存快照并传送给从数据库），即使从数据库可以仅有几条命令没有收到，主数据库也必须要将数据库里的所有数据重新传送给从数据库。这使得主从数据库断线重连后的数据恢复过程效率很低下，在网络环境不好的时候这一问题尤其明显，Redis 2.8 版本的一个重要改进就是断线重连能够支持有条件的增量数据传输，当从数据库重新连接上主数据库后，主数据库只需要将断线期间执行的命令传送给从数据库，从而大大提高Redis复制的实用性。

full resynchronization 全量同步工作流程

1. replica 发送向 maser 发送 PSYNC。（假设满足全量同步的条件）
2. master 通过子进程处理全量同步，子进程通过 BGSAVE 命令，fork 一个子进程写入快照 dump.rdb。同时，master 开始缓冲从客户端收到的所有新写命令到 replication buffer。
3. master 子进程通过网卡传输  rdb 数据给 replica。
4. replica 保存 rdb 数据到磁盘，然后加载到内存（删除旧数据，并阻塞加载新数据）。
5. 后续就是部分重同步。

partial resynchronization 部分重同步工作流程

部分重同步的实现，基于由以下三个部分构成：

1. Redis 实例的运行ID（run id）。
2. master 的复制积压缓冲区（replication backlog）。
3. master 和 replica 记录的偏移量。

这三点是实现部分重同步的基础，当主从连接准备就绪后，从数据库会发送一条 PSYNC 命令来告诉主数据库可以开始同步数据了。PSYNC 命令的格式为“PSYNC 主数据库的运行ID 断开前最新的命令偏移量”。主数据库收到 PSYNC 命令后，会判断此次重连是否可以执行部分重同步以及如何执行部分重同步。

服务器运行ID

除了复制偏移量和复制积压缓冲区之外，实现部分重同步还需要用到服务器运行ID（run ID）：

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

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

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

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

master 和 replica 记录的偏移量

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

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

假设从服务器断线之后立即重新连到主服务器，并且成功。那么接下来，从服务器将向主服务器发送 PSYNC 命令，报告从服务器当前的复制偏移量，主服务器收到后对比自身的复制偏移量，如果一致则表示两者数据一致，随后进行部分重同步即可。如果主服务器偏移量大于从服务器偏移量，那么这时主服务器应该对从服务器执行完全重同步还是部分重同步呢？如果执行部分重同步的话，主服务器又该如何补偿从服务器在断线期间丢失的那部分数据呢？这个问题就是主服务器的复制积压缓冲区有关了。

master 复制积压缓冲区

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

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

因此，主服务器的复制积压缓冲区里面会保存着一部分最近传播的写命令，并且复制积压缓冲区会为队列中的每个字节记录相应的复制偏移量。当从服务器重新连上主服务器时，从服务器会通过 PSYNC 命令将自己的复制偏移量 offset 发送给主服务器，主服务器会根据这个复制偏移量来决定对从服务器执行何种同步操作：

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

积压队列在本质上是一个固定长度的循环队列，默认情况下积压队列的大小为1MB，可以通过配置文件的repl-backlog-size选项来调整。很容易理解的是，积压队列越大，其允许的主从数据库断线的时间就越长。根据主从数据库之间的网络状态，设置一个合理的积压队列很重要。因为积压队列存储的内容是命令本身，如 SET FOO BAR，所以估算积压队列的大小只需要估计主从数据库断线的时间中主从数据库可能执行的命令的大小即可。与积压队列相关的另一个配置选项是repl-backlog-ttl，即当所有主从数据库与主数据断开连接后，经过多久时间可以释放积压队列的内存空间，默认时间是1小时。

主从数据一致性

master 默认采用异步复制，意思是客户端写入命令，master 需要自己确认，并且确认至少有 N 个副本，并且延迟少于 M 秒，则将接受写入，否则返回错误。

另外客户端可以使用WAIT命令类似 ACK 机制，能确保其他 Redis 实例中具有指定数量的已确认副本。

故障转移

replication ID 的作用主要是标识来自当前 master 的数据集标识。replication ID 有两个：master_replid，master_replid2

当 master 挂了，其中一个 replica 升级为 master，它将开启一个新纪元，生成新的 replication ID：master_replid 同时旧的 master_replid 设置到 master_replid2。

这样其他 replica 连接新的 master 就不需要又来一次全量同步，可以继续副本同步完，再使用新的纪元数据。

replica 如何处理已过期的 Key？

• replica 不主动让已过期的 key 被删除掉，只有当 master 通过 LRU 等内存淘汰策略或主动访问过期，合成 DEL 命令给到 replica，replica 才会删掉它。
• 以上存在一个时间差，replica 内部采用逻辑时钟，当客户端尝试读取一个过期 key 的时候，replica 会报告不存在。

replica 持久化

另一个相对耗时的操作是持久化，为了提高性能，可以通过复制功能建立一个或多个从数据库，并在从数据库中启用持久化，同时在主数据库禁用持久化，当从数据库崩溃重启后主数据库会自动将时间同步过来，所以无需担心数据丢失。

然后当主数据库崩溃时，情况就稍显复杂了。手工通过从数据库数据恢复主数据库数据时，需要严格按照以下两步进行：

1）在从数据库中使用SLAVEOF NO ONE命令将从数据库提升为主数据库继续服务。

2）启动之前崩溃的主数据库，然后使用SLAVEOF命令将其设置成新的主数据库的从数据库，即可将数据同步回来。

注意，当开启复制且主数据库关闭持久化的时候，一定不要使用supervisor以及类似的进程管理工具令主数据库崩溃后自动重启。同样当主数据库所在的服务器因故关闭时，也要避免直接重新启动。这是因为当主数据库重新启动后，因为没开持久化功能，所以数据库中所有数据都被清空，这时从数据库依然会从主数据库中接收数据，使得所有从数据库也被清空，导致从数据库的持久化失去意义。

无论哪种情况，手工维护从数据库或主数据的重启以及数据恢复都相对麻烦，好在Redis提供了一种自动化方案哨兵来实现这一过程，避免了手工维护的麻烦和容易出错的问题。

无盘复制

上面介绍了Redis复制的工作原理时介绍了复制是基于RDB方式的持久化实现的，即主数据库端在后台保存了RDB快照，从数据库端则接收并载入快照文件，这样的实现有点是可以显著地简化逻辑，复用已有的代码，但是缺点也很明显。

1）当主数据库禁用RDB快照时（即删除了所有的配置文件中的save语句），如果执行了复制初始化操作，Redis依然会生成RDB快照，所以下次启动后主数据库会以该快照恢复数据。因为复制发生的时间不能确定，这使得恢复的数据可能是任何时间点的。

2）因为复制初始化时需要在硬盘中创建RDB快照文件，所以如果硬盘性能很慢时这一过程会对性能产生影响。举例来说，当使用Redis做缓存系统时，因为不需要持久化，所以服务器的硬盘读写速度可能较差。但是当该缓存系统使用一主多从的集群架构时，每次和从数据库同步，Redis都会执行一次快照，同时对硬盘进行读写，导致性能下降。

因此从2.8.18版本开始，Redis引入了无硬盘复制选项，开启该选项时，Redis在与从数据库进行复制初始化时将不会将快照内容存储到硬盘上，而是直接通过网络发送给从数据库，避免了硬盘的性能瓶颈。可以在配置文件中使用如下配置来开启该功能：

PS：当需要把Slave转换为Master时可以使用”SLAVEOF ON ONE”指令。

<参考>

https://redis.io/topics/replication

https://cloud.tencent.com/developer/article/1633541

喜欢 (2)赏

[资助本站您就扫码 谢谢]

分享 (0)