Redis之持久化机制（RDB和AOF）

最新推荐文章于 2025-10-29 09:11:11 发布

原创最新推荐文章于 2025-10-29 09:11:11 发布 · 1w 阅读

4 ·

CC 4.0 BY-SA版权

Redis 专栏收录该内容

13 篇文章

订阅专栏

本文深入解析Redis的RDB和AOF两种持久化机制，探讨其工作原理、触发条件及数据恢复流程，帮助读者理解如何在不同场景下选择合适的持久化策略。

因为Redis是内存数据库，将自己的数据库状态都存在了内存中，如果不想办法将存在内存中的数据库状态保存到磁盘里，如果出现了断电或者服务器宕机的情况，那么在内存中的数据库状态也会消失不见。为了解决这个问题，Redis提供了两种解决方案：RDB和AOF。

RDB

RDB持久化是通过快照方式来完成的。当达到触发条件时，Redis会自动将内存中所有数据以二进制方式生成一份副本并存储在硬盘上。

第一种是主动触发：指的是客户端执行save和bgsave命令会进行持久化

redis> SAVE
OK

当save命令执行的时候，redis服务器会被阻塞，所以当save命令正在执行的时候，客户端发送的所有命令都会被阻塞住。只有当save命令执行完毕之后，客户端发送的指令才会被处理，所以这个save命令使用需要慎重。

redis> BGSAVE
Background saving started

bgsave即background save，后台保存。当执行bgsave命令时，Redis会fork出一个子进程来执行快照操作。需要注意的是，在fork子进程的过程中，Redis是阻塞的。而当子进程创建完成后，Redis就可以继续响应客户端的请求了。

第二种是save m n规则触发

在指定的m秒内，Redis中有n个键发生改变，则自动触发bgsave。该规则默认在redis.conf中进行了配置，并且可组合使用，满足其中一个规则，则触发bgsave

比如save 900 1，表明当900秒内至少有1个键发生改变时候，Redis会触发bgsave操作。

第三种是flushall触发

flushall命令用于清空数据库，请慎用，当我们使用了则表明我们需要对数据进行清空，那Redis当然需要对快照文件也进行清空，所以会触发bgsave。

第四种是主从复制

在Redis主从复制中，从节点执行全量复制操作，主节点会执行bgsave命令，并将rdb文件发送给从节点。

第五种是shutdown

Redis在关闭前处于安全角度将所有数据全部保存下来，以便下次启动会恢复。可以使用客户端连入执行shutdown命令，也可以直接使用脚本关闭Redis，都会在退出前先执行save。

RDB数据恢复

了解了redis是在什么时候创建RDB快照，我们来了解一下数据恢复
在这里插入图片描述
当Redis意外崩溃或者关闭再次启动时，此时AOF持久化未开启时(默认未开启)，将使用RDB快照文件恢复数据。关掉Redis服务再重启，会发现日志里面有：

DB loaded from disk

AOF

默认情况下，Redis是关闭了AOF持久化，开启AOF通过配置appendonly为yes开启。

除了RDB持久化功能之外，redis还提供了AOF（Append Only File）持久化功能。与RDB持久化通过保存数据库中的键值对来记录数据库状态不同，AOF持久化是通过保存redis服务所执行的写命令来记录数据库状态的。

在这里插入图片描述
假设有这样子一种场景：比如Redis服务突然宕机，这个时候有些内存里面的数据还没来得及刷新进磁盘，就会导致一部分数据丢失。

AOF就是用来解决这个问题的。AOF是Append Only File的缩写，AOF可以将Redis执行的每一条写命令追加到磁盘文件中，在Redis启动时候优先选择从AOF文件恢复数据。AOF实现本质是基于Redis通讯协议，将命令以纯文本的方式写入到文件中。

Redis协议：

首先Redis是以行来划分，每行以\r\n行结束。每一行都有一个消息头，消息头共分为5种分别如下:

+表示一个正确的状态信息，具体信息是当前行后面的字符。
-表示一个错误信息，具体信息是当前行后面的字符。
*表示消息体总共有多少行，不包括当前行,后面是具体的行数。
$表示下一行数据长度，不包括换行符长度\r\n,后面则是对应的长度的数据。
: 表示返回一个数值，后面是相应的数字节符。

AOF持久化

追加写入

Redis将每一条写命令以Redis通讯协议添加至缓冲区aof_buf，这样的好处在于在大量写请求情况下，采用缓冲区暂存一部分命令随后根据策略一次性写入磁盘，这样可以减少磁盘的I/O次数，提高性能。

