Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘中，那么一旦服务器进程退出，服务器的数据库状态也会消失，所以Redis提供了持久化功能。
RDB（Redis DataBase）
- 在指定的时间间隔内将内存中的数据集快照写入磁盘，它恢复时是将快照文件直接读到内存里。
- Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行IO操作的，这就确保了极高的性能。
- 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式比AOF方式更加高效。
- RDB的缺点是最后一次持久化后的数据可能丢失。
-
RDB保存的默认文件是dump.rdb
触发机制
-
sava规则满足的情况下，会自动触发rdb规则
- 执行 flushall 命令，也会触发我们的rdb规则
- 退出Redis，也会产生 rdb 文件
备份就自动生成一个dump.rdb文件
恢复rdb文件
- 只需要将rdb文件放在我们的redis启动目录就可以，redis启动的时候会自动检查dump.rdb恢复其中的数据
- 查看需要存在的位置
127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin" # 如果这个目录下存在dump.rdb 文件，启动就会自动恢复其中的数据
优点
- 适合大规模的数据恢复
- 对数据的完整性要求不高
缺点
- 需要一定的时间间隔进行操作！如果redis意外宕机了，最后一次修改的数据就没有了
- fork进程的时候，会占用一定的内存空间
AOF（Append Only File）
将我们的所有命令都记录下来，history，恢复的时候就把文件全部都执行一遍！
- 以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录）
- 只追加文件但不可以改写文件
- redis启动之初会读取该文件重新构建数据
- Aof保存的是 Appendonly.aof文件
append
-
默认是不开启的，我也要进行手动配置。只需要将 appendonly 改为 yes就开启了aof，重启redis即可生效
- 如果aof文件有错误，这时候redis是无法启动的，我们需要修复这个aof文件，redis给我们提供了一个工具
redis-check-aof --fix appendonly.aof
优点
- 每次修改都同步，文件的完整性会更加好
- 每秒同步一次，可能会丢失一秒的数据
- 从不同步，效率最高
缺点
- 相对于数据文件来说，aof远远大于rdb，修复速度也比rdb慢
- aof运行效率也要比rdb慢，所以我们redis默认的配置就是rdb持久化
appendonly no # 默认不开启，默认使用rdb方式持久化，在大部分情况下，rdb完全够用
appendfilename "appendonly.aof" # 持久化文件的名字
# appendfsync always # 每次修改都会同步 sync，消耗性能
appendfsync everysec # 每秒执行一次 sync，可能会丢失这一秒的数据
# appendfsync no # 不执行 sync，这个时候操作系统自己同步数据，速度最快
# rewrite 重写
如果
