持久化机制

• 理解 RDB 和 AOF 两种持久化的原理

• 掌握两种持久化的配置与优缺点

• 能根据场景选择持久化方案

核心讲解

Redis 是内存数据库，断电数据会丢，持久化就是把数据存到磁盘，重启恢复。

（1）RDB 快照

在某个时间点，把整个内存的数据生成一个快照文件，保存到磁盘。

• 触发方式：

  • 自动：配置 save 规则，比如save 900 1，900 秒内至少 1 次修改就保存

  • 手动：SAVE（阻塞）、BGSAVE（后台非阻塞）

• 优点：

  • 快照文件小，恢复速度快

  • 适合备份、灾备

• 缺点：

  • 两次快照之间宕机，会丢失这段时间的数据

  • 大数据量快照时，fork 子进程消耗资源

（2）AOF 日志

把每一条写命令都追加到日志文件里，重启的时候重新执行所有命令，恢复数据。

• 写回策略：

  • always：每条命令都刷盘，最安全，最慢

  • everysec：每秒刷盘，默认，平衡，最多丢 1 秒数据

  • no：操作系统控制刷盘，最快，最不安全

• 优点：

  • 数据更安全，最多丢 1 秒

  • 日志文件，可修复

• 缺点：

  • 文件比 RDB 大很多

  • 恢复速度慢

  • 重写机制（AOF Rewrite）：定期压缩 AOF 文件

（3）混合模式

Redis 4.0 + 支持，RDB+AOF 结合，恢复的时候先用 RDB 快速恢复，再用 AOF 补增量。

• 开启：aof-use-rdb-preamble yes

• 兼顾恢复速度和数据安全，推荐生产开启

操作示例

# ===== 手动RDB快照 =====
# 后台生成RDB，不阻塞
BGSAVE

# 查看持久化信息
INFO persistence

# ===== AOF相关 =====
# 手动重写AOF，压缩
BGREWRITEAOF

# 查看AOF信息
INFO persistence | grep aof

配置文件示例：

# RDB配置
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb
dir ./data

# AOF配置
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 混合模式
aof-use-rdb-preamble yes

常见误区

1. 开了持久化就 100% 不丢数据：AOF 最多也会丢 1 秒数据，没有绝对安全，只有更安全

2. save 越多越好：save 太频繁，频繁快照严重影响性能

3. AOF 文件不会变大：AOF 会越来越大，需要开启自动重写，或者手动重写

4. RDB 和 AOF 只能开一个：可以同时开，也可以只开一个，推荐生产都开或者混合模式

课后练习

1. 开启 RDB 持久化，配置 5 分钟有 1 次修改就保存

2. 开启 AOF 持久化，设置每秒刷盘

3. 手动执行 BGSAVE，查看生成的 RDB 文件

4. 对比 RDB 和 AOF 的优缺点，分别适合什么场景