Redis 持久化方案

持久化简介

什么是持久化？

利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化。

持久化用于防止数据的意外丢失，确保数据安全性。

我们知道一点，计算机中的数据全部都是二进制，如果现在要保存一组数据的话，有什么样的方式呢？其实最简单的就是现在长什么样，我记下来就行了，那么这种记录纯粹的数据就叫做快照存储，也就是它保存的是某一时刻的数据状态。

还有一种形式，它不记录你的数据，它记录你所有的操作过程，比如说大家用 idea 的时候，有没有遇到过写错了 ctrl+z 撤销，然后 ctrl+y 还能恢复，这个地方它也是在记录，但是记录的是你所有的操作过程。既然这样，在操作过程中都给你记录下来了，你说数据还会丢吗？肯定不会丢，因为你所有的操作过程我都保存了。这种保存操作过程的存储，用专业术语来说可以说是日志，以上是两种不同的保存数据的形式。

Redis 持久化方案

虽说 Redis 是内存数据库，但是它为数据的持久化提供了两种技术。分别是「RDB 快照和 AOF 日志 」。

这两种技术都会用各用一个日志文件来记录信息，但是记录的内容是不同的。

• RDB 文件的内容是二进制数据。
• AOF 文件的内容是操作命令。

总结：

• 第一种：将当前数据状态进行保存，即快照形式，存储数据结果，存储格式简单，关注点在数据。
• 第二种：将数据的操作过程进行保存，即日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程。

RDB

RDB 简介

RDB 是 Redis 默认开启的持久化方案，通过快照来将数据持久化到磁盘中。

所谓的快照，就是记录某一个瞬间东西，比如当我们给风景拍照时，那一个瞬间的画面和信息就记录到了一张照片。

所以，RDB 快照就是记录某一个瞬间的内存数据，记录的是实际数据；而 AOF 文件记录的是命令操作的日志，而不是实际的数据。

因此在 Redis 恢复数据时，RDB 恢复数据的效率会比 AOF 高些，因为直接将 RDB 文件读入内存就可以，不需要像 AOF 那样还需要额外执行操作命令的步骤才能恢复数据。

Redis 提供了两个命令来生成 RDB 文件，分别是save和bgsave，他们的区别就在于是否在「主线程」里执行：

• 执行了 save 命令，就会在主线程生成 RDB 文件，由于和执行操作命令在同一个线程，所以如果写入 RDB 文件的时间太长，会阻塞主线程。

• 执行了 bgsave 命令，会创建一个子进程来生成 RDB 文件，这样可以避免主线程的阻塞。

RDB 文件的加载工作是在服务器启动时自动执行的，Redis 并没有提供专门用于加载 RDB 文件的命令。

save 指令

操作与配置

执行命令：

# 手动执行一次保存操作
save

redis.conf 配置文件 save 指令相关：

# 设置持久化文件名，默认值为 dump.rdb，通常设置为 dump-端口号.rdb
dbfilename filename

# 设置存储.rdb文件的路径，通常设置成存储空间较大的目录中。如目录名称为 data
dir path

# 设置存储至本地数据库时是否压缩数据，默认 yes；若设置为 no 则节省 CPU 运行时间，但存储文件变大
rdbcompression yes|no

# 设置读写文件过程是否进行RDB格式校验，默认 yes；若设置为 no，节约读写 10% 时间消耗，单存在数据损坏的风险
rdbchecksum yes|no

工作原理

以上图为例，现在有四个客户端各自要执行一个指令，把这些指令发送到 redis 服务器后，他们的执行会有一个先后顺序问题，假定就是按照 1234 的顺序放过去的话，那会是什么样的呢？

Redis 是单线程的工作模式，它会创建一个任务队列，所有的命令都会进到这个队列里边，在这儿排队执行，执行完一个消失一个，当所有的命令都执行完了，OK，结果达到了。

但是如果现在我们执行 save 指令保存大数据量时，会是什么现象呢？

它会非常耗时，以至于它在执行时，后面的指令都要等，所以说这种模式是不友好的，这是 save 指令的一个问题，当 cpu 执行时会阻塞 redis 服务器，直到它执行完毕，所以这里不建议在线上环境用 save 指令。

bgsave 指令

操作与配置

上问讲到了当 save 指令的数据量过大时，单线程执行方式造成效率过低，那应该如何处理呢？

