【425943】本文来源于请联系小菜良记公众号获取转载本文的授权。大家好，我叫小菜。希望成为一个擅长吹牛X谈架构的人！如果你也希望成为我期望成为的人，就请关注我，与我做个伴，让我不再孤单！最近我在找工作的时候发现，Redis肯定是一个非常受欢迎的面试内容。数据结构可以分为多种类型，每种都有其独特的特点和应用场景。常见的数据结构包括：\n1. **数组（Array）**：用于存储相同类型的数据元素，通过索引访问。\n \n2. **链表（Linked List）**：通过节点相互连接的方式存储数据，分为单向链表、双向链表等形式。\n \n3. **栈（Stack）**：后进先出（LIFO）的数据结构，只能在栈顶进行插入和删除操作。\n \n4. **队列（Queue）**：先进先出（FIFO）的数据结构，支持在队尾插入元素，在队头删除元素。\n \n5. **树（Tree）**：由节点和边组成的层级结构，包括二叉树、平衡树、二叉搜索树等。\n6. **图（Graph）**：由节点（顶点）和边（边缘）组成的非线性数据结构，用于表示各种关系。\n7. **堆（Heap）**：特殊的树形数据结构，通常用于实现优先队列。\n8. **哈希表（Hash Table）**：通过哈希函数将键映射到值的数据结构，实现快速的插入和查找操作。\n9. **集合（Set）**：存储互不相同元素的数据结构，通常支持并集、交集等操作。\n这些数据结构在不同的应用场景下具有不同的优势和效率，程序员需要根据具体需求选择合适的数据结构来优化算法和数据管理。怎样才能实现延迟队列呢？什么是淘汰机制？我的头脑几乎变得麻木了，这些问题依然困扰着我。我们接下来讨论一个比较普遍且难度适中的面试问题。Redis 的持久化机制是如何实现的？在开局就问一个问题：相信被问到 Redis 持久化的同学不在少数，而且答对的同学也不在少数。有些同学说起 Redis 持久化，可能就会迅速地提到 AOF 和 RDB 两个概念。只要你做好了面试准备，也就不会在这个问题上被问得太惨。你是否真正理解，还是当然知道。AOF 是 Append Only File 的缩写，指的是一种 Redis 数据持久化的方式，它将所有写操作追加到文件末尾。RDB 是 Redis DataBase 的缩写，是 Redis 另一种持久化方式，它通过保存数据库的快照来实现持久化。你有没有实际执行过呢？你认为面试官分辨不出你是在背题还是实际操作吗？如果你成功回答了一半的问题，可以继续往下阅读，也许会有所收获，至少在面试时有备无患~!Redis持久化是什么？让我们先不要急着朝着解决问题的方向前进，而是先弄清楚这道题的意思。数据持久化是指确保数据永久保存的过程。Redis 持久化是指将 Redis 内存中的数据存储到硬盘上，以保证数据在断电或重启后不会丢失的机制。Redis 提供了两种主要的持久化方式：RDB 和 AOF。\n1. **RDB（Redis DataBase）持久化**：RDB 是将 Redis 在内存中的数据定期保存到磁盘上的一种方式。通过生成一个快照文件（snapshot），记录了某个时间点上 Redis 数据的状态。RDB 文件是一个二进制文件，可以通过配置 Redis 的保存策略来控制生成的频率。\n2. **AOF（Append Only File）持久化**：AOF 是通过记录 Redis 服务器接收到的每一个写操作命令来实现的。这些命令会追加（append）到文件末尾，当服务器重启时，Redis 会重新执行这些命令来恢复数据。AOF 文件是一个文本文件，可以通过配置来控制其刷新的频率和方式。\nRDB 持久化相对于 AOF 持久化更加轻量和高效，但可能会丢失最后一次持久化之后的数据。AOF 持久化则更为安全，能够提供更高的数据保证性，但相对会占用更多的磁盘空间和写入操作。在实际使用中，可以根据业务需求和数据重要性选择适合的持久化方式，甚至可以同时使用两种方式以提高数据的安全性和可靠性。将Redis中保存在内存中的数据写入磁盘，以防止因服务宕机而导致内存数据丢失的问题。有些朋友问道：如果磁盘受损，数据怎样才能持久保存呢？即使做了多重备份可以解决硬盘损坏的问题，但如果出现多点丢失怎么办呢？停一下，我们所讲的是关于Redis内存数据转移到磁盘的持久化问题，不要以为这个问题可以与面试官聊上半个小时哦~！这篇文章将从几个方面阐述Redis持久化问题。在处理你的持续性问题时，我们可以采取三个主要方面，即战略的三步走。RDB 的全称是什么？Redis 数据备份文件又称为 Redis 数据快照，是 RDB 的缩写，用于备份 Redis 数据库。这个工具的作用是将内存中的所有数据记录到磁盘上，当 Redis 实例出现故障并重新启动时，可以通过读取快照文件来恢复数据。内心充满喜悦，看来学到的第一个概念可以解决 Redis 持久化问题~ 在学习 RDB 之前，让我们先了解两个核心概念fork和cow，接下来我们会进行解释，但先保持悬念。RDB是Redis中默认的持久化机制，它会按照一定的时间周期将内存中的数据以快照的方式保存到磁盘中，在磁盘中生成以 .rdb 为后缀的特殊类型的数据文件。同时，可以通过配置文件中的save参数来定义快照的周期。我们先从配置文件中的两个参数入手，首先是save配置。Redis 会将所有数据存储到 dump.rdb 文件中，但这个操作会让 Redis 阻塞其他命令的执行。因此，在配置文件中，我们可以找到与 save 相关的配置项 dbfilename，它的作用是定义 rdb 文件的名称，但必须注意不能将其定义为路径，只能定义为文件名。执行完 save 命令后，Redis 会将所有数据存储到 dump.rdb 文件中。在 redis 文件夹中可以找到一个名为 dump.rdb 的文件。save 配置项定义了在多长时间内发生多少次变化后，会执行 bgsave 操作。如果该配置项的值为 save ""，则表示禁用 RDB。接下来我们将使用 save 配置进行测试。修改 dbfilename 的值为 dump-test.rdb，即可设置生成的 RDB 文件名。save 选项用于设置 Redis 自动触发 bgsave 的条件，格式为 save ，其中 表示自上次 save 以来经过的秒数， 表示在经过指定的秒数后 Redis 中的数据至少发生了 次更改，才会执行 bgsave。我们可以在 redis-cli 中执行相应的操作，退出后可以在当前目录中看到生成的 dump-test.rdb 文件，证明我们的配置生效了。接下来，我们可以直接重启 Redis。检查我们刚刚保存的数据 `

` 是否仍然存在。如果能够看到我们的数据，这表示 Redis 持久化操作成功了。然后我们删除了刚刚生成的 dump-test.rdb 文件，并重新启动 Redis。这表明 Redis 在启动时依赖 .rdb 文件来恢复数据。接下来，我们需要删除刚生成的dump-test.rdb文件，并重新启动Redis

