RDB（快照）
二进制文件，保存某个时间点的数据。
两种策略方式：
save（同步）：执行命令save，同步方式可能导致线程阻塞；
bgsave(异步)：fork一个子进程，让子进程去完成RDB的生成，完成后会通知主进程。
自动持久化：
通过配置让Redis在某个条件触发时自动进行持久化；如 save m n配置;
save 900 1 900秒内至少有1个key被改变则做一次快照
save 300 10 300秒内至少有300个key被改变则做一次快照
save 60 10000 60秒内至少有10000个key被改变则做一次快照
在以下情况下也会主动触发RDB：
主从复制时，从库全量同步主库数据时，主库会执行bgsave命令；
执行flushall清空数据库命令时会触发；
客户端执行shutdown命令时会触发；
一般来说，在进行RDB持久化时，主线程会fork一个子线程,去出持久化此时的数据，需要一定的时间，而在这段时间的数据变化不会反馈到快照文件中。
AOF(日志文件)
记录每一条成功的命令，只记录对内存数据修改的命令。
AOF的写入策略
Redis在执行修改内存数据的命令时，并不是直接刷到磁盘文件，而是①先写入到内核的内存缓冲区，②根据策略将内容从内核缓冲区异步刷新到磁盘文件；
策略（影响内核执行fsync函数的时间）：
1、always：当执行的命令一到缓冲区就立刻刷新到磁盘AOF文件；
优缺点：数据完整，不会出现丢失，但是每次内存操作会绑定一次磁盘IO操作，影响Redis的写性能。
2、everysec：每秒刷新一次； 折中方案，一定程度保证了数据完整和性能。
3、no：不强制刷新；由操作系统决定； 一般不使用，无法确定同步日志的时间，丢失数据。
AOF的重写
随着时间 AOF文件会越来越大，可以进行重写。进行文件瘦身，减少文件大小。
AOF文件中可能存在这样的命令 key对应的值修改为1，然后再修改为2，重复一千次，最终key对应的value为1000，AOF文件注重结果而非过程，所以可以等同于直接将key值改为1000。
Redis提供bgrewriteaof指令，开辟一个子进程，对当期内存中的数据进行遍历，转换为一系列的操作指令， 然后序列化写入到新的AOF文件中，完成后再将操作间的增量操作写入到新的AOF文件中，都完成后替换 掉旧的AOF文件。
Redis建议的持久化策略：AOF+RDB
混合持久化：RDB文件内容和AOF增量文件内容在同一个AOF文件中，在进行RDB快照过程中，会进行AOF增量日志记录，通常文件RDB占大头，AOF日志文件很少。Redis宕机重启时会先加载RDB快照，然后读取增量AOF日志进行数据恢复。
