Redis 核心原理串讲（中），架构演进之高可用

布满荆棘的人生 2024-03-30 12:36 20阅读 0赞

#### 文章目录 ####

*  Redis 核心原理总览（全局篇）
 *  前言
 *  一、持久化
 *   *  1、RDB
     *  2、AOF
     *  3、AOF 重写
     *  4、混合持久化
     *  5、对比
 *  二、副本
 *   *  1、同步模式
     *  2、部分重同步
 *  三、哨兵
 *   *  1、核心能力
     *  2、节点通信
 *  总结

--------------------

## Redis 核心原理总览（全局篇） ##

正文开始之前，我们先思考下「如何造一个缓存组件？」

> `注`：***该片段是 Redis 原理知识地图，请仔细阅读！（基于 `redis6.2`）***

1）最小可用版：

*  要快：缓存最核心的目的是支持快速访问，硬件层面一般选择「内存」
 *  远程访问：作为缓存组件，要支持单独部署，可以利用现有开源网络库，也可以自己实现。

大部分语言都提供了内存操作，条件 1 很容易满足，条件 2 要支持远程访问，就要和 TCP 连接打交道，我们可以利用开源的网络库，比如 C 版的 `libc` 等。

`原理篇第一部分：将围绕一条请求探索 redis 高性能的核心原理。`

2）进阶版：

第一步我们已经有了缓存组件最基本的雏形，并且已经达到了高性能的处理能力，这个时候我们可能有更多的诉求：

*  稳定：即 尽可能不丢数据、无故障或故障后快速恢复、自动处理故障的能力
 *  可扩展：单机容量或者 QPS 达到上限，支持水平扩展能力。

`原理篇第二部分：将围绕 redis 架构演进进行剖析。`

全局知识地图：

![在这里插入图片描述][bb3862415c624d018e606eb511f78473.png_pic_center]

## 前言 ##

本文围绕「架构主线」来透视 Redis「高可靠」的核心原理，在正文开始之前，我们先思考几个问题：

*  Redis 数据丢失风险？
 *  持久化机制会拖慢 Redis 吗？
 *  fork 子进程是否会阻塞主线程？不用 fork 操作行不行？
 *  有了持久化还需要副本机制？
 *  能不能自己写个 HA 来代替 Redis 哨兵？

如果你对以上问题了然于胸，这篇文章读起来很容易，权当帮你串联、回顾知识点，如果不是很清楚也没关系，且听我细细道来！

--------------------

## 一、持久化 ##

持久化是什么？就 redis 而言，本质就是将内存中不稳定的数据，通过一些刷盘策略写入磁盘，从而达到断电等故障能恢复数据的效果。

如果让你来实现持久化，你会如何考虑？

首先，我们可以「定期全量备份」的方案，5分钟、10分钟一个备份周期，这种方式的好处是，处理起来足够简单，但由于是全量备份，每次消耗不小，因此需要「一定间隔」周期，但丢失数据风险就大了。

我们还可以考虑像 MySQL 的 binlog 方式，记录「明细」，故障时直接进行重放即可，这种方式的好处是数据丢失范围进一步减小，但故障恢复时需要更多的时间，而且数据文件占用空间也更大。

能不能结合两种优点？也是可以的，这就是「混合模式」

### 1、RDB ###

RDB 全称 *redis database*，是以时间为轴线的全量内存快照，存在磁盘上。快照，就是那个时间点内存数据库的全景图，就像拍照一样，把那个瞬间的所有状态“咔”的一声记录下来。

我们来看看 RDB 生成过程：

![在这里插入图片描述][b065bee9d7314c77ba3cd0d2abd26200.png_pic_center]

redis 提供了两种方式，一种是 save，另一种是 bgsave。两者底层处理原理都一样，最大的区别点在于:

*  SAVE 由主线程执行，会阻塞客户端命令
 *  BGSAVE 由 fork 的子进程处理，不会阻塞执行。

redis 提供了一些契机，达到这些条件就可以触发执行 RDB 快照生成，可以在 redis.config 中配置：

save 900 1
    save 300 10
    save 60 10000

只要满足以下三个条件中的任意一个，BGSAVE 命令就会被执行：

