Redis 持久化有两种：RDB（快照）、AOF（日志追加），还支持RDB+AOF 混合持久化（Redis 4.0+，生产最常用）。下面从原理、优缺点、适用场景、选型建议讲清楚。
一、RDB（Redis Database）快照
把某一时刻全量内存数据，压缩保存成二进制
.rdb文件。 触发方式：
自动触发：
save配置，例如save 900 1：900 秒内至少 1 个 key 修改就快照；手动触发：
BGSAVE（fork 子进程，不阻塞主线程）、SAVE（主线程阻塞，生产禁用）；停机、主从全量同步也会触发 BGSAVE。
✅ 优点
文件体积小，二进制压缩，恢复速度极快；
fork 子进程做持久化，正常 BGSAVE 不阻塞 Redis 主线程；
适合做冷备份、灾难恢复。
❌ 缺点
会丢数据：两次 RDB 之间的新增数据没有落盘，如果宕机，丢失上一次快照之后的数据；
fork 子进程时，内存量大（几十 GB）会有COW 写时复制开销，瞬间占用双倍内存，可能触发 OOM；
大实例 fork 会短暂阻塞主线程（fork 本身需要拷贝页表）。
二、AOF（Append Only File）追加日志
记录每一条写命令，追加写入
.aof文本日志，重启时重放命令恢复数据。
AOF 刷盘策略 appendfsync
always：每条写命令都 fsync 刷盘。几乎不丢数据，但性能极差；everysec（默认）：每秒刷一次。最多丢失 1 秒数据，性能均衡；no：交给操作系统自行刷盘，不可控，丢数据更多。
AOF 重写 bgrewriteaof：日志不断膨胀，会 fork 子进程，直接读取当前内存数据生成精简 AOF，删掉冗余命令，压缩文件。
✅ 优点
数据安全性高，
everysec最多丢 1 秒数据；日志可读，误操作可以人工修复。
❌ 缺点
AOF 文件通常比 RDB 大很多；
数据恢复速度比 RDB 慢很多（需要逐条重放命令）；
持续刷盘 + 重写，磁盘 IO 压力更大；
AOF 重写同样有 fork 内存开销。
三、混合持久化（Redis4.0 + 推荐）
aof-use-rdb-preamble yes（5.0 默认开启）
AOF 重写时，先写一段 RDB 格式的全量快照，后面追加增量 AOF 命令。
恢复：先加载 RDB 部分，再重放后面增量 AOF；
兼顾：RDB 恢复快 + AOF 少丢数据，生产首选。
四、选型对照表
五、选型核心判断标准
1. 纯缓存场景（数据丢了无所谓，可以从数据库重新加载）
👉 关闭持久化 save "" + appendonly no
例如页面热点缓存，宕机最多短暂穿透 DB。
2. 业务允许少量丢失（最多丢 1 秒数据），生产主实例
👉 开启混合持久化（默认）
save 3600 1 # 可选，定时RDB做额外备份
appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes
主库推荐混合：AOF 保证数据安全，RDB 格式的头部保证恢复速度。
3. 业务零容忍，一条数据都不能丢（极少）
👉 AOF appendfsync always
⚠️ 性能下降非常明显，磁盘压力巨大，一般不推荐。可以改用集群 + 多副本架构。
4. 只做备份、从节点
👉 可以只开 RDB，用来做定期冷备份，减少磁盘压力。从库一般不开启 AOF。
六、生产避坑要点
fork 开销：Redis 内存越大，BGSAVE/BGREWRITEAOF 的 fork 耗时越高，大实例（>16G）要关注页表拷贝，高峰避免触发重写；
磁盘容量：AOF 会持续增长，要监控 AOF 文件大小，预留磁盘；
不要把持久化放在同一块磁盘：RDB/AOF 和系统盘分开，防止磁盘打满导致 Redis 阻塞；
备份策略：持久化文件只是本地落盘，必须定时把 rdb/aof 拷贝到异地备份，防止机器硬盘损坏；
主从集群：持久化一般在主节点开启，从节点关闭 AOF，只按需开启 RDB 用于备份。
一句话总结
纯缓存：关闭持久化；
普通业务 Redis 主库：混合持久化（AOF+RDB）；
仅做备份 / 从库：单用 RDB；
绝对不能丢数据：AOF always（慎重，性能代价很大）。
本文原创作者：易君召，详见：https://www.yijunzhao.cn/authors/yijunzhao，转载请注明出处。
原文链接
欢迎访问 小易撩挨踢