关于后端:全面解析-Redis-持久化RDBAOF与混合持久化

Redis 长久化

前言：

在数字时代，数据的价值越来越被人们所器重。但数据只有在通过妥善保存和治理时，能力真正施展其潜在价值。对于应用 Redis 这一热门的内存数据库的开发者和企业来说，数据的长久化无疑是一个必须面对的重要议题。

咱们都晓得，Redis 以其卓越的性能和灵便的数据结构而著称，但如何确保内存中的数据不因突发事件而失落？如何在确保性能的前提下，为数据提供一个更加巩固的避风港？

本文将为你揭开 Redis 长久化的神秘面纱，探讨其背地的机制，并帮忙你为你的利用抉择适合的长久化策略。

Redis 与内存数据库的个性

为什么 Redis 是内存数据库？

Redis 是一种键值存储系统，其数据次要存储在 内存 中，因而被称为 内存数据库。与传统的磁盘存储数据库不同，Redis 的设计初衷是为了提供高速、低提早的数据拜访。因为数据间接存储在内存中，能够防止磁盘 I / O 的开销，从而实现极高的读写速度。

🔍例子: 设想一下你在家里找一本书。如果这本书就放在你的桌子上（相当于内存），你能够立即拿到它。但如果它放在地下室的一个盒子里（相当于磁盘），那你可能须要破费更多工夫去找。Redis 的工作形式就像那本放在桌子上的书。

内存数据库的长处和毛病

长处：

• 速度：内存数据库如 Redis 可能提供疾速的读写能力，因为内存的访问速度远超过磁盘。
• 低提早：数据存取的响应工夫短，适宜须要疾速响应的利用。
• 灵活性：因为数据结构存储在内存中，Redis 等内存数据库反对丰盛的数据类型和操作。
• 简化的数据模型：键值存储形式简化了数据模型，便于开发和保护。

毛病：

• 老本：内存通常比磁盘更低廉，大量的数据存储须要大量的内存，可能导致高老本。
• 数据持久性危险：如果没有适合的长久化策略，忽然的零碎解体可能导致数据失落。
• 数据容量限度：因为依赖内存，数据的容量受到物理内存大小的限度。

什么是长久化

长久化的定义：

长久化，顾名思义，指的是将短暂的、易失的数据转化为长时间保留，且不易失落的格局。在数据库的语境中，长久化经常指的是将内存中的数据保留到硬盘或其余长期存储介质中，从而确保即便在零碎解体、断电或其余突发事件中，数据也不会失落。

长久化的必要性：

数据安全性：技术世界并非总是完满的。零碎可能会蒙受故障、解体或蒙受攻打。在没有长久化的状况下，所有存储在内存中的数据在这些状况下都可能失落。长久化提供了一种机制，确保这些数据在产生故障后能够被复原。

🔍例子: 设想一下你在电脑上工作了好几个小时，忽然停电了。如果你没有定期保留你的工作，那么你可能会失去所有的致力。数据库长久化就像定期保留你的文件，确保即便发生意外，你的数据也不会失落。

Redis 长久化的形式

Redis 提供三种长久化的形式: 别离是 RDB（Redis Database Snapshot）和 AOF（Append Only File）以及 混合长久化。

RDB

RDB 是什么？

RDB 长久化形式是 Redis 将以后内存中的数据快照（snapshot）保留到硬盘的过程。换句话说，Redis 会创立一个代表某一时刻的数据集的磁盘文件。

例子: 设想一下相机的快门点击。每当你点击快门，你都会捕捉到那个特定时刻的场景。RDB 的工作形式很类似，只不过它捕获的是数据的状态。

了解 RDB 的实质后，你可能会问，咱们如何生成这个快照呢？应用 SAVE 和 BGSAVE 命令即可。

RDB 生成图解

RDB 工作原理

RDB 生成的流程图

步骤阐明：

1. 触发 RDB 生成:

触发 RDB 文件的生成有以下两种形式:

手动触发：通过执行 SAVE 或 BGSAVE 命令。

主动触发：基于 Redis 配置文件中的 save 指令设置的条件。（默认是通过 BGSAVE 命令来触发的）

redis 配置文件 save 指令设置：save 3600 1        # 3600 秒内如果超过 1 个 key 被批改则生成 RDB
save 300 100       # 300 秒内如果超过 100 个 key 被批改则生成 RDB
save 60 10000      # 60 秒内如果超过 10000 个 key 被批改则生成 RDB

2. 创立子过程:

