Redis持久化机制（面试结构化）
Redis持久化就是把内存的数据保存到磁盘，防止宕机数据全部丢失，有两种：RDB、AOF，也可以两者同时开启。
1. RDB（快照）
把某一时刻全量内存数据，生成一个二进制快照文件dump.rdb保存磁盘。
触发方式
- 手动触发
save：主线程同步执行，会阻塞，大数据量不建议用。bgsave：fork子进程，子进程做快照，主线程继续处理请求，日常主要用这个。 - 自动触发：配置
save 秒 改动次数，比如save 900 1，900秒内至少1个key改动，自动执行bgsave。
优点
- 文件体积小，二进制文件，适合做备份、迁移。
- 恢复速度快，直接加载rdb文件。
缺点
- 会丢失最后一次快照之后的数据：两次快照之间宕机，这部分内存数据没落地磁盘，直接丢失。
- fork子进程时，如果数据量大，会短暂阻塞主线程。
2. AOF（追加日志）
记录每一条写命令，以文本日志形式追加到aof文件；Redis重启时，重新回放日志命令恢复数据。
三种刷盘策略appendfsync
always：每写一条就刷磁盘，几乎不丢数据，性能很差。everysec：每秒刷一次磁盘，默认配置，最多丢失1秒数据，性能和安全折中。no：交给操作系统自己刷盘，不可控，丢失数据多。
AOF重写 bgrewriteaof
AOF日志会越写越大。重写会fork子进程，读取当前内存数据，生成一份精简AOF日志，替换旧大文件，不会记录无效的中间命令。
注意：重写不会阻塞主线程。
优点
- 数据丢失极少，默认everysec最多丢1秒数据，安全性高。
缺点
- AOF日志文件体积一般比RDB大；恢复数据需要回放命令，速度慢于RDB。
3. RDB + AOF同时开启
Redis4.0以后混合持久化：
bgsave生成RDB快照，同时把快照之后增量写命令追加到AOF，aof文件开头是rdb二进制，后面是aof日志。
- 恢复的时候：先加载rdb快照，再回放后面增量AOF命令。
兼顾RDB恢复快、AOF丢失少的优点。
注意：同时开启时，Redis重启优先加载AOF文件。
4. 各自适用场景
- RDB：适合定时冷备份，可以容忍少量数据丢失。
- AOF：追求数据安全，不想丢失大量数据，线上一般开启AOF。
总结
- RDB：全量快照，bgsave子进程，恢复快，存在数据丢失风险；
- AOF：记录写命令日志，三种刷盘策略，靠AOF重写压缩文件；
- 4.0+支持混合持久化，线上最推荐；
- 两种持久化都会fork子进程，大数据量要注意fork带来的短暂阻塞。
