一、RDB快照（snapshot）

在默认情况下， Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。
设置规则：在N秒内至少有M个改动，自动保存一次数据收集
例如：
save 60 1000 //60秒内，至少有1000次改动，则保存一次
可以手动执行：save或bgsave（异步执行），每次执行都会覆盖原来的快照文件
特点：执行快，恢复数据快（只需要恢复快照就行），但容易丢失数据（没有到达执行策略的条件）

二、AOF（append-only file）

AOF 持久化，将修改的每一条指令记录进文件appendonly.aof中(先写入os cache，每隔一段时间fsync到磁盘)
配置有三个选项：
appendfsync always：每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全。
appendfsync everysec：每秒 fsync 一次，足够快，并且在故障时只会丢失 1 秒钟的数据。
appendfsync no：从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择。
一般我们都选择默认的everysec
有重写策略：
auto-aof-rewrite-min-size 64mb //aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就很快，重写的意义不大
auto-aof-rewrite-percentage 100 //aof文件自上一次重写后文件大小增长了100%则再次触发重写
重写会把多余的命令合并，缩小文件大小
可以手动执行：bgrewriteaof
特点：执行速度根据配置来，恢复速度慢，数据丢失根据配置（always配置则不会丢失数据，但是非常慢；everysec异常情况下会丢失一秒钟的数据）

三、Redis 4.0 混合持久化

重启时，我们很少使用RDB来恢复数据（如果我们同时开启RDB和AOF，默认使用AOF来恢复数据），使用AOF恢复数据，启动则需要花费很长时间，reids 4.0 解决了该问题，新增功能混合持久化；
需要先开启AOF，该功能依赖AOF，再开启配置：
aof-use-rdb-preamble yes
开启后，不再是单纯的记录命令到AOF文件中，在触发AOF重写操作时，这一刻将之前的RDB快照，写入AOF文件中，增量的修改命令，还是用原来的方式保存，混合持久化文件结构如下：