Redis：持久化 RDB快照 AOF日志

为什么要持久化？

当服务器故障、断电等意外情况会导致内存数据丢失，持久化能将数据保存到磁盘，重启时直接加载持久化文件恢复数据，比重新构建数据快得多，能快速恢复服务，如电商购物车数据不会因故障丢失。持久化生成的文件可用于备份，复制到其他存储设备，应对数据丢失、损坏风险，像重要的用户信息可借此长期保存。

Redis共有三种数据持久化的方式：

• AOF日志：每执行一条写操作命令，就把该命令以追加的方式写入到一个文件里。
• RDB快照：将某一时刻的内存数据，以二进制的方式写入磁盘。
• 混合持久化方式：Redis4.0新增的方式，集成了AOF和RDB的优点。

RDB快照

RDB（Redis Database）快照是将 Redis 在内存中的数据以二进制的形式保存到磁盘上的一个快照文件。它可以在指定的时间间隔内，对内存中的数据进行一次完整的备份，当 Redis 服务器重启时，可以通过加载这个快照文件来恢复数据。

使用方式

• 手动触发 ：
  • SAVE 命令 ：在主线程中执行，会阻塞所有客户端请求 ，直到 RDB 文件创建完成。期间 Redis 服务器无法响应其他客户端请求，例如在 Redis 客户端输入SAVE，就会立即开始创建 RDB 快照。
  • BGSAVE 命令 ：更为常用，执行后 Redis 主进程会 fork 一个子进程，由子进程负责创建 RDB 文件，主进程继续处理客户端请求。比如在 Redis 客户端输入BGSAVE ，主进程返回 "Background saving started"，表示开始在后台生成 RDB 快照，完成后返回 "OK" 。
• 自动触发 ：在 Redis 配置文件（通常是redis.conf）中，通过设置save参数来定义自动触发条件。
  • save 900 1表示 900 秒内至少有 1 个键被修改，就会触发 RDB 快照。
  • save 300 10 表示 300 秒内至少有 10 个键被修改触发快照。
  • save 60 10000表示 60 秒内至少有 10000 个键被修改触发快照 。
  • 此外，执行debug reload命令重新加载 Redis，或者在未开启 AOF 持久化功能时执行shutdown命令，也会自动触发相关的保存操作。

工作原理

1. 触发bgsave命令

   • bgsave是用于在后台执行 RDB 快照的命令。当发出bgsave命令后，流程进入父进程处理环节。

2. 父进程检查与处理

   • 父进程首先会检查是否有其他子进程正在执行诸如bgsave或bgrewriteaof（AOF 文件重写）等操作。如果有，为避免资源竞争，父进程会直接返回，不做任何处理；若没有其他进程在运行相关操作，则父进程继续执行，通过fork操作创建一个子进程。fork操作利用写时拷贝（Copy - On - Write, COW）技术，使得子进程能共享父进程的内存数据，在数据未被修改前，父子进程无需额外的内存开销。

3. 父子进程后续操作

   • 父进程：继续响应客户端的其他命令请求，在子进程进行 RDB 快照生成期间，父进程正常处理业务，不会被阻塞。但如果父进程收到了新的写命令，这些写操作并不会立即反映到子进程中，因为采用了写时拷贝机制。

   • 子进程：负责生成 RDB 文件。子进程会遍历当前内存中的数据，将其以二进制格式写入到临时的 RDB 文件中。在这个过程中，子进程专注于数据的持久化操作，不处理其他客户端请求。

4. 完成快照与通知

   • 子进程完成 RDB 文件的生成后，会通过信号通知父进程。父进程收到通知后，将临时的 RDB 文件替换为正式的 RDB 文件，完成一次完整的 RDB 快照操作。下次 Redis 服务器重启时，就可以通过加载这个 RDB 文件，将数据恢复到内存中。

优点

