Redis的持久化策略：RDB与AOF（面试题详解）

文章来源：Redis持久化的两种方式：RDB与AOF（详解），订正了一些错误

一、概述：

RDB和AOF持久化的由来？

因为Redis中的数据是基于内存的，所以如果出现服务器断电或者服务器宕机，那么Redis中存放的数据就会直接丢失。RDB和AOF就是针对Redis提供的两种持久化机制，可以将Redis中的数据持久化到磁盘中。当Redis实例故障重启后，就可以根据备份的文件来进行数据的恢复

二、RDB

概述:

RDB全称Redis Database Backup file，也被叫做Redis数据快照，简单来说就是把内存中所有的数据都记录在磁盘中，当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为RDB文件，默认是保存在当前的运行目录（RDB可以理解为U盘拷贝，将Redis中的数据直接进行复制操作）
每次触发RDB的时候，就会重新生成一个新的RDB文件，覆盖旧的RDB文件，这样就可以确保备份得到最新的数据。

RDB的触发策略：

① 关闭Redis实例的时候，redis会在关闭之前主动的进行一次RDB（关闭不是宕机，宕机则数据丢失）
② 当你使用save/bgsave命令的时候，redis也会进行内存数据的持久化
③ 通过配置文件的配置触发：redis.conf配置文件

save 900 1
– 表示在900秒内，redis中有1个key发生改变，那么就进行一次bgsave
save 300 10
– 表示在300秒内，redis中有10个key发生改变，那么就进行一次bgsave
save 60 10000
– 表示在60秒内，redis中有10000个key发生改变，那么就进行一次bgsave

save/bgsave的不同

前面说到可以使用save命令或者bgsave命令来触发RDB，那么两者有什么区别呢？

• 如果使用的是save命令，数据备份就是由主线程来操作的，由于Redis是单线程的，所以如果使用save命令来进行内存的数据备份，那么在数据备份的时候redis是无法响应用户的请求的。当需要备份的数据非常大的时候，就可能导致请求被阻塞超时的情况
  如果使用的是bgsave命令，那么实际上是主线程fork个子线程，让子线程来进行RDB操作，主线程只是在fork子线程的时候阻塞，之后便可以继续响应用户的请求。接下来子进程即可读取内存数据并进行持久化，生成新的RDB文件替换旧的RDB文件

RDB缺点：

• RDB执行间隔时间长，两次RDB之间写入数据有丢失风险
• fork子进程、压缩、写出RDB文件都比较耗时

RDB优点：

• 使用RDB文件进行数据的恢复速度快、效率高（类似于文件拷贝）
• 相比于AOF持久化的文件，RDB的文件更小

RDB的相关配置：

• 在redis.conf配置RDB文件压缩

# 表示的是是否开启压缩，不建议开启，虽然节省空间，但是会耗费CPU
rdbcompression yes
1
2

• 在redis.conf配置RDB文件名

# 默认的rdb文件名称
dbfilename dump.rdb
1
2

• 在redis.conf配置rdb文件存放路径

dir ./
1

• 在redis.conf配置触发策略

# 15分钟内有1个key发生改变，那么就保存
save 900 1
# 5分钟内有10个key发生改变，那么就保存
save 300 10
# 1分钟内有10000个key发生改变，那么就保存
save 60 10000
# 执行的都是bgsave
1
2
3
4
5
6
7

三、AOF

概述：

AOF的全称叫做Append Only File（追加文件）Redis处理的每一个命令都会记录在AOF文件中，可以看做是命令日志文件（AOF存放的不是数据本身而是执行redis写操作的命令，类似于存放insert/update等这类命令而不是数据）

触发策略：根据配置文件触发redis.conf

• 每执行一次命令，立即记录到AOF文件（性能最差，是有主进程执行）

appendfsync always
1

• 写命令执行完先放入AOF缓存区，然后每间隔1s将缓冲区中的数据写到AOF文件，默认设置（性能较好，但是可能丢失1s内的数据）

appendfsync everysec
1

• 写命令执行完先放入AOF缓冲区中，由操作系统决定合适写回磁盘（可靠性比较低，性能最好）

appendfync no
1

AOF的重写机制：

由于AOF记录的是命令，那么当执行了很多命令的时候，就会记录到很多的冗余命令，例如：

# 添加key1的值
set key1 v1
# 修改key1的值
set key1 v2
# 删除key1的值
del key1
1
2
3
4
5
6

实际上key1最后被删除了，那么所有关于key1的命令实际上都是没有作用的，但是AOF中却记录了所有的命令，这样就会导致AOF文件很大而且存放了很多冗余命令。
通过使用bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同的效果，执行完该指令后，所有的冗余指令就会被删除，达到AOF文件压缩的效果。

AOF优点：

• 通过配置，可以使得备份的数据更加完整安全
• 每次进行AOF时占用的CPU资源较少（因为是追加，RDB则是全部重新复制一遍）

AOF缺点：

• 通过使用AOF文件进行恢复的速度较慢，需要依次执行所有指令
• AOF文件可能会比RDB大得多，记录的是所有的写操作

AOF配置：

• 在redis.conf配置AOF开启

# 表示的是开启，默认是no
appendonly yes
1
2

• 在redis.conf配置AOF文件名

# 这里表示的是AOF文件名称
appendfilename "appendonly.aof"
1
2

• 在redis.conf配置重写触发策略

# AOF文件比上次文件增长超过百分之百则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才能触发重写
auto-aof-rewrite-min-size 64mb
1
2
3
4

四、RDB和AOF的对比

五、知识点：

• 默认方式开启的是RDB，AOF默认是关闭的

六、实际使用

在实际使用中，一般不会单独的开启其中的一个，一般都会使用两者结合的方式一并使用。RDB根据有容灾性，可以周期性的进行RDB得到指定时间点的备份文件。AOF则数据更加的完整，仅仅有非常少的数据的丢失。

RDB-AOF混合方式

混合持久化是结合了 RDB 和 AOF 的优点，在写入的时候，先把当前的数据以 RDB 的形式写入文件的开头，再将后续的操作命令以 AOF 的格式存入文件。即以 RDB 作为全量备份，AOF 作为增量备份，来提高备份效率。这样既能保证 Redis 重启时的速度，又能防止数据丢失的风险， 这就是 Redis 4.0 之后推出的 RDB-AOF 混合持久化模式，其作为默认配置来使用。

持久化机制选择

• 如果对数据安全性有非常高的要求，建议 RDB 和 AOF 同时启用。

• 如果对数据安全性要求不是很高，能够容忍数据的丢失，建议单独使用 RDB。

• 不推荐单独使用 AOF，因为对于进行数据库备份、更快重启以及 AOF 引擎中出现错误的情况来说，RDB 是更好的选择。

• 如果没特殊要求，Redis又是4.x版本以上，可以选择RDB-AOF混合方式。

如果不是混合模式，而是普通的RDB与AOF一起启动时，Redis加载数据执行流程：