主题

Redis持久化

目标

• 掌握redis的RDB和AOF的原理
• 掌握RDB和AOF配置
• 根据业务情况合理选用RDB和AOF

Redis持久化

Redis是一个内存数据库，为了保证数据的持久性，它提供了两种持久化方案：

RDB方式（默认，快照方式）

RDB方式是通过快照（ snapshotting ）完成的，当符合一定条件时Redis会自动将内存中的数据进行快照并持久化到硬盘。

触发快照的时机

• 1、符合自定义配置的快照规则 redis.conf
• 2、执行save或者bgsave命令
  • save：此命令会使用Redis的主线程进程同步存储，阻塞当前的Redis服务器，造成服务不可用，直到RDB过程完成。
  • bgsave：此命令会通过fork()创建子进程，在后台进程存储。只有fork阶段会阻塞当前Redis服务器，不必到整个RDB过程结束，一般时间很短。
• 3、 执行flushall命令
• 4.、执行主从复制操作 (全量同步的时候，后面会讲)

设置快照规则

Redis支持自动触发RDB持久化机制，配置都在redis.conf文件里面：

• save <seconds> <changes>    多少秒内 数据变了多少
  • save “” : 不使用RDB存储，如果想禁用RDB
  • save 900 1 ： 表示15分钟（900秒钟）内至少1个键被更改则进行快照。
  • save 300 10 ： 表示5分钟（300秒）内至少10个键被更改则进行快照。
  • save 60 10000 ：表示1分钟内至少10000个键被更改则进行快照。
  • 过滤条件是或的关系，而且是漏斗型的过滤顺序。
• stop-writes-on-bgsave-error：如果是yes，当bgsave命令失败时Redis将停止写入操作。
• rdbcompression：是否对RDB文件进行压缩，但是在LZF压缩消耗更多CPU
• rdbchecksum：是否对RDB文件进程校验
• dbfilename：配置文件名称，默认dump.rdb
• dir：配置rdb文件存放的路劲，这个参数比较重要

原理图

（1）Redis使用fork函数复制一份当前进程（父进程）的副本（子进程）；
（注意是进程不是线程）
（2）父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件；
（3）当子进程写入完所有数据后会用该临时文件替换旧的 RDB 文件，至此一次快照操作完成。
（不会直接对rdb文件进行修改，避免写入过程产生问题对文件有损坏）

注意事项

• 1、在执行 fork 的时候操作系统（类 Unix 操作系统）会使用写时复制（copy-on-write）策略，即fork函数发生的一刻父子进程共享同一内存数据，当父进程要更改其中某片数据时（如执行一个写命令），操作系统会将该片数据复制一份以保证子进程的数据不受影响，所以新的RDB文件存储的是执行fork一刻的内存数据。
• 2、写时复制策略也保证了在 fork 的时刻虽然看上去生成了两份内存副本，但实际上内存的占用量并不会增加一倍。这就意味着当系统内存只有2 GB，而Redis数据库的内存有1.5 GB时，执行 fork后内存使用量并不会增加到3 GB（超出物理内存）。为此需要确保 Linux 系统允许应用程序申请超过可用内存（物理内存和交换分区）的空间，方法是在/etc/sysctl.conf 文件加入 vm.overcommit_memory = 1，然后重启系统或者执行 sysctl vm.overcommit_memory=1 确保设置生效。
• 3、另外需要注意的是，当进行快照的过程中，如果写入操作较多，造成 fork 前后数据差异较大，是会使得内存使用量显著超过实际数据大小的，因为内存中不仅保存了当前的数据库数据，而且还保存着 fork 时刻的内存数据。进行内存用量估算时很容易忽略这一问题，造成内存用量超限。
• 4、通过上述过程可以发现Redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候 RDB 文件都是完整的。这使得我们可以通过定时备份 RDB 文件来实现 Redis 数据库备份。RDB 文件是经过压缩（可以配置rdbcompression 参数以禁用压缩节省CPU占用）的二进制格式，所以占用的空间会小于内存中的数据大小，更加利于传输。

RDB优缺点