*  服务器在900秒之内，对数据库进行了至少1次修改。
 *  服务器在300秒之内，对数据库进行了至少10次修改。
 *  服务器在60秒之内，对数据库进行了至少10000次修改。

> `注`：save 操作由主线程阻塞执行，而 bgsave 则由子进程来完成（不过复制内存页表项的时候仍然会阻塞主线程）。

### 2、AOF ###

全称 *Append Only File*，像记录日志一样，记录命令明细。

我们来看看 AOF 写入文件的过程：

![在这里插入图片描述][b7ed887c699e4f7a886dc211ee7d428c.png_pic_center]

**首先：**

*  `写入`：指通过 write 系统调用，将数据从 aof\_buf 写入 内核缓冲区。
 *  `落盘（同步）`：指的是将数据**从内核缓冲区同步至磁盘**中。因为，由于操作系统自身的优化策略，我们通过 write 写入的数据，都是直接进入内核缓冲区，然后会根据内核将数据同步至磁盘。

**aof\_buf 缓冲区:**

redis 服务端提供的缓冲区，请求命令会写入 aof\_buf 缓冲区，然后由 aof\_buf 缓冲区写入内核缓冲区或者同步至磁盘。

**落盘时机：**

在主事件循环，通过 beforeSleep 方法触发 flushAppendOnlyFile 调用，这便是入口。那，一条命令，经过哪些过程最终追加到 AOF 文件呢？

*  redis 接收请求命令 cmd，并执行。
 *  cmd 执行成功后，通过 feedAppendOnlyFile 方法将命令写入 aof\_buf 缓冲区。
 *  下一轮主循环中，通过 flushAppendOnlyFile 尝试写入或者同步。

**3 种刷盘策略：**

*  no：即 redis 不做任何操作，由内核自行刷盘，Linux 默认 30s 刷一次，效率最高，安全性最低
 *  everysec：redis 控制，每秒刷盘一次
 *  always：每一轮命令执行完之后，立即刷盘，安全性最高，效率最低

> `注`：刷盘策略是指将「内核缓冲区」的数据，通过 fsync 系统调用写入磁盘

### 3、AOF 重写 ###

上文提到，AOF 实实在在的记录了每一条命令，尤其是出现大量重复 key 的操作，会使得 AOF 看起来冗余且臃肿。

AOF 重写就相当于对 AOF 文件进行压缩，同一个 key 只保留最新的操作记录。

我们来看看 AOF 重写执行过程：

![在这里插入图片描述][7bdcbd30a8be4627b1a7eb14f431023f.png_pic_center]

1）触发重写条件（自动 or 手动）  
2）redis 调用 aof.c\#rewriteAppendOnlyFileBackground 方法，并 fork 子进程进行处理

*  2a）子进程重写 AOF 到临时文件
 *  2b）父进程继续接收新命令并累加到 server.aof\_rewrite\_buf 缓冲区

3）直到 2a 完成后  
4）父进程尝试将 server.aof\_rewrite\_buf 数据写入临时文件，并用临时文件替换原 AOF 文件。

**重写时机？**

redis 提供了灵活的重写机制，可以自动触发，也可以手动触发。

首先，需要确定是否开启了 AOF 策略，即：

appendonly yes

你可以在命令行输入 BGREWRITEAOF 手动触发重写：

127.0.0.1:6379> BGREWRITEAOF
    Background append only file rewriting started

另外，redis 也提供了自动触发重写条件：

auto-aof-rewrite-percentage 100
    auto-aof-rewrite-min-size 64mb

每次重写之后都会记录文件大小，作为下一次重写的触发条件：当前文件大小超过上次重写的百分比后，触发重写操作。

同时，为避免 AOF 文件过小而触发重写操作，提供了 auto-aof-rewrite-min-size 参数控制重写条件的下限。

> `注`：AOF 重写并不需要从原 AOF 文件中进行压缩，而是直接扫描整个库，把每一个 key / value 转变成写命令，然后追加至临时文件，待重写操作完成后，将临时文件原子性重命名即可。

### 4、混合持久化 ###

前面我们提到，RDB 记录快照，数据文件相对小，但丢失数据风险较大，AOF 记录明细，数据丢失风险小，但数据文件相对较大。

