Redis 持久化揭秘：选择 RDB、AOF 还是混合持久化？

Redis 持久化揭秘：选择 RDB、AOF 还是混合持久化？

一、关于Redis 持久化

Redis 是一个内存数据库，意味着它主要将数据存储在内存中，从而能够提供极高的性能。然而，作为内存数据库，Redis 默认情况下的数据不会永久保存。为了确保数据在重启或故障后能够恢复，Redis 提供了几种 持久化机制。这些机制允许 Redis 将内存中的数据保存到硬盘上，从而实现数据持久化。

Redis 提供了两种主要的持久化方式：RDB（Redis 数据库快照） 和 AOF（Append-Only File）日志。除此之外，Redis 还提供了 混合持久化 机制，结合了 RDB 和 AOF 的优点。

​

‍

Redis 的持久化机制经历了多个版本的改进与演化，随着需求的变化，Redis 提供了不同的持久化方案来满足各种应用场景。以下是 Redis 持久化发展历程的简要概述：

1. 早期（Redis 1.x）

• 在 Redis 1.x 版本，持久化机制的设计就已经开始出现，并且初步支持了 RDB（Redis 数据库快照） 机制。此时，RDB 是 Redis 唯一的持久化方式。
• RDB（快照） ：每隔一段时间，Redis 会将内存中的数据写入到磁盘生成一个二进制文件（dump.rdb​），通过这种方式来保证数据在重启后能够恢复。
• 该版本的持久化机制设计较为简单，主要是为了提供对数据丢失的容忍以及重启后的数据恢复能力。

1. Redis 2.0 - 引入 AOF（追加文件）

• AOF（Append-Only File） ：在 Redis 2.0 版本中，新增了 AOF 持久化，这为 Redis 提供了另一种持久化策略。与 RDB 快照不同，AOF 会记录 Redis 执行的所有写操作，并将这些操作以日志的形式追加到文件中（appendonly.aof​）。在 Redis 重启时，可以通过重放 AOF 文件中的命令恢复数据。
  • AOF 提供了比 RDB 更高的数据安全性，因为它记录了每个操作，理论上可以做到几乎没有数据丢失。
  • 但是，由于每个写操作都需要同步到磁盘，AOF 的性能开销相对较大，尤其是在高频率写入的情况下。

1. Redis 2.4 - AOF 重写机制

• 在 Redis 2.4 版本中，为了减少 AOF 文件随着时间推移而变得越来越大的问题，引入了 AOF 重写机制（AOF Rewrite） 。
• AOF 重写机制通过创建一个新的 AOF 文件，重写当前数据库状态下的最小化写操作，将文件缩减到一个更小的大小。这一机制使得 AOF 文件不会无限增长，有助于节省磁盘空间。
• 通过定期重写 AOF 文件，Redis 在性能和磁盘空间使用之间到了一个较好的平衡。

1. Redis .0 - 引入 RDB 和 AOF 混合持久化

• Redis .0 在原有的 RDB 和 AOF 两种持久化机制基础上，提出了 RDB + AOF 混合持久化 方案。
  • 混合持久化模式将 RDB 和 AOF 的优点结合起来：在 Redis 重启时，首先使用 RDB 文件进行快速恢复，然后再用 AOF 文件来完成更高精度的恢复。这样可以在启动时获得更好的性能，同时减少 AOF 文件的恢复时间。
  • 混合持久化机制通过将 AOF 写操作存储在 RDB 快照文件之后，减少了 AOF 文件的大小，并提高了数据恢复的速度。

1. Redis 4.0 - AOF 重写性能优化

• 在 Redis 4.0 版本中，AOF 重写机制进行了进一步的优化，尤其是在内存消耗和文件重写的效率上做了改进。
• Redis 4.0 引入了 AOF 持久化重写时的后台线程，即 AOF 重写不再阻塞主线程，而是通过一个后台线程异步地进行，从而避免了 AOF 重写过程中的性能瓶颈。
• 此外，Redis 4.0 增强了对 AOF 文件在大规模数据时的处理能力，使得 AOF 持久化更加高效。

1. Redis 5.0 - AOF 日志的优化和压缩

• Redis 5.0 进一步对 AOF 持久化机制进行了优化，增强了 AOF 文件的压缩和优化。通过对 AOF 文件中的重复操作进行压缩，减少了磁盘的使用空间，提升了 AOF 机制的性能。
• Redis 5.0 中还对持久化的配置进行了一些细化，比如优化了 AOF 文件的重写触发机制，避免了重写过程中因不必要的操作而造成性能的影响。

1. Redis 6.0 - 持久化机制的改进和安全性增强

