一文讲解Redis的持久化方式及各自的区别

Redis 的持久化机制保证了 Redis 服务器在重启后数据不丢失，通过 RDB 和 AOF 文件来恢复内存中原有的数据。

这两种持久化方式可以单独使用，也可以同时使用。

三分恶面渣逆袭：Redis持久化的两种方式

说一下 RDB？

RDB 持久化通过创建数据集的快照来工作，在指定的时间间隔内将 Redis 在某一时刻的数据状态保存到磁盘的一个 RDB 文件中。

可通过 save 和 bgsave 命令两个命令来手动触发 RDB 持久化操作：

三分恶面渣逆袭：save和bgsave

①、save 命令：会同步地将 Redis 的所有数据保存到磁盘上的一个 RDB 文件中。这个操作会阻塞所有客户端请求直到 RDB 文件被完全写入磁盘。

当 Redis 数据集较大时，使用 SAVE 命令会导致 Redis 服务器停止响应客户端的请求。

不推荐在生产环境中使用，除非数据集非常小，或者可以接受服务暂时的不可用状态。

②、bgsave 命令：会在后台异步地创建 Redis 的数据快照，并将快照保存到磁盘上的 RDB 文件中。这个命令会立即返回，Redis 服务器可以继续处理客户端请求。

在 BGSAVE 命令执行期间，Redis 会继续响应客户端的请求，对服务的可用性影响较小。快照的创建过程是由一个子进程完成的，主进程不会被阻塞。是在生产环境中执行 RDB 持久化的推荐方式。

以下场景会自动触发 RDB 持久化：

①、在 Redis 配置文件（通常是 redis.conf）中，可以通过save <seconds> <changes>指令配置自动触发 RDB 持久化的条件。这个指令可以设置多次，每个设置定义了一个时间间隔（秒）和该时间内发生的变更次数阈值。

save 900 1
save 300 10
save 60 10000

这意味着：

如果至少有 1 个键被修改，900 秒后自动触发一次 RDB 持久化。
如果至少有 10 个键被修改，300 秒后自动触发一次 RDB 持久化。
如果至少有 10000 个键被修改，60 秒后自动触发一次 RDB 持久化。

满足以上任一条件，RDB 持久化就会被自动触发。

②、当 Redis 服务器通过 SHUTDOWN 命令正常关闭时，如果没有禁用 RDB 持久化，Redis 会自动执行一次 RDB 持久化，以确保数据在下次启动时能够恢复。

③、在 Redis 复制场景中，当一个 Redis 实例被配置为从节点并且与主节点建立连接时，它可能会根据配置接收主节点的 RDB 文件来初始化数据集。这个过程中，主节点会在后台自动触发 RDB 持久化，然后将生成的 RDB 文件发送给从节点。

说一下 AOF？

AOF 持久化通过记录每个写操作命令并将其追加到 AOF 文件中来工作，恢复时通过重新执行这些命令来重建数据集。

AOF 的主要作用是解决了数据持久化的实时性，目前已经是 Redis 持久化的主流方式。

AOF 的工作流程分为四个步骤：命令写入、文件同步、文件重写、重启加载。

三分恶面渣逆袭：AOF工作流程

1）当 AOF 持久化机制被启用时，Redis 服务器会将接收到的所有写命令追加到 AOF 缓冲区的末尾。

2）接着将缓冲区中的命令刷新到磁盘的 AOF 文件中，刷新策略有三种：

always：每次写命令都会同步到 AOF 文件。
everysec（默认）：每秒同步一次。如果系统崩溃，可能会丢失最后一秒的数据。
no：在这种模式下，如果发生宕机，那么丢失的数据量由操作系统内核的缓存冲洗策略决定。

3）随着 AOF 文件的不断增长，Redis 会启用重写机制来生成一个更小的 AOF 文件：

将内存中每个键值对的当前状态转换为一条最简单的 Redis 命令，写入到一个新的 AOF 文件中。即使某个键被修改了多次，在新的 AOF 文件中也只会保留最终的状态。
Redis 会 fork 一个子进程，子进程负责重写 AOF 文件，主进程不会被阻塞。

主进程（fork）  │  ├─→ 子进程（生成新的 AOF 文件）  │       │  │       ├─→ 内存快照  │       ├─→ 写入临时 AOF 文件  │       ├─→ 通知主进程完成  │  ├─→ 主进程（追加缓冲区到新 AOF 文件）  ├─→ 替换旧 AOF 文件  ├─→ 重写完成

4）当 Redis 服务器重启时，会读取 AOF 文件中的所有命令并重新执行它们，以恢复重启前的内存状态。