Redis 中除了可以将数据保存在内存中，还支持两种数据持久化方案：RDB、AOF，实现将内存中的数据持久化到磁盘中，防止数据意外丢失。

一、RDB

使用 RDB 持久化时，Redis 会 fock 出一个子进程，并将数据持久化的操作交给子进程去处理，而主进程则继续处理客户端的请求，这也保证了性能。子进程要持久化那些数据在子进程创建成功时就能立即确定下来了，所以 RDB 持久化也称作快照持久化。

Redis 中默认是开启 RDB 持久化的，默认用一个名为dump.rdb的文件保存持久化数据，当子进程完成一次 RDB 持久化时，会用新的dump.rdb文件覆盖旧的文件，Redis 下次启动时会去加载这个文件，实现数据的恢复。

RDB 持久化相关的配置如下：

# 数据持久化的规则，也是开启 RDB 持久化
save 3600 1
save 300 100
save 60 10000
save 10 2
# 持久化出错时，是否继续处理客户端的写命令
stop-writes-on-bgsave-error yes
# 是否压缩持久化文件
rdbcompression yes
# 持久化文件名
dbfilename dump.rdb
# 持久化文件目录，默认就是 Redis 的启动目录，RDB 和 AOF 的持久化文件都会保存在该目录
dir ./

关于数据持久化规则这里解释一下，根据实际情况，可以配置多个持久化规则来触发快照持久化，例如save 10 2，表示每10秒时，至少有2个key的值发生变化（添加、修改、删除、过期等）就进行一次快照持久化，两个条件必须同时满足。

需要注意的是，如果还不满足持久化规则时 Redis 服务器宕机了，则会造成最近的数据丢失。

除了依赖配置文件中的save规则去触发持久化，我们还可以在 Redis 客户端手动执行快照持久化命令bgsave，该命令也会使用子进程去持久化数据，是异步的，不会影响主进程正常工作。

除了bgsave，还可以手动执行save命令，但这个命令是同步的，会阻塞客户端的其它请求，很少使用，了解即可。

二、AOF

AOF 持久化是将所有执行过的 Redis 命令追加到一个后缀名为.aof文件末尾，也就是备份命令，Redis 下次启动时会将文件中记录的命令全部执行一遍来恢复数据。

AOF 持久化默认是关闭的。

下边是 AOF 持久化相关的主要配置：

# 开启 AOF 持久化
appendonly yes
# 备份命令的文件名
appendfilename "appendonly.aof"
# 备份策略，每秒钟备份一次命令
appendfsync everysec
# 触发 .aof 文件执行重写时文件体积相比上次重新时的增长率
auto-aof-rewrite-percentage 100
# 触发 .aof 文件执行重写时的最小文件体积
auto-aof-rewrite-min-size 64mb

AOF 中有三种命令备份策略：

• always，有新的命令就追加到.aof文件中，速度非常慢，但也非常安全
• everysec，默认的策略，每秒备份一次，兼顾了速度和安全性，Redis 服务故障时会丢失1秒的数据
• no，由操作系统控制备份的时机，速度快，但安全性不可控

AOF 持久化机制中有一个.aof文件重写的策略，由于命令不断的追加到.aof文件尾部，会导致文件体积越来越大，所以在一定的触发条件下，Redis 会对.aof中的命令进行优化，去除无用冗余的，只保留恢复当前文件对应数据需要的最少的命令，然后用优化后的命令重建一个新的.aof文件。

AOF 的文件重写策略，不仅可以减少磁盘占用，也可以提高数据的恢复效率。

上边 AOF 配置中最后两条满足时就会触发一次 AOF 文件重写，即当.aof的文件体积大于64mb，并且体积比上次重写时大了至少一倍，则开始新一次重写。除了使用配置文件，也可以在客户端执行bgrewriteaof命令手动触发重写。

AOF 的文件重写是在一个子进程中进行的。

三、小结

备份相同的数据，RDB 的文件体积一般是要小于 AOF 的；如果同时开启了两种方式，Redis 启动恢复数据时优先使用 AOF 文件，因为 AOF 在数据备份的安全性上要好一些，可以减少数据的丢失，更能保证数据完整性；RDB 方式的数据恢复速度快一些。如果对数据安全性要求高的化，可以两种持久化方式都开启，双保险。