Redis 持久化详解

  Redis 支持 RDB 和 AOF 两种持久化机制，持久化功能有效地避免因进程退出造成的数据丢失问题，当下次重启时利用之前持久化的文件即可实现数据恢复。

  

1. RDB

  RDB 持久化是把当前进程数据生成快照保存到硬盘的过程，触发 RDB 持
久化过程分为手动触发和自动触发。

  

1.1 触发机制

手动触发分别对应 save 和 bgsave 命令：

• save 命令：阻塞当前 Redis 服务器，直到 RDB 过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用；
• bgsave 命令：Redis 进程执行 fork 操作创建子进程，RDB 持久化过程由子进程负责，完成后自动结束。阻塞只发生在 fork 阶段，一般时间很短。运行 bgsave 命令对应的 Redis 日志如下：

* * * *
Background saving started by pid 3151
DB saved on disk
RDB: 0 MB of memory used by copy-on-write Background saving terminated with success

  显然 bgsave 命令是针对 save 阻塞问题做的优化。因此 Redis 内部所有的涉及 RDB 的操作都采用 bgsave 的方式，而 save 命令已经废弃。

  除了执行命令手动触发之外，Redis 内部还存在自动触发 RDB 的持久化机制，例如以下场景：

• 使用 save 相关配置，如 “save m n”。表示 m秒内数据集存在 n次修改时，自动触发 bgsave；
• 如果从节点执行全量复制操作，主节点自动执行 bgsave 生成 RDB 文件并发送给从节点；
• 执行 debug reload 命令重新加载 Redis 时，也会自动触发 save 操作；
• 默认情况下执行 shutdown 命令时，如果没有开启 AOF 持久化功能则自动执行 bgsave。

  

1.2 流程说明

  bgsave 是主流的触发 RDB 持久化方式，下面根据图了解它的运作流程：

• 1)执行 bgsave 命令，Redis 父进程判断当前是否存在正在执行的子进程，如 RDB/AOF 子进程，如果存在 bgsave 命令直接返回。
• 2)父进程执行 fork 操作创建子进程，fork 操作过程中父进程会阻塞，通过 info stats 命令查看 latest_fork_usec 选项，可以获取最近一个 fork 操作的耗时，单位为微秒。
• 3)父进程 fork 完成后，bgsave 命令返回 “Background saving started” 信息 并不再阻塞父进程，可以继续响应其他命令。
• 4)子进程创建 RDB 文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。执行 lastsave 命令可以获取最后一次生成 RDB 的时间，对应 info 统计的 rdb_last_save_time 选项。
• 5)进程发送信号给父进程表示完成，父进程更新统计信息，具体见 info Persistence 下的 rdb_* 相关选项。

  

1.3 RDB文件的处理

• 保存：RDB 文件保存在 dir 配置指定的目录下，文件名通过 dbfilename 配置指定。可以通过执行 config set dir{newDir} 和 config set dbfilename{newFileName} 运行期动态执行，当下次运行时 RDB 文件会保存到新目录；

当遇到坏盘或磁盘写满等情况时，可以通过 config set dir{newDir} 在线修改文件路径到可用的磁盘路径，之后执行 bgsave 进行磁盘切换，同样适用于 AOF 持久化文件。

• 压缩：Redis 默认采用 LZF 算法对生成的 RDB 文件做压缩处理，压缩后的文件远远小于内存大小，默认开启，可以通过参数 config set rdbcompression{yes|no} 动态修改；

虽然压缩 RDB 会消耗 CPU，但可大幅降低文件的体积，方便保存到硬盘或通过网络发送给从节点，因此线上建议开启。

• 校验：如果 Redis 加载损坏的 RDB 文件时拒绝启动；

  

1.4 RDB的优缺点

RDB 的优点：

• RDB 是一个紧凑压缩的二进制文件，代表 Redis 在某个时间点上的数据快照。非常适用于备份，全量复制等场景；
• Redis 加载 RDB 恢复数据远远快于 AOF 的方式。

  

RDB 的缺点：

• RDB 方式数据没办法做到实时持久化/秒级持久化。因为 bgsave 每次运行都要执行 fork 操作创建子进程，属于重量级操作，频繁执行成本过高；
• RDB 文件使用特定二进制格式保存，Redis 版本演进过程中有多个格式的 RDB 版本，存在老版本 Redis 服务无法兼容新版 RDB 格式的问题；

  针对 RDB 不适合实时持久化的问题，Redis 提供了 AOF 持久化方式来解决。

  

  

2. AOF

  AOF (append only file) 持久化：以独立日志的方式记录每次写命令，重启时再重新执行 AOF 文件中的命令达到恢复数据的目的。AOF 的主要作用是解决了数据持久化的实时性，目前已经是 Redis 持久化的主流方式。

  

