一篇文章带你搞懂Redis RDB和AOF持久化

Redis作为一款高性能的内存数据库,在实际应用中被广泛使用。但由于数据存储在内存中,一旦服务器宕机,数据就会丢失。为了解决这个问题,Redis提供了持久化机制,将内存中的数据保存到磁盘上,以便在服务器重启后能够恢复数据。本文将详细介绍Redis的两种主要持久化方式:RDB和AOF。

1. RDB持久化

1.1 RDB简介

RDB(Redis Database)是Redis默认的持久化方式。RDB持久化是指在指定的时间间隔内,将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。

1.2 RDB工作原理

RDB持久化的过程如下:

1. Redis父进程首先判断:当前是否在执行save,或bgsave/bgrewriteaof的子进程,如果在执行则bgsave命令直接返回。
2. 父进程执行fork操作创建子进程,这个过程中父进程是阻塞的。
3. 父进程fork后,bgsave命令返回"Background saving started"信息并不再阻塞父进程,可以继续响应其他命令。
4. 子进程创建RDB文件,根据父进程内存快照生成临时快照文件,完成后对原有文件进行原子替换。
5. 子进程发送信号给父进程表示完成,父进程更新统计信息。

整个流程如下图所示:

RDB工作原理

1.3 RDB触发方式

RDB持久化的触发方式可以分为手动触发和自动触发。

手动触发:

save命令:阻塞Redis服务器进程,直到RDB文件创建完毕为止。
bgsave命令:派生出一个子进程,由子进程负责创建RDB文件,不阻塞服务器进程。

自动触发:

redis.conf中配置`save m n`,表示m秒内数据集存在n次修改时,自动触发bgsave。
如果从节点执行全量复制操作,主节点自动执行bgsave生成RDB文件并发送给从节点。
执行debug reload命令重新加载Redis时,也会自动触发save操作。
默认情况下执行shutdown命令时,如果没有开启AOF持久化功能则自动执行bgsave。

1.4Redis中默认的周期新设置

周期性执行条件的设置格式为
save <seconds> <changes>

默认的设置为：
save 900 1
save 300 10
save 60 10000

以下设置方式为关闭RDB快照功能
save ""

以上三项默认信息设置代表的意义是：

• 如果900秒内有1条Key信息发生变化，则进行快照；

• 如果300秒内有10条Key信息发生变化，则进行快照；

• 如果60秒内有10000条Key信息发生变化，则进行快照。

1.5 RDB优缺点

优点:

1. RDB是一个紧凑压缩的二进制文件,代表Redis在某个时间点上的数据快照。非常适用于备份,全量复制等场景。
2. RDB对Redis对外提供的读写服务,影响较小,可以最大化Redis的性能。
3. 相比于AOF,RDB文件恢复数据的速度更快。

缺点:

1. RDB无法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程,频繁执行成本过高。
2. 在一定间隔时间做一次备份,所以如果Redis意外down掉的话,就会丢失最后一次快照之后的所有修改。

2. AOF持久化

2.1 AOF简介

AOF(Append Only File)持久化是通过保存Redis服务器所执行的写命令来记录数据库状态的。

2.2 AOF工作原理

AOF持久化功能的实现可以分为命令追加(append)、文件写入(write)和文件同步(sync)三个步骤。

1. 命令追加:当AOF持久化功能打开时,服务器在执行完一个写命令后,会将被执行的写命令追加到服务器状态的aof_buf缓冲区的末尾。

2. 文件写入和同步:Redis的服务器进程就是一个事件循环(Event Loop),这个循环中的文件事件负责接收客户端的命令请求,以及向客户端发送命令回复,而时间事件则负责执行像serverCron函数这样需要定时运行的函数。

3. 随着服务器不断处理写命令,aof_buf缓冲区的体积会越来越大。为了避免缓冲区体积过大,服务器会根据配置,将aof_buf缓冲区中的内容写入和同步到AOF文件。

AOF工作流程如下图所示:

AOF工作原理

2.3 AOF重写

随着时间流逝,AOF文件会变得越来越大。为了解决这个问题,Redis提供了AOF文件重写功能。