此时我们可以使用 bgsave 指令，bg 其实是 background（后台执行）的意思。

执行命令：

# 手动启动后台保存操作，但不是立即执行
bgsave

redis.conf 配置文件 bgsave 指令相关：

# 后台存储过程中如果出现错误现象，是否停止保存操作，默认 yes
stop-writes-on-bgsave-error yes|no

# 其他
dbfilename filename
dir path
rdbcompression yes|no
rdbchecksum yes|no

工作原理

当执行 bgsave 时，客户端发出 bgsave 指令给到 redis 服务器。注意，这个时候服务器会马上回一个结果告诉客户端后台已经开始了，与此同时它会创建一个子进程，使用 Linux 的 fork 函数创建一个子进程，让这个子进程去执行 save 相关的操作。此时可以想一下，我们主进程一直在处理指令，而子进程在执行后台的保存，它会不会干扰到主进程的执行呢？

答案是不会，所以说它才是主流方案。子进程开始执行之后，它就会创建 RDB 文件把它存起来，操作完以后他会把这个结果返回，也就是说 bgsave 的过程分成两个过程：第一个是服务端拿到指令直接告诉客户端开始执行了；另一个过程是一个子进程在完成后台的保存操作，操作完以后回一个消息。

bgsave 配置执行

相关配置

Redis 还可以通过配置文件的选项来实现每隔一段时间自动执行一次 bgsave 命令，（redis.conf）默认会提供以下配置：

# 设置自动持久化的条件，满足限定时间范围内 key 的变化数量达到指定数量即进行持久化
save second changes

别看选项名叫 save，实际上执行的是 bgsave 命令，也就是会创建子进程来生成 RDB 快照文件。其参数含义为：

• second：监控时间范围
• changes：监控 key 的变化量

示例：

只要满足上面条件的任意一个，就会执行 bgsave，它们的意思分别是：

900 秒发生 1 次操作，就会持久化存储；
300 秒发生 10 次操作，就会持久化存储；
60 秒发生 10000 次操作，就会持久化存储。

执行 bgsave 过程中，Redis 依然可以继续处理操作命令的，也就是数据是能被修改的。

工作原理

RDB 启动方式对比

方式	save 指令	bgsave 指令
读写	同步	异步
阻塞客户端指令	是	否
额外内存消耗	否	是
启动新进程	否	是

RDB特殊启动形式：

# 服务器运行过程中重启
debug reload

# 关闭服务器并保存数据
shutdown save

RDB 优缺点

RDB 优点：

• RDB 是一个紧凑压缩的二进制文件，存储效率较高。
• RDB 内部存储的是 redis 在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景。
• RDB 恢复数据的速度要比 AOF 快很多。
• 应用：服务器中每 X 小时执行 bgsave 备份，并将 RDB 文件拷贝到远程机器中，用于灾难恢复。

RDB 缺点：

• 注意，Redis 的快照是全量快照，也就是说每次执行快照，都是把内存中的「所有数据」都记录到磁盘中。
  所以可以认为，执行快照是一个比较重的操作，如果频率太频繁，可能会对 Redis 性能产生影响。如果频率太低，服务器故障时，丢失的数据会更多。
  通常可能设置至少 5 分钟才保存一次快照，这时如果 Redis 出现宕机等情况，则意味着最多可能丢失 5 分钟数据。

• 这就是 RDB 快照最明显的缺点，在服务器发生故障时，丢失的数据会比 AOF 持久化的方式更多，因为 RDB 快照是全量快照的方式，因此执行的频率不能太频繁，否则会影响 Redis 性能；而 AOF 日志可以以秒级的方式记录操作命令，所以丢失的数据就相对更少。

• 此外，Redis 的众多版本中未进行 RDB 文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象。

AOF

AOF 简介

AOF 方式的持久化，是每操作一次 Redis 数据库，就将操作的记录存储到 AOF 持久化日志文件中。

AOF 的主要作用是解决了数据持久化的实时性，目前已经是 Redis 持久化的主流方式。

这种保存写操作命令到日志的持久化方式，就是 Redis 里的 AOF(Append Only File) 持久化功能，注意只会记录写操作命令，读操作命令是不会被记录的，因为没意义。

AOF 日志文件其实就是普通的文本，我们可以通过 cat 命令查看里面的内容，不过里面的内容如果不知道一定的规则的话，可能会看不懂。