• 缺点：
  • 使用 RDB 方式实现持久化，一旦 Redis 异常退出，就会丢失最后一次快照以后更改的所有数据。这个时候我们就需要根据具体的应用场景，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受范围。如果数据相对来说比较重要，希望将损失降到最小，则可以使用 AOF 方式进行持久化
• 优点：
  • RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无需执行任何磁盘 I/O 操作。同时这个也是一个缺点，如果数据集比较大的时候， fork 可以能比较耗时，造成服务器在一段时间内停止处理客户端的请求；
  • 恢复速度比AOF快,非常适合全量备份

AOF方式（记录命令方式）

RDB方式不能提供强一致性，如果Redis进程崩溃，那么两次RDB之间的数据也随之消失。那么AOF的出现很好的解决了数据持久化的实时性，AOF以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令来恢复数据。AOF会先把命令追加在AOF缓冲区，然后根据对应策略写入硬盘（appendfsync），具体参数后面有讲。接下来介绍一下AOF重写命令。

AOF触发时机

• 符合AOF配置规则 redis.conf
• bgrewriteaof命令：Redis主进程fork子进程来执行AOF重写，这个子进程创建新的AOF文件来存储重写结果，防止影响旧文件。因为fork采用了写时复制机制，子进程不能访问在其被创建出来之后产生的新数据。Redis使用“AOF重写缓冲区”保存这部分新数据，最后父进程将AOF重写缓冲区的数据写入新的AOF文件中然后使用新AOF文件替换老文件。

AOF相关配置

• appendonly：是否打开AOF持久化功能
• appendfilename：AOF文件名称
• dir：配置aof文件存放的路劲，和rdb一样
• appendfsync：同步频率
  • 这里介绍一下appendfsync参数的可配置值
  • always：命令写入aof缓冲区后，每一次写入都需要同步，直到写入磁盘（阻塞，系统调用fsync）结束后返回。显然和Redis高性能背道而驰，不建议配置
  • everysec：命令写入aof缓冲区后，在写入系统缓冲区直接返回（系统调用write），然后有专门线程每秒执行写入磁盘（阻塞，系统调用fsync）后返回
  • no：命令写入aof缓冲区后，在写入系统缓冲区直接返回（系统调用write）。之后写入磁盘（阻塞，系统调用fsync）的操作由操作系统负责，通常最长30s
• auto-aof-rewrite-min-size：如果文件大小小于此值不会触发AOF重写，默认64MB
• auto-aof-rewrite-percentage：Redis记录最近的一次AOF操作的文件大小，如果当前AOF文件大小增长超过这个百分比则触发一次重写，默认100

AOF 持久化的整体流程

如上图所示，AOF 持久化功能的实现可以分为命令追加( append )、文件写入( write )、文件同步( sync )、文件重写(rewrite)和重启加载(load)。其流程如下：

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

命令追加

当 AOF 持久化功能处于打开状态时，Redis 在执行完一个写命令之后，会以协议格式(也就是RESP，即 Redis 客户端和服务器交互的通信协议 )将被执行的写命令追加到 Redis 服务端维护的 AOF 缓冲区末尾。

比如说 SET mykey myvalue 这条命令就以如下格式记录到 AOF 缓冲中。

"*3\r\n$3\r\nSET\r\n$5\r\nmykey\r\n$7\r\nmyvalue\r\n"

Redis 协议格式本文不再赘述，AOF之所以直接采用文本协议格式，是因为所有写入命令都要进行追加操作，直接采用协议格式，避免了二次处理开销。

文件写入和同步

Redis 每次结束一个事件循环之前，它都会调用flushAppendOnlyFile 函数，判断是否需要将 AOF 缓存区中的内容写入和同步到 AOF 文件中。

flushAppendOnlyFile 函数的行为由 redis.conf 配置中的 appendfsync 选项的值来决定。该选项有三个可选值，分别是 always、everysec 和 no：