• 恢复速度快：RDB 文件是一个紧凑的二进制文件，在恢复数据时，Redis 可以直接将文件中的数据加载到内存中，速度相对较快，尤其适用于大规模数据的恢复。
• 对服务器性能影响小 ：使用BGSAVE命令进行快照时，由于是在后台进行的，所以对 Redis 服务器的正常运行影响较小，不会导致服务器长时间阻塞而无法处理客户端请求。
• 适合数据备份：RDB 文件可以方便地用于数据备份，可以将其复制到其他存储设备或服务器上，以防止数据丢失。而且由于 RDB 文件是一个整体的二进制文件，所以在备份和恢复过程中相对简单，不容易出现数据不一致的情况。

缺点

• 数据可能丢失：因为 RDB 快照是按照一定的时间间隔进行的，如果在两次快照之间 Redis 服务器发生故障，那么这期间的数据变化将会丢失。例如，如果设置了每 5 分钟进行一次 RDB 快照，而在第 4 分钟时服务器崩溃，那么这 4 分钟内的数据就无法通过 RDB 文件恢复。
• 内存占用大：在进行快照时，需要 fork 一个子进程，而子进程会复制父进程的内存空间，这在内存占用方面可能会产生一些压力，尤其是当内存中的数据量较大时。
• 兼容性问题：不同版本的 Redis 生成的 RDB 文件可能存在兼容性问题。如果使用较低版本的 Redis 生成的 RDB 文件，在较高版本的 Redis 中可能无法正常加载，或者反之。因此，在进行 Redis 版本升级或降级时，需要注意 RDB 文件的兼容性。

AOF日志

AOF（Append Only File）持久化是 Redis 提供的另一种持久化方式，它以日志的形式记录 Redis 服务器执行的所有写操作命令，以此来保证数据的持久化存储。

使用方式

• 开启 AOF 持久化

  • 在 Redis 配置文件中，将 appendonly 参数设置为 yes，即可开启 AOF 持久化功能。

• 配置同步策略 ：根据业务需求选择合适的同步策略，通过 appendfsync 参数进行配置：

  • always ：每次有写操作命令执行，都会将 AOF 缓冲区中的内容同步到磁盘上的 AOF 文件中。这种策略提供了最高的数据安全性 ，因为即使服务器发生故障，最多只会丢失一条命令的数据。但由于每次写操作都要进行磁盘 I/O，会导致性能有所下降。

  • everysec ：每秒将 AOF 缓冲区中的内容同步到磁盘上的 AOF 文件中。这是 Redis 默认的同步策略，它在性能和数据安全性之间做了较好的平衡。在这种策略下，即使服务器发生故障，最多只会丢失 1 秒钟内的数据。

  • no ：将 AOF 缓冲区的同步操作交给操作系统处理，由操作系统决定何时将缓冲区的内容同步到磁盘。这种策略性能最高 ，但数据安全性最低，因为操作系统的同步时机不确定，可能会导致在服务器故障时丢失较多的数据。

• 配置 AOF 文件重写

  • 设置 auto-aof-rewrite-percentage 100 表示当 AOF 文件大小比上次重写后增长 100% 时触发重写；

  • auto-aof-rewrite-min-size 64mb 表示 AOF 文件最小达到 64MB 才会考虑触发重写。

• 手动触发重写

  • 如果需要手动触发 AOF 文件重写，可以在 Redis 客户端执行 BGREWRITEAOF 命令。

工作原理

1. 触发重写命令 ：bgrewriteaof命令用于触发 AOF 文件重写，它是非阻塞的，可在后台执行。执行该命令后，流程进入父进程处理阶段。
2. 创建子进程 ：父进程通过fork操作创建子进程，子进程拥有和父进程相同的内存数据副本。fork 操作是一种高效的创建子进程方式，它采用写时拷贝（Copy - On - Write, COW）技术，父子进程在数据未修改前共享内存空间。
3. 处理写命令 ：
   • 父进程继续处理客户端请求，新的写命令会被追加到aof_buf（AOF 缓冲区）中，后续按照设置的同步策略写入旧 AOF 文件。
   • 同时，父进程还会将重写期间收到的写命令记录到aof_rewrite_buf（AOF 重写缓冲区），用于保证子进程重写期间数据的一致性。
