Redis持久化（RDB、AOF）详解

Redis持久化详解

一、Redis为什么需要持久化？

• Redis 是一个基于内存的数据库，拥有极高的读写性能，但是内存中的数据在断电或服务器重启时会全部丢失，因此需要一种持久化机制来将数据保存到硬盘上，以便在需要时进行恢复。
  
• Redis需要持久化主要是为了确保数据在服务器重启或发生故障时不会丢失。
  

---

二、Redis持久化方式

Redis 支持两种主要的持久化方式：RDB（Redis Database Backup）和AOF（Append-Only File）。

1. RDB（Redis Database Backup）

RDB 是 Redis 的默认持久化方式，它通过定期将内存中的数据快照（snapshotting）写入磁盘来实现持久化。

当启用 RDB 持久化时，Redis 会根据配置文件中的 save 指令，周期性地将内存中的数据集转化成二进制文件（快照文件）保存到磁盘上。

RDB 的优势：

• 1.高效：RDB最大化了Redis的性能，因为Redis父进程持久化时唯一需要做的是启动(fork)一个子进程，由子进程完成所有剩余工作。父进程实例不需要执行像磁盘IO这样的操作。

• 2.紧凑：RDB 文件是 Redis 数据在某个时间点的快照，以二进制格式存储，适合用于备份和恢复。

配置 RDB 持久化：

在 Redis 的配置文件中，可以通过以下配置来调整 RDB 持久化的行为：

• save 指令的参数依次为持久化操作触发的时间和改变的 key 的数量。

save 900 1         # 在 900 秒（15 分钟）内，如果至少有 1 个 key 被改变，则执行持久化操作
save 300 10        # 在 300 秒内，如果至少有 10 个 key 被改变，则执行持久化操作
save 60 10000      # 在 60 秒内，如果至少有 10000 个 key 被改变，则执行持久化操作

默认情况下，Redis保存数据集快照到磁盘，名为dump.rdb的二进制文件。

RDB 快照文件较小，是一个紧凑的二进制文件，所以重启时加载速度很快。适合快速加载和传输。

配置示例

常见的 redis.conf 配置片段，涵盖了 RDB 快照的自动触发设置：

# 自动触发配置
save 900 1       # 900秒内至少1次写操作
save 300 10      # 300秒内至少10次写操作
save 60 10000    # 60秒内至少10000次写操作

# RDB 文件名
dbfilename dump.rdb

# RDB 文件保存路径
dir /var/lib/redis

# 是否压缩 RDB 文件
rdbcompression yes

# 是否校验 RDB 文件
rdbchecksum yes

---

RDB 触发机制：

1. 手动触发

Redis 提供了两个命令用于手动生成 RDB 快照：

• SAVE：SAVE 命令会立即生成一个 RDB 文件，并阻塞 Redis 服务器直到保存操作完成。

• 在执行 SAVE 的过程中，Redis 不能处理其他命令，因此在生产环境中通常不建议使用。

  SAVE
  

• BGSAVE：BGSAVE 命令会触发一个后台保存操作。

• Redis 会创建一个子进程来进行 RDB 文件的生成，而父进程继续处理客户端请求。生成 RDB 文件完成后，子进程会退出。

  BGSAVE
  

2. 自动触发（基于配置）

Redis 根据配置文件中的设置，自动触发 RDB 快照保存。

这个机制基于配置文件 redis.conf 中的 save 参数，该参数定义了在一定时间内发生一定数量的写操作后触发 RDB 快照。

save 900 1  # 900秒内至少有1次写操作
save 300 10 # 300秒内至少有10次写操作
save 60 10000 # 60秒内至少有10000次写操作

• 在900秒（15分钟）内，如果至少有一次写操作，Redis 将触发一次 RDB 保存。
• 在300秒（5分钟）内，如果至少有10次写操作，Redis 将触发一次 RDB 保存。
• 在60秒内，如果至少有10000次写操作，Redis 将触发一次 RDB 保存。

这些规则是按顺序检查的，一旦满足任一规则，Redis 就会触发一次 RDB 快照保存。

3. 特殊事件触发

除了手动和自动触发，某些特殊事件也会触发 RDB 快照保存：

• 主从复制（Replication）：当一个 Redis 实例作为主节点接受一个从节点的连接请求时，主节点会执行一次 BGSAVE 并将生成的 RDB 文件发送给从节点，这样从节点可以快速同步数据。

• 故障恢复：如果 Redis 被配置为在启动时加载 RDB 文件，那么每次 Redis 重启时都会通过加载 RDB 文件来恢复数据。

---

Redis 快照（RDB）持久化的工作流程

1. 调用 fork()：

   • Redis 会调用 fork() 函数来创建一个子进程。

   • 此时，父进程和子进程会共享相同的内存空间，但由于操作系统的写时复制（Copy-On-Write, COW）机制，只有在父进程或子进程对数据进行写操作时，才会真正复制这些内存页面。
     

   • 写时复制（Copy-On-Write, COW）是操作系统的一种优化技术。在 fork() 之后，父进程和子进程共享相同的物理内存页面，只有当其中一个进程需要写入数据时，才会为该进程创建新的内存页面。这带来了几个优势：

   • 效率高：通过共享内存，避免了不必要的内存复制，提高了效率。

   • 资源节约：只有在需要修改时才分配新的内存页面，节省了内存资源。

