文章来源：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

• 在redis.conf配置RDB文件名

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

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

dir ./

• 在redis.conf配置触发策略

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

三、AOF

概述：

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

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

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

appendfsync always

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

appendfsync everysec

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

appendfync no

配置项	刷盘时机	优点	缺点
Always	同步刷盘	可靠性高，几乎不丢数据	性能影响大
everysec	每秒刷盘	性能适中	最多丢失1s数据
no	操作系统控制	性能最好	可靠性较差，可能丢失大量数据

AOF的重写机制：

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

# 添加key1的值
set key1 v1
# 修改key1的值
set key1 v2
# 删除key1的值
del key1

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

AOF优点：

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

AOF缺点：

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

AOF配置：

• 在redis.conf配置AOF开启

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

• 在redis.conf配置AOF文件名

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

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

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

四、RDB和AOF的对比

	RDB	AOF
持久化方式	定时对整个内存做快照	记录每一次执行的命令
数据完整性	不完整，两次备份之间会丢失	相对完整，取决于刷盘策略
文件大小	会有压缩，文件体积较小	记录命令，文件体积很大
宕机恢复速度	很快	慢
数据恢复优先级	低，因为数据完整性不如AOF	高，因为数据完整性更高
系统资源占用	高，大量CPU和内存消耗	低，主要是磁盘IO资源，但AOF重写时会占用大量CPU和内存资源
使用场景	可以容忍数分钟的数据丢失，追求更快的启动速度	对数据安全要求较高常见

五、知识点：

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

六、实际使用

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