Redis AOF Vs RDB

概述

Redis持久化主要有2种方式，一种是基于内存快照的RDB格式，另外一种是基于操作日志的AOF格式，下面简单整理一下相关知识点。

RDB

• RDB是基于内存快照的方式对Redis数据进行持久化，方式有两种，一种是自动触发，一种是手动触发。
• 对于生成的RDB文件，Redis默认采用LZF算法进行压缩，然后进行网络传输。

手动触发

• 方式1:执行save命令
  • 优点：整体执行时间快
  • 缺点：执行过程中，阻塞Redis相关操作
• 方式2:执行bgsave命令
  • fork一个子进程，RDB持久化过程由子进程负责，整个过程中只有fork阶段是阻塞的。
  • 优点：阻塞Redis相关操作时间较短
  • 缺点：整体执行时间较长

自动触发

• 配置文件中配置了：m秒内执行的n次修改，则触发bgsave

  save m n

• 新加入从节点，需要复制主节点全部数据，则触发bgsave生成RDB文件，提供给从节点恢复数据
• 执行shutdown命令时，如果没有配置AOF，则触发bgsave生成RDB文件，下次启动时进行恢复。

优缺点

• 优点
  • RDB文件是一个经过压缩的二进制文件，非常适合全量备份，全量复制等场景。
  • Redis加载并恢复RDB文件速度非常快，远超过AOF方式。
• 缺点
  • 创建RDB文件多少需要导致Redis停顿(无论save还是bgsave)，所以不适合实时生成，无法实时备份
  • 不同版本的Redis可能无法互相兼容
  • 如果最后一次备份RDB时候down机，数据可能丢失，数据完整性无法得到保障。

AOF

• AOF实际上是Append Only File的缩写，该方式会生成一个独立的日志文件，记录每次的写入的命令。恢复的时候则重新执行AOF文件中的每一条命令。

• 如果需要开启AOF格式，需要修改Redis配置文件,这个配置默认是不开启的:

  appendonly yes

• 重写触发配置如下：

  auto-aof-rewrite-percentage 100
  auto-aof-rewrite-min-size 500mb

• AOF执行分4个阶段：

  • 命令写入（append）：将所有命令追加到缓冲区中
  • 文件同步（sync）：将缓冲区中的数据同步落盘
  • 文件重写（rewrite）：定期对AOF文件进行重写操作，主要是进行压缩(比如插入后又删除，这种数据直接从aof中移除)。
  • 重启加载（load）：读取aof文件，并重写加载数据

优缺点

• 优点
  • 提供多种同步策略：
    • 每秒同步（一般推荐使用这个）
    • 每次修改同步（效率较低，但是数据可靠）
    • 不同步
  • 适合数据完整性要求较高场景
• 缺点
  • 随着追加数据越来越多，AOF越来越大。
  • 数据恢复过程较慢。
  • 通常同等情况下，AOF文件大于RDB文件大小。

其他

• 其实目前生产环境中很少有只是使用其中一种模式的，往往都是两种模式开启，作为互补使用。
• 对于一些特殊场景，比如只是用来做缓存，则可以关闭持久化，以提升性能。