Redis 是内存数据库，数据都是存储在内存中，为了避免进程退出导致数据的永久丢失，需要定期将 Redis 中的数据以某种形式把内存中的数据保存到磁盘中；当 Redis 重启时，利用持久化文件实现数据恢复。除此之外，为了进行灾难备份，可以将持久化文件拷贝到一个远程位置。
Redis 提供了两种不同的持久化方法来讲数据存储到硬盘上 ：
快照的方式，是 将某一时刻内存中的所有数据以快照的形式写入硬盘上。只追加文件的方式，它会是将每次执行的写命令以追加的形式保存到硬盘上。下面依次介绍 RDB 持久化和 AOF 持久化。
RDB ( Redis Database ) 持久化就是把存储在内存里的数据在某个时间点上写入到硬盘上。在创建快照之后，用户可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本，也可以当Redis 重新启动时，读取快照文件恢复数据。
redis.conf 配置文件中设置了 save 配置选项， 比如 save 60 10000, 是指当“60 秒之内有10000次写入” 这个条件满足是，Redis 会自动触发 BGSAVE 命令。如果设置了多个 save 配置选项，那么当任意一个满足是，Redis 就会触发一次 BGSAVE 命令。上文我们提到了创建 RDB 快照的几种方式，总结可以发现这几种方式无非就是通过 SAVE 或 BGSAVE 命令来生成快照。
由于 SAVE 命令会造成长时间阻塞，而 BGSAVE 命令阻塞时间较短，所以，一般很少使用SAVE 命令，而是用BGSAVE 命令，接下来我们进一步讲解一下 BGSAVE 命令。
虽然 SAVE 命令一直阻塞 Redis 直到快照生成完毕, 但是因为它不需要创建子进程, 并且没有子进程争抢资源，所以 SAVE 创建快照的速度比 BGSAVE 创建快照的速度快些。
fork系统调
fork 系统调用会产生一个子进程，它与父进程共享相同的内存地址空间，这样子进程在这一时刻就能拥有与父进程的相同的内存数据。
虽然子进程与父进程共享同一块内存地址空间，但是在 fork 子进程时，操作系统需要拷贝父进程的内存页表给子进程，如果整个 Redis 实例内存占用很大，那么它的内存页也会很大，在拷贝是就会比较耗时，同时这个过程会消耗大量的 CPU 资源。在完成拷贝之前父进程也处于阻塞状态，无法处理客户端请求。
fork 执行完之后，子进程就可以扫描自身所有的内存数据，然后把全部数据写入到 RDB 文件中。
fork 操作的流程如下所示：
Copy On Write
前面介绍了 BGSAVE 命令不会造成阻塞主进程接收其他命令的请求，有 fork 系统调用可知，子进程共享主进程的内存数据，那么，当 Redis 服务器接收到写命令时，修改内存数据时，子进程读取同一内存地址的数据时，就会出现脏数据。
如果为了快照而暂停写操作，肯定是不能接受的。所以，Redis 借助了操作系统提供的写时复制技术（Copy-On-Write, COW），在执行快照的同时，正常处理写操作。
当父进程接收到写操作时，如果要修改的数据在内存中已经存在，那么，主进程就会拷贝一份数据，重新分配新的内存地址空间，这样，父进程就在新申请的内存空间中修改数据，不在与子进程共享，这个过程就是 Copy On Write（写实复制）。
比如我们修改上图的 物理页13 的数据，Copy On Write 后的图如下所：
这样父子进程的内存就会逐渐分离，父进程申请新的内存空间并更改内存数据，子进程的内存数据不受影响。
由此可以看出，在生成 RDB 文件时，不仅消耗 CPU 资源，还有需要占用最多一倍的内存空间。所以，我们应该保证 Redis 机器拥有 足够的CPU和内存资源，并合理设置生成 RDB 的时机。
RDB 的优点:
RDB 的缺点：
AOF 全称成为 Append Only File ( 只追加文件)。简单来说，AOF 持久化会把执行的写命令写到 AOF 文件的末尾，以此来记录数据发生的变化。因此，Redis 只要从头到尾执行一次 AOF 文件中的文件，就可以恢复数据。
Redis 中 AOF 默认是关闭的，在 redis.conf 配置文件中添加如下配置开启。
# 开启AOF
appendonly yes
# AOF文件名
appendfilename "appendonly.aof"
# 文件刷盘方式
appendfsync everysec
开启 AOF 后，所有的写入命令都会追加到 AOF缓冲区 中， Redis 会根据刷盘策略把 AOF 缓冲区中的数据保存到磁盘中，为了保证数据文件的安全性，Redis 提供了如下刷盘策略：
appendfsync always：每个 Redis 写命令都会被写入硬盘，在一般 SATA 硬盘上，Redis 只能支持大约几百的 TPS 写入，对性能影响大；而 SSD 硬盘能处理几万的TPS，但是频繁的吸入会造成 SSD 硬盘的寿命缩短。所以 always 占用磁盘 I/O 比较高，数据安全性高。appendfsync everysec：Redis 每秒对 AOF 文件进行同步一次。对性能影响较小，Redis 宕机时最多丢失 1 秒钟的数据。一般建议配置此种刷盘策略。appendfsync no：按照操作系统的机制刷盘，对性能影响最小，数据安全性低，Redis 宕机丢失数据取决于操作系刷盘机制。随着命令不断写入 AOF，文件会越来越大，为了解决这个问题，Redis 引入了 AOF 重写机制压缩文件体积。AOF 文件重写是把 Redis 进程内的数据转化为写命令同步到新的 AOF文件的过程。
文件变小原因
触发方式
AOF 重写可以手动触发和自动触发：
手动触发：直接调用 BGREWRITEAOF命令。
自动触发：根据 auto-aof-rewrite-percentage 和auto-aof-rewrite-min-size 参数确定自动触发机制，当满足条件时，就会调用 Redis 的 BGREWRITEAOF 命令。
// AOF文件距离上次文件增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
// AOF文件体积最小多大以上才触发重写
auto-aof-rewrite-min-size 64mb
重写机制
BGREWRITEAOF 命令 与 BGSAVE 命令相似，在执行 BGREWRITEAOF 命令后，父进程 调用 fork 创建一个子进程执行 AOF 的重写操作。流程如下所示：
流程说明：
1、执行 AOF 重写请求2、父进程执行 fork 创建子进程
3.1、fork 完成后，主进程继续响应其他命令，所有修改命令写入 AOF 缓冲区
3.2、接收的写命令同时也写入 AOF 重写缓冲区中。
4、子进程根据内存快照，按照命令合并规则写入到新的 AOF 文件。
5.1、新 AOF文件写完成后，子进程发送信号给父进程。
5.2、父进程把 AOF 重写缓冲区的数据写入到新的 AOF 文件
5.3、使用新 AOF 文件替换老文件，完成 AOF 重写。
当开启 AOF 持久化时，常用的同步硬盘策略是 everysec ，用于平衡性能和数据安全性。对于这种方式，Redis 使用另一个线程执行 fsync 同步刷盘。当系统硬盘资源繁忙是，会造成 Redis 主线程阻塞。
阻塞流程
阻塞流程发现问题
AOF优点：
AOF缺点：
参考资料：
《Redis 开发与运维》
《Redis 设计与实现》