两者都不完美，能不能只取它们的优点？确实有，这就是「混合持久化」。

![9efd11f981a340c38ff81b9ea906276b.png_pic_center][]

redis 4.0 推出了 RDB-AOF 这种混合模式，可以通过下面配置开启：

appendonly yes
    aof-use-rdb-preamble yes

可以看到，使用混合模式的前提是，需要先开启 AOF，而 `aof-use-rdb-preamble` 参数则控制是否使用混合模式。

使用这种模式，当数据重写后，AOF 文件前半部分是 RDB 数据（采用 RDB 数据格式），AOF 文件后半部分继续追加 AOF 数据（AOF 数据格式）。

当采用 RDB-AOF 混合模式时，数据直接从 AOF 文件加载，由于 AOF 文件存储了 RDB 和 AOF 数据，也就达到了 `全量加载RDB数据 和 增量加载AOF数据` 的策略。

**数据写入过程？**

前面我们提到混合模式的数据也是直接存到 AOF 文件，前半部分存 RDB 数据、后半部分存 AOF 数据。

相信你也猜到了，整体数据写入过程与 AOF 模式类似，我们来看看：

![在这里插入图片描述][b7ed887c699e4f7a886dc211ee7d428c.png_pic_center]

文件追加写的部分没有变化，那变化在哪里？`AOF 文件重写`

你想想，我们的最终目的是「压缩文件」，采用现成的 RDB 方式就可以完成，因此，我们可以考虑直接在重写 AOF 文件时，直接存储 RDB 格式的数据：

![在这里插入图片描述][7bdcbd30a8be4627b1a7eb14f431023f.png_pic_center]

*  fork 子进程直接按照 RDB 格式将快照数据写入 AOF 文件
 *  aof\_rewrite\_buf 缓冲区数据仍然以 AOF 数据格式写入 AOF 文件

整体来看，混合模式的数据写入和 AOF 模式基本一致！！！

### 5、对比 ###

截止目前 Redis 提供了 AOF、RDB 以及两者混合模式的持久化方式，主要特点如下：

![在这里插入图片描述][b4985d47a01a4d82bb9f0437c93db387.png_pic_center]

## 二、副本 ##

持久化机制保障了数据不丢失，但还无法做到故障秒级切换，那怎么办？`副本机制`，也就是我们常见的主从结构。

### 1、同步模式 ###

redis 的复制功能可以分为`数据同步`和`命令传播`两部分。

*  数据同步：将从节点保持与主节点一致，一般有完全重同步和部分重同步两种模式。
 *  命令传播：当主从节点状态一致后，后续新的命令通过 TCP 长连接发送至从节点。

当然，我们也可以通过以下三种具体的数据传输形式来区分：

*  完全重同步，一般是启动时或者主从断开连接过长时间
 *  部分重同步，一般是主从短时间断连
 *  命令传播，也就是命令实时同步

![在这里插入图片描述][40e1a5213403415397fbf3455d94fa15.png_pic_center]

### 2、部分重同步 ###

这种模式主要考虑 主从数据同步期间要尽可能的减少数据传输，你想想，主从同步是通过网络进行传输，网络具有不稳定性，如果中断了一小会，难道就要全量重新发一次吗？**当然不用**

如何实现？`环形缓冲区`

顾名思义，一块指定大小的缓冲区，可重复循环使用（即，写满了又可以从头开始写，当然就有覆盖较早数据的问题）

![在这里插入图片描述][85651ad2c7694ce49da4a6a70bb47a68.png_pic_center]

从节点会记录已经从主服务器接收到的数据量（复制偏移量），而主节点会维护一个「复制缓冲区」，记录自己已执行且待发送给从节点的命令请求，同时还需要记录复制缓冲区第一个字节的复制偏移量。

从节点请求时带上自己的复制偏移量，主节点接收后对比复制偏移量刻度是否还在，如果还在说明环形缓冲区还没有被覆盖，直接将这边增量数据发送给从节点。

如果复制偏移量不存在，说明已经被覆盖了，就需要完整将整个 RDB 数据文件全量发给从节点。

## 三、哨兵 ##

