【Redis】的持久化机制AOF和RDB

Redis的持久化机制

为什么Redis需要持久化?(持久化的必要性)

Redis是一个内存数据库，如果没有持久化，那么在数据库连接时保存的数据，在数据库关闭连接时就会销毁。而我们希望在Redis中保存的数据能够持久化保存。

Redis提供了两种持久化的机制：RDB和AOF。

RDB

RDB：Redis DataBase

在指定的时间间隔内将内存中的数据集体快照写入磁盘，也就是Snapshot快照，它恢复是将快照文件直接读到内存中。

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上传持久化好的文件。整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的回复，且对于数据恢复的完整性不是非常敏感，那么RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

Redis默认使用的就是RDB的持久化策略,一般情况下不需要更改该配置

但是RDB持久化机制也是有缺点的:

假如说我们在持久化的时候宕机了，那么最后一次持久化的数据就没有在RDB文件中，可能会丢失文件。

RDB保存的文件就是dump.rdb文件。

看一下配置文件

触发机制：

1. save的规则满足的情况下，会自动触发rdb规则。
2. 执行flushall命令，也会触发我们的rdb规则。
3. 退出redis，也会产生rdb文件。

备份就自动生成一个dump.rdb。

如何恢复rdb文件：

只需要将rdb文件放在我们redis启动目录就可以，redis启动的时候回自动检查dump.rdb恢复其中的数据。

优点：

1. 适合处理大规模的数据恢复。（而且在生成rdb文件时，主进程没有IO进程（是fork另一个子进程来执行的），因此效率很高）
2. 对数据完整性要求不高的。（因为是要符合规定的规则，比如说60s内修改key10000次才产生dump文件，但是如果在59s时服务器宕机了，这时就丢失了文件）

缺点：

1. 需要一定的时间间隔，如果redis意外宕机了，这个最后一次修改数据就没有了！
2. fork子进程时，会占用一定的内存空间。

一般在生产环境下，我们会将dump文件备份，然后供后续使用

AOF

AOF:（Append Only File）

将我们执行的所有命令都记录下来，相当于history，恢复的时候就将aof文件重新执行一遍。（只记录写的操作，不记录读的操作）。

aof默认是不开启的,需要手动修改配置文件的配置。

如果aof文件在恢复数据库时，发现是aof文件时错误的，那么就要使用aof的检测文件来检测和修复然后再恢复redis。redis提供了一个工具redis-check-aof --fix

优点:

1. 可以设置每一次修改都同步，那么文件的完整性会更好
2. 默认开启的是每秒同步一次，那么假如服务器宕机的话，只会丢失1s的数据
3. 也可以设置为从不同步，那么效率是最高的

缺点:

1. 相对于数据文件来说，aof远远大于rdb，修复的速度也比rdb慢
2. aof的运行效率也比rdb慢，所以rdb的默认配置是rdb开启，而aof关闭。