AOF文件重写并不需要对现有的AOF文件进行任何读取、分析或者写入操作,这个功能是通过读取服务器当前的数据库状态来实现的。

AOF重写的流程如下:

1. Redis服务器fork出子进程。
2. 子进程根据内存中的数据库状态,构建一个新的AOF文件。
3. 主进程继续处理客户端请求,将新的写入命令追加到AOF重写缓冲区。
4. 子进程完成AOF重写后,向父进程发送一个信号。
5. 父进程接收到信号后,将AOF重写缓冲区中的内容追加到新的AOF文件中。
6. 使用新的AOF文件替换旧的AOF文件。

2.4 AOF优缺点

优点:

1. AOF持久化的方式可以带来更高的数据安全性,即数据持久性。
2. AOF持久化在对日志文件进行操作时,是以append-only的方式进行写操作的,因此在写入过程中即使出现宕机现象,也不会破坏日志文件中已经存在的内容。

缺点:

1. 对于相同数量的数据集而言,AOF文件通常要大于RDB文件。
2. AOF方式的恢复速度通常要慢于RDB方式。
3. 根据所使用的fsync策略,AOF的速度可能会慢于RDB。

非常好,我会在原文的基础上加入RDB和AOF混合持久化的相关内容。以下是更新后的部分:

3. RDB和AOF的混合持久化

Redis 4.0版本引入了RDB和AOF的混合持久化模式,旨在结合两种方法的优点,为用户提供更灵活、更可靠的数据持久化选择。

3.1 混合持久化的工作原理

混合持久化的基本工作流程如下:

1. 当AOF重写触发时,Redis创建一个子进程。
2. 子进程首先将内存中的数据以RDB格式写入AOF文件。
3. 接着,子进程将重写缓冲区中的增量数据以AOF格式追加到文件末尾。
4. 重写完成后,新的AOF文件替换旧的AOF文件。

这种方式结合了RDB的快速加载和AOF的数据安全性,示意图如下:

混合持久化工作原理

3.2 混合持久化的优点

1. 快速恢复: 重启时,Redis可以快速加载RDB部分,然后再执行AOF部分,大大减少了数据恢复的时间。

2. 数据完整性: AOF部分记录了自上次RDB快照之后的所有写操作,确保了数据的完整性。

3. 文件大小优化: 相比纯AOF模式,混合模式的文件通常更小,因为RDB部分是经过压缩的二进制数据。

4. 灵活性: 用户可以根据需求调整RDB快照的频率和AOF重写的触发条件。

3.3 如何启用混合持久化

要启用混合持久化,需要在Redis配置文件中设置以下参数:

aof-use-rdb-preamble yes

开启AOF持久化:

appendonly yes

3.4 混合持久化的注意事项

1. 版本兼容性: 混合持久化只在Redis 4.0及以上版本可用。

2. 文件格式变化: 启用混合持久化后,AOF文件的格式会发生变化,可能影响一些依赖于旧格式的工具或脚本。

3. 内存占用: 在进行AOF重写时,可能会短暂增加内存占用。

4. 性能影响: 虽然影响较小,但混合模式可能会对Redis的性能产生轻微影响。

4. 选择合适的持久化策略

在选择Redis持久化策略时,需要考虑以下因素:

1. 数据安全性要求: 如果对数据丢失极度敏感,可以选择AOF或混合模式。

2. 性能需求: 如果追求最高性能,可以选择RDB或完全关闭持久化。

3. 恢复速度: 如果需要快速恢复大量数据,RDB或混合模式更合适。

4. 磁盘空间: AOF文件通常比RDB文件大,如果磁盘空间有限,可以考虑RDB或混合模式。

5. 应用场景: 对于缓存场景,可以选择RDB或关闭持久化;对于数据存储场景,AOF或混合模式更合适。

对于重要的生产环境,可以使用混合持久化,同时配置适当的RDB快照频率和AOF重写策略。
对于次要的缓存服务,可以仅使用RDB,并降低快照频率。
对于对数据一致性要求极高的场景,可以使用AOF并设置`appendfsync always`。