有了副本就能实现秒级故障恢复？**还不够，这个时候还需要你手动进行切换**。

能不能做成自动故障切换？**能，这就是哨兵，其本质就是一个监控程序**。

用一个哨兵似乎就能完成？**能，但不够准，网络的复杂性，经常出故障是可能的，所以，我们最好搞多个哨兵**。

我画了张图，大概是这样：

![在这里插入图片描述][ac39c5fc39d24fc4b6377d60325c6b3c.png_pic_center]

### 1、核心能力 ###

首先，哨兵的主要职责是保障 redis 服务能正常对外提供服务。因此，肯定是要监听 redis 主节点的在线状态。

其次，当主节点挂掉之后，需要进行故障转移，也就是需要知道所有从节点的信息。因此，哨兵的第二项职责便是监听从节点的状态。

另外，前面部分提到，单哨兵可能并不是那么健壮，我们一般需要搞一个哨兵集群。因此，第三项职责便是哨兵节点间的沟通交流。

![76b80ab67cae4abdb8bfea8199820b58.png][]

当然，监听节点的目的是为了获取信息，对这些信息进一步处理并采取相应的行动才是目的：

*  哨兵集群信息沟通交流
 *  master 节点下线判断
 *  哨兵集群 leader 选举
 *  哨兵 leader 执行故障转移
 *  通知客户端，master - slave 变更信息

### 2、节点通信 ###

哨兵，本质也是一个 redis 服务，既能接收请求又能定期监视相关节点，这是如何做到的？

我们知道，事件是贯穿 redis 的核心机制，客户端发来的请求封装为`文件事件`，另外还有一些后台周期性的任务封装为`时间事件`。

哨兵的工作过程号称是`异步`的，比如发出 PING 之后不需要等待响应，而是当响应到来时，通过回调函数来继续处理。哨兵的异步操作是如何实现的？

哨兵在启动时会创建相关连接，并将对应已连接的 fd 向操作系统内核注册，当有请求到来时，和一般的 redis 请求类似，服务正常处理请求即可。

在哨兵主动发起通信时，主要借助于客户端工具 hiredis，其封装了 RESP 通信协议，发送请求时，这个过程不必等待结果返回，因此，异步体现在这里。

我画了张图，大概是这样：

![85c9ef624ba44427b3e04be4df97f1ee.png][]

值得注意的是，redis 哨兵的异步过程是与主线程轮训（事件）紧密相连。

--------------------

## 总结 ##

本文主要围绕 redis `高可用` 进行贯穿讲述，核心问题是要解决 `如何确保 redis 无故障或秒级恢复？`，我们循序渐进的讲述了三大部分内容：

*  持久化：RDB 、AOF 持久化机制
 *  副本机制：一主一丛、一主多从 …
 *  哨兵机制：监视、故障转移、通知

把这三部分内容串起来就是这个问题的答案。

[bb3862415c624d018e606eb511f78473.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/b66a1eb29f0b4a49a131c9f30c244f81.png
[b065bee9d7314c77ba3cd0d2abd26200.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/240ace6ad21e4b58a8f545c9f63e0536.png
[b7ed887c699e4f7a886dc211ee7d428c.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/2c15b1324a2f486ba58eddcf9617bf44.png
[7bdcbd30a8be4627b1a7eb14f431023f.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/8f88a039e90f4100987369f8f3c2a485.png
[9efd11f981a340c38ff81b9ea906276b.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/5474d3d628464d72bd0f011a85fcd2c5.png
[b4985d47a01a4d82bb9f0437c93db387.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/239162cc01ae419aaa30210ce283b72d.png
[40e1a5213403415397fbf3455d94fa15.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/3163fc0a60b548d1af6c74515ac66520.png
[85651ad2c7694ce49da4a6a70bb47a68.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/038efa0698484325ac2bc6bac12c4a57.png
[ac39c5fc39d24fc4b6377d60325c6b3c.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/176f53605bd54900b389d5d44a1bbf15.png
[76b80ab67cae4abdb8bfea8199820b58.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/30b5598693904d86ada07181c75e521d.png
[85c9ef624ba44427b3e04be4df97f1ee.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/ce5f1190587344d5842397bf7d7c1487.png