同步命令到硬盘

当写命令写入aof_buf缓冲区后，Redis会将缓冲区的命令写入到文件，Redis提供了三种同步策略，由配置参数appendfsync决定，下面是每个策略所对应的含义：

no：不使用fsync方法同步，而是交给操作系统write函数去执行同步操作，在linux操作系统中大约每30秒刷一次缓冲。
always：表示每次有写操作都调用fsync方法强制内核将数据写入到aof文件。
everysec：数据将使用调用操作系统write写入文件，并使用fsync每秒一次从内核刷新到磁盘。这是折中的方案，兼顾性能和数据安全，所以Redis默认推荐使用该配置。

文件重写(bgrewriteaof)

当开启的AOF时，随着时间推移，AOF文件会越来越大，当然Redis也对AOF文件进行了优化，即触发AOF文件重写条件的时候，Redis将使用bgrewriteaof对AOF文件进行重写。这样的好处在于减少AOF文件大小，同时有利于数据的恢复。重写策略：

重复或无效的命令不写入文件
过期的数据不再写入文件
多条命令合并写入

AOF文件重写过程与RDB快照bgsave工作过程有点相似，都是通过fork子进程，由子进程完成相应的操作，同样的在fork子进程简短的时间内，Redis是阻塞的。
在这里插入图片描述

开始bgrewriteaof，判断当前有没有bgsave命令(RDB持久化)/bgrewriteaof在执行，倘若有，则这些命令执行完成以后再执行。
主进程fork出子进程，在这一个短暂的时间内，redis是阻塞的。
主进程fork完子进程继续接受客户端请求，所有写命令依然写入AOF文件缓冲区并根据appendfsync策略同步到磁盘，保证原有AOF文件完整和正确。由于fork的子进程仅仅只共享主进程fork时的内存，因此Redis使用采用重写缓冲区(aof_rewrite_buf)机制保存fork之后的客户端的写请求，防止新AOF文件生成期间丢失这部分数据。此时，客户端的写请求不仅仅写入原来aof_buf缓冲，还写入重写缓冲区(aof_rewrite_buf)。
子进程通过内存快照，按照命令重写策略写入到新的AOF文件。
子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。
主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
使用新的AOF文件覆盖旧的AOF文件，标志AOF重写完成。

重写的触发条件：

AOF文件触发条件可分为手动触发和自动触发。手动触发：客户端执行bgrewriteaof命令。自动触发：自动触发通过以下两个配置协作生效：

auto-aof-rewrite-min-size: AOF文件最小重写大小，只有当AOF文件大小大于该值时候才可能重写，4.0默认配置64mb。
auto-aof-rewrite-percentage：当前AOF文件大小和最后一次重写后的大小之间的比率等于或者等于指定的增长百分比，如100代表当前AOF文件是上次重写的两倍时候才重写。

AOF数据恢复

当AOF开启时候，Redis数据恢复优先选用AOF进行数据恢复。关掉Redis服务再重启，会发现日志里面有：

DB loaded from append only file

RDB与AOF对比

RDB
- RDB是一个压缩过的非常紧凑的文件，保存着某个时间点的数据集，适合做备份，灾难恢复。RDB使Redis性能更高，子进程处理保存工作。在恢复大数据集时比AOF恢复速度快。
- 但是RDB的安全性是不如AOF的，保存整个数据集的过程是比较繁重的，整个过程可能需要几分钟，如果服务器宕机，那么可能就会丢失几分钟的数据。
AOF
- 数据更完整，安全性也更高，秒级数据丢失（取决于appendfsync策略，如果是everysec，最多丢失一秒的数据）。AOF是一个只进行追加的日志文件，而且写入操作是以Redis协议的格式保存的，内容是可读的，且任何版本的Redis都兼容。
- 相对于RDB，AOF的体积会略大于RDB，数据恢复也比较慢。根据appendfsync的策略，AOF的速度可能会慢于RDB。

混合持久化

混合持久化是Redis 4.0才有的功能。混合持久化同样也是通过bgrewriteaof完成的，不同的是当开启混合持久化时，fork出的子进程先将共享的内存副本以RDB方式写入AOF文件，然后在将重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的AOF文件替换旧的的AOF文件。

简单的说：新的AOF文件前半段是RDB格式的全量数据，后半段是AOF格式的增量数据。