rdb适合定时备份、从节点初始化同步及恢复速度优先且可容忍分钟级数据丢失的场景，但不适用于订单支付等强一致性业务。
Redis RDB 持久化到底适合什么场景
RDB 是通过 fork 子进程生成 dump.rdb 快照文件，适合做冷备和灾难恢复，但不是实时持久化方案。它天然适合定时备份、集群从节点初始化同步、以及对恢复速度要求高、能容忍几分钟数据丢失的业务。
常见误用是把它当唯一持久化手段部署在订单、支付类系统中——一旦宕机且上次 save 是 15 分钟前，就真丢了 15 分钟数据。
-
save 900 1表示 900 秒内至少 1 次写入才触发快照，低频写入场景下可能长期不落盘 - fork 耗时与 Redis 实例内存大小强相关：10GB 内存实例 fork 可能卡主进程 100ms+，线上需监控
latest_fork_usec - RDB 文件是二进制压缩格式，不能像 AOF 那样用
cat或grep直接查看内容，调试困难
AOF 重写（rewrite）为什么经常导致内存飙升
AOF 重写不是“复制旧日志”，而是由子进程读取当前内存数据，重新生成一条条等效命令写入新 appendonly.aof。这个过程会额外占用一块与当前数据集等大的内存空间（用于构建重写缓冲区 + 子进程页表）。
比如 Redis 使用了 4GB 内存，AOF 重写期间 RSS 很可能冲到 7–8GB，若机器只剩 2GB 空闲内存，就会触发 OOM Killer 杀掉 redis-server。
立即学习“Java免费学习笔记（深入）”；
- 重写是否触发取决于
auto-aof-rewrite-percentage和auto-aof-rewrite-min-size，建议把后者设为64mb以上，避免小文件频繁重写 -
aof-rewrite-incremental-fsync yes必须开启，否则重写时所有写都积压在 page cache，一次性刷盘易打爆磁盘 I/O - 重写期间新写入命令仍会同时写入老 AOF 文件和重写缓冲区，所以
bgrewriteaof并发执行时要小心缓冲区溢出
RDB + AOF 混合使用时加载顺序和风险点
Redis 4.0+ 支持 aof-use-rdb-preamble yes，此时 AOF 文件开头是一段 RDB 格式数据，后面才是追加的命令。启动时只加载这一个文件，不再先载 RDB 再回放 AOF —— 这是性能关键优化。
但混合模式下最容易踩的坑是：手动替换 AOF 文件后忘记重命名或权限不对，Redis 启动时检测到 appendonly.aof 存在但无法读取，会静默退回到仅加载 RDB（如果有的话），结果就是“以为开了 AOF，其实没生效”。
- 检查是否真正启用混合模式：启动后执行
CONFIG GET aof-use-rdb-preamble，返回值必须是yes - 用
redis-check-aof --fix修复损坏 AOF 时，它只会修尾部命令部分，不会碰前面的 RDB preamble，修完记得cat前 100 字节确认仍有 Redis RDB magic header（REDIS0009） - 如果关闭了 RDB 但开启了 AOF，又设置了
aof-use-rdb-preamble no，那 AOF 文件体积会随时间线性增长，务必配好重写策略
面试常问：AOF everysec 模式为什么最多丢 2 秒数据
不是“每秒刷一次盘”就等于“最多丢 1 秒”，而是因为 write(2) 和 fsync(2) 是分离的：appendfsync everysec 表示 Redis 主线程每秒调用一次 write 把日志写入内核 buffer，后台线程再负责 fsync 刷盘。
但如果主线程某次 write 完还没等到后台线程 fsync，实例就崩溃了，这部分刚 write 进 buffer 但未 fsync 的数据就丢了。而两次 fsync 最大间隔接近 2 秒（例如上一次在 00:00:00.999，下一次在 00:00:02.001）。
- 极端情况下，Linux kernel 的 dirty_ratio 设置过高（如 40%），会导致 write buffer 长期不刷，实际丢失可能远超 2 秒
-
appendfsync always看似安全，但每次写都 fsync，QPS 跌 5–10 倍，SSD 寿命也会明显下降 - 生产环境推荐
everysec+ 配合高可靠硬件（UPS、RAID 电池保护写缓存），而不是盲目切always
# 示例：如何验证当前 AOF 是否启用了 RDB preamble $ strings /var/lib/redis/appendonly.aof | head -c 20 REDIS0009*1\r\n$8\r\nselect\r\n$1\r\n0\r\n
RDB 和 AOF 不是二选一的选择题，而是数据可靠性、恢复速度、运维成本之间的权衡。真正容易被忽略的是：AOF 重写时的内存放大、混合模式下文件损坏的静默降级、以及 everysec 在内核 buffer 满时的行为漂移。这些细节往往比背对比表格更能暴露真实经验。
