为什么redis需要持久化
Redis对数据的操作时基于内存的，服务器宕机等意外情况，如果没有持久化机制，那么redis中的数据就会丢失无法恢复。有了持久化机制，redis在下次重启的时候可以利用之前的持久化文件进行数据恢复，
- RDB：把当前数据生成快照保存在硬盘中
- AOF：记录每次对数据的操作到硬盘中
RDB持久化
RDB(Redis DataBase)持久化把当前redis中全部数据生成快照保存在硬盘中，RDB持久化可以手动开启，也可以自动触发。
save和bgsave命令可以触发RDB持久化操作。
save命令
执行save命令会手动触发RDB持久化，但是save命令会阻塞Redis服务，直到RDB持久化完成，当Redis服务储存大量数据时，会造成较长时间的阻塞，不建议使用
127.0.0.1:6379> save OK
bgsave命令
执行bgsave命令也会手动触发RDB持久化，和save命令不同的是：Redis服务一般不会阻塞，Redis进程会执行fork操作创建子进程，RDB持久化由子进程负责，不会阻塞Redis服务进程，Redis服务的阻塞只发生在fork，
127.0.0.1:6379> bgsave Background saving started
1，执行bgsave命令，Redis进程先判断当前是否正在执行RDB或者AOF持久化，如果存在就是直接结束，
2，Redis进程执行fork操作创建子进程，在fork操作的过程中Redis进程会被阻塞。
3，Redis进程fork完成后，bgsave命令就会结束，自此Redis进程不会被阻塞，可以进行其他命令。
4，子进程根据Redis进程的内存生成快照文件，并替换掉原来的RDB文件。
5，子进程通过信号量通知Redis进程已完成。
RDB优点
RDB文件一个紧凑的二进程压缩文件，是Redis在某个时间点的全部数据快照，所以使用RDB恢复数据的速度比AOF的快。适合备份，全量复制，灾难恢复等场景。
RDB缺点
每次进行bgsave操作都要执行fork操作创建出子进程，属于重量级操作，频繁执行成本过高，所以无法做到实时持久化。
由于Redis版本的不断迭代，存在不同格式的RDB版本，有可能出现低版本的RDB格式无法兼容高版本的RDB文件的问题。
AOF持久化
AOF（Append Only File）持久化，是把每次写命令追加写入日志中，当需要恢复数据时重新执行AOF文件中的命令就可以了，AOF解决了数据持久化的实时性，最常见主流的Redis持久化操作。
文件同步策略
AOF持久化流程中的文件同步有以下策略：
- always：每次写入缓存区都要同步到AOF文件中，磁盘的操作比较慢，限制了Redis高并发，不建议配置
- no：每次写入缓冲区后不进行同步，同步到AOF文件的操作是由操作系统负责的，每次同步AOF文件的周期不可控，而且增大每次同步的磁盘的数据量。
- eversec：每次写入缓冲区后，由专门的线程每秒同步一次，做到兼顾性能和数据安全，建议的同步策略，也是默认的策略。
触发文件重写
AOF持久化流程中的文件重写可以手动触发，也可以自动触发。
-
手动触发：使用bgrewriteaof命令
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started -
手动触发：根据auto-aof-rewrite-min-size 和auto-aof-rewrite-percentage配置确定自动触发的时机，auto-aof-rewrite-min-size 表示运行AOF重写时文件大小的最小值，默认为64MB，auto-aof-rewrite-percentage表示当前AOF文件大小和上一次重写后AOF文件大小的比值的最小值，默认100，只有前两者同时超时才会触发。
