简单谈谈 redis 持久化（RDB 和 AOF）

• 1.1 为什么要持久化
• 1.2 怎么持久化

• 2.1 概述
• 2.2 触发生成RDB文件
• • 2.2.1 使用save、bgsave命令手动触发
  • 2.2.2 配置自动触发RDB机制
  • 2.2.3 其他情况——服务器shutdown
• 2.3 载入RDB文件
• 2.4 RDB对过期键的处理

• 3.1 概述
• • 3.1.1 启动时载入还原数据
• 3.2 AOF 持久化实现
• • 3.2.1 开启AOF持久化
  • 3.2.2 AOF 持久化实现的过程
  • • 3.2.2.1 AOF 持久化过程
    • 3.2.2.2 关于 appendfsync 配置说明
  • 3.2.3 AOF 文件重写
  • • 3.2.3.1 重写实现过程
    • 3.2.3.2 AOF 重写触发方式

• 4.1 RDB 和 AOF 优缺点对比
• 4.2 RDB 与 AOF 优先级
• 4.3 混合持久化

redis的持久化功能主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。

因为Redis是内存数据库，它将自己的数据库状态储存在内存里面，所以如果不想办法将储存在内存中的数据库状态保存到磁盘里面，那么一旦服务器进程退出，服务器中的数据库状态也会消失不见。

为了解决这个问题，Redis提供了RDB持久化功能，这个功能可以将Redis在内存中的数据库状态保存到磁盘里面，避免数据意外丢失。

除了RDB持久化，Redis还提供了AOF持久化（Append Only File），RDB持久化将当前数据保存到硬盘，而AOF则是将每次执行的写命令保存到硬盘。

① save：同步保存，阻塞主线程
SAVE 命令会阻塞 Redis 服务器进程，直到 RDB 文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求。

② bgsave：fork新的子线程执行持久化，不阻塞主线程
与 save 命令不同，bgsave 命令会创建一个子进程，由子进程来负责生成 RDB 文件，不会阻塞父进程处理其他调用它的请求，即：父进程(即Redis主进程)则继续处理请求。

看 save 和 bgsave 的日志

③ 需要注意的是：
当执行 SAVE 命令时会阻塞 Redis 服务器进程，只有当 save 命令执行完、重新开始接受命令请求之后，客户端发送的命令才会被处理。

在执行 bgsave 命令时，不会阻塞主线程，但是执行 bgsave 期间，客户端发送的save 命令和 bgsave 命令会被服务器拒绝。

• save 命令不能和 bgsave 命令同时执行，为了避免父进程（服务器进程）和子进程同时执行两个rdbSave调用，防止产生资源竞争条件。
• 两个 bgsave 命令也会产生资源竞争条件，所以当一个 bgsave 在执行时，会拒绝其他 bgsave 命令的请求。

在执行 bgsave 命令时，客户端发送的 BGREWRITEAOF 命令会被延迟到 BGSAVE 命令执行完毕之后执行；如果BGREWRITEAOF 命令正在执行，那么客户端发送的 BGSAVE 命令会被服务器拒绝

④ 根据上面我们了解到 save 命令和 bgsave 命令，由于 save 命令会造成服务器阻塞，所以实际开发中我们都是用 bgsave 命令来触发生成RDB文件实现持久化，但是手动触发肯定不是我们最理想的，所以一般是通过配置 save 选项，让服务器每隔一段时间自动执行一次BGSAVE 命令来实现自动触发生成RDB文件。请继续……

① 先看默认配置

② 参数解释
语法：save second times（其中 second是设置多少秒内，times 是设置在所设置的 second 内，redis数据库所发生变化的次数） ，比如：

save 900 1 表示：900秒(15分钟)内数据发生一次变化；
save 300 10 表示：300秒(5分钟)内数据发生10次变化；
save 60 10000 表示：60秒(1分钟)内数据发生10000次变化；
即用户可以通过 save 选项设置多个保存条件，在默认配置下，只要满足上面三种情况的任何一种情况，都会自动触发执行 bgsave 命令来生成 RDB 文件。

③ 简单测试
为了方便测试，我们调整一次默认值

满足60秒内修改3次的条件即自动触发，如下图：

命令 FLUSHALL 与 命令 shutdown 也会触发生成RDB文件

需要注意的是：
① FLUSHALL 命令是清空数据库并执行持久化 *** 作，所以 FLUSHALL 之后的 RDB 文件是没有什么意义的，不能拿来恢复数据。
与 FLUSHALL 不同的是，FLUSHDB 命令清空当前数据库且不执行持久化 *** 作。所以FLUSHDB之后，如果想恢复数据可以杀掉redis-server的进程重启redis服务。

② shutdown 命令也会自动执行RDB持久化。

我们先来说一下AOF如何还原数据的，再说AOF持久化过程。

因为AOF文件里面包含了重建数据库状态所需的所有写命令，所以服务器只要读入并重新执行一遍AOF文件里面保存的写命令，就可以还原服务器关闭之前的数据库状态。具体怎么读入再重写，这个地方我们需要注意了：

• 因为 Redis 的命令只能在客户端上下文中执行，而载入 AOF 文件时所使用的命令直接来源于AOF文件而不是网络连接，所以，服务器在载入 AOF 文件之前会先创建一个不带网络连接的伪客户端。

  然后从 AOF 文件中分析并逐条读取出一条条写命令；每读取一条，服务器就使用这个伪客户端来执行从 AOF 文件中读出的写命令。

  等所有的命令被执行完后，AOF文件所保存的数据库状态就被完全恢复了。