2. 子进程写入 RDB 文件：

   • 子进程负责将当前的数据集（即内存中的所有数据）写入到一个临时的 RDB 文件中。
   • 这个过程不会影响父进程的正常读写操作，因为它们在内存上是独立的。

3. 替换旧的 RDB 文件：

   • 当子进程完成对临时 RDB 文件的写入后，Redis 会用这个新的 RDB 文件替换原来的 RDB 文件。
   • 这是一个原子操作，可以确保在整个替换过程中，如果发生任何错误，旧的 RDB 文件仍然存在，不会造成数据丢失。

4. 删除旧的 RDB 文件：

   • 替换完成后，旧的 RDB 文件将被删除，以确保磁盘空间的合理使用。

---

RDB不足之处：

1.数据丢失风险：

• RDB 持久化是通过周期性地生成数据快照来保存数据的。

• 所以在两次快照之间发生的写操作如果宕机，会导致这些操作的数据丢失。

• 例如，如果 Redis 在最后一次持久化后发生了故障，但是在下次持久化之前未能恢复，那么这期间的数据更新会丢失。

2.性能影响：

• 在进行 RDB 持久化时，Redis 会 fork() 出一个子进程来执行持久化操作。
• 如果数据集非常大，fork() 操作可能会消耗大量的 CPU 和内存资源，影响 Redis 的性能表现，特别是在持久化大数据集时会更加明显。

为了弥补这些不足，Redis 还提供了另一种持久化机制 AOF（Append-Only File），它通过记录每一次写操作来保证更高的持久化频率和数据安全性。

---

2. AOF（Append-Only File）

AOF 通过将每一个写操作（如 SET、INCR 等）追加到日志文件中，从而记录下所有对数据库状态改变的操作。

即使在 Redis 崩溃或重启后，可以通过重放这些操作来恢复数据。

当服务器重启时，会重新执行这些命令来恢复原始数据集的状态。

2. AOF 的工作流程

2.1 写命令的记录

每当 Redis 接收到一个会修改数据的命令时（如 SET、INCR 等），该命令会被以文本形式追加到 AOF 文件的末尾。

当然这些命令肯定不会执行一条就写入到文件中一条，这样会严重拖垮性能，而是先保存到临时缓冲区aof-buf中,再择机写入文件。

这些命令按照它们执行的顺序被记录下来。

2.2 同步策略

Redis 提供了几种不同的 AOF 同步策略，可以通过配置 appendfsync 参数来控制aof_buf缓冲区什么时候写入到AOF文件：

• appendfsync always：每次有新命令追加到 AOF 文件时，都会立即调用 fsync() 将数据同步到磁盘。这种方式保证了最高的数据安全性，但性能较低。
• appendfsync everysec：每秒钟调用一次 fsync()。这是默认配置，它在数据安全性和性能之间取得了良好的平衡。
• appendfsync no：从不调用 fsync()，只依赖操作系统来决定何时将数据刷新到磁盘。这种方式性能最好，但数据安全性最低，如果系统崩溃，可能会丢失最近的写操作。

2.3 AOF 重写

随着时间的推移，AOF 文件会变得越来越大。为了避免文件过大影响性能，Redis 提供了 AOF 重写机制。

重写不是简单地压缩 AOF 文件，而是重新构建一个新的 AOF 文件，包含产生当前数据集的最简化命令集。

重写过程：

1. 创建子进程：Redis 创建一个子进程来进行重写。这与 RDB 快照类似，使用 fork() 创建子进程。

2. 子进程重写 AOF 文件：子进程会读取父进程的内存数据，并生成相应的最小集命令写入新的 AOF 文件。

• 这个最小集合命令指的是在重写过程中，Redis 会尽可能地合并和优化原始 AOF 文件中的写操作，以便生成一个更加紧凑和高效的新 AOF 文件。
  • 1. 命令合并：Redis 子进程会读取当前内存中的数据集，并将多个连续的写命令合并为单个命令。例如，多个连续的 SET 命令可以被合并为一个 MSET 命令。
  • 2. 删除和更新优化：子进程会检查并丢弃那些已经被覆盖或者已经不存在的命令，从而减少新 AOF 文件中不必要的写入。
  • 3. 数据结构优化：Redis 会尝试将多个操作合并到一起，以减少写入的次数。例如，将多个操作整合成一个复合操作，比如一个事务或者一个批量操作。
  • 4. 命令合并和命令过滤：Redis 会分析命令之间的依赖关系，尽量合并多个操作为一个，同时过滤掉对最终数据集无效的命令。
       

4. 继续接收写操作：在重写过程中，父进程继续接收客户端的写操作，并将这些操作同时记录在旧的 AOF 文件和一个临时缓冲区aof_rewrite_buf中。

