redis RDB

长风朗月碎梦
144 阅读11分钟

image.png

做快照时，数据还能被增删改吗？

Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave。 save：在主线程中执行，会导致阻塞； bgsave：创建一个子进程，专门用于写入 RDB 文件，避免了主线程的阻塞，这也是 Redis RDB 文件生成的默认配置。

是的，当Redis进行快照操作时（如执行RDB持久化），它仍然可以正常处理增加、删除和修改数据的请求。这得益于Redis使用的写时复制（Copy-On-Write, COW）机制在进行快照时减少阻塞。

RDB快照过程和写时复制（COW）

当执行RDB持久化（例如，通过SAVE命令或根据配置自动触发BGSAVE）时，Redis会fork出一个子进程来创建数据的快照。这个子进程会将当时的数据库状态写入一个磁盘文件中，而主进程继续处理客户端请求。

  1. fork操作：快照开始时，Redis通过fork创建一个子进程。这个过程是快照操作中唯一可能导致短暂阻塞的步骤，因为fork需要复制父进程的内存空间给子进程。fork的时间取决于Redis主进程所使用的内存大小，但通常很快完成。

  2. 写时复制（COW）：fork之后，子进程开始写快照文件，而主进程继续响应客户端请求。如果在快照过程中有数据被修改，操作系统会利用写时复制（COW）技术，为被修改的内存页创建一个副本，确保子进程的快照视图保持不变。这意味着主进程可以无阻塞地继续处理请求。

处理请求的能力

  • 继续处理请求：由于COW机制的存在，Redis的主进程在快照过程中仍然可以处理增加、删除和修改数据的请求，几乎不受快照操作的影响。

  • 性能考虑：虽然快照操作本身不会阻塞数据的增删改操作，但需要注意，如果快照期间发生了大量的数据修改，COW机制可能会导致额外的内存使用，因为修改的数据需要在内存中被复制。这不会影响Redis的响应能力，但可能会增加系统的内存需求。

结论

Redis的快照操作设计得非常高效，确保了即使在进行数据持久化时，也能保持服务的高可用性和响应性。通过利用写时复制技术，Redis可以在几乎不影响正常操作的情况下完成数据的持久化工作。然而，系统的性能可能会受到正在进行的数据修改活动和fork操作时刻系统资源状况的影响。

快照时数据能修改吗?

在对内存数据做快照时，这些数据还能“动”吗? 也就是说，这些数据还能被修改吗？ 这个问题非常重要，这是因为，如果数据能被修改，那就意味着 Redis 还能正常处理写操作。否则，所有写操作都得等到快照完了才能执行，性能一下子就降低了。

为了快照而暂停写操作，肯定是不能接受的。所以这个时候，Redis 就会借助操作系统提供的写时复制技术（Copy-On-Write, COW），在执行快照的同时，正常处理写操作。简单来说，bgsave 子进程是由主线程 fork 生成的，可以共享主线程的所有内存数据。bgsave 子进程运行后，开始读取主线程的内存数据，并把它们写入 RDB 文件。此时，如果主线程对这些数据也都是读操作（例如图中的键值对 A），那么，主线程和 bgsave 子进程相互不影响。但是，如果主线程要修改一块数据（例如图中的键值对 C），那么，这块数据就会被复制一份，生成该数据的副本（键值对 C’）。然后，主线程在这个数据副本上进行修改。同时，bgsave 子进程可以继续把原来的数据（键值对 C）写入 RDB 文件。

Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。是什么意思

在Redis 4.0中引入的混合持久化模式是一种结合了AOF（Append Only File）和RDB（Redis Database）持久化机制的方法，旨在利用各自的优势，提高数据恢复的速度，同时保持AOF提供的数据安全性。这种混合持久化方法在redis.conf配置文件中通过aof-use-rdb-preamble选项进行配置。

工作原理

在混合持久化模式下，当Redis执行AOF重写时，它不再仅仅只是追加命令到AOF文件中。相反，它会先创建一个RDB格式的数据快照（preamble，或称为前言部分），然后紧接着这个快照，追加之后执行的所有写命令。这样做的结果是一个包含了RDB快照和之后写操作日志的AOF文件。

模式优势

  1. 快速恢复：使用混合持久化模式可以显著加快数据恢复的速度。在重启时，Redis可以先加载RDB快照部分来快速恢复大部分数据状态，然后再应用AOF中RDB之后的写命令来恢复完整的数据状态。这比传统的只使用AOF方式恢复数据要快得多，因为加载RDB文件通常比逐条执行AOF中的命令要快。

  2. 数据安全性：这种方法保留了AOF持久化的所有优点，特别是在数据安全性方面。通过配置AOF重写策略和同步策略，可以在最小化数据丢失的同时，实现对数据的实时保护。

使用场景

混合持久化模式特别适合于那些既需要快速重启恢复，又不能承受因为使用纯AOF持久化而可能带来的长时间数据恢复过程的场景。这种模式结合了RDB的快速加载能力和AOF的高数据安全性，为Redis用户提供了一个折中的选择。

配置方法

在redis.conf配置文件中启用混合持久化模式的配置示例：

appendonly yes
aof-use-rdb-preamble yes

启用这个配置后，当AOF重写被触发时，Redis将使用混合持久化方式来生成新的AOF文件。