2.1 使用AOF

  开启 AOF 功能需要设置配置：appendonly yes，默认不开启。AOF 文件名通过 appendfilename 配置设置，默认文件名是 appendonly.aof。保存路径同 RDB 持久化方式一致，通过 dir 配置指定。

AOF 的工作流程操作：

• 命令写入 (append)
• 文件同步 (sync)
• 文件重写 (rewrite)
• 重启加载 (load)

流程如下：

• 1)所有的写入命令会追加到 aof_buf (缓冲区) 中。
• 2)AOF 缓冲区根据对应的策略向硬盘做同步操作。
• 3)随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩的目的。
• 4)当 Redis 服务器重启时，可以加载 AOF 文件进行数据恢复。

  

2.2 执行流程

2.2.1 命令写入

  AOF 命令写入的内容直接是文本协议格式。例如 set hello world 这条命令，在AOF 缓冲区会追加如下文本:

*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n

  

AOF为什么直接采用文本协议格式：

• 文本协议具有很好的兼容性；
• 开启 AOF 后，所有写入命令都包含追加操作，直接采用协议格式，避免了二次处理开销；
• 文本协议具有可读性，方便直接修改和处理。

  

AOF 为什么把命令追加到 aof_buf 中?

• Redis 使用单线程响应命令，如果每次写 AOF 文件命令都直接追加到硬盘，那么性能完全取决于当前硬盘负载；
• 先写入缓冲区 aof_buf 中，还有另一个好处，Redis 可以提供多种缓冲区同步硬盘的策略，在性能和安全性方面做出平衡。

  

2.2.2 文件同步

  Redis 提供了多种 AOF 缓冲区同步文件策略，由参数 appendfsync 控制，不同值的含义如表所示：

系统调用 write 和 fsync 说明：

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

• 配置为 always 时，每次写入都要同步 AOF 文件，在一般的 SATA 硬盘 上，Redis 只能支持大约几百 TPS 写入，显然跟 Redis 高性能特性背道而驰， 不建议配置。
• 配置为 no，由于操作系统每次同步 AOF 文件的周期不可控，而且会加大每次同步硬盘的数据量，虽然提升了性能，但数据安全性无法保证。
• 配置为 everysec，是建议的同步策略，也是默认配置，做到兼顾性能和数据安全性。理论上只有在系统突然宕机的情况下丢失 1秒的数据。

  

2.2.3 重写机制

  随着命令不断写入 AOF，文件会越来越大，为了解决这个问题，Redis 引入 AOF 重写机制压缩文件体积。AOF 文件重写是把 Redis 进程内的数据转化为写命令同步到新AOF文件的过程。

  

重写后的AOF文件为什么可以变小：

• 1)进程内已经超时的数据不再写入文件；
• 2)旧的 AOF 文件含有无效命令，如 del key1、hdel key2、srem keys、set a111、set a222等。重写使用进程内数据直接生成，这样新的 AOF 文件只保留最终数据的写入命令。
• 3)多条写命令可以合并为一个，如：lpush list a、lpush list b、lpush list c 可以转化为：lpush list a b c。为了防止单条命令过大造成客户端缓冲区溢出，对于list、set、hash、zset 等类型操作，以64个元素为界拆分为多条。

  AOF 重写降低了文件占用空间，除此之外，另一个目的是：更小的 AOF 文件可以更快地被 Redis 加载。

  

AO F重写过程可以手动触发和自动触发：

• 手动触发：直接调用 bgrewriteaof 命令；
• 自动触发：根据 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 参数确定自动触发时机。
  • auto-aof-rewrite-min-size：表示运行 AOF 重写时文件最小体积，默认为64MB；
  • auto-aof-rewrite-percentage：代表当前 AOF 文件空间 (aof_current_size) 和上一次重写后 AOF 文件空间 (aof_base_size) 的比值。

  

当触发 AOF 重写时，内部做了哪些事呢？

流程说明：

1. 执行AOF重写请求：
   • 如果当前进程正在执行 AOF 重写，请求不执行并返回；
   • 如果当前进程正在执行 bgsave 操作，重写命令延迟到 bgsave 完成之后再执行。
