redis持久化机制
redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，如武器中的数据状态也会消息。所以redis提供了持久化功能。
RDB(Redis DataBase)
在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加高效。RDB的缺点是最后一次持久化的数据可能会丢失。
我们默认的就是RDB，一般情况下不需要修改这个配置
RDB保存的文件是dump.rdb，默认保存在bin目录下
触发机制
- 满足配置文件save条件的情况下，会自动触发RDB规则
- 执行flushall命令，也会触发RDB规则
- 退出redis，也会产生dump.rdb文件
恢复备份数据，只需要将dump.rdb文件放在redis启动目录（bin）就可以，redis启动的时候会自动检查dump.rdb恢复其中的数据
优点
- 适合大规模的数据恢复
- RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快
缺点
- 需要一定的时间间隔进程操作，如果redis意外宕机了，这个最后一次修改的数据就没有了
- fork进程的时候，会占用一定的内存空间
AOF(Append Only File)
将我们的所有命令都记录下来，恢复的时候就把这个文件包含的命令全部再执行一遍
以日志的形式来记录每个写操作，将redis执行过的所有指令记录下来（读操作不记录），只许追加文件，不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次来完成数据的恢复工作
AOF保存的文件是appendonly.aof，默认也是保存在bin目录下
redis默认是不开启AOF的，需要修改配置文件将appendonly设置为yes手动开启
如果appendonly.aof文件有错，redis是启动不了的，我们需要修复这个文件
redis给我们提供了一个修复工具，执行命令：redis-check-aof --fix appendonly.aof 进行修复
触发机制
- 每一次修改都同步，文件的完整性更好
- 每秒同步一次，可能会丢失那一秒的数据
- 从不同步，效率最高
优点
- 数据的完整性更好
缺点
- 相对于数据文件来说，AOF远远大于RDB
- 因为AOF需要进行写操作，运行效率低，修复的速度比RDB慢
如果同时开启两种持久化方式，redis会优先载入AOF文件来恢复原始数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整；而且RDB的数据不实时，同时启动两者是服务器重启也只会找AOF文件