• Redis 6.0 版本对持久化机制做了些许优化，尤其是对 AOF 和 RDB 文件在高负载下的表现进行了改进，提升了 Redis 在大规模部署时的稳定性。
• 此版本还引入了更多的安全性特性，比如 更强的加密 支持和对客户端连接的限制，虽然这些主要是针对安全性，但间接地影响了 Redis 的持久化性能。
• 同时，Redis 6.0 提供了更多灵活的配置选项，允许更精细地控制持久化机制的行为，以适应不同的生产环境需求。

1. Redis 7.0 - 更进一步的持久化优化

• Redis 7.0 引入了 更智能的 AOF 重写机制，进一步优化了 Redis 启动和恢复的速度。
• 在 Redis 7 中，持久化机制更加灵活，通过配置 appendfsync​（AOF 文件同步策略）和 save​（RDB 快照保存策略），用户可以精确控制持久化行为，从而在性能和数据一致性之间到平衡。
• Redis 7.0 对 RDB 文件和 AOF 文件的合并操作进行了改进，以便在某些情况下减少系统资源的消耗，并提高数据恢复效率。

‍

‍

二、RDB 持久化（快照）

RDB（Redis Database）持久化通过 定期创建数据快照 来保存数据。RDB 会将 Redis 内存中的数据保存到一个二进制文件（默认为 dump.rdb​）中。

Redis 默认启用了 RDB 快照 持久化，而 AOF 持久化 默认是关闭的

​

‍

• Redis 会在特定的时间间隔内，自动将内存中的数据快照保存到磁盘上（即 RDB 文件）。
• RDB 是一种 时间点快照，这意味着 Redis 会在某个时间点将内存中的数据全部写入文件。如果在快照期间发生了数据变化，那么这些变化将不会出现在该快照中。

​

• 当 Redis 执行 BGSAVE​ 命令或者根据 save​ 配置自动执行时，它会通过 fork()​ 系统调用创建一个子进程，子进程会将当前内存中的所有数据（整个数据库的内容）写入一个临时的 RDB 文件。
• 快照的写入是一次性操作，不会中途停止，也没有增量更新。
• 快照完成后，新的 RDB 文件会替换原先的文件（通常是 dump.rdb​）。

‍

• 可以通过 ​ 文件中的配置来设置 RDB 快照的生成条件。例如，设置在特定时间内执行多少次写操作后进行快照： save 900 1 # 900秒内如果至少发生1次写操作，则生成快照 save 00 10 # 00秒内如果至少发生10次写操作，则生成快照 save 60 10000 # 60秒内如果至少发生10000次写操作，则生成快照

这些条件是 “或” 的关系，也就是说，只要 任意一个条件满足，Redis 就会执行快照操作。因此，只要有任意一组条件被触发，Redis 就会创建 RDB 快照文件。

‍

windows redis版本，redis.文件配置

​

‍

​

‍

• 性能高效：RDB 持久化是基于快照的方式，生成快照时对 Redis 的性能影响相对较小。
• 恢复速度快：当 Redis 重启时，RDB 文件加载速度较快，可以迅速恢复数据。
• 节省磁盘空间：由于是定期生成快照，因此 RDB 文件通常比 AOF 文件小。

‍

• 数据丢失风险：由于 RDB 是基于快照的，如果在快照生成和下一次快照之间发生故障，则该段时间内的数据将丢失。
• 不够灵活：无法像 AOF 那样记录每一条命令，灵活性较差。

‍

• 适用于对数据丢失要求不高的场景，或者数据本身容易重建的应用。
• 在大多数情况下，RDB 适合用来进行数据备份。

‍

‍

三、AOF 持久化（Append-Only File）

AOF（Append-Only File）是 Redis 的另一种持久化机制，它通过记录所有写操作的日志来确保数据持久性。每次对 Redis 执行写操作时，都会将该操作追加到 AOF 文件中。AOF 文件实际上是 Redis 执行命令的一个日志，重启 Redis 时，Redis 会重新执行这些命令来恢复数据。

文件名：appendonly.aof，如果没有更改过配置文件的 dir​ 配置，默认会在 Redis 的当前工作目录下生成 AOF 文件。

​

‍

• Redis 将每一个写操作（如 SET​、ICR​ 等）追加到 AOF 文件中，AOF 文件会记录每个写命令。
• 在 Redis 重启时，会重新执行 AOF 文件中的命令，恢复数据。

‍

• 可以通过 ​ 文件中的 appendonly​ 配置项开启 AOF 持久化： appendonly yes appendfilename "appendonly.aof"
• AOF 同步策略：Redis 提供了三种 AOF 同步策略，控制写命令同步到 AOF 文件的方式：
  • appendfsync always​：每个写命令都会同步到 AOF 文件（最安全，但性能最差）。
  • appendfsync everysec​：每秒同步一次（既保证了数据安全，又提供了较好的性能，推荐使用）。
  • appendfsync no​：Redis 依赖操作系统来同步 AOF 文件（性能最好，但数据安全性最差）。

​

‍