这里以「set name xiaolin」命令作为例子，Redis 执行了这条命令后，记录在 AOF 日志里的内容如下图：

解释：

• 「*3」表示当前命令有三个部分，每部分都是以「$+数字」开头，后面紧跟着具体的命令、键或值。
• 然后，这里的「数字」表示这部分中的命令、键或值一共有多少字节。例如「$3 set」表示这部分有 3 个字节，也就是「set」命令这个字符串的长度。

Redis 是先执行写操作命令后，才将该命令记录到 AOF 日志里的，这么做其实有两个好处：

• 第一个好处：避免额外的检查开销。
  因为如果先将写操作命令记录到 AOF 日志里，再执行该命令的话，如果当前的命令语法有问题，那么如果不进行命令语法检查，该错误的命令记录到 AOF 日志里后，Redis 在使用日志恢复数据时，就可能会出错。
  而如果先执行写操作命令再记录日志的话，只有在该命令执行成功后，才将命令记录到 AOF 日志里，这样就不用额外的检查开销，保证记录在 AOF 日志里的命令都是可执行并且正确的。

• 第二个好处：不会阻塞当前写操作命令的执行。因为当写操作命令执行成功后，才会将命令记录到 AOF 日志。

AOF 配置

在 Redis 中 AOF 持久化功能默认是不开启的，需要我们修改 redis.conf 配置文件中的以下参数：

# 开启AOF持久化功能，默认no，即不开启状态
appendonly yes|no

# AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof
appendfilename filename

# AOF持久化文件保存路径，与RDB持久化文件保持一致即可
dir

# AOF写数据策略，默认为everysec
appendfsync always|everysec|no

AOF 风险

当然，AOF 持久化功能也不是没有潜在风险。

• 第一个风险，执行写操作命令和记录日志是两个过程，那当 Redis 在还没来得及将命令写入到硬盘时，服务器发生宕机了，这个数据就会有丢失的风险。

• 第二个风险，前面说道，由于写操作命令执行成功后才记录到 AOF 日志，所以不会阻塞当前写操作命令的执行，但是可能会给「下一个」命令带来阻塞风险。
  因为将命令写入到日志的这个操作也是在主进程完成的（执行命令也是在主进程），也就是说这两个操作是同步的。

如果在将日志内容写入到硬盘时，服务器的硬盘的 I/O 压力太大，就会导致写硬盘的速度很慢，进而阻塞住了，也就会导致后续的命令无法执行。

认真分析一下，其实这两个风险都有一个共性，都跟「 AOF 日志写回硬盘的时机」有关。

AOF 三种回写策略

Redis 写入 AOF 日志的过程，如下图：

1. Redis 执行完写操作命令后，会将命令追加到 server.aof_buf 缓冲区；

2. 然后通过 write() 系统调用，将 aof_buf 缓冲区的数据写入到 AOF 文件，此时数据并没有写入到硬盘，而是拷贝到了内核缓冲区 page cache，等待内核将数据写入硬盘；

3. 具体内核缓冲区的数据什么时候写入到硬盘，由内核决定。

Redis 提供了 3 种写回硬盘的策略，控制的就是上面说的第三步的过程。

在 redis.conf 配置文件中的appendfsync配置项可以有以下 3 种参数可填：

• Always：这个单词的意思是「总是」，所以它的意思是每次写操作命令执行完后，同步将 AOF 日志数据写回硬盘。

• Everysec：这个单词的意思是「每秒」，所以它的意思是每次写操作命令执行完后，先将命令写入到 AOF 文件的内核缓冲区，然后每隔一秒将缓冲区里的内容写回到硬盘；也是默认策略。

• No：意味着不由 Redis 控制写回硬盘的时机，转交给操作系统控制写回的时机，也就是每次写操作命令执行完后，先将命令写入到 AOF 文件的内核缓冲区，再由操作系统决定何时将缓冲区内容写回硬盘。

这 3 种写回策略都无法能完美解决「主进程阻塞」和「减少数据丢失」的问题，因为两个问题是对立的，偏向于一边的话，就会要牺牲另外一边，原因如下：

• Always 策略的话，可以最大程度保证数据不丢失，但是由于它每执行一条写操作命令就同步将 AOF 内容写回硬盘，所以是不可避免会影响主进程的性能。

