Redis持久化双保险：RDB与AOF原理、优缺点和配置实战

Hey，各位 Java 老司机！今天咱们聊聊 Redis 的持久化——这玩意儿就像给内存里的数据买了份“意外险”，万一服务器抽风重启，数据还能找回来。Redis提供了两种主要的持久化方式：RDB（快照）和 AOF（追加文件）。接下来逐个掰扯它们怎么工作、有什么优缺点，以及实际该怎么选、怎么用。

RDB：快照式持久化

RDB 就像给数据库拍张照片，然后把照片存到硬盘上（默认文件叫 dump.rdb）。它是 Redis 默认 的持久化方式。

工作原理

RDB 通过 fork 一个子进程来干活：父进程继续处理客户端请求，子进程负责把内存数据写进临时 RDB 文件，写完再替换掉旧文件。这样主进程几乎不受影响，够优雅吧？

优点（为啥要用它？）

• 性能高：子进程干活，主进程不卡顿。
• 文件紧凑：RDB 是压缩过的二进制格式，文件小，适合备份和灾难恢复。
• 恢复快：重启时直接加载 RDB 文件，比 AOF 快得多（尤其大数据集场景）。

缺点（小心坑！）

• 可能丢数据：如果两次快照之间 Redis 挂掉，这期间的数据就没了。比如你设定每 5 分钟备份一次，结果第 4 分 59 秒宕机——最近 5 分钟的数据全丢。
• fork 可能卡顿：数据集很大时，fork 子进程的过程中可能会暂时卡住主进程（尤其在虚拟机上）。

配置示例

在 redis.conf 里调教 RDB：

# 每900秒（15分钟）至少有1个key变化就备份
save 900 1
save 300 10
save 60 10000

# RDB文件名
dbfilename dump.rdb

# 工作目录
dir ./

# 备份时是否压缩（推荐开启）
rdbcompression yes

# 是否校验CRC64（防文件损坏，但稍微占内存）
rdbchecksum yes

手动备份可以用 SAVE（同步，会阻塞）或 BGSAVE（后台异步）。

AOF：日志式持久化

AOF 则是把每个 写命令 都记录下来，追加到文件末尾（默认 appendonly.aof）。重启时重新执行一遍这些命令，数据就回来了。

工作原理

写命令执行后，会按Redis序列化协议（RESP）格式追加到AOF缓冲区，然后根据策略（appendfsync）决定何时刷到硬盘。

优点（它强在哪？）

• 数据安全：默认每秒刷一次盘（appendfsync everysec），最多丢 1 秒的数据；设成 always 的话每个命令都刷盘，基本零丢失（但性能会明显下降）。
• 可读性好：AOF 是文本格式（RESP），方便人眼查看和 debug（虽然平时不建议直接改）。
• 自动修复：如果 AOF 文件损坏，可以用 redis-check-aof 工具修复（删掉出错的后半部分）。

缺点（代价呢？）

• 文件更大：AOF 记录每条命令，文件通常比 RDB 大得多。
• 恢复慢：重启时要重新执行所有命令，数据集大了之后可能很慢。
• 写性能略低：频繁刷盘会影响吞吐量（尤其 always 模式）。

配置示例

在 redis.conf 里开启 AOF：

# 开启AOF
appendonly yes

# AOF文件名
appendfilename "appendonly.aof"

# 刷盘策略：
# always - 每个命令都刷盘（最安全，最慢）
# everysec - 每秒刷一次（默认，平衡点）
# no - 让操作系统决定（最快，但可能丢更多数据）
appendfsync everysec

# AOF重写时是否刷盘
no-appendfsync-on-rewrite no

# 当前AOF文件比上次重写后大了100%时，触发重写
auto-aof-rewrite-percentage 100
# AOF文件至少达到64MB才重写
auto-aof-rewrite-min-size 64mb

注意：AOF 重写（BGREWRITEAOF）是为了压缩文件，它会 fork 子进程，基于当前数据生成一个新 AOF 文件（只包含重建数据集的最小命令集）。

RDB vs AOF：到底选哪个？（双持它不香吗？）

其实，Redis 允许同时开启 RDB 和 AOF（推荐做法！）。重启时，AOF 优先级更高——只要 AOF 存在，Redis 就会优先用它恢复，因为它的数据更完整。

混合持久化（Redis 4.0+）

Redis 4.0 之后多了个“杂交品种”：重写后的 AOF 文件前半段用 RDB 格式存快照，后半段继续追加命令。这样启动时加载快照飞快，再用命令补齐最新数据——两全其美！从 Redis 5.0 起默认开启混合持久化（aof-use-rdb-preamble yes），AOF 重写时自动生成这种格式。

使用姿势建议

1. 优先用 AOF 保障数据安全（appendfsync everysec）。
2. 同时开 RDB：用于定时备份、快速恢复，或者传输到从节点。
3. 监控磁盘空间：AOF 文件会不断增长，记得用重写控制体积。
4. 定期备份：把 RDB 和 AOF 文件拷到别的机器上（云存储、异地备份），防硬盘物理损坏。

反例警告

• 别只用 RDB 还设很长间隔：比如 save 3600 1（1 小时备份一次），宕机可能丢 1 小时数据——心不痛吗？
• 别在 appendfsync always 下狂写：比如疯狂 INCR 计数器，每个命令都刷盘，IO 扛不住，Redis 会变慢。
• 别手动乱改 AOF 文件：可能导致重启时解析失败，数据全丢。修复请用官方工具！

总结一把

• RDB：快照，适合备份、快速恢复，但可能丢数据。
• AOF：日志，适合高安全性，但文件大、恢复慢。
• 最佳实践：两者都开，让 RDB 做定期快照，AOF 实时追日志。数据安全才是王道，别等服务器“猝死”了才哭爹喊娘！如果你对 Redis 高可用和持久化还有疑问，欢迎到 云栈社区 和同行一起交流。