1、触发机制：
save手动触发：阻塞当前redis服务器，直到rdb过程完成。不建议使用
bgsave手动触发：fork创建子进程，由子进程完成持久化。阻塞只存在fork阶段。
自动触发：
save m n （在m内修改n次，自动触发bgsave）
从节点执行全量复制，主节点自动执行bgsave
执行debug reload命令，触发save
执行shutdown，没有开启AOF自动执行bgsave
2、持久化文件处理方式
默认采用LZF算法对生成RDB二进制文件压缩。（压缩会消耗cpu，但能大幅降低文件体积）
3、优点
适用于备份、全量复制场景。比如每6小时执行bgsave，用于熔灾恢复。
RDB恢复数据远快于AOF
4、缺点
不能做到秒级、实时持久化， fork子进程、频繁执行，性能耗费严重
使用特定二进制格式保存，存在新老版本不兼容问题
AOF介绍1、触发机制：采用缓冲区文件同步策略。可配置写入文件时机。
同步策略介绍：新命令写入AOF缓冲区 -> sync按规则将缓冲区向硬盘同步 ->在硬盘AOF文件过大时，按规则对文件重写。
sync同步硬盘3种策略：
always：有新命令立即执行，将文件同步到硬盘
everysec（推荐）：每秒同步一次
no：同步硬盘操作由操作系统负责，周期最长30s
2、AOF文件重写机制详解
重写后硬盘文件通过以下方式进行压缩
1、进程内的超时数据不再进行保存
2、旧的AOF无效命令直接生成数据。如del key、hdel key、set aaa 1 set aaa2
3、多条命令合并处理。对于list、set、zset、hash类型。防止单条数据过大，以64个元素拆分多条
AOF重写触发机制
1、手动调用 bgrewriteaof
2、根据配置自动触发 auto-aof-rewrite-min-size（默认64M，超过此数值执行），auto-aof-rewrite-percentage（新增数据超过，最后一次执行的百分之几触发）。两者同时满足后触发
3、持久化文件处理方式
采用文本格式直接存储。兼容性更好，避免二次处理开销。
4、优点
可以实现秒级、实时持久化，且性能耗费低
5、缺点
everysec策略，存在追加阻塞可能，严重情况小概率会丢失2s数据
恢复数据耗时较长
