Redis持久化

目录

一、RDB (Redis Database)

1、原理

2、触发方式

3、优缺点分析

4、配置选项（redis.conf）

二、AOF (Append Only File)

1、原理

2、文件同步策略 (fsync)

3、AOF 重写 (Rewrite)

4、优缺点分析

5、配置选项 (redis.conf)

三、混合持久化 (RDB-AOF, 4.0+)

1、原理

2、优点

3、配置选项（redis.conf）

四、持久化策略选择与配置建议

1、选择策略

2、关键配置建议（生产环境推荐）

3、监控与运维

---

Redis 的持久化是其核心功能之一，它解决了内存数据库数据易失性的问题，确保在服务器重启或发生故障时，数据能够得以恢复。Redis 主要提供了两种持久化机制：RDB (Redis Database) 和 AOF (Append Only File)。从 Redis 4.0 开始，还引入了 混合持久化 (RDB-AOF) 模式，结合了两者的优点。

一、RDB (Redis Database)

1、原理

• RDB 在指定的时间间隔内，将内存中整个 Redis 数据集的一个快照 (Snapshot) 以二进制压缩格式保存到一个 .rdb 文件中。

• 它创建的是某个时间点的全量数据备份。

• 生成 RDB 文件的过程是异步的，由 fork 出一个子进程来完成实际的保存工作，父进程继续处理客户端请求。

• 保证fork后，生成RDB文件的不阻塞且不受到新数据影响的原因：写时复制（COW）

2、触发方式

• 配置文件 (save 指令)： 在 redis.conf 中配置规则，例如 save 900 1（900秒内有至少1个key变化）、save 300 10（300秒内有至少10个key变化）、save 60 10000（60秒内有至少10000个key变化）。满足任一规则即触发 BGSAVE。

• 手动命令：

  • SAVE: 同步保存，会阻塞服务器直到 RDB 文件创建完毕。生产环境慎用！

  • BGSAVE: 后台异步保存。推荐使用。

• 主从复制： 当从节点第一次连接主节点或需要全量同步时，主节点会自动执行 BGSAVE 并将 RDB 文件发送给从节点。

• SHUTDOWN： 使用 SHUTDOWN 命令正常关闭 Redis 时，如果没有开启 AOF，Redis 会执行一次 SAVE。

• FLUSHALL： 执行 FLUSHALL 命令清空数据库时，如果配置了 RDB 规则且满足条件，也会触发（但保存的是空数据库）。

3、优缺点分析

优点：

• 数据紧凑： RDB 文件是压缩的二进制文件，体积小。

• 恢复速度快： 恢复大数据集时（比 AOF 快很多），直接将 RDB 文件读入内存即可。

• 最大化性能： BGSAVE 由子进程完成，主进程几乎不受影响（除了 fork 瞬间可能阻塞）。

• 适合备份： 单个文件方便备份、传输和灾难恢复。可以定时将 RDB 文件复制到远程存储。

缺点：

• 数据丢失风险高： 基于时间点快照，如果服务器在两次快照之间崩溃，会丢失最后一次快照之后的所有修改。

• fork 可能阻塞： 如果数据集非常大，fork 子进程的过程可能会比较耗时（尤其是在虚拟机上），导致主进程短暂阻塞（毫秒到秒级），影响服务响应。数据集越大、机器物理内存不足或 swap 使用率高时，阻塞越明显。

• 非实时持久化： 无法做到秒级或更细粒度的数据持久化。

4、配置选项（redis.conf）

• dbfilename dump.rdb: RDB 文件名。

• dir ./: RDB 文件（和 AOF 文件）保存目录。

• save : 触发 BGSAVE 的条件。

• stop-writes-on-bgsave-error yes: 如果后台保存失败，Redis 是否停止接收写操作（推荐 yes）。

• rdbcompression yes: 是否压缩 RDB 文件（推荐 yes）。

• rdbchecksum yes: 是否在 RDB 文件末尾添加 CRC64 校验和（推荐 yes）。

二、AOF (Append Only File)

1、原理

• AOF 记录服务器执行的每一条写命令（SET, LPUSH, SADD, DEL 等，读命令不记录）。

• 这些命令以 Redis 协议格式追加写入到一个文本文件的末尾。

• 重启时，Redis 通过重放 (Replay) AOF 文件中的所有命令来重建数据集。

2、文件同步策略 (fsync)

这是 AOF 的核心，决定了何时将内存缓冲区中的 AOF 日志数据真正写入并同步到磁盘。在 redis.conf 中通过 appendfsync 配置：

• always：最安全，性能最低。 每个写命令都立即同步到磁盘。数据基本不会丢失（除非磁盘损坏），但严重降低吞吐量。通常不推荐。

• everysec：默认值，推荐。 每秒同步一次。由后台线程完成。性能较好（接近 RDB），最多丢失 1 秒钟的数据。是安全性和性能的良好折衷。

• no：最不安全，性能最高。 由操作系统决定何时同步（通常 30 秒左右）。写入性能最好，但数据丢失风险最高（可能丢失操作系统缓存中未刷盘的数据）。不推荐用于需要数据安全的场景。

3、AOF 重写 (Rewrite)

• 问题： 随着运行时间增长，AOF 文件会变得非常大。文件大不仅占磁盘空间，恢复时重放命令也会非常慢。很多命令是冗余的（例如多次修改同一个 key，只有最后一条命令有效）。

• 解决方案： AOF 重写。创建一个新的 AOF 文件，该文件包含重建当前数据集所需的最小命令集。它不是基于旧 AOF 文件分析，而是直接读取数据库当前状态，用一条命令表示一个 key 的最终值（例如 SET key current_value）。重写过程也是由子进程 (fork) 完成的。

