RDB并非实时持久化，仅在满足save配置条件时fork子进程生成dump.rdb，期间崩溃会导致自上次成功save起的数据丢失；AOF通过bgrewriteaof基于内存快照重写为最小指令集，避免日志膨胀；混合模式下AOF文件开头嵌入RDB二进制块以加速加载。
RDB持久化触发条件与实际失效场景
RDB不是“只要开了就自动保数据”，它依赖明确的触发策略，很多面试者误以为 save 900 1 这类配置是实时生效的守护进程。其实它只是服务器在满足条件时才 fork 子进程生成 dump.rdb 文件，期间若发生崩溃，最后一次成功 save 之后的所有写操作都会丢失。
-
save配置只对主进程有效，Redis Cluster 中每个节点需单独配置 - 手动执行
SAVE命令会阻塞主线程，生产环境应改用BGSAVE - 启用了 AOF 后，RDB 文件仍会被生成（如
redis-cli --rdb导出），但重启时默认优先加载 AOF —— 这点常被忽略 - 如果磁盘空间不足或
fork()失败（如虚拟内存碎片高、容器内存限制严），RDB 会静默失败，日志里只有Can't save in background: fork: Cannot allocate memory
AOF重写机制如何避免文件无限膨胀
AOF 本质是追加命令日志，不做处理的话，一个 key 被 set 100 次就会记 100 行，重启回放效率极低。Redis 通过 bgrewriteaof 在后台生成最小化等效指令集，但这个过程不是“读旧AOF+压缩”，而是读取当前内存快照再转成命令流。
- 重写期间新写入仍继续追加到原 AOF 文件，重写完成后原子替换 —— 所以不会丢数据
-
auto-aof-rewrite-percentage和auto-aof-rewrite-min-size共同控制触发时机，若设为100和64mb，表示当前 AOF 比上次重写后大一倍且体积超 64MB 才触发 - 重写时若子进程内存占用过高（尤其使用了大量 bigkey 或开启了
lua-time-limit），可能被 OOM killer 杀掉，导致重写中断
RDB与AOF混合使用（AOF+RDB）的真实加载逻辑
Redis 4.0 引入的 aof-use-rdb-preamble yes 并非“先加载RDB再追AOF”，而是把 RDB 格式的内容作为 AOF 文件开头的一段二进制块（类似快照头）。启动时 Redis 会识别这个 preamble，直接 mmap 加载它，再顺序执行 preamble 之后的文本命令。
- 启用后，
appendonly.aof文件开头是 RDB 二进制，后面才是普通命令；用cat appendonly.aof | head -c 100 | hexdump -C可看到前几个字节是REDIS0011 - 这种模式下，AOF 文件体积比纯文本 AOF 小得多，且加载速度接近纯 RDB —— 但重写仍需完整遍历内存，开销没减少
- 如果中途关闭了 AOF，再开启并设置
aof-use-rdb-preamble yes，首次重写会生成带 preamble 的新 AOF，但旧 AOF 不会自动转换
选型关键：不是“哪个更好”，而是“什么场景不能只用它”
面试常问“RDB 和 AOF 怎么选”，正确思路是看数据容忍度和恢复 SLA。RDB 适合做冷备或灾备快照，AOF 适合要求秒级以内数据不丢的业务。但真实线上几乎都开双开
- 纯 RDB：无法接受分钟级数据丢失（比如支付订单状态更新），也不适用于频繁变更小数据量场景（如计数器）
- 纯 AOF +
appendfsync always：吞吐暴跌（每条命令都 fsync），磁盘 IOPS 成瓶颈，SSD 寿命也会加速消耗 - 双开时若
auto-aof-rewrite-percentage设太激进（如 50），可能刚重写完又触发下一次，导致 CPU 和 fork 压力持续高企 - 容器化部署时，
vm.overcommit_memory=1必须设置，否则fork极易失败，RDB 和 AOF 重写都会卡住
config get auto-aof-rewrite-percentage 1) "auto-aof-rewrite-percentage" 2) "100" config get aof-use-rdb-preamble 1) "aof-use-rdb-preamble" 2) "yes"
真正容易被忽略的是：RDB 和 AOF 的恢复时间差异不仅来自格式，更取决于数据结构复杂度。比如一个含百万元素的 zset，RDB 加载快但内存分配集中，AOF 回放慢但内存增长平缓 —— 这会影响 K8s Pod 的 startupProbe 超时判定。