当执行 BGSAVE 命令时，Redis 主过程（父过程）会执行 fork 操作来创立一个子过程。这是一个低廉的操作，尤其当数据集很大时。但益处是，一旦 fork 实现，父过程能够立刻返回解决其余客户端申请，而不须要期待 RDB 的生成过程。

这里波及到操作系统级别的常识。当 fork 操作执行后，子过程会取得父过程内存中的数据正本。但因为操作系统应用 写时复制（Copy-On-Write, COW）技术，任何在父过程（Redis 主过程）上产生的写操作不会影响子过程中的数据。这确保了子过程中的数据是隔离的，不受父过程中数据更改的影响。

3. 子过程生成 RDB 文件:

子过程将开始遍历整个数据集，将所有的数据写入一个新的长期 RDB 文件。这是一个纯 I / O 操作，并且是线性的，所以十分快。子过程不须要解决任何客户端申请，只专一于写 RDB 文件，所以效率很高。

留神：线性指的是数据在磁盘上是间断写入的。

4.RDB 文件替换：

一旦子过程实现了新的 RDB 文件的写入，它会替换掉旧的 RDB 文件，并发送一个信号告诉父过程工作实现。而后子过程退出。

RDB 的载入

当 Redis 重新启动时，如果配置为应用 RDB 长久化，它会查找 RDB 文件，并加载它。因为 RDB 文件是一个紧凑的二进制示意模式，数据加载十分快。

RDB 配置详解

Redis 默认是不会开启长久化选项的，只有重启 redis，redis 之前保留的数据都会失落的。因而在理论的生产环境中，咱们都会配置 Redis 的 RDB 配置。

redis.conf 中对于 RDB 的所有配置:

save <seconds> <changes>
stop-writes-on-bgsave-error
rdbcompression
rdbchecksum
sanitize-dump-payload
dbfilename
rdb-del-sync-files
dir

外围配置的常见问题解答：

Q: save seconds changes 是什么意思？

A: 这个配置管制 Redis 如何定期保留数据到磁盘。当指定的工夫（秒）内，数据产生的变动次数超过或等于 <changes> 时，Redis 将触发数据的保留操作。如果想禁用 RDB 长久化，能够在配置文件中正文掉所有的 save 指令，并且重启 Redis 服务即可。

Q: 我看到了 stop-writes-on-bgsave-error，它的作用是什么？

A: 当此选项被设置为 yes 时，如果后盾保留数据呈现谬误，Redis 将进行所有写入操作。这是一种爱护机制，确保在可能的磁盘问题或其余故障时，不再承受可能导致数据失落的写操作。
当该选项被设置为 no 时，即便后盾保留数据呈现谬误，Redis 依然会持续承受写入操作。

Q: rdbcompression 能给我带来什么益处？

A: rdbcompression 设置为 yes 时，示意启用 rdbcompression，启用 rdbcompression 会使 Redis 在保留数据前先对其进行压缩，这样能够缩小存储空间的应用。但这也意味着在数据加载时可能须要额定的 CPU 工夫来解压。

Q: 我在配置中看到了 rdbchecksum，这是什么意思？

A: rdbchecksum 决定是否在 RDB 文件开端增加一个 CRC64 校验和。这个校验和帮忙检测 RDB 文件是否在传输或存储过程中受到损坏。如果你设置为 yes，那么每次 Redis 保留或加载 RDB 文件时，它都会计算并查看这个校验和，确保数据的完整性。

Q: 什么是 sanitize-dump-payload？我应该如何配置它？

A: 当你有一个 Redis 数据备份（RDB 文件）或者应用 RESTORE 命令来导入数据时，你会心愿这些数据是平安的，没有任何问题。然而，有些时候数据可能存在问题，这可能会导致 Redis 在后续的操作中解体或者呈现谬误。

sanitize-dump-payload 这个配置项就是帮忙你在加载数据时查看这些数据的安全性。

如果你设置为 no，那么 Redis 不会检查数据，这样会更快，然而危险也更大。

如果设置为 yes，Redis 会查看所有的数据，确保它们是平安的，不会导致问题。这样更平安，但可能会略微慢一些。

如果设置为 clients，只有从客户端（比方你的应用程序）发来的数据会被查看，而从其它 Redis 实例同步来的数据或 RDB 文件不会被查看。

Q: rdb-del-sync-files 配置是做什么的？

A: 这个配置项决定是否在某些场景下删除与复制（replication）相干的 RDB 文件。

