S12-B04 · 持久化：RDB / AOF / 混合

适用读者：要回答"Redis 宕机会丢多少数据"的人。
前置：S12-B03。
实测环境：Redis 7.0.15（2026-11-05）。
覆盖旧文：867(80) 1579(115) 886(64) = 259 点。
覆盖扩展：E-S12-012（AOF 重写）。
上一篇：S12-B03 · 过期、淘汰与内存
下一篇：S12-B05 · 缓存入门与 Spring Boot 整合。

1. 一句话结论

RDB 是"某一刻的快照"（丢得多、恢复快），AOF 是"命令流水账"（丢得少、文件大）。7.0 起默认混合持久化：RDB 打底 + AOF 增量。

方式	内容	丢失窗口	恢复速度
RDB	二进制快照	到上次快照（分钟级）	快
AOF	追加命令日志	取决于 `appendfsync`（最多 1 秒）	慢（要重放）
混合（7.0 默认）	RDB + AOF 增量	同 AOF	快

2. 实测：RDB 与 AOF 的状态

redis-cli bgsave

实测输出：

Background saving started
rdb_last_bgsave_status:ok
rdb_changes_since_last_save:0

AOF 开启后：

aof_enabled:1
aof_current_size:300449
aof_last_bgrewrite_status:ok

AOF 重写后：

aof_current_size:300427
aof_base_size:300427

指标	含义
`rdb_last_bgsave_status`	上次快照是否成功
`aof_current_size`	当前 AOF 体积
`aof_base_size`	上次重写后的基准体积

"AOF 会无限膨胀吗"——不会，BGREWRITEAOF 会压缩（实测重写后体积基本持平，因为数据本身没冗余）。

3. `appendfsync` 的三档（E-S12-012）

值	行为	丢失窗口	性能
`always`	每条命令都 fsync	几乎不丢	最差
`everysec`（默认）	每秒 fsync	最多 1 秒	好
`no`	交给 OS	不确定	最好

实测：本实例 appendfsync = everysec。

判据："能接受丢 1 秒数据吗？" 能 → 保持 everysec；不能 → always（但吞吐会掉一个量级）。

4. 为什么 Redis 事务不支持回滚（A-886）

原因	说明
错误分两类	语法错误（入队就报，整个事务不执行）；运行时错误（如对 string 做 `INCR`，只该条失败）
设计取舍	回滚需要额外记录 undo，与"简单快速"目标冲突
责任划分	把"用错类型"当编程错误，不该让服务器兜底

"那为什么还叫事务"：它保证命令连续执行不被打断（隔离性），不保证原子回滚（原子性）。

5. 五种持久化组合的取舍

组合	适用
纯缓存（可丢）	可以不开持久化
RDB only	能接受分钟级丢失、要快恢复
AOF everysec（默认推荐）	最多丢 1 秒
AOF always	金融级（性能代价大）
混合	默认，兼顾

6. 五个误区

误区	真相
"AOF 是实时的，不丢数据"	`everysec` 最多丢 1 秒
"RDB 会丢很多所以不能用"	快照频率可调
"事务能回滚"	不支持回滚
"AOF 一定比 RDB 大"	重写后会压缩
"持久化不影响性能"	`always`/频繁快照都会影响

7. 自检

RDB 与 AOF 的丢失窗口与恢复速度差异？
appendfsync 三档怎么选？
为什么 Redis 事务不回滚？它保证什么？
混合持久化的组成？
怎么确认上次快照/重写成功？

8. 下一篇

S12-B05 · 缓存入门与 Spring Boot 整合

持久化讲完，下一篇把 Redis 接进项目：RedisTemplate 与 @Cacheable 的差异、序列化坑。

本篇属于系列《S12 · Redis 与缓存》。旧文来源：A-867/1579/886；扩展点 E-S12-012。持久化指标为 Redis 7.0.15 实测。