Redis支持RDB和AOF两种持久化机制，持久化功能有效得避免因进程退出造成的数据丢失问题，下次重启时利用之前持久化文件即可实现数据恢复。
一、RDB
RDB持久化是把当前进程数据生成快照保存到硬盘的过程，分为手动触发和自动触发：
手动触发有save和bgsave两种命令：
save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用。（已废弃）
bgsave命令：针对save阻塞问题做的优化。Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。具体流程如下：
1）执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如RDB/AOF子进程，如果存在，bgsave命令直接返回；
2）父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通过info stats命令查看latest_fork_usec选项，可以获取最近一个fork操作的耗时，单位为微秒；
3）父进程fork完成后，bgsave命令返回“Background saving started”信息并不再阻塞父进程，可以继续相应其他命令；
4）子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的时间，对于info统计rdb_last_save_time选项；
5）进程发送信号给父进程表示完成，父进程更新统计信息。
自动触发：
1）使用save相关配置，如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave。
2）如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点。
3）执行debug reload命令重新加载Redis，也会自动触发save操作。
4）默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则自动执行bgsave。
二、AOF
AOF（append only file）持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性。
AOF的工作流程：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）：
1）所有的写入命令会追加到aof_buf（缓冲区）中；
2）AOF缓冲区根据对应的策略向硬盘做同步操作；
3）随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的；
4）当Redis服务器重启时，可以加载AOF文件进行数据恢复。（AOF持久化开启且存在AOF文件时，优先加载AOF文件）
AOF重写过程可以手动触发和自动触发，流程如下：
1）执行AOF重写请求；
如果当前进程正在执行bgsave操作，重写命令延迟到bgsave完成之后再执行。
2）父进程执行fork创建子进程，开销等同于bgsave过程；
3.1）主进程fork操作完成后，继续响应其他命令。所有修改命令依然写入AOF缓冲区并根据appendfsync策略同步到硬盘，保证原有AOF机制正确性。
3.2）由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令，Redis使用“AOF重写缓冲区”保存这部分新数据，防止新AOF文件生成期间丢失这部分数据。
4）子进程根据内存快照，按照命令合并规则写入到新的AOF文件。每次批量写入硬盘数据量由配置aof-rewrite-incremental-fsync控制，默认为32MB，防止单次刷盘数据过多造成硬盘阻塞。
5.1）新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息，具体见info persistence下的aof_*相关统计。
5.2）父进程把AOF重写缓冲区的数据写入到新的AOF文件。
5.3）使用新的AOF文件替换老文件，完成AOF重写。
三、RDB和AOF的区别：
RDB使用一次性生成内存快照的方式，产生的文件紧凑压缩比更高，因此读取RDB恢复速度更快。由于每次生成RDB开销较大，无法做到实时持久化，一般用于数据冷备和复制传输。