Redis 持久化操作 (RDB, AOF)

Redis 持久化操作

Redis提供了两种持久化策略：

• RDB (Redis DataBase)
• AOF (Append Only File)

1. RDB (Redis DataBase)

RDB持久化主要是通过SAVE和BGSAVE两个命令对Redis数据库中当前的数据做snapshot (快照) 并生成rdb文件来实现的。在Redis启动的时候会检测rdb文件，然后载入rdb文件中未过期的数据到服务器中。

• SAVE时只管保存，其它不管，全部阻塞。手动保存。
• BGSAVE是非阻塞的，通过fork了一个子进程来完成的。

SAVE和BGSAVE的区别：

• SAVE 直接调用 rdbSave函数 ，阻塞 Redis 主进程，直到保存完成为止。在主进程阻塞期间，服务器不能处理客户端的任何请求。
• BGSAVE 则 fork 出一个子进程，子进程负责调用 rdbSave 函数，并在保存完成之后向主进程发送信号，通知保存已完成。 Redis 服务器在BGSAVE 执行期间仍然可以继续处理客户端的请求。

RDB可以通过向服务器提供配置信息来自动间隔性保存。如默认情况下服务器满足以下3个条件中任意一个条件就会触发BGSAVE命令。

save 900 1 // 服务器在900秒之内，对数据库进行了至少1次修改
save 300 10 // 服务器在300秒之内，对数据库进行了至少10次修改
save 60 10000 // 服务器在60秒之内，对数据库进行了至少10000次修改

优势：

• 适合大规模的数据恢复
• 对数据完整性和一致性要求不高更适合使用
• 节省磁盘空间
• 恢复速度快

劣势：

• Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
• 虽然Redis在fork时使用了 写时拷贝技术 ,但是如果数据庞大时还是比较消耗性能。
• 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

2. AOF (Append Only File)

以 日志 的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来( 读操作不记录 )， 只许追加文件但不可以改写文件 ，redis启动之初会读取该文件重新构建数据，也就是redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。AOF 一共分为命令追加（append）、文件写入、*文件同步（sync）*三个步骤完成的。AOF是默认不开启的，可以在修改配置文件开启AOF，默认用来储存指令的文件叫做：appendonly.aof

命令追加:

当有修改、删除操作时，服务器会在执行完之后以协议格式将被执行的写命令追加到服务器状态的aof_buf缓冲区的末尾。

文件写入:

Redis的服务进程是一个事件循环，这个循环中的文件事件负责接收客户端的命令请求。服务器在处理文件事件时可能会执行写命令，同时会追加到aof_buf缓冲区，所以在每结束一次循环之前，都会调用flushAppendOnlyFile函数，将aof_buf缓冲区的数据写入到AOF文件里面。

文件同步:

flushAppendOnlyFile函数通过服务器配置appendfsync选项的值来决定的将每次循环结束之前aof_buf缓冲区的数据写入到AOF文件后，将以某种方式同步到AOF文件里面，例如：每次都同步。

AOF重写 (Rewrite)

AOF方式持久化时记录的时一条一条的写命令，随着服务器运行的时间越来越长，AOF文件会越来越大，AOF重写就是为了解决这个问题。

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，redis4.0版本后的重写，是指上就是把rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。

no-appendfsync-on-rewrite ：

• 如果 no-appendfsync-on-rewrite=yes , 不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）
• 如果 no-appendfsync-on-rewrite=no, 还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）

触发机制，何时重写:

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。

• auto-aof-rewrite-percentage：设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发）。
• auto-aof-rewrite-min-size：设置重写的基准值，最小文件64MB。达到这个值开始重写。

如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。

重写流程：

1. bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。
2. 主进程fork出子进程执行重写操作，保证主进程不会阻塞。
3. 子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。
4. (1) 子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。(2) 主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
5. 使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

优势：

• 备份机制更稳健，丢失数据概率更低。
• 可读的日志文本，通过操作AOF稳健，可以处理误操作。

劣势：

• 比起RDB占用更多的磁盘空间。
• 恢复备份速度要慢。
• 每次读写都同步的话，有一定的性能压力。
• 存在个别Bug，造成恢复不能。

3. 总结

两种持久化策略使用那个好？

• 官方推荐两个都启用。
• 如果对数据不敏感，可以选单独用RDB。
• 不建议单独用 AOF，因为可能会出现Bug。
• 如果只是做纯内存缓存，可以都不用。

参考文章：Redis数据持久化方式RDB和AOF的区别