Redis 主从复制，爱了

2021-09-18 00:00:00 命令 服务器 复制 主从 同步

以下文章来源于七哥聊编程 ，作者七哥  

今天我们来聊聊后端面试必考知识点：Redis 主从复制的原理，那通过今天的学习你可以掌握下面这几点知识：

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

我们都知道Redis是一个内存数据库，在学习主从同步之前，我们首先要想到 Redis 是如何做数据持久化的，也就是说要先存储到磁盘上嘛，这样才方便主从之间的数据同步。

0. Redis持久化

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

RDB 方式（默认）

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

触发快照的时机
  1. 符合自定义配置的快照规则 redis.conf
  2. 执行 save 或者 bgsave 命令
  3. 执行 flushall 命令
  4. 次执行主从复制操作
原理图
设置快照保存规则

快照规则是配置在 redis.conf 文件中的，我这里我截取对应的代码片段，给大家看下。

#
# Save the DB on disk:
# 
# 持久化操作设置，下面的配置分别表示：900秒内至少一个键被修改则进行快照，5分钟内至少10个键被修改则进行快照，1分钟内10000个键被更改则进行快照

save 900 1
save 300 10
save 60 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 的性能。

开启AOF持久化模式

还是一样的，我们只需要去修改Redis安装目录中的 redis.conf 文件中下面三个属性值即可。

appendonly yes // 开启AOF

# 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的序列化协议）

从图中可以看到客户端在调用redis服务端时，传入的命令和 key、value 都会通过 RESP 协议序列化为文本。AOF文件中存储的就是序列化后的reids命令。

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

通过这张图，我们知道了Redis是将客户端传入的命令直接写入AOF文件的，那如果同一个key原本值是0，然后改为1，后在改为2，如果每一条命令都记录不仅毫无意义，同时会使得AOF文件越来越大，所以 Redis 在这块有一个小优化。

AOF重写（优化AOF文件） 
set s1 11
set s1 22

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

重写过程分析

那如果做到同一个key在AOF文件中只存储新的值呢？不可能每一次写入文件前去检查一遍删除之前这个key的值吧，这样做效率肯定贼低，我们来看看Redis是怎么做的？

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

这个操作不得不说还是玩的66的！大写的服。

优化的触发条件：

那上面说的定期重建 AOF 文件具体的时机是啥时候呢？答案也在配置文件 redis.conf 中，需要如下的配置即可，我已经写了注释，你一眼就能看懂的。

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

如何选择RDB和AOF

面试官再问了你Redis的持久化方法之后，就爱问这个问题了：具体如何选择 RDB 和 AOF 呢？你可以结合下面的场景去分析选择即可。

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

1. Redis主从复制

来自灵魂的拷问：什么是Redis主从复制？

简言之就是：

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

看下面的图加深下理解：

对，你没看错，Redis主从复制没有动态选举Master节点的能力，主挂了服务就不可以写数据了。仅仅就是增强了应用读数据的并发量同时做数据备份。

一般生产环境会采用 哨兵 或者 Redis Cluster 这种具备Master自动选举的方案，我们学习时还是要掌握主从的原理后，再去更深一步，对于哨兵和Redis Cluster方案感兴趣的话，可以留言告诉我，咱们后面安排上。

主从如何配置

接下来，我们实战一下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协议)的写命令的长度总和）；

例如，如果主服务器平均每秒产生 1MB 的写数据，而从服务器断线之后平均要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> <offset> 命令：其中 runid 是上一次复制的主服务器的运行ID，而 offset 则是从服务器当前的复制偏移量，接收到这个命令的主服务器会通过这两个参数来判断应该对从服务器执行哪种同步操作。

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

  • 如果主服务器返回 +FULLRESYNC <runid> <offset> 回复，那么表示主服务器将与从服务器执行完整重同步操作：其中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 接收并执行。

3. 总结

Redis 主从复制这套架构，一般我们生产上是不用的，不过这个确实一个难点和重点，面试官基本上都会问到。建议大家都好好看看，整明白了，对于你理解其他各种关于数据同步方案或者中间件的原理思想都是很受用的。

后求个赞还是要的，嗯~~ 看懂点赞。                    

--end--


相关文章