• AOF重写期间保证新数据不会干扰：AOF重写缓冲区、写时复制（COW）

• 触发方式：

  • 手动执行 BGREWRITEAOF 命令。

  • 自动触发：在 redis.conf 中配置：

    • auto-aof-rewrite-percentage 100：当前 AOF 文件大小比上次重写后的大小增长超过 100% 时触发。

    • auto-aof-rewrite-min-size 64mb：AOF 文件最小达到 64MB 才考虑自动重写。

4、优缺点分析

优点：

• 数据安全性高： 特别是 appendfsync always 或 everysec 时，数据丢失风险远低于 RDB。

• 可读性好： AOF 文件是纯文本格式（Redis 协议），易于理解和手动修复（虽然不推荐）。

• 日志追加： 只有追加操作，即使文件损坏（如写入一半时断电），也可以使用 redis-check-aof 工具轻松修复（删除最后一条不完整的命令）。

• 更精细的持久化： everysec 策略接近实时持久化。

缺点：

• 文件体积大： 即使有重写，AOF 文件通常也比同数据集的 RDB 文件大。

• 恢复速度慢： 重放 AOF 文件中的命令来恢复数据，通常比加载 RDB 文件慢很多（尤其是文件很大时）。

• 性能略低： 虽然 everysec 策略性能不错，但通常仍略低于 RDB（因为需要记录每条写命令）。always 策略性能下降明显。

• 历史 bug： 在早期版本中，AOF 重写或加载遇到过一些 bug（不过现在已非常成熟稳定）。

5、配置选项 (redis.conf)

• appendonly no：是否开启 AOF（默认 no）。

• appendfilename "appendonly.aof"：AOF 文件名。

• appendfsync everysec：同步策略（推荐）。

• no-appendfsync-on-rewrite no：重写期间是否暂停 fsync（默认 no，保证安全；如果对延迟敏感且能容忍重写期间丢失数据风险，可设 yes 提升重写性能）。

• auto-aof-rewrite-percentage / auto-aof-rewrite-min-size：自动重写触发条件。

• aof-load-truncated yes：如果 AOF 文件末尾损坏，是否加载截断后的文件（推荐 yes，尝试恢复尽可能多的数据）。

三、混合持久化 (RDB-AOF, 4.0+)

1、原理

• 为了解决 AOF 恢复慢的问题，Redis 4.0 引入了混合持久化。

• 开启条件： 需要同时开启 AOF (appendonly yes)。

• 工作方式：

  • 当执行 AOF 重写 (BGREWRITEAOF) 时：

    1. 子进程不再像纯 AOF 重写那样只生成新的 AOF 命令集。

    2. 子进程会先将内存数据以 RDB 格式写入到新的 AOF 文件的开头部分。

    3. 然后，再将重写缓冲区（在重写期间，主进程会把新的写命令同时写入到原有的 AOF 缓冲区和 AOF 重写缓冲区）中的命令，以 AOF 格式追加到新 AOF 文件的 RDB 数据之后。

  • 最终生成的新 AOF 文件是一个前半部分是 RDB 格式快照，后半部分是 AOF 格式增量命令的混合文件。

• 文件扩展名： 仍然是 .aof。

2、优点

• 结合 RDB 和 AOF 的优点：

  • 快速加载： 重启恢复时，首先加载 RDB 部分，速度非常快。

  • 数据安全： 再加载 AOF 部分的增量命令，保证数据完整性（丢失的数据量取决于 appendfsync 策略）。

• 文件相对较小： 比纯 AOF 文件小（因为开头用了紧凑的 RDB 格式）。

• 兼容性好： 对旧版本的 Redis 工具（如 redis-check-aof）仍然透明，它们会忽略开头的 RDB 数据。

3、配置选项（redis.conf）

• appendonly yes (开启 AOF)

• aof-use-rdb-preamble yes (开启混合持久化，这是默认值)

四、持久化策略选择与配置建议

1、选择策略

• 追求最高性能，能容忍分钟级数据丢失： 仅使用 RDB。

• 追求数据安全，能容忍少量数据丢失（秒级）： 仅使用 AOF (appendfsync everysec)。

• 追求数据安全且希望重启恢复快： 强烈推荐使用混合持久化 (AOF + aof-use-rdb-preamble yes + appendfsync everysec)。这是目前生产环境的最佳实践。

• 追求最高数据安全性，不惜牺牲性能： 仅使用 AOF (appendfsync always)（很少见）。

• 完全不关心数据丢失： 关闭所有持久化（仅用于缓存）。

2、关键配置建议（生产环境推荐）

• appendonly yes：开启 AOF。

• aof-use-rdb-preamble yes：开启混合持久化。

• appendfsync everysec：AOF 同步策略（平衡安全与性能）。

• 合理配置 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size（例如 100 和 64mb）。

• 保留 RDB 配置（save 900 1 等）作为备份补充或容灾手段（混合持久化下的 RDB 配置主要是用于手动 SAVE/BGSAVE 备份或主从复制）。

• dir 配置到足够大的磁盘分区。

• stop-writes-on-bgsave-error yes, rdbcompression yes, rdbchecksum yes, no-appendfsync-on-rewrite no, aof-load-truncated yes：保持默认推荐值。

3、监控与运维

• 监控 rdb_last_save_time，aof_last_bgrewrite_status，aof_current_size， aof_base_size, aof_buffer_length 等指标。

• 定期检查 RDB 和 AOF 文件的完整性（redis-check-rdb, redis-check-aof）。

• 务必进行备份！ 将 RDB 快照和 AOF 文件定期备份到异地安全的存储（如云存储、磁带库）。备份是持久化的最后防线。

• 制定并测试灾难恢复计划。