Redis的持久化：RDB和AOF机制

概述

Redis 提供 RDB 和 AOF 两种持久化机制，它们在数据安全性、性能、恢复速度等方面有显著差异。

为什么要进行持久化？如果是大数据量的恢复，会有下述的影响

• 会对数据库带来巨大的压力，
• 数据库的性能不如Redis。导致程序响应慢
• 实现数据的持久化，避免从后端数据库中恢复数据

RDB（Redis Database）

核心原理

RDB持久化是把当前进程数据生成快照保存到磁盘上的过程，由于是某一时刻的快照，那么快照中的值要早于或者等于内存中的值

• RDB文件默认为当前工作目录下的dump.rdb，可以根据配置文件中的dbfilename和dir设置RDB的文件名和文件位置

触发方式

有下述两种触发方式

1. 手动触发：分别对应save和bgsave命令
2. 自动触发：以下4种情况时会自动触发

手动触发

手动触发：分别对应save和bgsave命令

save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存 比较大的实例会造成长时间阻塞，线上环境不建议使用

bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子 进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短

• fork()是由操作系统提供的函数，作用是创建当前进程的一个副本作为子进程
• fork一个子进程，子进程会把数据集先写入临时文件，写入成功之后，再替换之前的RDB文件，用二进制压缩存储，这样可以保证RDB文件始终存储的是完整的持久化内容

自动触发

自动触发：以下4种情况时会自动触发

1. redis.conf中配置save m n，即在m秒内有n次修改时，自动触发bgsave生成rdb文件；

   save <seconds> <changes>
   表示在seconds秒内，至少有changes次变化，就会自动触发gbsave命令

2. 主从复制时，从节点要从主节点进行全量复制时也会触发bgsave操作，生成当时的快照发送到从节点

3. 执行debug reload命令重新加载redis时也会触发bgsave操作；

4. 默认情况下执行shutdown命令时，如果没有开启aof持久化，那么也会触发bgsave操作；

AOF（Append-Only File）

核心原理

AOF日志采用写后日志，即先写内存，后写日志

1. AOF持久化会把被执行的写命令写到AOF文件的末尾，记录数据的变化。
2. 默认情况下，Redis是没有开启AOF持久化的，
3. 开启后，每执行一条更改Redis数据的命令，都会把该命令追加到AOF文件中，这是会降低Redis的性能，但大部分情况下这个影响是能够接受的，
4. 另外使用较快的硬盘可以提高AOF的性能

配置方式

通过配置redis.conf文件开启AOF持久化

# appendonly参数开启AOF持久化
appendonly no# AOF持久化的文件名，默认是appendonly.aof
appendfilename "appendonly.aof"# AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的
dir ./# 同步策略
# appendfsync always
appendfsync everysec
# appendfsync no# aof重写期间是否同步
no-appendfsync-on-rewrite no# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb# 加载aof出错如何处理
aof-load-truncated yes# 文件重写策略
aof-rewrite-incremental-fsync yes

AOF实现步骤

AOF需要记录Redis的每个写命令，步骤为：

1. 命令追加（append）：启AOF持久化功能后，服务器每执行一个写命令，都会把该命令以协议格式先追加到aof_buf缓存区的末尾

   不是直接写入文件，避免每次有命令都直接写入硬盘，减少硬盘IO次数

2. 文件写入（write），文件同步（sync）：何时把aof_buf缓冲区的内容写入保存在AOF文件中，Redis提供了多种策略，appendfsync选项的默认配置为everysec，即每秒执行一次同步

   • appendfsync always：将aof_buf缓冲区的所有内容写入并同步到AOF文件，每个写命令同步写入磁盘
   • appendfsync everysec：将aof_buf缓存区的内容写入AOF文件，每秒同步一次，该操作由一个线程专门负责
   • appendfsync no：将aof_buf缓存区的内容写入AOF文件，什么时候同步由操作系统来决定

AOF的同步策略是涉及到操作系统的write函数和fsync函数的

AOF重写

AOF会记录每个写命令到AOF文件，随着时间越来越长，AOF文件会变得越来越大。

为了解决AOF文件体积膨胀的问题，Redis提供AOF文件重写机制来对AOF文件进行“瘦身”。

AOF重写的目的就是减小AOF文件的体积

Redis通过创建一个新的AOF文件来替换现有的AOF，新旧两个AOF文件保存的数据相同，但新AOF文件没有了冗余命令

• 时间长了，AOF文件中通常会有一些冗余命令，

  比如：过期数据的命令、无效的命令（重复设置、删除）、多个命令可合并为一个命令（批处理命令）。

• 所以AOF文件是有精简压缩的空间的

文件重写可分为手动触发和自动触发，

• 手动触发执行bgrewriteaof命令，该命令的执行跟bgsave触发快照时类似的，都是先fork一个子进程做具体的工作
• 自动触发会根据auto-aof-rewrite-percentage和auto-aof-rewrite-min-size 64mb配置来自动执行bgrewriteaof命令

RDB vs AOF

维度	RDB	AOF
数据安全性	低（依赖快照周期）	高（可配置秒级同步）
性能影响	低（后台异步）	中高（同步写盘/重放命令）
恢复速度	快（直接加载二进制）	慢（逐条执行命令）
文件体积	小（压缩存储）	大（需重写优化）
适用场景	容灾备份/快速恢复	金融级数据安全要求