所谓的RDB方式就是通过fork子线程以快照的方式将redis当前内存中的数据写入到硬盘中。

RDB持久化的优点：生成的文件小，备份和恢复速度都很快
RDB持久化的缺点：1、经常需要fork子进程，所以占用CPU会比较高 2、只是进行定期的备份数据，容易造成数据丢失
可以通过dbfilename dump.rdb来指定rdb的文件名，可以通过dir ./ 来配置备份文件保存的路径。RDB保存的策略可以通过下面的配置项来进行配置：

# save 3600 1
# save 300 100
# save 60 10000

此配置也是默认的配置，在3600秒内有一条数据发生改变、300秒内有100条key发生改变、60秒内有10000个key发生改变就会触发备份。

1、自动触发
达到备份策略条件时候触发

2、手工触发
使用bgsave命令、save命令。不建议使用save命令，因为会阻塞线程

由于RDS持久化方式数据的安全性很低，所以redis还提供另外一种持久化方式AOF。
AOF默认情况下是关闭，如果我们需要开启的时候需要通过下面的配置项打开
即把appendonly 配置值由no修改为yes.

appendonly yes

在执行修改类的命令时，把命令追加到AOF文件中，如果这样会导致每次命令执行都会与磁盘进行一次交互，这个会严重的影响到性能，所以redis提供了配置项来指定刷盘的时机：

# appendfsync always 表示每次写入都执行fsync(刷新)函数 性能会
非常非常慢 但是非常安全
appendfsync everysec 每秒执行一次fsync函数 可能丢失1s的数据
# appendfsync no 由操作系统保证数据同步到磁盘，速度最快 你的数
据只需要交给操作系统就行

即使用默认的策略会导致有可能1秒左右的数据丢失

为什么需要重写呢？
因为我们会在每次更新操作都会记录指令到aof文件中，随着时间的推移该文件会越来越大。所以我们就需要当前内存的数据记录下来，然后把之前的文件删除。
aof的重写流程是什么样的呢？

1. Redis fork一个子进程，在一个临时文件中写入新的AOF （当前内存的
数据生成的新的AOF）
2. 那么在写入新的AOF的时候，主进程还会有指令进入，那么主进程会在
内存缓存区中累计新的指令 （但是同时也会写在旧的AOF文件中，就算
重写失败，也不会导致AOF损坏或者数据丢失）
3. 如果子进程重写完成，父进程会收到完成信号，并且把内存缓存中的指
令追加到新的AOF文件中
4. 替换旧的AOF文件 ，并且将新的指令附加到重写好的AOF文件中。

在Redis4.0以后支持aof重写的时候，以RDB的方式生成新的AOF文件，然后后续的指令还是以aof的方法追加到该文件中，配置的参数是：
混合方式默认是开启的

aof-use-rdb-preamble yes

这个也是通过配置项配置，默认情况下，超过64M且到达重写后文件两倍的时候会触发重写，默认的配置如下：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb 

1.安全性高，就算默认的持久化同步机制，也最多只会导致1s丢失。
2.AOF由于某些原因，比如磁盘满了等导致追加失败，也能通过redischeck-aof 工具来修复
3.格式都是追加的日志，所以可读性更高

1. 数据集一般比RDB大
2. 持久化跟数据加载比RDB更慢
3. 重写的时候，因为重写的时候，新的指令会缓存在内存
   区，所以会导致大量的内存使用