• always：Redis 在每个事件循环都要将 AOF 缓冲区中的所有内容写入到 AOF 文件（只是写入到系统缓冲区），并且同步 AOF 文件（阻塞调用系统函数保证文件落盘），所以 always 的效率是 appendfsync 选项三个值当中最差的一个，但从安全性来说，也是最安全的。当发生故障停机时，AOF 持久化也只会丢失一个事件循环中所产生的命令数据。
• everysec：Redis 在每个事件循环都要将 AOF 缓冲区中的所有内容写入到 AOF 文件中（只是写入到系统缓冲区），直接返回，并且有专门线程每隔一秒对 AOF 文件进行一次同步（阻塞调用系统函数保证文件落盘）。从效率上看，该模式足够快。当发生故障停机时，只会丢失一秒钟的命令数据。
• no：Redis 在每一个事件循环都要将 AOF 缓冲区中的所有内容写入到 AOF 文件。而 AOF 文件的同步由操作系统控制。这种模式下速度最快，但是同步的时间间隔较长，出现故障时可能会丢失较多数据。

Linux 系统下 write 操作会触发延迟写( delayed write )机制。Linux 在内核提供页缓存区用来提供硬盘 IO 性能。write 操作在写入系统缓冲区之后直接返回。同步硬盘操作依赖于系统调度机制，例如：缓冲区页空间写满或者达到特定时间周期。同步文件之前，如果此时系统故障宕机，缓冲区内数据将丢失。

而 fsync 针对单个文件操作，对其进行强制硬盘同步，fsync 将阻塞直到写入磁盘完成后返回，保证了数据持久化。

appendfsync的三个值代表着三种不同的调用 fsync的策略。调用fsync周期越频繁，读写效率就越差，但是相应的安全性越高，发生宕机时丢失的数据越少。

有关 Linux 的I/O和各个系统调用的作用如下图所示。具体内容可以查看《聊聊 Linux I/O》一文。

AOF 数据恢复

AOF 文件里边包含了重建 Redis 数据所需的所有写命令，所以 Redis 只要读入并重新执行一遍 AOF 文件里边保存的写命令，就可以还原 Redis 关闭之前的状态。

Redis 读取 AOF 文件并且还原数据库状态的详细步骤如下：

• 创建一个不带网络连接的的伪客户端( fake client)，因为 Redis 的命令只能在客户端上下文中执行，而载入 AOF 文件时所使用的的命令直接来源于 AOF 文件而不是网络连接，所以服务器使用了一个没有网络连接的伪客户端来执行 AOF 文件保存的写命令，伪客户端执行命令的效果和带网络连接的客户端执行命令的效果完全一样的。
• 从 AOF 文件中分析并取出一条写命令。
• 使用伪客户端执行被读出的写命令。
• 一直执行步骤 2 和步骤3，直到 AOF 文件中的所有写命令都被处理完毕为止。

当完成以上步骤之后，AOF 文件所保存的数据库状态就会被完整还原出来。

AOF 重写

因为 AOF 持久化是通过保存被执行的写命令来记录 Redis 状态的，所以随着 Redis 长时间运行，AOF 文件中的内容会越来越多，文件的体积也会越来越大，如果不加以控制的话，体积过大的 AOF 文件很可能对 Redis 甚至宿主计算机造成影响。

为了解决 AOF 文件体积膨胀的问题，Redis 提供了 AOF 文件重写( rewrite) 功能。通过该功能，Redis 可以创建一个新的 AOF 文件来替代现有的 AOF 文件。新旧两个 AOF 文件所保存的 Redis 状态相同，但是新的 AOF 文件不会包含任何浪费空间的荣誉命令，所以新 AOF 文件的体积通常比旧 AOF 文件的体积要小得很多。

如上图所示，重写前要记录名为list的键的状态，AOF 文件要保存五条命令，而重写后，则只需要保存一条命令。

AOF 文件重写并不需要对现有的 AOF 文件进行任何读取、分析或者写入操作，而是通过读取服务器当前的数据库状态来实现的。首先从数据库中读取键现在的值，然后用一条命令去记录键值对，代替之前记录这个键值对的多条命令，这就是 AOF 重写功能的实现原理。

