【Redis】RDB与AOF持久化

持久化

Redis支持RDB持久化、AOF持久化、RDB-AOF混合持久化这三种持久化方式。

为什么要持久化：

Redis的数据存储在内容中，服务停止后数据会消失。为了解决这个问题，Redis提供持久化功能，将数据存储在磁盘上，重启后可以恢复数据。

1. RDB(Redis Database)

1. 通过SAVE和BGSAVE命令持久化

• SAVE： 命令会阻塞进程，直到RDB文件创建完毕。阻塞期间不处理任何命令。不推荐使用
• BGSAVE： 会Fork子进程，子进程创建RDB文件，该过程不阻塞父进程。在BGSAVE执行期间
  • SAVE、BGSAVE命令会被拒绝，避免同时持久化产生竞争
  • BGREWRITEAOF命令会被延迟到BGSAVE结束后执行，因为两者无冲突，且不需要并发大量磁盘写入。

BGREWRITEAOF执行期间，BGSAVE会被拒绝。

2. 自动间隔性持久化

配置多个持久化触发条件，实现自动持久化。如满足下面任意条件就会触发持久化。

 save 900 1   // 900s内至少1次更改
 save 300 10  // 300s内至少10次更改

3. RDB文件载入Redis时机

• 服务启动时检测到RDB文件存在就会自动载入。无专门的命令。
• 若开启AOF持久化功能，会优先使用AOF还原数据。

4. RDB文件结构
RDB文件是经过压缩的二进制文件。

• REDIS五个字符。5字节
• 文件版本如0006。4字节
• 数据信息
• EOF常量。1个字节
• 校验和。8字节
  

5. 对过期键的处理

• 已过期的键不会保存到RDB中
• 主服务器载入RDB时会忽略过期键
• 从服务器载入RDB时不论是否过期都会载入到数据库，等主服务器对其数据同步时会清除掉过期键。

2. AOF(Append Only File)

AOF功能实现分为命令追加(append)、文件写入、文件同步(sync)三个步骤。

• 命令追加： 服务执行一个命令后，会将执行的命令追加到Redis的aof_buf缓冲区末尾。
• 文件写入： 写入是指将aof_buf缓冲区数据取出写到操作系统的内存缓冲区中，而非直接落到磁盘中。
• 文件同步： 同步是指将操作系统的内存缓冲区数据落到磁盘中。

1. 关于文件的写入和同步

• 写入与同步对应着c语言中的write函数： 用户调用write函数，会将数据最终而非直接落到磁盘。操作系统通常会将数据暂存到内存缓冲区中，缓冲区被填满或超过一定时间后才将数据落到缓冲区中。
• 只写入不同步同样会造成数据丢失： 写入只将数据存到缓冲区，同样是在内存中

2. 服务器配置appendfsync影响持久化的效率和安全性

• alway: 写入和同步连续执行，效率低，安全性高，只会丢失最后一次追加在aof_buf的数据
• everysec: 写入后不立即同步，而是每隔1s在子线程中对AOF文件进行同步。可能会丢失1s的命令数据。
• no: 写入后不同步，由操作系统控制。写入速度快，单次同步时间长，安全性低

3. AOF文件还原

生成伪客户端逐步执行存储的命令。

4. AOF重写

命令越多，文件体积越大。可以通过AOF重写，即重写出保存某key最后状态的命令，去除冗余命令，减小体积。

5. 重写期间，服务器执行的工作：

AOF重写不会阻塞父进程。

6. 对过期键的处理

• 未被惰性删除或定期删除，则不会有处理
• 被删除后，会在AOF文件追加DEL命令

3. RDB-AOF混合模式

Redis4.0提出混合方式，即以一定频率执行内存快照（RDB），在两次快照期间用AOF方式记录命令操作。

优点：

• 不需要频繁进行RDB快照存储和Fork出RDB子线程
• AOF只需要记录两次快照之间的命令，避免文件体积过大

4. 对比

	RDB	AOF	RDB-AOF
存储文件体积	压缩的二进制文件，体积小	记录每条命令，体积大	混合记录二进制文件和AOF文件，体积较小
实时性	持久化间隔较长，实时性差	根据配置最多丢1次/1s/1个缓冲区的数据，实时性好	除非RDB期间崩溃，实时性和AOF相同
恢复速度	快	慢	较快
其他	文件可读性差、有版本兼容问题，Fork子进程成本高	文件可读，可手动修改。AOF重写也需要Fork子线程

参考

• 《Redis设计与实现》九到十四章
• Java面试宝典
• Redis进阶 - 持久化：RDB和AOF机制详解