前言：
Redis支持RDB和AOF两种持久化机制，持久化功能有效地避免因进程退出造成的数据丢失问题，当下次启动时利用之前持久化的文件即可实现数据恢复。
RDB：
RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分手动触发和自动触发。
手动触发：
手动触发分别对应save和bgsave命令。
save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用。
bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。bgsave命令是针对save阻塞问题做的优化。因为Redis内容所有的涉及RDB的操作都采用bgsave的方式，而save命令已经废弃。
流程说明：
bgsave是主流的触发RDB持久化方式，它的运作流程大致可分为5步。
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）进程发送信号给父进程表示完成，父进程更新统计信息。
RDB的优缺点：
RDB的优点：
1）RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间上的数据快照。
2）Redis加载RDB恢复数据远远快于AOF方式。
RDB的缺点：
1）RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁成本过高。
2）RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题。
AOF:
AOF（append only file）持久化以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。
AOF工作流程：
AOF工作流程可以大致分为4步，命令写入（append）、文件同步（sync）、文件重写（rewrite）、重新加载（load）。
1）所有的写命令会追加到aof_buf(缓冲区)中。
2）AOF缓冲区根据对应的策略向硬盘做同步操作。
3）随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
4）当Redis服务器重启时，可以加载AOF文件进行数据恢复。
AOF重写可以通过auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数控制自动触发，也可以使用bgrewriteaof命令手动触发。子进程执行期间使用copy-on-write机制与父进程共享内存，避免内存消耗翻倍。AOF重写期间还需要维护重写缓冲区，保存新的写入命令避免数据丢失。
总结：
Redis持久化功能一直是影响Redis性能的高发地，可以在理解了Redis持久的基本内容以后，逐渐的深入学习，结合常见的持久化问题进行分析定位和优化。
