Redis有两种持久化方式，RDB和AOF。
RDB（默认开启）
RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照后，恢复数据。
快照默认称为RDB文件，默认是保存在当前运行目录中。
RDB文件默认名称：dump.rdb
Redis内部有触发RDB机制，在redis.conf配置文件中，格式如下：
XML
# 900秒内，如果有至少1个key被修改，则执行bgsave
save 900 1
# 300秒内，如果有至少10个key被修改，则执行bgsave
save 300 10
# 禁用RDB
save ""
# 其他配置
# 是否压缩，建议不开启，压缩会消耗cpu
rdbcompression no
# RDB文件名称（在恢复数据时，也会读这个文件名）
dbfilename dump.rdb
# 文件保存的路径目录
dir ./执行RDB快照命令：save 或 bgsave
例：save
注：该 save 命令是由Redis主进程来执行RDB，会阻塞所有命令。
Redis在手动停机 时会默认执行一次RDB的 save命令
例：bgsave
注：该 bgsave 命令是由Redis子进程来执行RDB，不影响其他请求命令。
bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入RDB文件。子进程不会影响主进程，但是在fork获取子进程的过程是阻塞的。
RDB方式 bgsave 的基本流程：
- fork主进程得到一个子进程，共享内存空间（如下图）
- 子进程读取内存数据并写入新的RDB文件
- 用新的RDB文件替换就的RDB文件
fork采用的是 copy-on-write技术
- 当主进程执行*++读操作++*时，访问共享内存
- 当主进程执行++写操作++时，则会拷贝一份数据，执行写操作
RDB的缺点：
- RDB的执行间隔时间长，两次RDB之间写入数据有丢失的风险
- fork子进程、压缩、写出RDB文件都比较耗时
AOF（默认关闭）
AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看作是命令日志文件。当Redis实例故障重启后，从磁盘读取并执行AOP文件中的每一条命令，恢复数据。
AOF文件默认名称：appendonly.aof
AOF相关配置，在redis.conf文件，格式如下：
XML
# 是否开启AOF功能，默认是no，代表是关闭，yes代表是开启
appendonly yes
# AOP文件的名称
appendfilename "appendonly.aof"
# AOF的命令记录的三种频率配置，三选一
# 表示每执行一次写命令，立即记录到AOF文件中
appendfsync always
# 写命令执行完成后先放入AOF缓冲区，然后每隔1秒将缓冲区的数据写到AOF文件中，默认方案
appendfsync everysec
# 写命令执行完成后先放入AOF缓冲区，由操作系统决定何时将缓冲区的数据写到AOF文件
appendfsync noAOF的命令记录的三种频率配置对比：
|--------------|----------|---------------|---------------|
| 配置项 | 刷盘时机 | 优点 | 缺点 |
| always | 同步刷盘 | 可靠性高，机会不会丢失数据 | 性能最差 |
| everysec（默认） | 每秒刷盘 | 性能适中 | 最多丢失1秒数据 |
| no | 操作系统刷盘 | 性能最好 | 可靠性差，可能丢失大量数据 |
AOF的缺点：
因为是记录Redis在运行过程中的所有写命令，所以AOF文件会比RDB文件大很多。并且AOF会记录对同一个key的多次写操作，但实际情况下只有最后一次写操作才有意义。通过执行 bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同的效果。
命令如下：（BGREWRITEAOF命令是异步执行）
XML
BGREWRITEAOFRedis也会在触发阈值时自动去重写AOF文件。阈值在redis.conf配置文件中：
XML
# AOF文件比上次文件增加超过多少百分比则触发重写（默认配置）
auto-aof-rewrite-percenttage 100
# AOF文件体积最小多大以上才触发重写（默认配置）
auto-aof-rewrite-min-size 64mbRDB和AOF的对比：
|-------------|---------------------|--------------------------------------|
| | RDB | AOF |
| 持久化方式 | 定时对整个内存做快照 | 记录每次执行的命令 |
| 数据完整性 | 不完整，两次备份之间可能会丢失 | 相对完整，取决于刷盘策略 |
| 文件大小 | 有压缩，文件体积较小 | 记录命令，文件体积大 |
| 宕机恢复速度 | 很快 | 慢 |
| 数据恢复优先级 | 低，数据完整性不如AOF | 高，数据完整性更高 |
| 系统资源占用 | 高，消耗大量CPU和内存 | 低，主要是磁盘IO资源。 但是AOF重写时会占用大量CPU资源和内存资源 |
| 使用场景 | 若能容忍数据的丢失，追求更快的启动速度 | 对数据安全性要求较高 |