Redis RDB持久化与AOF 持久化详解

持久化

Redis 支持 RDB 和 AOF 两种持久化机制， 持久化功能有效地避免因进程退出造成的数据丢失问题， 当下次重启时利用之前持久化的文件即可实现数 据恢复。

AOF持久化开启且存在AOF文件时， 优先加载AOF文件

AOF关闭或者AOF文件不存在时， 加载RDB文件

加载AOF/RDB文件成功后， Redis启动成功

AOF/RDB文件存在错误时， Redis启动失败并打印错误信息

RDB

RDB持久化是把当前进程数据生成快照保存到硬盘的过程， 触发RDB持久化过程分为手动触发和自动触发。

当满足一定条件时，Redis 会执行 RDB 持久化操作。这些条件通常包括经过一定数量的写操作（例如设置键值对、删除键值对等）和经过一定的时间间隔。

当RDB持久化被触发时，Redis会生成一个包含当前内存中所有数据的快照（snapshot）。这个快照是一个二进制文件，包含了所有数据的键值对以及它们的过期时间和类型等信息。在生成快照期间，Redis会将所有新的写操作记录到一个内存缓冲区中，以保证生成的快照是一个一致性的数据集。一旦生成快照完成，Redis会将快照文件写入到磁盘上的一个临时文件中。当临时文件写入完成后，Redis会将原来的RDB文件替换为新生成的快照文件。这个替换操作是一个原子操作，可以保证在替换过程中不会丢失数据。

RDB 文件存储路径

RDB文件保存在dir配置指定的目录下， 文件名通过 dbfilename 配置指定。 可以通过执行config set dir{newDir}和 config set dbfilename{newFileName}运行期动态执行， 当下次运行时RDB文件会保存到新目录。

手动触发

save

• SAVE 命令会阻塞主进程，直到持久化过程完成为止。

• 在执行 SAVE 命令期间，Redis将所有数据写入到磁盘上的一个新的RDB文件中。

• 这种方式会阻塞Redis服务器的主线程，因此在处理大量写操作的情况下可能会导致Redis服务器的响应变慢或不可用。

SAVE

bgsave

• BGSAVE 命令会在后台执行持久化操作，不会阻塞主进程，因此不会影响Redis服务器的响应速度。

• Redis会fork出一个子进程来执行持久化操作，并继续处理客户端请求。

• 在执行 BGSAVE 命令后，Redis会将所有新的写操作记录到内存缓冲区中，以确保生成的快照是一个一致性的数据集。

示例：

BGSAVE

bgsave 命令是针对save阻塞问题做的优化。 因此Redis内部所有的涉及RDB的操作都采用bgsave的方式， 而save命令已经废弃。

自动触发

除了执行命令手动触发之外， Redis内部还存在自动触发RDB的持久化机制， 例如以下场景：

1. 使用 save 相关配置， 如save m n。 表示m秒内数据集存在n次修改时， 自动触发bgsave。

2. 如果从节点执行全量复制操作， 主节点自动执行bgsave生成RDB文319件并发送给从节点。

3. 执行debug reload命令重新加载Redis时， 也会自动触发save操作。

4. 默认情况下执行shutdown命令时， 如果没有开启AOF持久化功能则自动执行bgsave。

压缩

Redis默认采用LZF算法对生成的RDB文件做压缩处理， 压缩后的文件远远小于内存大小， 默认开启， 可以通过参数config setrdbcompression{yes|no}动态修改。

Tips：

• RDB方式数据没办法做到实时持久化/秒级持久化。 因为bgsave每次运行都要执行fork操作创建子进程， 属于重量级操作， 频繁执行成本过高。

• RDB文件使用特定二进制格式保存， Redis版本演进过程中有多个格式的RDB版本， 存在老版本Redis服务无法兼容新版RDB格式的问题。

AOF

AOF（ append only file） 持久化： 以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。 AOF的主要作用是解决了数据持久化的实时性， 目前已经是Redis持久化的主流方式。 理解掌握好AOF持久化机制对我们兼顾数据安全性和性能非常有帮助 。

• AOF持久化是将Redis服务器接收到的每个写操作都追加到文件末尾。

• AOF持久化记录了Redis服务器的所有写操作，因此它提供了更好的数据安全性和灾难恢复能力。

• AOF文件以易读易写的格式记录了Redis服务器接收到的所有写操作，因此AOF文件也可以作为日志进行审计和分析。

• 为了避免AOF文件过大，Redis支持AOF文件的自动压缩和重写操作。

• 开启AOF后， 所有写入命令都包含追加操作

工作流程

命令写入（append） 、 文件同步（sync） 、 文件重写（rewrite） 、 重启加载（load）

启用AOF持久化

在Redis的配置文件（redis.conf）中，找到并修改以下配置项：

appendonly yes

将这行配置项的值修改为yes，表示启用AOF持久化。然后重启Redis服务器使配置生效。

文件位置

默认情况下，AOF文件会保存在Redis服务器的工作目录中，文件名为appendonly.aof。你也可以通过配置文件中的 dir 和 appendfilename 参数来指定AOF文件的位置和文件名。

重写

AOF文件可能会随着时间的推移变得越来越大，为了避免AOF文件过大，可以定期进行AOF重写操作。AOF重写是指将AOF文件中的写操作重新写入到一个新的AOF文件中，但只保留了生成这些写操作所需的最少信息，从而达到压缩AOF文件的目的。

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

上述配置表示当AOF文件的体积增长到当前AOF文件的体积的100%时（即翻倍），Redis会触发AOF重写操作。auto-aof-rewrite-min-size 配置项指定了触发AOF重写操作的最小AOF文件大小。

手动触发

bgrewriteaof

自动触发

根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机 。

• auto-aof-rewrite-min-size： 表示运行AOF重写时文件最小体积， 默认为64MB。

• auto-aof-rewrite-percentage： 代表当前AOF文件空间（ aof_current_size） 和上一次重写后AOF文件空间（ aof_base_size） 的比值

文件恢复

如果Redis服务器在启动时检测到AOF文件存在，它将会尝试从AOF文件中重新构建数据集。因此，即使Redis服务器崩溃或被关闭，只要AOF文件没有损坏，数据仍然可以通过AOF文件进行恢复。