Redis 中的持久化

Redis 的核心架构

IO多路复用线程模型

核心工作单线程模型

Redis持久化介绍

持久化的意义

持久化机制

持久化方式对比

Redis 持久化 - RDB

RDB简介

RDB的触发机制

Redis持久化- AOF

AOF简介

AOF 的重写机制

AOF的触发机制

AOF重写机制的副作用

REDIS持久化 - AOF和RDB混合模式

简介

四种持久化方式的对比

额外注意

Redis 中的持久化

Redis 的核心架构

IO多路复用线程模型

IO 多路复用也是一种同步阻塞 IO 模型，它实现了一个线程可以监视多个文件句柄；一旦某个文件句柄就绪，就能够通知应用程序进行相应的读写操作；而没有文件句柄就绪时,就会阻塞应用程序，交出 cpu。

核心工作单线程模型

1. 单线程源由

因为 CPU 不是 Redis 的瓶颈。Redis 的瓶颈最有可能是机器内存或者网络带宽，既然单线程容易实现，而且 CPU 不会成为瓶颈，那就顺理成章地

采用单线程的方案了。关于 Redis 的性能，官方网站也有，普通笔记本轻松处理每秒十万的请求

2. 所有版本

Redis 是单线程模型的，而单线程避免了 CPU 不必要的上下文切换和竞争锁的消耗。也正因为是单线程，如果某个命令执行过长（如 hgetall 命

令），会造成阻塞。Redis 是面向快速执行场景的数据库。所以要慎用如 smembers 和 lrange、hgetall 等命令

Redis 单线程指的是核心工作使用了一个线程，即一个线程处理所有命令请求

Redis 其他模块仍然有一些用了多个进程/线程，比如通过 fork 子进程，RDB 输出等

3. 6.0 后版本

Redis 6.0 引入了多线程提速，但多线程主要用于在 IO 处理，核心 work 线程(执行命令操作内存)仍然是个单线程

Redis持久化介绍

持久化的意义

Redis 的数据全部在内存中，如果突然宕机，数据就会全部丢失，因此必须有一种机制来保证 Redis 的数据在发生突发状况时不会丢失、或者只丢失少量；因此便产生了根据一些策略来把 Redis 内存中的数据写到磁盘中，这样当 Redis 服务重启时，就会将硬盘中的数据恢复到内存中。

Redis 持久化的意义就是为了保证突然宕机，内存数据不会全部丢失。

持久化机制

Redis 有两种持久化机制：RDB 和 AOF，每种持久化机制各有优缺点；Redis 4.0 后支持 RDB 和 AOF 两种持久化机制混合使用，所以实际上存在三种持久化策略

RDB 方式：把内存数据以快照的形式保存到磁盘上，可以周期性执行，重启的时候再执行 RDB 文件来进行数据恢复

AOF 方式：采用日志的形式来记录每个写操作，追加到文件中，重启时再重新执行 AOF 文件中的命令来恢复数据

混合持久化：采用两者相结合的方式

持久化方式对比

RDB 持久方式

适合大规模的数据恢复场景，如备份，全量复制等

没办法做到实时持久化/秒级持久化。

新老版本存在 RDB 格式兼容问题

AOF 持久方式

数据的一致性和完整性更高

AOF 记录的内容越多，文件越大，数据恢复变慢

混合持久化

结合了 RDB 和 AOF 的优点，使得数据恢复的效率大幅提升

跨版本兼容性不是很好，Redis-4.x 新增，虽然最终的文

件也是.aof 格式的文件，但在 4.0 之前版本都不识别

Redis 持久化 - RDB

RDB简介

RDB 是基于快照的一次全量备份，即周期性的把 Redis 当前内存中的全量数据写入到一个快照文件中

Redis 是使用操作系统的多进程 COW(Copy On Write)机制来实现快照的持久化，在持久化过程中调用函数 fork()产生一个子进程，快照持久化完全交给子进程来处理，父进程继续处理客户端的读写请求

子进程对当前内存中的数据进行持久化时，并不会修改当前的数据结构，如果父进程收到了读写请求，那么会把处理的一部分数据复制一份到内存，对复制后的数据进行修改，因此 RDB 持久化过程中，会产生一个内存扩张的问题，极限情况为 Redis 的 2 倍(我们在线上需要适当考虑)。

RDB的触发机制

自动触发：

在 Redis.conf 配置文件中的 SNAPSHOTTING 下配置 save 参数，来触发 Redis 的 RDB 持久化条件，

