Redis为持久化提供了两种方式：
- RDB：在指定的时间间隔能对你的数据进行快照存储。
- AOF：记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据。
RDB的原理
在Redis中RDB持久化的触发分为两种：自己手动触发与Redis定时触发。
手动触发：
- save：会阻塞当前Redis服务器，直到持久化完成，线上应该禁止使用。
- bgsave：该触发方式会fork一个子进程，由子进程负责持久化过程，因此阻塞只会发生在fork子进程的时候。
自动触发：
- 根据我们的
save m n配置规则自动触发bgsave命令【注意不是save命令】； - 从节点全量复制时，主节点发送rdb文件给从节点完成复制操作，主节点会触发
bgsave； - 执行
debug reload时； - 执行
shutdown时，如果没有开启aof，也会触发。
由于 save 基本不会被使用到，我们重点看看 bgsave 这个命令是如何完成RDB的持久化的。
这里注意的是 fork 操作会阻塞，导致Redis读写性能下降。我们可以控制单个Redis实例的最大内存，来尽可能降低Redis在fork时的事件消耗。以及上面提到的自动触发的频率减少fork次数，或者使用手动触发，根据自己的机制来完成持久化
AOF的原理
Redis 目前支持三种 AOF 保存模式，它们分别是：
AOF_FSYNC_NO ：不保存。
AOF_FSYNC_EVERYSEC ：每一秒钟保存一次。
AOF_FSYNC_ALWAYS ：每执行一个命令保存一次。
我们先来看看这3种模式对进程阻塞的情况：
- 不保存（AOF_FSYNC_NO）：【只会在AOF 关闭或 Redis 关闭时执行】写入和保存都由主进程执行，两个操作都会阻塞主进程。
- 每一秒钟保存一次（AOF_FSYNC_EVERYSEC）：写入操作由主进程执行，阻塞主进程。保存操作由子线程执行，不直接阻塞主进程，但保存操作完成的快慢会影响写入操作的阻塞时长。
- 每执行一个命令保存一次（AOF_FSYNC_ALWAYS）：和模式 1 一样。 因为阻塞操作会让 Redis 主进程无法持续处理请求， 所以一般说来， 阻塞操作执行得越少、完成得越快， Redis 的性能就越好。
AOF的整个流程大体来看可以分为两步，一步是命令的实时写入（如果是 appendfsync everysec 配置，会有1s损耗），第二步是对aof文件的重写。
对于增量追加到文件这一步主要的流程是：命令写入=》追加到aof_buf =》同步到aof磁盘。那么这里为什么要先写入buf在同步到磁盘呢？如果实时写入磁盘会带来非常高的磁盘IO，影响整体性能。
aof重写是为了减少aof文件的大小，可以手动或者自动触发，关于自动触发的规则请看上面配置部分。fork的操作也是发生在重写这一步，也是这里会对主进程产生阻塞。
手动触发： bgrewriteaof，自动触发 就是根据配置规则来触发，当然自动触发的整体时间还跟Redis的定时任务频率有关系。
下面来看看重写的一个流程图：
对于上图有四个关键点补充一下：
- 在重写期间，由于主进程依然在响应命令，为了保证最终备份的完整性；因此它依然会写入旧的AOF file中，如果重写失败，能够保证数据不丢失。
- 为了把重写期间响应的写入信息也写入到新的文件中，因此也会为子进程保留一个buf，防止新写的file丢失数据。
- 重写是直接把当前内存的数据生成对应命令，并不需要读取老的AOF文件进行分析、命令合并。
- AOF文件直接采用的文本协议，主要是兼容性好、追加方便、可读性高可认为修改修复。
综合比较
RDB的优缺点
优点：
- RDB最大限度地提高了Redis的性能，父进程不需要参与磁盘I/O
- 与AOF相比，RDB允许使用大数据集更快地重启
缺点：
- 如果您需要在Redis停止工作时（例如断电后）将数据丢失的可能性降至最低，则RDB并不好
- RDB经常需要fork才能使用子进程持久存储在磁盘上。如果数据集很大，Fork可能会非常耗时
AOF的优缺点
优点：
- 数据更加安全
- 当Redis AOF文件太大时，Redis能够在后台自动重写AOF ## INCRE 1 执行10万 = INCREBY10万执行一次
- AOF以易于理解和解析的格式一个接一个地包含所有操作的日志 # flushdb类似于rm -rf /*
缺点：
-
AOF文件通常比同一数据集的等效RDB文件大
-
根据确切的fsync策略，AOF可能比RDB慢
参考文章：