4. 子进程重写：子进程遍历内存中的数据，将其转化为最小化的一系列写命令，写入新的 AOF 文件中。子进程在重写过程中不会修改父进程的数据，也不会受到父进程新写命令的干扰。
5. 完成重写与切换 ：
   • 子进程完成新 AOF 文件的写入后，通过信号通知父进程。
   • 父进程收到信号后，将aof_rewrite_buf中的写命令追加到新 AOF 文件中，确保新 AOF 文件的数据完整性。
   • 最后，父进程用新的 AOF 文件替换旧的 AOF 文件，完成 AOF 文件重写流程。

优点

• 数据安全性高 ：通过不同的同步策略，可以根据实际需求选择合适的方式来保证数据的安全性。尤其是使用 always 同步策略时，几乎可以保证数据不丢失。
• 易读性和可恢复性：AOF 文件以文本格式记录了所有的写操作命令，方便查看和分析。并且在数据恢复时，只需要按照 AOF 文件中的命令顺序依次执行，就可以恢复到之前的状态。
• 兼容性好：AOF 文件的格式相对稳定，不同版本的 Redis 对 AOF 文件的兼容性较好，便于在不同版本之间进行迁移和升级。

缺点

• 文件体积大：由于 AOF 文件记录了所有的写操作命令，随着时间的推移，文件会不断增大，占用大量的磁盘空间。
• 恢复速度慢：在数据恢复时，需要依次执行 AOF 文件中的所有命令，相比 RDB 快照的恢复方式，速度会慢一些。特别是当 AOF 文件非常大时，恢复时间会更长。
• 性能开销 ：频繁的磁盘 I/O 操作会对 Redis 的性能产生一定的影响，尤其是在使用 always 同步策略时，性能下降更为明显。

混合持久化

混合持久化是 Redis 4.0 之后新增的持久化方式，结合了 RDB 和 AOF 的优点。

使用方式

可使用config get aof-use-rdb-preamble命令查看是否开启，yes表示已开启，no表示关闭。Redis 5.0 默认开启，可通过两种方式开启：

• 命令行 ：执行config set aof-use-rdb-preamble yes，但此方法在 Redis 重启后配置会失效。
• 修改配置文件 ：在 Redis 根路径下找到redis.conf文件，将aof-use-rdb-preamble no改为aof-use-rdb-preamble yes 。

工作原理

在开启混合持久化后，当触发 AOF 重写（如手动执行BGREWRITEAOF命令或满足自动重写条件）时，fork 出的子进程会先将内存数据以 RDB 格式写入 AOF 文件开头，随后把重写缓冲区中的增量命令以 AOF 格式追加到文件末尾 。最终新的 AOF 文件前半段是 RDB 格式的全量数据，后半段是 AOF 格式的增量数据。

与 AOF 持久化恢复过程相同，需将appendonly.aof文件放在 Redis 根目录，启动时若开启 AOF 持久化，Redis 会自动加载恢复数据。加载时，先判断是否开启 AOF 持久化；若开启且文件存在，再判断文件开头是否为 RDB 格式，是则先加载 RDB 内容，再加载剩余 AOF 内容，不是则直接以 AOF 格式加载整个文件。

优点

结合了 RDB 和 AOF 的长处，因开头是 RDB 格式，Redis 重启时加载速度快；后续采用 AOF 格式记录操作命令，降低了大量数据丢失的风险。

缺点

RDB 格式内容添加到 AOF 文件，使文件可读性变差；兼容性欠佳，开启混合持久化生成的 AOF 文件，无法在 Redis 4.0 之前的版本使用。

edis 重启时加载速度快；后续采用 AOF 格式记录操作命令，降低了大量数据丢失的风险。

缺点

RDB 格式内容添加到 AOF 文件，使文件可读性变差；兼容性欠佳，开启混合持久化生成的 AOF 文件，无法在 Redis 4.0 之前的版本使用。