比如“save m n”：表示 m 秒内数据集存在 n 次修改时，自动触发 bgsave

save 900 1：每隔 900s(15min)，如果有超过 1 个 key 发生了变化，就写一份新的 RDB 文件

save 300 10：每隔 300s(5min)，如果有超过 10 个 key 发生了变化，就写一份新的 RDB 文件

save 60 10000：每隔 60s(1min)，如果有超过 10000 个 key 发生了变化，就写一份新的 RDB 文件

手动触发：

手动生成新的 RDB 文件，执行 Redis 的 save、bgsave 命令。

save：阻塞主进程，直到生成新的 RDB 文件；执行 save 命令期间，Redis 不能处理其他命令。

bgsave：异步生成 RDB 文件，fork 子进程去生成新的 RDB 文件，主进程不阻塞。

另外，配置多种策略可以同时生效，无论满足哪一种条件都会写一份新的 RDB 文件；Redis 进程在 kill 时也会尝试生成 RDB 文件

Redis持久化- AOF

AOF简介

AOF(Append-only file)日志存储的是 Redis 服务器的顺序指令序列，即对内存中数据进行修改的指令记录。

当 Redis 收到修改指令后，先进行参数校验，如果校验通过，先把该指令存储到 AOF 日志文件中，也就是先存到磁盘，然后再执行该修改指令。

Redis 把操作指令追加到 AOF 文件这个过程，可以采用 always，everysec，no 三种模式

always：每次事件都会刷盘，最安全、效率最低

everysec：每秒同秒一次，安全性略差、效率提高

no：交由操作系统，安全性最差、性能最高

AOF 的重写机制

Redis 在长期运行过程中，AOF 日志会越来越大，如果 Redis 服务重启后根据很大的 AOF 文件来顺序执行指令，将会非常耗时，导致 Redis 服务长时间无法对外提供服务，所以需要对 AOF 文件进行"瘦身"。"瘦身"的过程称作 AOF 重写(rewrite)。

AOF Rewrite 的过程是，主进程 fork 一个子进程，将当前内存中的数据进转换成一系列的 Redis 操作指令，并序列化到一个新的 AOF 日志中，

然后把序列化操作期间新收到的操作指令追加到新的 AOF 文件中，这样就完成了"瘦身"工作，即 AOF Rewrite，注意，AOF 在 Rewrite 过程中同样用到了多进程 COW(Copy On Write)机制。AOF Rewrite 过程如下：

AOF的触发机制

AOF 触发机制有两种，手动触发和自动触发

1. 自动触发

通过配置参数触发

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

2. 手动触发

执行命令 bgrewriteaof，通过子进程生成更小体积的 aof，然后替换掉旧的、大体量的 aof 文件

AOF重写机制的副作用

AOF 在重写的时候，采用操作系统的多进程的 COW(Copy On Write)机制，因此在这期间，因此会出现内存扩张现象，极限情况是 Redis 当前内存的 2 倍

AOF Rewrite 带来的内存开销有可能导致 Redis 内存突然达到 maxmemory 限制，从而影响正常命令的写入，甚至会触发操作系统限制被 OOM Killer 杀死，导致 Redis 不可服务

AOF Rewrite 也会带来 CPU 和额外开销，有可能造成 Redis 在执行命令时出现 RT 上的抖动，甚至造成客户端超时的问题

RDB 在快照期间，也会造成内存和 CPU 的额外开销，但通常时间要远小于由行 AOF 重写时间，因此 AOF 重写的影响要远大于 RDB 快照

REDIS持久化 - AOF和RDB混合模式

简介

Redis-4.x 后支持了 RDB 和 AOF 混合使用。重启 Redis 时，我们很少使用 RDB 来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重

放，但是重放 AOF 日志性能相对 RDB 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。Redis-4.0 为了解决这个问题，

带来了一个新的持久化选项——混合持久化。将 RDB 文件的内容和增量的 AOF 日志文件存在一起，这里的 AOF 日志不再是全量的日志，而是 RDB 久化开始到 RDB 持久化结束的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小。Redis-4.x 混合持久化机制如下图：

四种持久化方式的对比

RDB 持久方式	正常周期、手动生成、kill	从 RDB 文件恢复
AOF 持久方式	正常周期、手动生成	从 AOF 文件恢复
两种方式组合	RDB 和 AOF 按各自规则生成	从 AOF 文件恢复
混合持久化(AOF 包括了 RDB 头部+AOF 混写)	RDB 和 AOF 按各自规则生成	从 AOF 文件恢复