Redis总结5——持久化RDB与AOP

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

1：RDB

1.1：RDB的优缺点

优点：

• DB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照。非常适用于备份，全量复制等场景。比如每6小时执行bgsave备份， 并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复。
• Redis加载RDB恢复数据远远快于AOF的方式。

缺点：

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

1.2：触发机制

触发RDB持久化过程分为手动触发和自动触发。

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

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

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

自动触发RDB场景：

1. 使用save相关配置，如“save m n”。表示m秒内数据集存在n次修改 时，自动触发bgsave。

2. 如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点。

3. 执行debug reload命令重新加载Redis时，也会自动触发save操作。

4. 默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则 自动执行bgsave。

1.3：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.4:RDB文件的处理

1.保存
  RDB文件保存在dir配置指定的目录下，文件名通过dbfilename配 置指定。可以通过执行config set dir{newDir}和config set dbfilename{newFileName}运行期动态执行，当下次运行时RDB文件会保存到 新目录。
2.压缩
  Redis默认采用LZF算法对生成的RDB文件做压缩处理，压缩后的 文件远远小于内存大小，默认开启，可以通过参数config set rdbcompression{yes|no}动态修改。

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

3.校验
  如果Redis加载损坏的RDB文件时拒绝启动，并打印如下日志：

这时可以使用Redis提供的redis-check-dump工具检测RDB文件并获取对应的错误报告。

2：AOF

  AOF以独立日志的方式记录每次写命令， 重启时再重新执行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.1.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.1.2：文件同步

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

系统调用write和fsync说明：

• write操作会触发延迟写（delayed write）机制。write操作在写入系统缓冲区后直接返回。同步 硬盘操作依赖于系统调度机制，同步文件之前，如果此时系统故障宕机，缓冲区内数据将丢失。
• fsync针对单个文件操作（比如AOF文件），做强制硬盘同步，fsync将 阻塞直到写入硬盘完成后返回，保证了数据持久化。

2.1.3：重写机制

  随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis 引入AOF重写机制压缩文件体积，另一个目的是：更小的AOF 文件可以更快地被Redis加载。AOF文件重写是把Redis进程内的数据转 化为写命令同步到新AOF文件的过程。

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

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

AOF重写过程可以手动触发和自动触发

• 手动触发：直接调用bgrewriteaof命令。
• 自动触发：根据auto-aof-rewrite-min-size（重写是AOF文件最小值，默认64MB）和auto-aof-rewrite-percentage（代表当前AOF与上一次AOF文件空间的比值）参 数确定自动触发时机。自动触发时机=aof_current_size>auto-aof-rewrite-min- size&&（aof_current_size-aof_base_size）/aof_base_size>=auto-aof-rewrite- percentage。

2.1.4：重启加载

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

流程说明：

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

2.2：文件校验

  加载损坏的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： AOF追加阻塞

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

阻塞流程分析

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

通过对AOF阻塞流程可以发现两个问题：
（1）everysec配置最多可能丢失2秒数据，不是1秒。
（2）如果系统fsync缓慢，将会导致Redis主线程阻塞影响效率。

3.2：单机上多实例部署

  Redis单线程架构导致无法充分利用CPU多核特性，通常的做法是在一 台机器上部署多个Redis实例。当多个实例开启AOF重写后，彼此之间会产 生对CPU和IO的竞争。因此需要采用一种 措施，把子进程工作进行隔离。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重写串行化执行。

3.3：fork操作

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

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