深入了解Redis持久化方式——RDB/AOF

Redis提供两种持久化方式

1、【全量】RDB持久化，是指在指定的时间间隔内将内存中的数据集快照写入磁盘。实际操作过程是，fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。

2、【增量】AOF持久化，以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

RDB优缺点

优点：

• 灵活设置备份频率和周期。

• 非常适合冷备份。

• 性能最大化。

• 恢复更快。数据集非常大的情况下，更适合恢复数据

缺点：

• 不能最大限度避免数据丢失

• 建议业务低估使用

AOF优缺点

优点：

• 更高数据安全性，3种同步机制：每秒同步、每修改同步和不同步

• 如果AOF日志过大，Redis可以自动启用rewrite机制。rewrite log的时候，会对其中的指令进行压缩。

• AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。

缺点：

• 相同数据集而言，AOF文件大于RDB文件。RDB文件恢复大数据集的速度快于AOF

• 根据同步策略不同，AOF运行效率慢于RDB

• rewrite时容易发生bug

Redis支持同时开启两种持久化方式，综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择；用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复。

如果同时使用RDB和AOF两种持久化机制，那么在Redis重启的时候，会使用AOF来重新构建数据，因为AOF中的数据更加完整。

定时生成RDB快照非常便于进行数据库备份，并且RDB恢复数据集的速度也要比AOF恢复的速度要快，除此之外，使用RDB还可以避免之前提到的AOF程序的bug。

在Redis实例重启时，会使用bgsave（RDB）持久化文件重新构建内存，再使用AOF重放近期的操作指令来实现完整恢复重启之前的状态。

机器突然掉电会怎样？取决于AOF日志sync属性的配置，每条指令sync一下磁盘（不现实），高性能要求下使用定时sync，最多丢失1秒数据，极端情况下，丢失2秒数据。

bgsave原理：fork和cow。fork是指Redis通过创建子进程来进行bgsave操作。cow指的是copy on write，子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写脏的页面数据会逐渐和子进程分离开来。