• 另外，伪客户端执行命令的效果和带网络连接的客户端执行命令的效果是完全一样的。

Redis读取AOF文件并还原数据库状态的图过程（来源《redis设计与实现》）：

默认是没有开启的，可通过 appendonly 选项设置 yes 来开启 AOF 持久化功能。

修改配置之后记得重启 redis 服务，重启之后在 rdb 文件的同目录下会自动生成 appendonly.aof 文件（这是默认文件名，可根据 appendfilename 配置）。

启动之后， appendonly.aof 文件不要删除，虽然 AOF 不需要触发 （文件是记录Redis的每条写命令，所以AOF不需要触发，会自动将命令写入），但是如果删除此文件，不会自动恢复！。

• ① 命令追加(append)

  当AOF持久化功能处于打开状态时，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器状态的 aof_buf 缓冲区的末尾，而不是直接写入 aof 文件，主要是为了避免每次有写命令都直接写入硬盘，导致硬盘IO成为Redis负载的瓶颈。

• ② 文件写入(write) 和 文件同步(sync)

  根据服务器配置的 appendfsync 选项的值，来决定是否需要将 aof_buf 缓冲区中的内容写入和保存到 AOF 文件里面。

  为什么既有写入又有同步？
  是将命令写入到缓冲区的，等到缓冲区的空间被填满、或者超过了指定的时限之后，才真正地将缓冲区中的数据写入到磁盘里面。但是这样虽然提高了效率，可能带来数据不安全问题（比如计算机异常停机等情况会导致缓存区里的内容还没来得及写入磁盘而造成数据丢失）。
  所以 redis 提供了同步机制（通过配置 appendfsync 控制），强制让 *** 作系统立即将缓冲区中的数据写入到硬盘里面，从而确保写入数据的安全性。

• ① always ：将 aof_buf 缓冲区中的所有内容写入并同步到 AOF 文件。
  即：每执行一个命令都会写入到缓冲区并同步到 aof 文件（写入磁盘），所以 always 效率上是最慢的，安全性上是最安全的，即便异常停机，也只会失去最后一个 *** 作的命令。
• ② everysec：将 aof_buf 缓冲区中的所有内容写入到 AOF 文件， *** 作由专门的线程每隔一秒对 AOF 文件进行同步一次。
  即：每隔一秒对 AOF 文件进行同步一次，同步频率上相比 always 低了很多，即便出现异常停机，只是丢失了一秒钟的命令数据，所以 everysec 是默认配置，也推荐的配置，效率上足够快，数据安全也有保证。
• ③ no ：将 aof_buf 缓冲区中的所有内容写入到 AOF 文件，但并不对 AOF 文件进行同步，何时同步由 *** 作系统来决定。
  即：命令写入aof_buf后调用系统write *** 作，不对AOF文件做同步 *** 作，至于何时同步由 *** 作系统控制；这种情况下，文件同步的时间不可控，且缓冲区中堆积的数据会很多，数据安全性无法保证。

什么是 AOF 重写？AOF 重写解决什么问题？
AOF 持久化是通过保存被执行的写命令来记录数据库状态的，所以随着时间的流逝，AOF 文件中的内容会越来越多，文件体积越来越大，那么使用 AOF 文件来恢复数据的时间就会越多，而且对计算机的存储也有一定的影响。所以为了解决 AOF 文件体积的膨胀问题， redis 提供了 AOF 文件重写功能（rewrite）。

Redis服务器可以创建一个新的 AOF 文件来替代现有的 AOF 文件，新旧两个文件所保存的数据库状态是相同的，但是新的 AOF 文件不会包含任何浪费空间的冗余命令，通常体积会较旧 AOF 文件小得多。

• ① AOF 重写时开启一个子进程，不影响 redis 服务器继续接收客户端的命令。
• ② 为了保证数据一致，在执行 bgrewriteof 命令重写时，Redis 服务器会维护一个 AOF 重写缓冲区，该缓冲区会在子进程创建 AOF 文件期间，记录服务器执行的所有写命令。当子进程完成创建新 AOF 文件的工作之后，服务器会将重写缓存区中的所有内容追加到新 AOF 文件的末尾，使得新旧两个 AOF 文件所保存的数据库状态一致。
• ③ 最后，服务器用新的 AOF 文件替换旧的 AOF 文件来完成 AOF 文件重写 *** 作。

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

因为 AOF 和 RDB 各有优缺点，因此 Redis 一般会同时开启 AOF和 RDB。
但这样会带来如下的两难选择：重启时如果优先加载 RDB，加载速度更快，但是数据不是很全；如果优先加载 AOF，加载速度会变慢，但是数据会比 RDB 中的要完整。

所以为了能同时使用 RDB 和 AOF 的优点，redis增加了混合持久化：

开启混合持久化：aof-use-rdb-preamble yes 默认是 yes 开启状态。

在开启混合持久化的情况下，进行 AOF 重写时子进程将当前时间点的数据快照保存为 RDB 文件格式，而后将父进程累积命令保存为 AO F格式。意思就是 AOF 重写时会把持久化数据先以 RDB 格式写入到 AOF 文件的开头，之后的数据再以 AOF 的格式追加到文件的末尾，数据存储结构如图：

加载时，首先会识别 AOF 文件是否以 REDIS 字符串开头，如果是，就按 RDB 格式加载，加载完 RDB 后继续按 AOF 格式加载剩余部分。