Redis主从复制及其实现原理

我就是我 2022-08-28 12:42 171阅读 0赞

## Redis主从复制及其实现原理 ##

首先，简单介绍一下`什么是Redis主从复制`。

假如我们服务中用到了Redis，并且只有一台Redis服务器。如果某个时刻该Redis服务挂了，那么会导致整个服务的Redis不可用，在此期间，大量的请求将会直接打到数据库(mysql)，导致数据库压力陡增，严重的可能导致数据库直接挂掉。这种情况，我们称之为`单点故障`。

为了应对Redis的单点故障问题，于是就有了Redis的主从复制，也就是服务中存在多台Redis服务器，或者称之为Redis节点。**所有Redis节点的数据都是一样的，其中一个Redis节点作为主节点（主库），其余的Redis节点作为该节点的从节点（从库）**。这就是`Redis`提供的`主从模式`。

然后主从模式下采用`读写分离`：

*  读操作：主库从库均可执行读操作，主要从从库读。
 *  写操作：仅主库可以执行写操作，然后把数据同步给各个从库，保证主从数据一致性。  
    ![redis主从复制][redis]

通过上面的介绍，相信大家应该了解了什么是Redis的主从复制。

那么，**如何实现Redis的主从复制功能呢？**  
因为Redis提供了主从模式的功能，所以我们只需要在Redis节点的配置文件(`redis.conf`)配置相关项即可。

*  主节点无需做任何修改
 *  从节点需要修改 redis.conf 配置文件的相关配置，如下：

# 配置主节点的ip和端口 注意：Redis5.0之后 slaveof 改成了replicaof
    slaveof 127.0.0.1 6379
    # 是否只读 redis2.6及之后 从节点默认只读
    slave-read-only yes
    # 主节点登录密码（如果主节点没有登录密码，则无需配置此选项）
    masterauth xxxxxx

从节点配置好以上信息之后，先启动主节点，再启动从节点，主从节点便会建立联系，开始执行主从同步操作。  
那么，这个**主从同步流程具体是如何执行的呢**？咱们且接着往下看。

首先，我们看一下整体的流程图，之后再逐步介绍都干了什么：  
![redis主从同步执行流程][redis 1]

##### 第一步：主从节点建立连接，协商数据同步，为全量复制做准备 #####

*  主从节点第一次建立连接的时候，会执行**全量复制**，即把主节点的全部数据都复制到从节点，所以称之为全量复制。
 *  通过上图第一步可以看到，从节点发送 `psync ? -1` 命令给主节点，表示要进行复制。  
    **其中?代表主节点的 runId；-1 代表复制进度 offset。**  
    **runId**：每个Redis节点启动时都会生成一个唯一的随机id，用来标识这个Redis节点。当从库第一次向主库发起复制请求时，是不知道主库的runId的，所以将runId设置为问号?  
    **offset**：复制进度为-1表示是第一次复制。
 *  主节点收到从节点的 `psync` 命令后，会通过 `FULLRESYNC` 命令进行响应，并将自己的 `runId` 和当前的复制进度 `offset` 发送给从节点。

##### 第二步：主节点将全部数据通过RDB文件发送给从节点 #####

*  第二步中，主节点会执行 `bgsave` 命令，生成 `RDB` 文件，并将 RDB 文件发送给从节点。
 *  从节点收到 RDB 文件后，会先清空自己的数据（防止主从数据不一致），然后完成 RDB 文件的数据加载。
 *  主节点给从节点同步数据的过程中，RDB 文件的生成是通过子进程完成的，主节点并不会被阻塞（`fork子进程会阻塞`）。在此期间主节点仍然会正常接收请求，但是这些请求中的写操作并没有记录到刚刚生成的 RDB 文件中，**为了保证主从数据一致性，主节点会把 RDB 文件生成后的写操作记录到内存中的一块缓冲区**，即 **`replication buffer`**。

##### 第三步：主节点将第二步执行过程中接收的写请求发送给从节点，从节点重新执行这些操作，实现主从同步。 #####

到此，Redis的主从同步具体执行流程，我们已经比较清楚了。  
**值得注意的是**：主从复制的过程中，Redis会 fork 子进程生成 RDB 文件，这个 fork 子进程的操作会阻塞 Redis 主线程。假如从节点非常多的时候，会导致主节点忙于 fork 子进程，进而导致主节点阻塞，这时候该怎么办呢？咱们且接着往下看：  
这时候，我们可以通过`“主-从-从”的模式`，`将主节点生成和发送 RDB 文件的压力以级联的方式分散到从节点`。