总结

Redis 4.0引入的混合持久化模式通过结合AOF和RDB的优点，提供了一个既能保证数据安全性又能加快数据恢复速度的解决方案。这种方法对于需要快速恢复和高数据安全性的生产环境是一个非常有用的功能。

启用这个配置后，当AOF重写被触发时，Redis将使用混合持久化方式来生成新的AOF文件。 具体展开讲讲

当Redis配置为使用混合持久化模式，并且触发了AOF重写时，它采取的操作步骤和内部机制旨在结合RDB和AOF的优点，以实现快速的数据恢复和高度的数据完整性。以下是具体的操作步骤和涉及的机制：

操作步骤

  1. 触发AOF重写：AOF重写可以由管理员手动触发（使用BGREWRITEAOF命令），或者由Redis根据配置的策略自动触发，例如当AOF文件增长到一定比例时。

  2. 生成RDB快照：在混合持久化模式下，重写过程开始时，Redis首先在AOF文件的开头生成一个RDB格式的数据快照。这一步是由重写的子进程执行的，该子进程会将当前内存中的数据状态以RDB格式写入一个临时文件中。

  3. 追加写命令：在RDB快照生成后，Redis继续将所有新的写命令追加到临时AOF文件中。这些是自RDB快照开始生成以来执行的所有写操作。

  4. 替换AOF文件：一旦新的AOF文件（包含RDB快照和之后的写命令）准备好，Redis会用这个新生成的AOF文件替换掉旧的AOF文件，完成重写过程。这一步的替换操作是原子的，确保了数据的一致性。

涉及的机制

  • 写时复制（Copy-On-Write, COW）：在AOF重写过程中，Redis利用操作系统层面的COW机制来避免在生成RDB快照时阻塞主进程的正常操作。这意味着主进程可以在子进程生成快照的同时继续处理客户端请求。

  • 原子替换：当新的AOF文件准备就绪后，Redis通过原子操作替换旧的AOF文件，这确保了即使在替换过程中发生故障，也不会导致数据丢失或状态不一致。

优点

  • 快速数据恢复：由于RDB快照可以快速加载到Redis中，使用混合持久化模式的Redis实例可以比仅使用AOF的实例更快地恢复到最近的状态。
  • 数据完整性：追加的写命令确保了自RDB快照点以来的所有更改都得到了保留，从而提供了与纯AOF模式相同的数据完整性保障。

结论

通过在AOF重写时采用混合持久化方式，Redis实现了一种折中的持久化策略，既能利用RDB的快速恢复能力，又能保持AOF提供的高数据完整性。这种方法对于那些既需要快速重启恢复能力，又不能容忍数据丢失的场景非常有用。

启用这个配置后， 主从同步的过程是怎么样的

启用混合持久化模式后，主从同步过程在Redis中依然遵循其基本的复制原理，但细节上有一些特别的地方需要注意。混合持久化模式主要影响的是数据如何被持久化到磁盘上，而主从同步是关于如何在网络上复制数据状态。不过，启用混合持久化模式对于初始化同步过程和部分重同步过程确实有一定的影响。

初始化同步过程

当一个Redis从服务器首次连接到主服务器，或者需要进行全量复制时，会发生以下步骤：

  1. 同步请求：从服务器向主服务器发送同步请求。
  2. RDB文件发送：在传统的复制过程中，主服务器会执行BGSAVE命令生成当前数据的RDB快照，并将这个RDB文件发送给从服务器。在混合持久化模式下，由于AOF文件已经包含了一个RDB格式的数据快照（即AOF重写时的前言部分），主服务器有可能直接使用当前的AOF文件来满足从服务器的全量复制请求，而不需要额外生成一个新的RDB文件。
  3. 缓存写命令：在生成RDB文件或准备AOF文件的过程中，主服务器会缓存所有新的写命令。
  4. 数据加载：从服务器接收到RDB文件后，会加载这个文件来构建自己的数据状态。如果是混合持久化模式下的AOF文件，从服务器同样会先加载AOF文件中的RDB部分。
  5. 处理缓存的写命令：一旦RDB文件加载完毕，从服务器会开始接收并应用主服务器在RDB文件生成期间缓存的所有写命令，以确保与主服务器的数据状态一致。

部分重同步过程

如果连接在短暂中断后恢复，且主服务器能够识别从服务器（通过复制积压缓冲区中的信息），则会进行部分重同步：

  1. 重同步请求：从服务器请求部分重同步。
  2. 积压缓冲区：主服务器会使用其复制积压缓冲区中的数据来满足从服务器的请求，发送自上次断开以来的所有写命令。

混合持久化模式的影响

  • 数据传输效率：在混合持久化模式下，由于AOF文件已经包括了RDB快照，这可能减少了主从同步时需要传输的数据量，尤其是在AOF重写后不久发生全量复制的情况下。
  • 快速启动：从服务器能够通过加载AOF文件中的RDB部分更快地完成初始数据状态的构建。

结论

启用混合持久化模式后，Redis的主从同步过程保持了其核心机制不变，但在全量同步时可能通过利用AOF文件中的RDB部分来提高效率和减少数据传输量。这种方法既保持了数据的完整性，又提高了同步过程的效率。

avatar
文章
阅读
粉丝