在 Redis 的主从复制过程中，主节点须要生成 RDB 文件并将其发送给从节点，帮忙从节点进行数据同步。在某些特定的平安环境中，一旦复制结束，可能会要求尽快删除这些 RDB 文件。

rdb-del-sync-files 这个选项，当设置为 yes 时，并且主节点没有启用 RDB 和 AOF 长久化，redis 会主动删除这些与复制相干的 RDB 文件。

默认为 no，这意味着与复制相干的 RDB 文件在同步后不会被主动删除。

Q8: dbfilename 和 dir 别离指的是什么？

A: dbfilename 是 RDB 文件名（默认是 dump.rdb）；dir 则是 RDB 文件寄存的目录，默认值 ./（当前目录：Redis 服务器启动时的工作目录），但举荐指定一个固定的目录，例如：/var/redis/data/

留神：

• 上述的 save、dbfilename、以及 dir 指令配置是咱们重点关注的，其余理解即可。
• 在更改 redis.conf 配置之后，咱们须要重启 redis 服务，能力失效。

RDB 长久化的优缺点

长处

疾速备份：RDB 能够迅速为你创立一个数据的“快照”，这是一个备份文件，不便你存储或者迁徙数据。

启动快：当 Redis 重新启动时，RDB 能帮忙它更疾速地加载数据，因为它间接读取一个残缺的数据文件。

节俭空间：与其余长久化形式相比，RDB 的文件大小通常较小，因为它是通过压缩的。

毛病：

可能丢数据：因为 RDB 只是不断地保留一次数据快照，如果在两次保留之间 Redis 出了问题，那两头的数据就可能会失落。

有时会卡：在数据很多的状况下，创立 RDB 文件时可能会使服务器短暂地感觉有些卡顿。

卡顿的起因：只管 Redis 应用写时复制（Copy-On-Write, COW）技术来缩小内存的复制，fork() 在大数据集上的调用依然可能相当耗时。这是因为操作系统须要为子过程筹备一个与父过程雷同的虚拟内存空间。在这个筹备过程中，即便不立刻复制物理内存，操作系统也须要复制和设置父过程的页表，这在数据集很大时会占用相当一部分工夫。fork() 的执行工夫与服务器上的数据量大小成正比。因而在数据集较大时，fork 可能会有比拟久的提早能力返回，所以才造成的卡顿。

AOF

AOF 是什么？

设想你正在写日记，每次有新的事件，你就写下来。AOF 就像是 Redis 的日记，记录了所有的写操作命令。

简略图解：

AOF 的工作原理

根本机制和流程

Redis 中的 AOF 长久化形式旨在继续地保留服务器上的所有批改操作。每当执行一个会扭转数据的命令时，Redis 都会将该命令写入 AOF 文件中。这样，当 Redis 须要复原数据时，只需执行 AOF 文件中的命令就能够复原到原来的状态。

AOF 文件的生成

流程图

步骤阐明：

AOF 长久化的实现次要是以上三步：命令追加、文件写入、文件同步

• 命令追加: 将 redis 写操作命令追加到 aof_buf 缓冲区
• 文件写入: 周期性地将 aof_buf 缓冲区的命令写入 AOF 文件的内核缓冲区。
• 文件同步: 依据配置同步策略，将 AOF 文件缓冲区的内容同步到磁盘。

其中文件同步策略 redis 提供了三种，别离是以下三种：

always：每次有命令写入时都立刻同步。这提供了最高的数据安全性，但效率最低。

everysec：每秒同步一次。这是一个衡量安全性和效率的策略。最多只失落 1 秒 的数据

no：让操作系统决定最佳的同步工夫。这可能导致数据失落，但提供了最高的效率。

AOF 文件的载入

当 Redis 服务器启动时，如果配置为应用 AOF 长久化，它会查看 AOF 文件的存在。如果找到 AOF 文件，Redis 会加载并执行其中的命令来复原数据的。

这里顺带提个问题：如果 Redis 的 RDB 和 AOF 长久化都启用，redis 在载入数据的时候，是载入 AOF 文件？还是 RDB 文件？

我间接说答案：Redis 会优先载入 AOF 文件来复原数据，而不是 RDB 文件。这是因为 AOF 文件通常蕴含了更残缺的操作记录，从而可能复原更残缺的数据状态。而 RDB 文件是定时生成的数据快照，所以它可能没有记录到最初一次快照之后产生的所有更改。因而，应用 AOF 文件复原数据能够提供更高的数据完整性。

AOF 重写