说简单点就是：可以选择一个配置相对较高的从节点，作为其他从节点的主节点，如下图所示：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YeJ5YeJ55qE6KW_55Oc_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center]  
可以看到，从节点2和从节点3的主节点就不再设置成主节点了，而是设置成从节点1。这样便可以有效缓解主节点的多从复制压力了。

那么，除了上述问题之外，还存在其他问题吗？答案是肯定的。  
**主从节点建立连接之后，他们之间会一直维护着一个长连接，避免频繁建立连接的开销**。但是，假如这个连接断开了会怎么样呢？

Redis2.8之前，主从节点断开重连之后会执行全量复制，显然全量复制开销过大，所以在**Redis2.8之后**就被淘汰了，**升级成了增量复制**。那么，什么是增量复制呢？

#### 增量复制 ####

断连重连之后，从节点不会复制所有的主节点数据，只会复制断连之后这段时间的写操作数据，这就是增量复制，顾名思义，就是只复制断连后增加的那部分数据量。

增量复制的实现依赖于一个**环形缓冲区** **`repl_backlog_buffer`**，**只要有从节点在，这个环形缓冲区就会存在**。`主节点会在这个环形缓冲区记录自己写到的位置，从节点会在这个环形缓冲区记录自己已经读到的位置`。如下图所示：

![环形缓冲区][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YeJ5YeJ55qE6KW_55Oc_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 1]  
主节点的所有写操作除了复制给从节点之外，也会在这个环形缓冲区记录一份，也就是上面说到的主节点会在这个环形缓冲区记录自己写到的位置，只有预先缓存了这些写操作，当从节点断连之后，又恢复连接然后发送 `psync {runId} {offset}` 命令执行主从同步。主节点才能通过 `{offset}` 参数在环形缓存区 `repl_backlog_buffer` 中找到从节点断连的位置，然后发送**增量数据**（offset位置到主节点写到的位置之间的数据）给从节点。

**注意**：假如从节点断连时的读位置 `offset` 已经被主节点的写位置覆盖了，那么此时便无法执行增量复制操作了，只能再执行一次全量复制了。所以，为了尽量避免断连之后的全量复制，可通过 `repl_backlog_size` 这个参数合理设置 `repl_backlog_buffer` 的大小，减少发生全量复制的概率。

计算公式：**缓冲空间大小 = 主节点写入命令速度 \* 操作大小 - 主从节点间网络传输命令速度 \* 操作大小**  
为应对突发情况，可将 `repl_backlog_size` 设置为缓冲空间大小的2倍。  
即：`repl_backlog_size = 缓冲空间大小 * 2`

接着上面的说，增量数据是如何发送给从节点的呢，这就用到了 **`replication buffer`**。

关于 `replication buffer` 的介绍

*  Redis和客户端或者从节点通信，都会分配一个对应的内存缓冲，通过这个内存缓冲完成数据交互，如果连接断开，这个内存缓冲也会不复存在。
 *  当和从节点进行交互的时候，这个内存缓冲专门用于复制主节点的写操作到从节点，所以叫 `replication buffer`。如果从节点处理数据特别慢，那么这个`replication buffer` 会持续增长，可能导致OOM。
 *  这个内存缓冲的大小可通过 `client-output-buffer-limit` 参数限制，如果超过这个限制，主节点会强行断开这个从节点（客户端）的连接。此时复制中断，如果之后再继续发起复制请求，可能会导致恶性循环，引发复制风暴，需格外注意。

以上内容参考了极客时间Redis专栏介绍以及Kaito大神的相关说明。

到此，Redis主从复制相关介绍就结束了。  
这种模式可以解决Redis的单点故障问题，提高Redis的可用性。但是缺点也是很明显的，假如主节点挂了，从节点是无法自动升级成主节点的，这个过程需要人工处理，在此期间，Redis无法对外提供写操作。此时，**Redis哨兵模式**就该登场了，待更新…  
此外，整个Redis的主从节点数据都是一样的，也就是冗余的，会造成一定的资源浪费。此时，**Redis集群模式**就该登场了，详见[Redis集群搭建][Redis]

[redis]: /images/20220828/23be88a40ba24d46b763ba83dfb685b0.png
[redis 1]: /images/20220828/bf11d676f91a4a3eab4d1f272044e9f3.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YeJ5YeJ55qE6KW_55Oc_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center]: /images/20220828/186d3fc06fe7486db7c713c1322ea2ca.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YeJ5YeJ55qE6KW_55Oc_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 1]: /images/20220828/f662f9b12895417e8e52282cdff68ccd.png
[Redis]: https://blog.csdn.net/qq_42815754/article/details/82912130