。这说明Redis启动时依赖.rdb文件来恢复数据。那么，我们之前提到的bgsave是如何执行的呢？我们之前提到了两个概念fork和cow，不知道大家是否还记得。这两个概念非常重要！发起bgsave命令时，主进程将会复制出一个新的子进程，而这个子进程将会与主进程共享内存数据。子进程会把数据写入一个临时的 .rdb 文件，当子进程写完临时文件后，会用它来替换原来的 .rdb 文件。这个是 fork 的核心原理，那么什么是 cow 呢？cow技术的全称是写时复制技术。当主进程进行读操作时，它会访问共享内存，而执行写操作时，它会复制一份数据并进行写操作。

的具体流程如下：

那么，这种持久化方式有哪些优点呢？数据持久化方式 RDB 具有一些优势： 方便持久化，只需一个 dump.rdb 文件 具备容灾性，可将文件保存到安全的磁盘中 最大化性能，通过 fork 子进程完成写操作，使主进程继续处理命令，最大限度地提高 IO，确保 Redis 高性能 不过，RDB 也存在缺点： 数据安全性低，RDB 定期持久化（save），若 Redis 在持久化期间发生故障，可能导致数据丢失，因此适用于数据要求不是非常严格的情况 长时间保存，对于大数据量，快照保存时间较长，会占用磁盘空间 因此， RDB 数据持久化方式有其优劣之处。 二、AOF

AOF 全名为 Append Only File (追加文件)，在使用时需要慎重考虑。Redis 将每个写命令记录到AOF文件中，这可以视为命令日志文件。该功能默认处于关闭状态，您可以在redis.conf文件中查看有关AOF相关的配置项。打开AOF日志记录功能的方法是将"appendonly"设置为"yes"。默认情况下，该功能是关闭的。配置项"appendfilename"用于设置AOF文件的名称。以上两个配置项是用来开启AOF日志记录的。需要了解的是还有一项额外配置，即appendfsync选项，用于设置AOF命令记录的频率。该选项有三个可选值，具体如下：\n配置项 刷盘时机 优点 缺点 \nAlways 同步刷盘 可靠性高，但效率较低 \nEverysec 每秒刷盘 可以在一定程度上保证数据可靠性和效率 \nNo 不刷盘 效率最高，但数据可靠性无法保证几乎不会发生数据丢失 对性能的影响较大 每秒 每秒同步 性能适中 最多丢失1秒的数据 不会 受操作系统控制 最佳性能 可靠性较低，可能会丢失大量数据

如果了解 Mysql 中relay log 日志的同学，对于这种模型，您一定会感到非常熟悉。