在实际过程中，为了避免在执行命令时造成客户端输入缓冲区溢出，AOF 重写在处理列表、哈希表、集合和有序集合这四种可能会带有多个元素的键时，会先检查键所包含的元素数量，如果数量超过 REDIS_AOF_REWRITE_ITEMS_PER_CMD ( 一般为64 )常量，则使用多条命令记录该键的值，而不是一条命令。

rewrite的触发机制主要有一下三个：

• 手动调用 bgrewriteaof 命令，如果当前有正在运行的 rewrite 子进程，则本次rewrite 会推迟执行，否则，直接触发一次 rewrite。
• 通过配置指令手动开启 AOF 功能，如果没有 RDB 子进程的情况下，会触发一次 rewrite，将当前数据库中的数据写入 rewrite 文件。
• 在 Redis 定时器中，如果有需要退出执行的 rewrite 并且没有正在运行的 RDB 或者 rewrite 子进程时，触发一次或者 AOF 文件大小已经到达配置的 rewrite 条件也会自动触发一次。

AOF 后台重写

AOF 重写函数会进行大量的写入操作，调用该函数的线程将被长时间阻塞，所以 Redis 在子进程中执行 AOF 重写操作。

• 子进程进行 AOF 重写期间，Redis 进程可以继续处理客户端命令请求。
• 子进程带有父进程的内存数据拷贝副本，在不使用锁的情况下，也可以保证数据的安全性。

但是，在子进程进行 AOF 重启期间，Redis接收客户端命令，会对现有数据库状态进行修改，从而导致数据当前状态和 重写后的 AOF 文件所保存的数据库状态不一致。

为此，Redis 设置了一个 AOF 重写缓冲区，这个缓冲区在服务器创建子进程之后开始使用，当 Redis 执行完一个写命令之后，它会同时将这个写命令发送给 AOF 缓冲区和 AOF 重写缓冲区。

当子进程完成 AOF 重写工作之后，它会向父进程发送一个信号，父进程在接收到该信号之后，会调用一个信号处理函数，并执行以下工作：

• 将 AOF 重写缓冲区中的所有内容写入到新的 AOF 文件中，保证新 AOF 文件保存的数据库状态和服务器当前状态一致。
• 对新的 AOF 文件进行改名，原子地覆盖现有 AOF 文件，完成新旧文件的替换
• 继续处理客户端请求命令。

在整个 AOF 后台重写过程中，只有信号处理函数执行时会对 Redis 主进程造成阻塞，在其他时候，AOF 后台重写都不会阻塞主进程。

AOF文件损坏以后如何修复

• 问题描述：
  • 服务器可能在程序正在对 AOF 文件覆盖时停机， 如果停机造成了 AOF 文件出错（ corrupt ）， 那么 Redis 在重启时会拒绝载入这个 AOF 文件， 从而确保数据的一致性不会被破坏。
• 当发生这种情况时， 可以用以下方法来修复出错的 AOF 文件：
  • 1、为现有的 AOF 文件创建一个备份。
  • 2、使用 Redis 附带的 redis-check-aof 程序，对原来的 AOF 文件进行修复。
    • redis-check-aof --fix readonly.aof
  • 3、重启 Redis 服务器，等待服务器载入修复后的 AOF 文件，并进行数据恢复。
• 当然会损失一定数据，没办法。

如何选择RDB和AOF

antirez 在《Redis 持久化解密》一文中讲述了 RDB 和 AOF 各自的优缺点：

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

一般来说,如果对数据的安全性要求非常高的话，应该同时使用两种持久化功能。
如果可以承受数分钟以内的数据丢失，那么可以只使用 RDB 持久化。

有很多用户都只使用 AOF 持久化， 但并不推荐这种方式： 因为定时生成 RDB 快照（ snapshot ）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快 。

# 禁止RDB方式
save ""

两种持久化策略可以同时使用，也可以使用其中一种。如果同时使用的话， 那么 Redis 重启时，会优先使用 AOF 文件来还原数据。

将重要数据放到Redis中存储，把它当数据库而不是缓存用的话，要使用 AOF。