6. 合并临时缓冲区：当子进程完成重写后，父进程将aof_rewrite_buf缓冲区中的命令追加到新的 AOF 文件末尾，确保所有写操作不丢失。

7. 替换旧的 AOF 文件：最后，新的 AOF 文件会替换旧的 AOF 文件。

3. AOF 的优点和缺点

优点：

• 数据安全性高：由于记录的是每个写操作，数据的持久化频率较高，可以最大程度地减少数据丢失。
• 可读性好：AOF 文件是文本格式的日志文件，直接打开即可阅读和理解，适合用于数据恢复和分析。
• 灵活性强：通过配置 appendfsync 参数，可以在性能和数据安全性之间进行灵活调整。

缺点：

• 文件体积大：相比于 RDB 快照，AOF 文件会更大，因为它记录了所有的写操作。
• 恢复速度慢：因为需要重放所有的写操作，恢复数据时会比加载 RDB 文件慢。
• 性能开销：频繁的 I/O 操作可能会影响 Redis 的性能，尤其是在 appendfsync always 模式下。

4. 配置AOF持久化：

通过编辑 Redis 的配置文件 redis.conf 来启用和配置 AOF。

启用 AOF

将 appendonly 设置为 yes 以启用 AOF：

appendonly yes

AOF 文件名

指定 AOF 文件的名称，默认是 appendonly.aof：

appendfilename "appendonly.aof"

AOF 重写策略

设置 AOF 重写的触发条件。Redis 提供了两种主要的重写触发策略：

• 基于文件大小增长：当 AOF 文件自上次重写以来增长超过一定比例时触发重写。

  # 当 AOF 文件大小是上次重写后的两倍时触发重写
  auto-aof-rewrite-percentage 100
  
  # AOF 文件至少要达到此大小（以字节为单位）才会触发重写
  auto-aof-rewrite-min-size 64mb
  

AOF 同步策略

AOF 文件的同步策略决定了缓冲区数据何时被写入磁盘，这是性能和数据安全之间的权衡：

• always：每个写操作都会同步到磁盘，非常安全但性能较差。
• everysec：每秒同步一次，是常见的折中方案。
• no：让操作系统决定何时将数据同步到磁盘，性能最好但有风险。
  

AOF 重写时的阻塞策略

在 AOF 重写过程中，可以配置 Redis 是否允许阻塞写操作：

no-appendfsync-on-rewrite no

设置为 yes 时，在重写过程中不会执行 fsync 操作，以减少阻塞，但可能会丢失部分写操作。

2. 使用 Redis 命令动态配置 AOF

在 Redis 服务器运行时，可以使用 Redis 命令来动态配置 AOF 设置。

启用 AOF

CONFIG SET appendonly yes

调整 AOF 同步策略

CONFIG SET appendfsync everysec

手动触发 AOF 重写

你可以手动触发 AOF 重写，这对于某些维护操作是有用的：

BGREWRITEAOF

示例

# 启用 AOF
appendonly yes

# AOF 文件名
appendfilename "appendonly.aof"

# AOF 文件同步策略
appendfsync everysec

# 在重写期间是否禁止 fsync
no-appendfsync-on-rewrite no

# AOF 文件重写策略
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

---

三、RDB和AOF如何抉择？

1.RDB方案

性能和快速恢复需求:

• 如果更关注于性能和快速启动恢复，且可以接受定期备份的数据丢失，那么可以选择 RDB。RDB 生成的备份文件小且加载速度快，适合定期备份和存档。

2.AOF方案

数据安全需求:

• 如果数据的完整性和实时恢复能力是首要考虑因素，则应优先选择 AOF。AOF 可以在每次写操作后将数据同步到磁盘，提供更高的数据安全性。

---

3.混合持久化方案

在实际部署中，可以同时启用 AOF 和 RDB。AOF 提供实时数据保护和灾难恢复能力，而 RDB 用于定期备份和快速的全量恢复。这既保证了数据的安全性，又兼顾了性能和存储成本的平衡。

• AOF 提供实时保护：AOF 记录每个写操作的日志，通过配置合适的 appendfsync 参数，可以保证数据在发生故障时的最小数据丢失。因此，将 AOF 设置为始终同步（always）或每秒同步（everysec）能够提供较高的数据安全性。

• RDB 提供快速恢复：虽然 RDB 是周期性的全量备份，但它生成的备份文件较小且加载速度快，适合用于定期的数据恢复，尤其是在需要快速启动和大规模数据集的场景下。

• AOF 文件大小管理：AOF 文件随着时间的推移可能会增长，影响存储和性能。定期进行 AOF 的压缩和重写（通过 AOF Rewrite 和 AOF compaction）可以控制文件大小，减少不必要的存储和传输成本。

• RDB 备份策略：通过配置合适的 RDB 备份频率（如每隔几小时或每天一次），可以在需要时恢复整个数据库状态，而不会因为频繁备份而增加系统负担。

---