Redis持久化RDB和AOF的优缺点及混合持久化策略
Redis 作为高性能的内存数据库，数据存储在内存中，一旦服务进程退出或服务器宕机，内存中的数据就会丢失。为了防止数据丢失，Redis 提供了 RDB 和 AOF 两种持久化机制，以及两者结合的混合持久化策略。了解它们的区别并根据业务场景进行配置，是保障数据安全的关键。
RDB 持久化：快照模式
RDB（Redis Database）是指在指定的时间间隔内，将内存中的数据集快照写入磁盘。它生成的文件是一个经过压缩的二进制文件，默认名为 dump.rdb。
工作原理
Redis 会单独创建（fork）一个子进程来进行持久化，先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。在整个过程中，主进程是不进行任何 IO 操作的，这确保了极高的性能。
RDB 的优缺点
| 特性 | 说明 |
|---|---|
| 优点 | 1. 文件紧凑，适合备份。<br>2. 恢复速度快，适合灾难恢复。<br>3. 对性能影响极小，父进程无需处理 IO。 |
| 缺点 | 1. 耐久性差。如果宕机，可能会丢失最后一次快照后的所有数据。<br>2. 数据集大时，fork 过程可能导致服务短暂阻塞。 |
配置 RDB
打开 Redis 配置文件 redis.conf。
找到 SNAPSHOTTING 配置区域，修改保存规则。格式为 save <seconds> <changes>，表示在 <seconds> 秒内至少有 <changes> 个键发生改变则触发快照。
# 900秒内至少有1个key发生变化
save 900 1
# 300秒内至少有10个key发生变化
save 300 10
# 60秒内至少有10000个key发生变化
save 60 10000配置 文件名和存储路径（可选）：
dbfilename dump.rdb
dir /var/lib/redis保存 文件并 重启 Redis 服务使配置生效。
AOF 持久化：日志模式
AOF（Append Only File）以日志的形式记录服务器所处理的每一个写操作命令，并在 Redis 服务器启动时，通过重新执行这些命令来恢复数据。
工作原理
Redis 将每个写命令追加到文件末尾。随着时间推移，AOF 文件会越来越大。Redis 提供了 AOF 重写机制，当文件体积过大时，Redis 会 fork 出一个子进程，将内存中的数据以命令的方式重写到一个新的临时文件中，再替换旧文件。
AOF 的优缺点
| 特性 | 说明 |
|---|---|
| 优点 | 1. 数据安全性高，通常最多丢失 1 秒的数据。<br>2. 通过 appendfsync everysec 策略，性能与持久性平衡良好。<br>3. AOF 文件是文本格式，容易读懂和手动修改。 |
| 缺点 | 1. 文件体积通常比 RDB 大。<br>2. 恢复速度比 RDB 慢，因为需要执行所有写命令。<br>3. 性能依赖磁盘 IO 和 fsync 频率。 |
配置 AOF
打开 redis.conf 文件。
将 appendonly 参数的值 修改 为 yes：
appendonly yes配置 刷盘策略 appendfsync：
# 每次执行写命令都同步到磁盘（最安全，最慢）
# appendfsync always
# 每秒同步一次（推荐，折中方案）
appendfsync everysec
# 由操作系统决定何时同步（最快，但可能丢失数据）
# appendfsync no设置 AOF 重写触发条件：
# AOF 文件大小比上次重写后增长 100% 时触发
auto-aof-rewrite-percentage 100
# AOF 文件体积至少达到 64MB 时才触发重写
auto-aof-rewrite-min-size 64mb保存 文件并 重启 Redis 服务。
RDB 与 AOF 的对比
为了更直观地理解两者的区别，请参考下表。
| 维度 | RDB | AOF |
|---|---|---|
| 文件格式 | 二进制压缩文件 | 文本日志（追加写命令） |
| 文件大小 | 小（压缩后） | 大（需记录所有写操作） |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 低（可能丢失数分钟数据） | 高（通常最多丢失 1 秒数据） |
| 系统资源开销 | 低（fork 时有阻塞风险） | 高（频繁的磁盘 IO 写入） |
| 适用场景 | 数据备份、主从复制 | 需要尽可能不丢失数据的场景 |
混合持久化策略
Redis 4.0 之后推出了混合持久化（Hybrid Persistence），结合了 RDB 和 AOF 的优点。开启混合持久化后，AOF 重写时，不再单纯将内存数据转换为命令写入，而是先将内存数据以 RDB 格式写入 AOF 文件的开头，再将重写期间累积的新增写命令以 AOF 格式追加到文件末尾。
混合持久化的优势
- 加载速度快：Redis 启动时，先加载文件头部的 RDB 数据，这部分速度很快。
- 数据丢失少：RDB 之后的部分仍然是 AOF 格式，保证了数据增量的一致性。
- 文件体积可控：结合了 RDB 的压缩特性和 AOF 的增量特性，文件大小优于纯 AOF。
配置混合持久化
打开 redis.conf 文件。
找到 并 开启 混合持久化开关。注意：此功能仅在 appendonly yes 的前提下生效。
aof-use-rdb-preamble yes保存 配置并 重启 Redis 服务。
重启后，当 Redis 自动触发 AOF 重写，或者手动执行重写命令时，生成的 AOF 文件将包含 RDB 格式的头部数据。可以使用 od -c 命令查看 AOF 文件头部，若看到 REDIS 字样及乱码（二进制），说明混合持久化已生效。
混合持久化文件结构示意
下面的流程图展示了混合持久化文件的内部结构以及 Redis 加载数据的逻辑。
选择持久化策略的建议
在实际生产环境中，需要根据业务对性能和数据的容忍度来选择策略。
- 仅开启 RDB：如果数据可以容忍丢失几分钟，且追求极致的性能，推荐只开启 RDB。这适合用于缓存（Cache）场景。
- 仅开启 AOF：如果数据极其重要，不能接受丢失，且能够接受较大的磁盘开销和稍慢的恢复速度，推荐开启 AOF 并使用
appendfsync everysec。 - 开启混合持久化：这是目前的推荐方案。它兼顾了 RDB 的快速恢复和 AOF 的数据完整性。只需在
redis.conf中同时开启 AOF 和混合持久化即可。
注意：开启持久化后，务必监控磁盘剩余空间和 Redis 主进程的 fork 耗时，避免因为内存过大导致持久化阻塞主线程。
暂无评论，快来抢沙发吧！