Redis AOF 和 RDB 持久化策略原理

一、数据持久化

默认情况下 Redis 的数据都是保存在内存中,为避免 Redis 进程意外退出而导致数据丢失的问题,Redis 提供了 RDB 和 AOF 两种方式来实现数据的持久化存储。

二、RDB 机制

RDB 机制是以指定的时间间隔将 Redis 中的数据生成快照并保存到硬盘中,它更适合于定时备份数据的应用场景。可以通过手动或者自动的方式来触发 RDB 机制:

2.1 手动触发

可以通过以下两种方式来手动触发 RDB 机制:

  • save :save 命令会阻塞当前 Redis 服务,直到 RDB 备份过程完成,在这个时间内,客户端的所有查询都会被阻塞;
  • bgsave :Redis 进程会 fork 出一个子进程,阻塞只会发生在 fork 阶段,之后持久化的操作则由子进程来完成。

2.2 自动触发

除了手动使用命令触发外,在某些场景下也会自动触发 Redis 的 RDB 机制:

  • redis.conf 中配置了 save m n ,表示如果在 m 秒内存在了 n 次修改操作时,则自动触发 bgsave;
  • 如果从节点执行全量复制操作,则主节点自动执行 bgsave,并将生成的 RDB 文件发送给从节点;
  • 执行 debug reload 命令重新加载 Redis 时,会触发 save 操作;
  • 执行 shutdown 命令时候,如果没有启用 AOF 持久化则默认采用 bgsave<span> </span>进行持久化。

2.3 相关配置

1. 文件目录

RDB 文件默认保存在 Redis 的工作目录下,默认文件名为 dump.rdb,可以通过静态或动态方式修改:

  • 静态配置:通过修改 redis.conf 中的工作目录 dir 和数据库存储文件名 dbfilename 两个配置;
  • 动态修改:通过在命令行中执行以下命令:
    config set dir{newDir}
    config set dbfilename{newFileName}
    

2. 压缩算法

Redis 默认采用 LZF 算法对生成的 RDB 文件做压缩处理, 这样可以减少占用空间和网络传输的数据量,但是压缩过程会耗费 CPU 的计算资源, 你可以按照实际情况,选择是否启用。可以通过修改 redis.conf 中的 rdbcompression 配置或使用以下命令来进行动态修改:

config set rdbcompression{yes|no}

三、AOF 机制

AOF 是 Redis 提供的另外一种持久化的方式,它以独立日志的方式记录每次写入操作,重启时再重新执行这些操作,从而达到恢复数据的命令。

3.1 执行原理

开启 AOF 机制后,所有的写入命令都会追加到 aof_buf 缓冲区中,并按照指定的策略定时将缓冲区中的数据同步到磁盘上。 AOF 除了记录每条命令外,还会在适当的时候 fork 出一个子进程对 AOF 文件进行重写,在重写过程中,Redis 会将可以合并的语句进行合并,将无效的语句进行删除,从而减小 AOF 文件的体积,以便减少文件的占用空间和方便在数据恢复时能够更快的进行加载。

3.2 同步策略

Redis 提供了三种同步策略,用于控制 AOF 缓冲区同步数据到磁盘上的行为,由参数 appendfsync 控制:

可选配置 说明
always 命令写入 aof_buf 后就调系统 fsync 操作同步到 AOF 文件
everysec 命令写入 aof_buf 后就调用系统的 write 操作,但 fsync 同步文件的操作则由专门线程每秒调用一次
no 命令写入 aof_buf 后就调用系统的 write 操作,不对 AOF 文件做 fsync 同步,同步操作由操作系统负责,通常同步周期最长为30秒

write 和 fsync 操作说明:

  • write 操作会触发延迟写机制,Linux 在内核提供页缓冲区用来提高硬盘的 IO 性能,write 操作在写入系统缓冲区后直接返回。同步操作依赖于系统调度机制,例如缓冲区页空间写满或达到特定时间周期。 同步文件之前,如果此时系统故障宕机,缓冲区内数据将丢失。
  • fsync 针对单个文件操作,做强制硬盘同步,fsync 操作将阻塞直到写入硬盘完成后返回,它保证了数据持久化的安全。

Redis 默认的同步机制为 everysec,此时能够兼顾性能和保证数据安全,在发生意外宕机的时,最多会丢失一秒的数据。

3.3 相关配置

想要使用 AOF 功能,需要配置 appendonly 的值为 yes,默认值为 no。默认 AOF 的文件名为 appendonly.aof, 可以通过修改appendfilename 的值进行修改,和 RDB 文件的保存位置一样,默认保存在 Redis 的工作目录下。

四、对比分析

4.1 优点与缺点

RDB 的优点

  • RDB 使用一次性生成内存快照的方式, 产生的文件紧凑压缩比更高, 适用于备份和全量复制等场景。
  • RDB 文件通常比同一数据集的等效 AOF 文件小,所以使用 RDB 恢复数据远远快于 AOF 方式。
  • RDB 最大限度地提高了 Redis 的性能,因为 Redis 父进程只需要 fork 出一个子进程,它本生并不会执行磁盘 I/O 等操作。

RDB 的缺点

  • RDB 方式没办法做到数据的实时持久化,假设每次持久化的时间间隔是 5 分钟,当在上一次持久化后 3 分钟后发生了服务宕机,则这三分钟内的数据会全部丢失。
  • fork 操作是一个重量级的操作,如果数据集很大,Fork 操作可能会非常耗时。

AOF 的优点

  • AOF 能够实现实时或秒级的持久化操作,能够保证数据的最少丢失。
  • 如果突然宕机,日志以半写命令结束,可以使用 redis-check-aof 工具进行修复,从而保证数据最少丢失。

AOF 的缺点

  • AOF 文件通常比同一数据集等效的 RDB 文件大。
  • 根据选择的同步策略的不同,AOF 可能比 RDB 还慢。

4.2 使用建议

按照 Redis 官方的推荐,为保证的数据安全性,可以同时使用这两种持久化机制,在 Redis 官方的长期计划里面,未来可能会将 AOF 和 RDB 统一为单一持久化模型。需要注意的是,在这种情况下,当 Redis 重新启动时,Redis 将使用 AOF 文件重建数据集,因为它可以保证数据的最少丢失。

参考资料

  1. 付磊,张益军 . 《Redis 开发与运维》. 机械工业出版社 . 2017-3-1
  2. 官方文档:Redis Persistence
下一节:复制机制、哨兵模式架构说明、哨兵模式搭建