Redis的两种持久化机制

Redis有两种持久化方案

Redis持久化

Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失，所以Redis提供了持久化的功能

RDB(Redis DataBase)

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

Redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，在用这个临时文件替换上次持久化好的文件，整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据库恢复的完整性要求不是很高，那RDB方式要比AOF方式更加高效，RDB的缺点是最后一次持久化的数据可能丢失，我们默认的就是RDB，一般情况下不需要修改这个配置。

触发机制：

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

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

如何恢复rdb文件？

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

2. 查看需要存放的位置

   127.0.0.1:6379> config get dir
   1) "dir"
   2) "/usr/local/bin" #如果在这个目录下存在dump.rdb文件，启动就会自动恢复其中的数据

优点：

1. 适合大规模的数据恢复
2. 对数据的完整性要求不高

缺点：

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

AOF(Append OnlyFile)

将所有命令记录下来，恢复的时候就把这个文件全部在执行一遍

默认的不开启的，我们需要手动进行配置，。只需要将appendonly改为yes

如果appendonly.aof被修改的话，可以使用redis-check-aof修复，

redis-check-aof --fix appendonly.aof

优点和缺点

# appendfsync always  # 每次修改都会sync，消耗性能
appendfsync everysec  # 每秒执行一次sync，可能会丢失1s的数据
# appendfsync no   # 不执行sync，这个时候操作系统自己同步数据，速度最快

优点：

1. 每一次修改都同步，文件的完整会更加好
2. 每秒同步一次，可能会丢失一秒的数据
3. 从不同步，效率最高的

缺点：

1. 相对于数据来说，aof远远大于rdb，修复的速度也比rdb慢
2. aof运行效率也要比rdb慢，所以我们redis默认的配置就是rdb持久化