的工作原理是将写入命令追加到AOF文件的末尾。为了使用AOF持久化功能，需要设置同步选项，以确保写入命令在合适的时机被同步到磁盘文件上。这是因为写入文件时，并不会立即将内存内容同步到磁盘文件上。相反，写入操作会先存储在缓存区中，然后由操作系统决定何时将其同步到磁盘。

的原理是将写入命令追加到AOF文件的末尾。使用AOF持久化需要设置同步选项，以确保写入命令同步到磁盘文件的时机。这是因为对文件进行写入并不会立即将内存同步到磁盘上，而是先存储到缓存区，然后由操作系统决定何时同步到磁盘。

我们打开AOF记录功能来查看：

可以看出每次操作均已记录到AOF文件中。即使重新启动Redis，也可以获取刚才存储的数据，证明持久化已生效。

看到上面的AOF记录文件，感觉整齐规范吗？但是在在线环境中过于规整反而不利，因为这些文件主要是供机器阅读，而不是人类阅读。因此最好能够进行压缩处理。

为了解决AOF文件体积不断增大的问题，用户可以向Redis发送 bgrewriteaof命令，这个命令会通过 通过移除AOF文件中的冗余命令 来重写(rewrite)AOF文件，使AOF文件的体积变得尽可能地小。bgrewriteaof的工作原理和 bgsave 创建快照的工作原理非常相似：Redis会创建一个子进程，然后由子进程负责对AOF文件进行重写。因为AOF文件重写也需要用到子进程，所以快照持久化因为创建子进程而导致的性能问题和内存占用问题，在AOF持久化中也同样存在。既然我们可以手动触发压缩，那么也可以自动触发压缩。这就需要提到两个配置项在配置文件中：auto-aof-rewrite-percentage和auto-aof-rewrite-min-size。这些配置项的含义是，当AOF文件的大小超过64MB，并且比上一次压缩后的大小至少增加了一倍（100%）时，Redis将执行bgrewriteaof命令。总结一下，它的优点如下：\n1. 数据安全。AOF持久化可以设置appendfsync属性为always，每执行一次写命令操作都会立即将其记录到AOF文件中，以确保一致性。通过使用 append 模型来进行文件写入，即使服务器在中途宕机，也可使用 redis-check-aof 工具解决数据一致性问题。

\n以下是缺点：

\n AOF 文件较 RDB 文件大，恢复速度慢 \n 数据集较大时比 RDB 文件的启动效率低

\n在优缺点均沾的情况下，需要谨慎选择

\n另外，我们来介绍一下两种文件的区别

\n分别介绍这两者后，我们来回顾一下它们之间的区别。

， 方面的 RDB AOF ， 持久化方式中的定时对整个内存做快照每次执行的命令都会被记录 数据的完整性 在两次备份之间可能会有数据丢失 相对而言更为完整。 刷盘策略的选择取决于多个因素。例如，文件大小和压缩对文件体积的影响，以及记录命令对文件体积的影响。此外，宕机恢复速度也是考虑因素，它可能快速或慢速。数据恢复的优先级也很重要，像AOF因数据完整性较高，因此优先级较高，而其他可能会较低。由于数据的完整性更高，系统所占用的资源会更多，其中大量的CPU和内存消耗较少，主要消耗的是磁盘IO资源。且 AOF 重写时会占用大量CPU和内存资源 使用场景 可以容忍数分钟的数据丢失，追求更快的启动速度 对数据安全性要求较高

看完上面后，想必对两种持久化机制都有一定的了解了。且 AOF 重写时会占用大量CPU和内存资源 使用场景 可以容忍数分钟的数据丢失，追求更快的启动速度 对数据安全性要求较高

看完上面后，想必对两种持久化机制都有一定的了解了。两者都有优劣势，那我们该如何选择?以下是几点建议：如果您可以容忍短时间内的数据丢失，可以采用 RDB 机制，定时生成 RDB 快照。此外，相比于 AOF，使用 RDB 恢复数据集的速度更快。但是，仅仅使用 RDB 机制可能会导致很多数据丢失，因此我们需要综合使用 AOF 和 RDB 两种持久化机制来确保数据的安全性。我们可以使用 AOF 作为数据恢复的第一选择，保证数据不丢失；同时，使用 RDB 做不同程度的冷备份，在 AOF 文件都丢失或损坏不可用的情况下，可以使用 RDB 进行快速的数据恢复。总之，充分利用 RDB 和 AOF，可以快速恢复数据。通过配置 AOF，可以完善数据

的持久化。本文已经讲述了 Redis 持久化机制的配置。相信通过学习本文，面试时遇到有关此问题，也会游刃有余！不要光说不做，不要懒惰贪图安逸，一起来和小编成为自夸技术的程序员吧~点个关注，一起相伴，让小编不再孤独。

不要光说不练，不要贪图安逸，与小编一同成为一个能够实际落地并深耕技术架构的程序员吧~点个关注，一同前行，让小编不再孤单。期待我们的深入交流！