Redis进阶你不得不了解的知识点-主从复制原理

文章内容

• 掌握Redis持久化RDB和AOF的原理和选型
• 理解Redis主从复制原理
• 能够配置Redis主从复制

一、Redis持久化

Redis是一个内存数据库，为了保证数据的持久性，它提供了两种持久化方案：

RDB 方式（默认）

RDB方式是通过快照（ snapshotting ）完成的，当符合一定条件时Redis会自动将内存中的数据进行快照并持久化到硬盘。

触发快照的时机

1. 符合自定义配置的快照规则 redis.conf
2. 执行save或者bgsave命令
3. 执行flushall命令
4. 第一次执行主从复制操作

原理图

设置快照保存规则

save 多少秒内 数据改变了多少

save “” : 不适用RDB存储

save 900 1 ： 表示900秒内至少一个键被修改则进行快照。

save 300 10 ： 表示5分钟内至少10个键被修改则进行快照。

save 60 10000 ： 表示1分钟内10000个键被更改则进行快照。

注意事项：

1. Redis在进行快照过程中不会修改RDB文件，只有快照结束后才会将旧的快照文件替换为新的，也就是说任何时候RDB文件都是完成的。
2. 这就使得我们可以通过定时备份RDB文件来实现Redis数据库的备份，RDB文件是经过压缩的二进制文件 ,占用空间会小于内存中的数据，更加利于传输。

RDB优缺点

缺点：使用RDB方式进行持久化，如果看明白了其备份原理，则很容易看出Redis如果异常宕机或者重启，就会丢失最后一次快照之后的所有数据修改。这个时候我们就需要根据具体的应用场景，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受范围。如果数据相对来说比较重要，希望将损失降到最小，则可以使用 AOF 方式进行持久化。

优点： RDB最大化了Redis性能，父进程在保存快照生成RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有文件保存工作，父进程无需执行任何磁盘 I/O 操作。同时这也是一个缺点，如果数据集比较大的时候，fork可能比较耗时，造成服务器在一段时间内会停止处理客户端请求。

AOF方式

默认情况下 Redis 没有开启 AOF （ append only file ）方式的持久化。

开启 AOF 持久化后，每执行一条会更改 Redis 中的数据的命令， Redis 就会将该命令写入硬盘中的AOF文件，这一过程显然会降低 Redis 的性能，但大部分情况下这个影响是能够接受的，另外使用较快的硬盘可以提高 AOF 的性能。

配置redis.conf

appendonly yes

# The name of the append only file (default: "appendonly.aof")

appendfilename "appendonly.aof"

# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./

上面三个参数指定了开启AOF持久化，以及持久化文件名和文件所在目录。

原理

在学习AOF原理前，我们首先要了解 RESP （Redis的序列化协议）

AOF文件中存储的是reids的命令。

AOF同步和RDB类似之处在于都是采用fork进程来处理：

AOF重写原理（优化AOF文件）

set s1 11
set s1 22

上面的操作，如果没有优化之前AOF文件是会将这两个命令按照RESP序列化后存储，如果优化后，则只存储后面一条命令即 set s1 22，同一个key的值被覆盖了，只存储最终结果。

重写过程分析

Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕， Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。

优化触发条件：

# 表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写。如果之前没有重写过，以启动时aof文件大小为准
auto-aof-rewrite-percentage 100
# 限制允许重写最小aof文件大小，也就是文件大小小于64mb的时候，不需要进行优化
auto-aof-rewrite-min-size 64mb

如何选择RDB和AOF

• 内存数据库，数据不能丢： rdb（redis database）+aof
• 缓存服务器：rdb
• 不建议只使用 aof (性能差)
• 恢复时：有aof就先选择aof恢复，没有的话选择rdb文件恢复

二、Redis主从复制

什么是主从复制？

简言之就是：

• 主对外从对内，主可写从不可写
• 主挂了，从不可为主

看下面的图加深下理解：

主从配置

接下来，我们实战一下redis的主从架构配置：

• 主redis无需任何配置
• 从机需要修改redis.conf文件中如下配置项

port 6378  # 如果是使用的一台机器注意端口要与主机不同
# slaveof <masterip> <masterport>
# 表示当前【从服务器】对应的【主服务器】的IP是192.168.10.135，端口是6379。
slaveof 192.168.137.6 6379

实现原理

Redis从2.8版本开始，使用PSYNC命令代替SYNC命令来执行复制时的同步操作。因为本文只讲解目前采用PSYNC同步原理。

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

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

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

下图展示了主从服务器在执行部分重同步时的通信过程：

其实看到这里的时候心里还是有一个疑问的：当从服务器掉线时间比较久，你这样一条指令一条指令地传输过去还不如直接来一个SYNC命令通过RDB文件快一些。所以在我看来使用PSYNC进行操作时，什么时候部分重同步，什么时候全部重同步是一个策略问题，当然Redis会解决这个问题，所以大家继续看0_0。

部分同步的实现

部分重同步功能由以下三个部分构成：

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

复制偏移量

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

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

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

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

如下面的情况：

假设从服务器A在断线之后就立即重新连接主服务器，并且成功，那么接下来，从服务器将向主服务器发送PSYNC命令，报告从服务器A当前的复制偏移量为10107，那么这时，主服务器应该对从服务器执行完整重同步还是部分重同步呢？如果执行部分重同步的话，主服务器又如何补偿从服务器A在断线期间丢失的那部分数据呢？以上问题的答案都和复制积压缓冲区有关。

复制积压缓冲区

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

和普通先进先出队列随着元素的增加和减少而动态调整长度不同，固定长度先进先出队列的长度是固定的，当入队元素的数量大于队列长度时，最先入队的元素会被弹出，而新元素会被放入队列。

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

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

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

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

根据需要调整复制积压缓冲区的大小

Redis为复制积压缓冲区设置的默认大小为1MB，如果主服务器需要执行大量写命令，又或者主从服务器断线后重连接所需的时间比较长，那么这个大小也许并不合适。如果复制积压缓冲区的大小设置得不恰当，那么PSYNC命令的复制重同步模式就不能正常发挥作用，因此，正确估算和设置复制积压缓冲区的大小非常重要。

复制积压缓冲区的最小大小可以根据公式 second * write_size_per_second来估算：

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

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

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

至于复制积压缓冲区大小的修改方法，可以参考配置文件中关于 repl-backlog-size 选项的说明。

服务器运行ID

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

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

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

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

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

PSYNC命令的实现

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

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

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

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

上面我们详细说明了redis主从同步时，底层是如何决定使用全量同步或者部分同步的策略。下面看下整个增量同步和部分同步的过程：

Redis 的全量同步过程主要分三个阶段：

• 同步快照阶段： Master 创建并发送快照给 Slave ， Slave 载入并解析快照。 Master 同时将此阶段所产生的新的写命令存储到缓冲区。
• 同步写缓冲阶段： Master 向 Slave 同步存储在缓冲区的写操作命令。
• 同步增量阶段： Master 向 Slave 同步写操作命令。

增量同步

• Redis 增量同步主要指 Slave 完成初始化后开始正常工作时， Master 发生的写操作同步到 Slave 的过程。
• 通常情况下， Master 每执行一个写命令就会向 Slave 发送相同的写命令，然后 Slave 接收并执行。

参考资料：

https://www.cnblogs.com/lukexwang/p/4711977.html