• No 策略的话，是交由操作系统来决定何时将 AOF 日志内容写回硬盘，相比于 Always 策略性能较好，但是操作系统写回硬盘的时机是不可预知的，如果 AOF 日志内容没有写回硬盘，一旦服务器宕机，就会丢失不定数量的数据。

• Everysec 策略的话，是折中的一种方式，避免了 Always 策略的性能开销，也比 No 策略更能避免数据丢失，当然如果上一秒的写操作命令日志没有写回到硬盘，发生了宕机，这一秒内的数据自然也会丢失。

大家可以根据自己的业务场景进行选择：

• 如果要高性能，就选择 No 策略。

• 如果要高可靠，就选择 Always 策略。

• 如果允许数据丢失一点，但又想性能高，就选择 Everysec 策略。

AOF 重写

AOF 重写介绍

场景：如果连续执行如下写数据的指令时，该如何处理？

---

随着命令不断写入 AOF，文件会越来越大，为了解决这个问题，Redis 引入了 AOF 重写机制压缩文件体积。AOF 文件重写是将 Redis 进程内的数据转化为写命令同步到新 AOF 文件的过程。简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。

AOF重写作用：

• 降低磁盘占用量，提高磁盘利用率。
• 提高持久化效率，降低持久化写时间，提高 I/O 性能。
• 降低数据恢复用时，提高数据恢复效率。

AOF重写规则：

• 进程内具有时效性的数据，并且数据已超时将不再写入文件。

• 非写入类的无效指令将被忽略，只保留最终数据的写入命令。

  • 如 del key1、 hdel key2、srem key3、set key4 111、set key4 222 等。

  • 如 select 指令虽然不更改数据，但是更改了数据的存储位置，此类命令同样需要记录。

• 对同一数据的多条写命令合并为一条命令。

  • 如 lpush list1 a、lpush list1 b、lpush list1 c 可以转化为 lpush list1 a b c。

• 为防止数据量过大造成客户端缓冲区溢出，对 list、set、hash、zset 等类型，每条指令最多写入 64 个元素。

AOF 重写配置

手动重写：

bgrewriteaof

手动重写原理分析：

自动重写：

auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage

自动重写触发比对参数（运行指令 info Persistence 获取具体信息）：

aof_current_size  
aof_base_size

自动重写触发条件公式：

混合持久化

RDB 和 AOF 对比

持久化方式	RDB	AOF
占用存储空间	小（数据级：压缩）	大（指令级：重写）
存储速度	慢	快
恢复速度	快	慢
数据安全性	会丢失数据	依据策略决定
资源消耗	高/重量级	低/轻量级
启动优先级	低	高

RDB 和 AOF 合体

尽管 RDB 比 AOF 的数据恢复速度快，但是快照的频率不好把握：

• 如果频率太低，两次快照间一旦服务器发生宕机，就可能会比较多的数据丢失；

• 如果频率太高，频繁写入磁盘和创建子进程会带来额外的性能开销。

那有没有什么方法不仅有 RDB 恢复速度快的优点，又有 AOF 丢失数据少的优点呢？

当然有，那就是将 RDB 和 AOF 合体使用，这个方法是在 Redis 4.0 提出的，该方法叫混合使用 AOF 日志和内存快照，也叫混合持久化。

如果想要开启混合持久化功能，可以在 Redis 配置文件将下面这个配置项设置成 yes：

aof-use-rdb-preamble yes

混合持久化工作在 AOF 日志重写过程。当开启了混合持久化时，在 AOF 重写日志时，fork 出来的重写子进程会先将与主线程共享的内存数据以 RDB 方式写入到 AOF 文件，然后主线程处理的操作命令会被记录在重写缓冲区里，重写缓冲区里的增量命令会以 AOF 方式写入到 AOF 文件，写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。

也就是说，使用了混合持久化，AOF 文件的前半部分是 RDB 格式的全量数据，后半部分是 AOF 格式的增量数据。

这样的好处在于：

• 重启 Redis 加载数据的时候，由于前半部分是 RDB 内容，这样加载的时候速度会很快。

• 加载完 RDB 的内容后，才会加载后半部分的 AOF 内容，这里的内容是 Redis 后台子进程重写 AOF 期间，主线程处理的操作命令，可以使得数据更少地丢失。