在理解了 AOF 的工作原理之后，咱们晓得它是通过追加写操作命令到文件的形式来复原数据的。但这会带来一个新的问题: 随着追加命令的一直减少，这个 AOF 文件可能会变得很大和简短。面对这样的问题，Redis 提供了一个十分无效的优化伎俩，那就是 AOF 重写。

AOF 重写是什么？

AOF 重写，能够看作是对 AOF 文件 进行的一次“精简”操作。它的目标是缩小 AOF 文件的大小，并去除那些冗余的、不再必要的命令，使得该文件只蕴含复原以后数据集所需的最小命令集。

为什么须要 AOF 重写？

节俭磁盘空间：随着操作的积攒，原始 AOF 文件可能会变得十分大。通过重写，咱们能够缩小文件的大小。

减速复原速度：一个更小、更简洁的 AOF 文件意味着在 Redis 重启时，数据的复原过程会更快。

AOF 重写流程图：

步骤阐明：

AOF 重写次要有以下四步：

• redis 主过程 fork 子过程来进行 AOF 的重写，生成 AOF 文件。
• 在子过程进行 AOF 重写的同时，redis 主过程将新的写操作命令写入 AOF 重写缓冲区
• 主过程将 AOF 重写缓冲区的内容写入到新的 AOF 文件中
• 应用新的 AOF 文件替换旧的 AOF 文件

这里思考一下：子过程 进行 AOF 重写，具体怎么重写，是依据现有的 AOF 文件进行重写还是其余形式？

子过程是通过读取 Redis 以后的内存数据来进行重写的。如果: redis 数据库存在列表键 List = [a,b,c,d,e,f,g,h]，在旧的 AOF 文件中，可能有多个命令增加和删除这些元素。但在 AOF 重写时，子过程只须要看 List 键 的以后状态，而后生成一个简短的命令，如 RPUSH List a b c d e f g h，间接设置正确的值，防止了任何冗余操作。

AOF 配置详解

咱们只须要在 Redis 配置文件 redis.conf 中搜寻 APPEND ONLY MODE 即可搜到 AOF 配置项。

Q: 我想启用 AOF 模式，我应该怎么做？

A: 将 appendonly 设置为 yes。默认是 no。

Q: 我想扭转 AOF 文件的名称，该怎么做？

A: 应用 appendfilename 选项。默认名称是 appendonly.aof。

Q: 有哪些形式能够管制 AOF 数据同步到磁盘的频率？

A: 应用 appendfsync 选项。你有三个抉择：

always: 每次写操作后都同步。

everysec: 每秒同步一次。

no: 由操作系统决定何时同步。

默认设置是 everysec。

Q: 当 Redis 进行 AOF 重写或快照保留时，我怎么防止主过程 fsync 的提早？

A: 设置 no-appendfsync-on-rewrite 为 yes。默认是 no。

Q: 我怎么主动触发 AOF 文件重写？

A: 应用以下两个配置：

auto-aof-rewrite-percentage: AOF 文件增长的百分比，达到此值则触发 AOF 重写。例如，如果设置为 100%，那么当 AOF 文件的大小是上次重写后的两倍时，Redis 会思考触发主动重写。

auto-aof-rewrite-min-size: AOF 文件大小门槛，超过此值即便增长的百分比小也会触发 AOF 重写。

Q: 如果 AOF 文件在开端被截断，Redis 怎么办？

A: 应用 aof-load-truncated 选项。如果设置为 yes，Redis 尝试加载并启动，同时收回日志正告；如果为 no，Redis 会停止并回绝启动。默认是 yes。

AOF 长久化的优缺点

长处：

不轻易丢数据：AOF 记录了所有的写操作，所以即便服务器忽然断电，数据失落的机会也很小。

易于了解：AOF 是一个文本文件，外面就是一系列的命令，你能够关上查看。

出问题也能救：如果 AOF 文件最初有点损坏，Redis 也可能修复它，防止大量数据失落。

毛病：

可能会慢一些：因为要一直写入操作，所以比 RDB 要慢一点。

文件可能很大：AOF 会记录所有操作，所以文件可能迅速增大，占用更多空间。

复原工夫长：如果须要从 AOF 文件中复原数据，因为文件可能很大，所以这个过程可能会比较慢。

混合长久化

回顾一下，咱们曾经探讨了 Redis 的 RDB 和 AOF 长久化。RDB 提供疾速的数据恢复，但可能有数据失落危险；AOF 保障了数据完整性，但文件可能过大，复原速度较慢。那么，是否有一种既疾速又牢靠的办法？接下来，咱们将介绍 Redis 的 混合长久化策略。

混合长久化是什么？