• 数据安全性高：AOF 持久化记录了每个写命令，即使 Redis 崩溃，AOF 文件可以保证数据的恢复。
• 精确恢复：由于记录的是每个写命令，AOF 可以恢复到非常接近崩溃时的状态。

‍

• 性能开销较大：每次写命令都需要记录到 AOF 文件，频繁的磁盘写入会影响性能。
• AOF 文件可能较大：由于记录了每一条写操作，AOF 文件通常比 RDB 文件大，特别是在写操作频繁的情况下。

‍

• 适用于对数据安全性要求较高的场景，如金融、交易系统等。

‍

‍

四、混合持久化（RDB + AOF）

Redis 4.0 引入了 混合持久化（Hybrid Persistence）功能，将 RDB 和 AOF 结合起来，结合了两者的优点。混合持久化将 RDB 快照的内容和 AOF 操作日志结合保存。

​

‍

备注：Redis Windows 版本（无论是官方的还是第三方移植的版本）并不支持混合持久化功能。（Redis 最初是为了 Linux/Unix 系统设计的，因此官方并未提供直接支持 Windows 的原生版本。Windows 上的 Redis 实际上是通过 Microsoft 的开源项目 MicrosoftArchive/redis 来移植的，或者有社区的其他移植版本。）

‍

• 在混合持久化模式下，Redis 会在生成 RDB 快照时，将 RDB 快照头和 AOF 日志结合成一个新的 AOF 文件。这样既保证了数据在恢复时的精确性，又降低了 AOF 文件的大小。

‍

• 恢复速度快：因为它结合了 RDB 的快速恢复能力和 AOF 的精确恢复能力。
• 节省磁盘空间：相比纯 AOF，混合持久化生成的文件更小。
• 高性能：相对于纯 AOF 持久化，混合持久化对性能的影响较小。

‍

要启用混合持久化，您需要在 ​ 配置文件中做如下设置：

1. 启用 AOF 持久化： 确保 appendonly​ 配置项设置为 yes​，表示启用 AOF 持久化。 appendonly yes
2. 启用混合持久化： 在 Redis 4.0 及以上版本，混合持久化是默认启用的，但您可以通过设置以下选项来进行配置： aof-use-rdb-preamble yes 这个配置项的作用是启用 AOF 文件中的 RDB 前缀（即在 AOF 文件开头部分存储 RDB 快照）。如果设置为 no​，则 Redis 会使用传统的 AOF 文件格式，不会混合 RDB 快照。
3. RDB 和 AOF 配置： 如果您已经启用了 AOF 持久化，您可以继续使用常规的 AOF 配置项来调整 AOF 文件的行为（如 appendfsync​ 和 auto-aof-rewrite​ 等）。

‍

完整配置示例：

# 启用 AOF 持久化
appendonly yes
​
# 启用混合持久化
aof-use-rdb-preamble yes
​
# AOF 文件同步策略（根据需要选择）
appendfsync everysec
​
# AOF 文件的重写策略
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
​
# 定期创建 RDB 快照的配置（如果需要）
save 900 1   # 900秒（15分钟）内至少有1次写操作
save 00 10  # 00秒（5分钟）内至少有10次写操作
save 60 10000 # 60秒内至少有10000次写操作

‍

1. 高频写入与持久化要求高的场景：混合持久化减少了 AOF 写入的性能瓶颈，同时保证数据持久化。
2. 快速恢复场景：混合持久化利用 RDB 快速恢复数据，再通过 AOF 恢复增量更新，减少恢复时间。
3. 磁盘 I/O 和内存占用平衡的场景：结合 RDB 的定期快照和 AOF 的增量更新，避免 AOF 文件过大，优化磁盘空间使用。
4. 高可用性和数据安全性需求：通过结合 RDB 和 AOF，减少数据丢失的风险，并保证数据快速恢复。
5. 低延迟要求的系统：混合持久化减少了 AOF 文件的写入，降低了磁盘延迟，适用于低延迟的应用场景。

‍

‍

五、持久化选择与配置

在实际应用中，如何选择持久化方式取决于对 性能 和 数据安全性 的不同需求：

• 如果 数据安全性要求较高，可以选择 AOF 持久化或混合持久化。
• 如果 对性能要求较高，且可以容忍少量数据丢失（例如一分钟内的数据），则可以使用 RDB 持久化。
• 对于一些 备份需求，可以使用 RDB 配合 AOF，获得两者的优势。

‍

Redis 提供了两种主要的持久化机制：RDB 和 AOF，每种机制有各自的优缺点。RDB 更注重性能，适合做定期备份，但可能会丢失最近的几分钟数据；AOF 更注重数据的完整性，适合对数据丢失敏感的应用，但会带来一定的性能开销。混合持久化结合了 RDB 和 AOF 的优势，可以提供更快的恢复速度和更小的文件大小。根据具体的业务需求，可以选择合适的持久化策略。

‍

‍

‍

‍

‍