redis持久化有两种方式RDB和AOF：
RDB：
RDB就是将数据通过快照的方式写入二进制文件，使用save和bgsave命令可以生成RDB文件。
save命令是阻塞的，直到redis服务器保存完为止（阻塞主线程，已放弃使用）。bgsave则是fork出一个子进程来保存RDB文件。持久化失败的可能性（1：内存不足以开始fork子进程。2：没有写入权限）
优点：是一个紧凑的文件（压缩），适合备份，方便传输到其他数据中心。备份是通过fork子进程来完成，性能强，与AOF相比，在恢复数据的时候会更快一些。
缺点：宕机时有可能丢失部分数据，当数据量比较大的时候fork过程比较耗时，会阻塞，不能响应客户端请求，而且RDB数据格式的兼容性比较差，最致命的缺点是由于RDB的特点，不能做到实时持久化，在数据越来越重要的今天，数据丢失是无法接受的，所以AOF成为主流。
AOF：
命令追加（append）：将写的命令追加到缓冲区aof_buf
文件写入（write）和文件同步（sync）：根据不同的同步策略将aof_buf中的内容同步到硬盘。
文件重写（rewrite）：定期重写AOF文件，达到压缩的目的。
文件载入（load）：用于服务器重启时恢复数据。
文件同步和写入过程：
将内存缓冲区的数据写入磁盘有三种策略。
1：是每次有新的命令将缓冲区的数据写入到AOF的缓冲区并同步到AOF文件，这种方式的效率会比较慢。
2：是每秒将缓冲区的数据写入AOF的缓冲区并同步到AOF文件（默认选 项），有丢数据可能。
3： 是将缓冲区数据写入AOF缓冲区，但是同步操作交给操作系统。
文件重写：
1：过期的数据不再写入文件。
2：无效的命令不再写入文件，比如删除的数据。
3：命令合并，多条命令整合为一条。
重写自动触发机制，
1：AOF文件体积达到最小 值（默认64M）。
2：AOF文件体积增长比例达到设置的值（默认翻倍）。
手动触发命令（bgrewriteaof）。
优点：
1：支持秒级持久化。
2：可用于不同版本的redis服务器，兼容性强。
3：AOF可读性高，分析容易。
缺点：
AOF文件大，恢复速度慢，对性能影响大。
