Redis持久化——RDB AOF

Redis持久化

Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，一旦服务器进程退出，数据库状态将丢失，

RDB （Redis DataBase)

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

会单独创建一个子进程来进行持久化（fork作用是复制一个与当前进程相同的进程，这是个全新的进程，作为原来进程的子进程）

先将数据写入一个临时文件，等持久化过程都结束了，再用这个临时文件替换上次持久化好的文件，整个过程主进程不进行IO操作，确保及高性能

唯一缺点是最后一次持久化的数据可能丢失

rdb保存的文件是dump.rdb（根据配置文件）

触发机制

• 当配置文件中的save 条件满足时
• 执行flushAll命令时，但里面是空的，无意义
• 退出redis时

如何恢复RDB文件

只需将文件放入redis启动目录（/usr/local/bin），reids启动时会自动检查dump.rdb，并恢复其中数据

优点：

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

缺点：

1. 如果redis意外宕机了，最后一次修改的数据将会丢失
2. fork进程时，需占用内存空间

AOF （Append Only File）

如要使用，先在配置文件中开启

以日志的形式将所有的命令都记录下来（读数据操作不记录），恢复时，将这个文件全部执行一遍

AOF保存的文件名为appendonly.aof

如果AOF文件遭到破坏，redis是启动不起来的

redis提供了工具可以修复aof文件

执行以下命令即可

redis-check-aof --fix appendonly.aof

文件正常之后，重启就可以恢复了

缺点：

1. 相对于数据文件来说，aof远远大于rdb，修复速度也比rdb慢
2. 运行效率也比rdb慢

优点：

文件完整性会更好（当然这取决于配置文件中的配置）

# appendfsync always # 每次修改都会同步，效率太低
appendfsync everysec # 每一秒同步一次，可能会丢失这一秒的数据
# appendfsync no     # 不同步，操作系统自己同步数据，速度最快

扩展：

重写原理

• AOF 文件持续增长而过大时，会 Fork 出一条新进程来将文件重写（也是先写临时文件最后再 rename）。
• 遍历新进程的内存中数据，每条记录有一条的 set 语句。
• 重写 aof 文件的操作，并没有读取旧的 aof 文件，这点和快照有点类似。

aof默认是文件的无限累加，文件越来越大，所以设置了重写机制

auto-aof-rewrite-min-size 64mb    # 默认是文件大小达到64兆，重写到新文件

如果同时开启两种持久化方式，重启redis默认会先载入aof。因为aof数据集要比rdb更加完整，而且rdb不实时，所以rdb更适合用于备份数据库（aof不断变化不好备份）