2. 父进程执行 fork 创建子进程，开销等同于 bgsave 过程：
3. 主进程 fork 操作完成后，继续响应其他命令。所有修改命令依然写入 AOF 缓冲区并根据 appendfsync 策略同步到硬盘，保证原有 AOF 机制正确性。
4. 由于 fork 操作运用写时复制技术，子进程只能共享 fork 操作时的内存数据。由于父进程依然响应命令，Redis 使用 “AOF 重写缓冲区” 保存这部分新数据，防止新 AOF 文件生成期间丢失这部分数据；
5. 子进程根据内存快照，按照命令合并规则写入到新的 AOF 文件。每次批量写入硬盘数据量由配置 aof-rewrite-incremental-fsync 控制，默认为 32MB，防止单次刷盘数据过多造成硬盘阻塞；
6. 新 AOF 文件写入完成后，子进程发送信号给父进程，父进程更新统计信息，具体见i nfo persistence 下的 aof_* 相关统计
7. 父进程把 AOF 重写缓冲区的数据写入到新的 AOF 文件；
8. 使用新 AOF 文件替换老文件，完成 AOF 重写。

  

2.2.4 重启加载

  AOF 和 RDB 文件都可以用于服务器重启时的数据恢复。如图所示， 表示 Redis 持久化文件加载流程：

流程说明：

1. AOF 持久化开启且存在 AOF 文件时，优先加载 AOF 文件；
2. AOF 关闭或者 AOF 文件不存在时，加载 RDB 文件；
3. 加载 AOF/RDB 文件成功后，Redis 启动成功；
4. AOF/RDB 文件存在错误时，Redis 启动失败并打印错误信息。

  

2.2.5 文件校验

  加载损坏的 AOF 文件时会拒绝启动，并打印如下日志:

# Bad file format reading the append only file: 
make a backup of your AOF file,
 		then use ./redis-check-aof --fix <filename>

于错误格式的 AOF 文件，先进行备份，然后采用 redis-check-aof–fix 命令进行修复，修复后使用 diff-u 对比数据的差异，找出丢失的数据，有些可 以人工修改补全。
AOF 文件可能存在结尾不完整的情况，比如机器突然掉电导致 AOF 尾部 文件命令写入不全。Redis 为我们提供了 aof-load-truncated 配置来兼容这种情况，默认开启。加载 AOF 时，当遇到此问题时会忽略并继续启动，同时打印如下警告日志:

# !!! Warning: short read while loading the AOF file !!! 
# !!! Truncating the AOF at offset 397856725 !!!
# AOF loaded anyway because aof-load-truncated is enabled

  

  

3. 问题定位与优化

3.1 fork操作

  当 Redis 做 RDB 或 AOF 重写时，一个必不可少的操作就是执行 fork 操作创建子进程，对于大多数操作系统来说 fork 是个重量级操作。虽然 fork 创建的子进程不需要拷贝父进程的物理内存空间，但是会复制父进程的空间内存页表。例如对于 10GB的 Redis 进程，需要复制大约 20MB的内存页表，因此 fork 操作耗时跟进程总内存量息息相关，如果使用虚拟化技术，特别是Xen虚拟机，fork操作会更耗时。

  

fork 耗时问题定位：

• 对于高流量的 Redis 实例 OPS 可达 5万以上，如果 fork 操作耗时在秒级别将拖慢 Redis 几万条命令执行，对线上应用延迟影响非常明显。正常情况下 fork 耗时应该是每 GB消耗 20毫秒左右。可以在 info stats 统计中查 latest_fork_usec 指标获取最近一次 fork操作耗时，单位微秒。
    

如何改善 fork 操作的耗时：

• 优先使用物理机或者高效支持 fork 操作的虚拟化技术，避免使用 Xen；
• 控制 Redis 实例最大可用内存，fork 耗时跟内存量成正比，线上建议每个 Redis 实例内存控制在 10GB以内；
• 合理配置 Linux 内存分配策略，避免物理内存不足导致 fork 失败；
• 降低 fork 操作的频率，如适度放宽 AOF 自动触发时机，避免不必要 的全量复制等。

  

3.2 子进程开销监控和优化

  子进程负责 AOF 或者 RDB 文件的重写，它的运行过程主要涉及 CPU、内
存、硬盘三部分的消耗。

• CPU

  • CPU 开销分析：子进程负责把进程内的数据分批写入文件，这个过程属于 CPU密集操作，通常子进程对单核 CPU利用率接近90%；
  • CPU 消耗优化：
    • redis 是 CPU 密集型服务，不要做绑定单核 CPU操作。 由于子进程非常消耗 CPU，会和父进程产生单核资源竞争；
    • 不要和其他 CPU密集型服务部署在一起，造成 CPU过度竞争；
    • 如果部署多个 Redis 实例，尽量保证同一时刻只有一个子进程执行重写工作；
        