混合长久化是 Redis 4.0 新引入的长久化策略，联合了 RDB 的疾速复原和 AOF 的数据完整性的长处，它首先以 RDB 格局保留以后数据状态，而后持续以 AOF 格局记录新的写操作，确保数据完整性并优化复原速度。

简略图解

混合长久化的工作原理

在 AOF 重写之前，RDB 和 AOF 都是依照它们各自的长久化策略工作的。当 AOF 重写被触发时，混合长久化才开始发挥作用：将以后的数据集会首先以 RDB 格局写入新 AOF 文件的顶部，而后再追加新的命令到文件的开端。

混合长久化的工作流程图

步骤阐明：

混合长久化的实现次要是靠主过程和子过程独特来实现的。

子过程:

子过程进行 AOF 重写：

• 首先创立新的 AOF 文件 appendonly.rdb
• 将 Redis 以后的数据生成 RDB 快照写入 appendonly.rdb 文件的开始局部

主过程

• 主过程先将新的写操作命令写入 AOF 重写缓冲区
  - 主过程将 AOF 重写缓冲区的内容追加到 appendonly.rdb

文件的 RDB 数据的开端

• 应用 appendonly.rdb 文件替换旧的 AOF 文件

混合长久化的配置

Q: Redis 的混合长久化如何开启？

A: 将 aof-use-rdb-preamble 选项设置为 yes，并且要同时启用 RDB 和 AOF 两种长久化。

混合长久化的 AOF 重写与一般的 AOF 重写的区别：

在不应用混合长久化的状况下，一般的 AOF 重写是通过读取以后的内存数据并记录达到这一状态所需的起码命令来缩小 AOF 文件的大小的。

而混合长久化在 AOF 重写时，会首先将以后数据集以 RDB 格局快照的模式写入新 AOF 文件的开始地位，而后再追加新的写命令到文件开端。

混合长久化的优缺点

长处：

更快的启动速度：混合长久化联合了 RDB 的速度劣势，所以 Redis 能够更快地重新启动，不必期待很久。

数据安全：利用 AOF 的形式，即便服务器忽然断电，也只会失落极短的工夫内的数据。

文件更玲珑：因为混合长久化联合了 RDB 和 AOF 的劣势，所以文件大小和冗余度都能够失去管制。

两败俱伤：简略说，它就是 RDB 和 AOF 的结合体，带来了两者的益处。

毛病：

略微简单：因为它联合了两种技术，所以解决起来比繁多的 RDB 或 AOF 要简单一点。

可能占更多空间：在某些状况下，保留数据的文件可能会比只应用 RDB 或 AOF 的文件要大一些。

写入速度：可能会稍慢一些，特地是当数据须要常常被保留到硬盘时（比方当 appendfsync 配置为“always”时）

总结

在本系列文章中，咱们深入探讨了 Redis 的长久化机制。通过具体介绍 RDB、AOF 以及混合长久化这三种支流的长久化办法，咱们不仅学习了它们各自的工作机制和配置策略，还探讨了它们的优缺点，以帮忙读者依据本人的理论需要选出适合的长久化形式。

• RDB 长久化以其高效的数据恢复速度和较小的性能开销怀才不遇，适宜数据备份和劫难复原场景。
• AOF 长久化通过记录每个写操作确保了更高级别的数据安全性，只管它可能导致文件体积增大和写入性能的轻微降落。
• 混合长久化模式联合了 RDB 的疾速数据恢复能力和 AOF 的数据安全性，提供了一种既疾速又牢靠的数据恢复解决方案。

所以大家在抉择长久化策略时，须要思考到数据安全性、复原速度、以及零碎性能三者之间的均衡。RDB 适宜须要定期备份的场景，AOF 适宜对数据失落有严格要求的利用，而混合长久化模式则是一种比拟折中的计划，它联合了 RDB 的疾速数据恢复能力和 AOF 的数据安全性。

这里我又将 Redis 的三种长久化形式的优缺点以及应用场景做了具体的比照:

最初

如果你对 Linux C/C++ 编程，Redis 等后端技术感兴趣或者想学习计算机根底相干的常识，无妨关注我的公众号「跟着小康学编程」。这里会继续更新的简略易懂的技术文章，也包含常见的技术面试题。

另外，小康最近创立了一个技术交换群，专门用来探讨技术相干或者解答读者的问题。大家在浏览这篇文章的时候，如果感觉有问题的或者有不了解的知识点，欢送大家加群询问。我可能解决的，尽量给大家回复。

本文由 mdnice 多平台公布