redis 的持久化方式——RDB 和 AOF 的介绍以及优缺点

一、RDB#

RDB (Redis Database) 持久化方式是以指定时间间隔保存是某个时间点的快照。也就是说，Redis 会在某种策略（比如说在900秒内有一次改变）条件达成时进行数据集的备份，数据会备份到 dump.rdb 文件中。

RDB 持久化策略可以在 Redis 配置文件 redis.conf 中修改，配置示例如下：

# save <seconds> <changes>
save 3600 1
save 300 100
save 60 10000

RDB 的优点#

• RDB 是 Redis 数据的一个非常紧凑的单文件。 RDB 文件非常适合备份，可以非常轻松地进行容灾恢复。
• RDB 非常适合灾难恢复，它是一个可以远程传输的压缩文件。
• RDB 最大限度地提高了 Redis 的性能，因为 Redis 父进程为了持久化而需要做的唯一工作就是 fork 一个子进程。父进程永远不会执行磁盘 I/O 或类似操作。
• 与 AOF 相比，RDB 允许使用大数据集更快地重启。
• 在副本上，RDB 支持重启和故障转移后的部分重新同步。

RDB 的缺点#

• RDB 可能会导致数据的丢失。比如，在上一次 RDB 备份之后，又生成了新的数据，这时 Redis 非正常停止了（例如断电），那么这些新数据就会丢失。
• RDB 可能会导致性能问题。RDB 需要经常 fork() 以便使用子进程在磁盘上持久化。如果数据集很大，fork() 可能会很耗时, 如果 CPU 性能又不是很好，可能会导致 Redis 停止为客户端服务几毫秒甚至一秒钟。

二、AOF#

AOF (Append Only File) 持久化方式记录服务器接收到的每个写入操作持久化到 appendonly.aof 文件中，在服务器启动时将再次执行，重建原始数据集。Redis 能够在日志变得太大时在后台重写日志。

AOF 的优点#

• 使用 AOF 有更好的持久性。可以有不同的同步策略：从不同步（no）、每秒同步（eversec）、每次写入时同步（always）。默认使用每秒同步的策略，写入性能仍然很好。同步是使用后台线程执行的，当没有同步正在进行时，主线程将努力执行写入，因此您只能丢失一秒钟的写入。
• AOF 日志是一个仅附加日志，因此不会出现寻道问题，也不会在断电时出现损坏问题。即使出现问题，redis-check-aof 工具也能够轻松修复它。
• 当 AOF 变得太大时，Redis 能够在后台自动重写 AOF。重写是完全安全的，因为当 Redis 继续附加到旧文件时，会使用创建当前数据集所需的最少操作集生成一个全新的文件，一旦第二个文件准备就绪，Redis 就会切换两者并开始附加到新的那一个。
• AOF 以易于理解和解析的格式包含所有操作的日志。可以轻松导出 AOF 文件。例如，即使不小心使用 FLUSHALL 命令刷新了所有内容，只要在此期间没有执行日志重写，仍然可以通过停止服务器、删除最新命令并重新启动 Redis 来恢复数据集。

AOF 同步策略#

• no: 不调用 fsync, 让操作系统在需要时刷新数据，速度最快。
• always: 在每次写入 appendonly 日志之后调用 fsync，速度最慢但是数据安全性最高。
• everysec（默认）: 每秒调用 fsync, Redis 性能和数据安全性适中。

配置如下所示：

# appendfsync always
appendfsync everysec
# appendfsync no

AOF 的缺点#

Redis 7.0之后

• AOF 文件通常比相同数据集的 RDB 文件大。
• 根据确切的 fsync 策略，AOF 可能比 RDB 慢。一般来说，将 fsync 设置为 everysec 的性能仍然非常高，并且在禁用 fsync 的情况下，即使在高负载下它也应该与 RDB 一样快。即使在巨大的写入负载的情况下，RDB 仍然能够提供最大延迟的更多保障。

Redis 7.0以前

• 如果在重写期间有数据的写入，AOF 可能会使用大量内存（这些被缓冲在内存中并在最后写入新的 AOF）。
• 重写期间到达的所有写入命令都会写入磁盘两次。
• Redis 会在重写结束时冻结写入并将这些写入命令同步到新的 AOF 文件。

三、建议#

1. 如果对数据安全性有非常高的要求，建议 RDB 和 AOF 同时启用。
2. 如果对数据安全性要求不是很高，能够容忍数据的丢失，建议单独使用 RDB。
3. 不推荐单独使用 AOF，因为对于进行数据库备份、更快重启以及 AOF 引擎中出现错误的情况来说，RDB 是更好的选择。