• 内存：

  • 内存消耗分析：子进程通过 fork 操作产生，占用内存大小等同于父进程，理论上需要两倍的内存来完成持久化操作，但 Linux 有写时复制机制 (copy-on-write)。父子进程会共享相同的物理内存页，当父进程处理写请求时会把要修改的页创建副本，而子进程在 fork 操作过程中共享整个父进程内存快照。
  • 内存消耗优化：
    • 同 CPU优化一样，如果部署多个 Redis 实例，尽量保证同一时刻只有 一个子进程在工作；
    • 避免在大量写入时做子进程重写操作，这样将导致父进程维护大量页副本，造成内存消耗。
        

• 硬盘：

  • 硬盘开销分析：子进程主要职责是把 AOF 或者 RDB 文件写入硬盘持久化。势必造成硬盘写入压力。根据 Redis 重写 AOF/RDB 的数据量，结合系统工具如 sar、iostat、iotop 等，可分析出重写期间硬盘负载情况；
  • 硬盘开销优化：
    • 不要和其他高硬盘负载的服务部署在一起。如：存储服务、消息队列服务等；
    • AOF 重写时会消耗大量硬盘 IO，可以开启配置 no-appendfsync-on-rewrite，默认关闭。表示在 AOF 重写期间不做 fsync 操作；
    • 当开启 AOF 功能的 Redis 用于高流量写入场景时，如果使用普通机械磁盘，写入吞吐一般在 100MB/s左右，这时 Redis 实例的瓶颈主要在 AOF同步硬盘上；
    • 对于单机配置多个 Redis 实例的情况，可以配置不同实例分盘存储 AOF 文件，分摊硬盘写入压力。

配置 no-appendfsync-on-rewrite=yes 时，在极端情况下可能丢失整个 AOF 重写期间的数据，需要根据数据安全性决定是否配置。

  

3.3 AOF追加阻塞

  当开启 AOF 持久化时，常用的同步硬盘的策略是 everysec，用于平衡性能和数据安全性。对于这种方式，Redis 使用另一条线程每秒执行 fsync 同步硬盘。当系统硬盘资源繁忙时，会造成 Redis 主线程阻塞，如图所示：

阻塞流程分析：

1. 主线程负责写入 AOF 缓冲区；
2. AOF 线程负责每秒执行一次同步磁盘操作，并记录最近一次同步时间；
3. 主线程负责对比上次 AOF 同步时间：
   • 如果距上次同步成功时间在2秒内，主线程直接返回；
   • 如果距上次同步成功时间超过 2秒，主线程将会阻塞，直到同步操作完成；

  

通过对 AOF 阻塞流程可以发现两个问题：

• everysec 配置最多可能丢失 2秒数据，不是 1秒；
• 如果系统 fsync 缓慢，将会导致 Redis 主线程阻塞影响效率。

  

AOF 阻塞问题定位：

• 发生 AOF阻塞时，Redis 输出如下日志，用于记录 AOF fsync 阻塞导致 拖慢 Redis 服务的行为：

Asynchronous AOF fsync is taking too long (disk is busy). 
Writing the AOF buffer without waiting for fsync to complete, 
this may slow down Redis

• 每当发生 AOF 追加阻塞事件发生时，在 info Persistence 统计中， aof_delayed_fsync 指标会累加，查看这个指标方便定位 AOF 阻塞问题；
• AOF 同步最多允许 2秒的延迟，当延迟发生时说明硬盘存在高负载问 题，可以通过监控工具如 iotop，定位消耗硬盘 IO资源的进程；

  

  

4. 多实例部署

  Redis 单线程架构导致无法充分利用 CPU 多核特性，通常的做法是在一台机器上部署多个 Redis 实例。当多个实例开启 AOF 重写后，彼此之间会产生对 CPU 和 IO 的竞争。

  上面介绍了持久化相关的子进程开销。对于单机多 Redis 部署，如果同一时刻运行多个子进程，对当前系统影响将非常明显，因此需要采用一种措施，把子进程工作进行隔离。Redis 在 info Persistence 中为我们提供监控子进程运行状况的度量指标，如表所示：

  我们基于以上指标，可以通过外部程序轮询控制 AOF 重写操作的执行， 整个过程如图所示

流程说明：

1. 外部程序定时轮询监控机器 (machine) 上所有 Redis 实例；
2. 对于开启AOF的实例，查看 (aof_current_size- aof_base_size)/aof_base_size 确认增长率；
3. 当增长率超过特定阈值 (如100%)，执行 bgrewriteaof 命令手动触发 当前实例的 AOF 重写；
4. 运行期间循环检查 aof_rewrite_in_progress 和 aof_current_rewrite_time_sec 指标，直到AOF 重写结束；
5. 确认实例 AOF 重写完成后，再检查其他实例并重复 2)~4) 步操作。 从而保证机器内每个 Redis 实例 AOF 重写串行化执行。