一文讲透 Redis 持久化：RDB、AOF、混合模式该怎么选？

内容分享1周前发布

0 0 0

上个月，我去面试一家挺知名的互联网公司。面试官戴着眼镜，微微一笑：“小米，我们来聊聊 Redis 吧～”

我心想，Redis？老朋友了！从缓存到消息队列，我都玩得溜。于是他接着说：

“那你给我讲讲 Redis 的持久化机制吧，AOF、RDB 各有什么区别？生产环境你会怎么选？”

瞬间，我笑容凝固。脑子里“嗡”的一声，AOF？RDB？是的，Redis 持久化，我知道！但要清楚地讲出来，优缺点、使用场景、扩容策略……那真得细细聊聊。

于是今天，就借这篇文章，系统地讲清楚：什么是 Redis 持久化、有哪些机制、如何选择，以及扩容的最佳实践。

什么是 Redis 持久化？

Redis 是一个基于内存的高性能键值数据库，内存的速度很快，但它也有个问题：

内存断电就没了。

所以 Redis 就像一个超快的记事本，写得飞快，但一旦掉电，记录就消失。为了解决这个问题，Redis 提供了“持久化机制”，也就是：

把内存中的数据保存到磁盘上，确保重启后还能恢复数据。

你可以理解为 Redis 每隔一段时间会拍个“快照”（RDB），或者干脆像录音机一样把每次操作都记录下来（AOF）。

Redis 的两种主流持久化机制

Redis 提供了两种核心的持久化方式：

RDB（Redis DataBase）快照方式AOF（Append Only File）日志方式

我们先从 RDB 说起

1. RDB 持久化 —— “定期拍快照”

RDB（Redis DataBase）的原理其实挺浪漫的：

它会在指定的时间间隔，把 Redis 中的数据“整体快照”保存成一个 .rdb 文件。

你可以想象一下，就像打游戏时存档。Redis 每隔一段时间，会保存一个“全量存档”，哪怕掉电，也能读档复活。

RDB 的优点：

性能高：RDB 持久化时，Redis 主进程会 fork 出一个子进程来专门做持久化，主线程继续处理请求，几乎不受影响。文件小、恢复快：RDB 文件是压缩过的二进制文件，占用空间小，加载速度快。适合灾备：因为是一个个“快照文件”，可以定期备份到远程服务器，非常方便。

RDB 的缺点：

可能丢数据：因为 RDB 是“定期”保存快照，比如你设置每 5 分钟保存一次，如果这 5 分钟内宕机，就会丢掉这期间的数据。Fork 成本高：当 Redis 数据量很大时，fork 子进程复制内存页会消耗资源，可能导致短暂延迟。

2. AOF 持久化 —— “像录音机一样记日志”

AOF（Append Only File）的思路就更直接了：

Redis 把每一次“写操作”都记录下来，就像在记账本。

当你执行一条 SET name 'XiaoMi'，AOF 文件就写入这条命令。下次重启 Redis 时，它会从头到尾重放这些命令，恢复出一样的数据状态。

AOF 的优点：

数据更安全：因为 AOF 可以设置为“每秒同步”甚至“每次写入都同步”，几乎不会丢数据。可读性好：AOF 文件是纯文本命令，打开后能看到 Redis 的“操作历史”，非常方便调试。可修复性强：如果文件损坏，手动修复的可能性比 RDB 高。

AOF 的缺点：

文件大、恢复慢：记录所有操作日志，文件体积会比 RDB 大很多，恢复时要逐条执行命令。写入性能略差：因为要频繁追加文件，AOF 的性能比 RDB 稍低。重写机制复杂：Redis 会周期性地对 AOF 文件进行“重写”，以压缩日志，但这个过程也会带来额外的 CPU 消耗。

3. 混合持久化 —— “两全其美的选择”

从 Redis 4.0 开始，官方引入了一个新的模式：RDB + AOF 混合持久化（Hybrid Persistence）

它的逻辑很聪明：

在 AOF 重写时，Redis 会先写入一份 RDB 快照（用于全量恢复），然后再把重写期间的新命令追加到 AOF 文件中。

这样既能保证恢复速度快（RDB），又能最大限度减少数据丢失（AOF）。可以说是官方最推荐的组合拳。

那生产环境怎么选？

这个问题在面试中是重头戏！

不同场景，选择不一样。我们分三种典型业务场景讲：

场景一：缓存为主，丢点数据无所谓

比如商品推荐、排行榜、Session 缓存等。这些数据可以通过数据库重新生成，即使 Redis 崩了，也能自动恢复。

推荐方案：只用 RDB 快照。

配置定期保存（如 save 900 1 表示 900 秒内有 1 次修改就触发保存）简单高效，节省 IO。

场景二：对数据安全要求高

比如订单、支付状态、用户余额、日志分析等。

推荐方案：AOF 模式（appendfsync everysec）

每秒刷盘一次，性能与安全平衡。如果掉电，最多丢 1 秒数据。

同时建议开启 RDB 作为灾备补充，一旦 AOF 文件损坏还能快速恢复。

场景三：企业级核心业务

对性能和数据安全都敏感，比如金融、电商交易系统。

推荐方案：AOF + RDB 混合持久化

启动快（因为先加载 RDB）数据安全（因为追加了 AOF）恢复效率高。

这也是现在 Redis 官方默认开启的模式。

Redis 持久化数据和缓存的扩容

聊到这里，很多面试官都会“加一刀”：

“那如果你的 Redis 数据越来越多，要扩容怎么办？”

这个问题的关键，是要区分两种情况：

缓存数据的扩容持久化数据的扩容

1、缓存数据的扩容 —— 水平分片更香

缓存类型的数据扩容，最常用的方法就是水平分片（Sharding）。

简单来说，不要让一台 Redis 顶天立地，而是多开几台，让它们分担压力。常见方案：

客户端分片：在应用端根据 key 哈希到不同 Redis 实例，比如 hash(key) % N。Redis Cluster：官方自带的分布式方案，自动分配哈希槽（16384个），支持节点动态扩容。

对缓存来说，扩容的重点是性能、命中率和可扩展性，数据丢失问题可以交给数据库兜底。

2、持久化数据的扩容 —— 数据迁移要小心

如果 Redis 中的数据是必须持久保存的业务数据，那扩容要谨慎，数据不能乱丢。这时候有两种方式：

方式一：使用 Redis Cluster 自动分片

官方方案，天然支持持久化与复制。每个节点有自己的 RDB/AOF 文件，支持 failover 自动恢复。

方式二：手动迁移 + 主从同步

适用于老版本 Redis：

新建节点配置为主节点的从库同步完成后切换主从身份最后下线老节点

这种方式可控，但要注意迁移时 AOF/RDB 文件一致性，最好暂停写入操作。

面试官的“灵魂拷问”

那场面试最后，面试官笑着问了我一句：

“如果让你在高并发场景下设计一个 Redis 缓存系统，你会怎么结合持久化？”

我回答：

用 Redis Cluster 实现水平扩展；开启 RDB 定期快照保证备份；开启 AOF everysec 提高可靠性；设置合理的 maxmemory-policy 确保不会 OOM；再用主从 + Sentinel 架构实现高可用。