【Redis】总结（二）——持久化方式RDB和AOF

一、什么是持久化

将数据保存到可永久保存的存储设备中。主要应用是将内存中的对象存储在数据库中或者存储在磁盘文件、XML数据文件中等等。

二、RDB

1、是什么

RDB（Redis DataBase）持久化：是把当前进程数据生成快照保存到硬盘的过程。Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。

2、如何触发

分为手动触发和自动触发。

手动触发：

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

自动触发：

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

3、bgsave命令的运作流程：

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_*相关选项。

4、保存的文件：

RDB文件，保存在dir配置指定的目录下，文件名通过dbfilename配置指定。

5、RDB的优缺点：

优点：

• 适用于备份（冷备），全量复制等场景。
• Redis加载RDB恢复数据远远快于AOF方式。

缺点：

• 没办法做到实时持久化/秒级持久化。bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。
• 存在老版本Redis服务无法兼容新版RDB格式的问题。

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

三、AOF

1、是什么

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

2、如何使用

开启AOF功能需要设置配置：appendonly yes，默认不开启。AOF文件名通过appendfilename配置设置，默认文件名是appendonly.aof。保存路径通过dir配置指定。

3、AOF工作流程：

AOF的工作流程操作：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）。

 

流程如下：

1） 所有的写入命令会追加到aof_buf（缓冲区）中。

2） AOF缓冲区根据对应的策略向硬盘做同步操作。

3） 随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。

4） 当Redis服务重启时，可以加载AOF文件进行数据恢复。

4、AOF缓冲区同步文件策略

由参数 appendfsync 控制，不同值含义如下表所示。建议使用 everysec，同时也是默认配置。

5、AOF重写机制

用于压缩文件体积。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程。

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

• 手动触发：直接调用 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_current_size>auto-aof-rewrite-min-size && (aof_current_size-aof_base_size) / aof_base_size >= auto-aof-rewrite-percentage
  • 其中aof_current_size和aof_base_size可以再info Persistence统计信息中查看。

运行流程：

流程说明：

    1）执行AOF重写请求。

    如果当前进程正在执行AOF重写，请求不执行并返回如下响应:

ERR Background append only file rewriting already in progress

     如果当前进程正在执行bgsave操作，重写命令延迟到bgsave完成后再执行，返回如下响应：

Background append only file rewriting scheduled

    2) 父进程执行fork创建子进程，开销等同于bgsave过程。

    3.1） 主进程fork操作完成后，继续响应其他命令。所有修改命令依然写入AOF缓冲区并更具appendfsync策略同步到硬盘，保证原有AOF机制正确性。

    3.2） 由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令，Redis使用"AOF重写缓冲区"保存这部分新数据，防止新AOF文件生成期间丢失这部分数据。

    4）子进程根据内存快照，按照命令合并规则写入到新的AOF文件。每次批量写入硬盘数据量由配置aof-rewrite-incremental-fsync控制，默认为32MB，防止单次刷盘数据过多造成硬盘阻塞。

    5.1）新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息，具体见info persistence下的aof_*相关统计。

    5.2）父进程把AOF重写缓冲区的数据写入到新的AOF文件。

    5.3）使用新AOF文件替换老文件，完成AOF重写。

6、AOF重启加载

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

 流程说明：

    1） AOF持久化开启且存在AOF文件时，优先加载AOF文件。

    2） AOF关闭或者AOF文件不存在时，加载RDB文件。

    3） 加载AOF/RDB文件城后，Redis启动成功。

    4） AOF/RDB文件存在错误时，Redis启动失败并打印错误信息。

7、AOF文件校验

加载损坏的AOF文件，先进行备份，然后采用 redis-check-aof- --fix 命令进行修复，修复后使用diff -u对比数据的差异，找出丢失的数据，有些可以人工修改补全。

8、AOF的优缺点

优点：

• AOF可以更好的保护数据不丢失，一般AOF会以每隔1秒，通过后台的一个线程去执行一次fsync操作，如果redis进程挂掉，最多丢失1秒的数据。
• AOF以appen-only的模式写入，所以没有任何磁盘寻址的开销，写入性能非常高。
• AOF日志文件的命令通过非常可读的方式进行记录，这个非常适合做灾难性的误删除紧急恢复，如果某人不小心用flushall命令清空了所有数据，只要这个时候还没有执行rewrite，那么就可以将日志文件中的flushall删除，进行恢复。

缺点：

• 对于同一份文件，AOF文件要远大于RDB文件，恢复速度慢于RDB。
• AOF开启后支持写的QPS会比RDB支持的写的QPS低，因为AOF一般会配置成每秒fsync操作，每秒的fsync操作还是很高的。

三、使用建议

建议同时开启两种持久化方式。在这种情况下，当Redis重启的时候会优先载入AOF文件来恢复原始数据，在通常情况下AOF文件保存的数据集都要比RDB文件保存的更加完整。当RDB的数据不实时，同时使用两者对服务器重启也只会找AOF文件。RDB更加适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有AOF潜在的bug，留着作为一个万一的手段。