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

2024-11-04 来源：个人技术集锦

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

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

1）最小可用版：

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

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

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

2）进阶版：

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

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

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

全局知识地图：

前言

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

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

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

一、持久化

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

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

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

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

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

1、RDB

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

我们来看看 RDB 生成过程：

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 写入文件的过程：

首先：

写入：指通过 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 重写执行过程：

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 记录明细，数据丢失风险小，但数据文件相对较大。

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

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 模式类似，我们来看看：

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

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

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

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

5、对比

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

二、副本

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

1、同步模式

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

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

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

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

2、部分重同步

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

如何实现？环形缓冲区

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

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

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

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

三、哨兵

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

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

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

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

1、核心能力

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

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

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

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

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

2、节点通信

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

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

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

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

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