rdb恢复快但易丢数据，因其是内存全量二进制快照，启动时直接加载dump.rdb跳过命令重放，不记录两次快照间的写操作；默认save 900 1配置下最坏可丢失15分钟数据。
RDB 和 AOF 不是“选一个就好”的关系，而是解决不同问题的两种机制：RDB 保恢复速度和磁盘开销，AOF 保数据不丢。生产环境几乎都得配 AOF，RDB 通常作为补充或灾备手段。
为什么 RDB 恢复快但容易丢数据
RDB 是内存数据的二进制快照，启动时直接加载 dump.rdb 文件，跳过命令重放过程。它不记录中间状态，只保存某一时刻的全量数据 —— 所以恢复快，但两次快照之间发生的写操作全没了。
- 默认配置
save 900 1意味着：900 秒内至少 1 次修改才触发一次bgsave，最坏可能丢近 15 分钟数据 -
save命令会阻塞所有客户端请求，线上严禁使用；bgsave虽异步，但 fork 子进程在内存 >10GB 时可能卡顿 100ms+，影响延迟敏感业务 - 文件体积小（比如 2GB 内存常压成 300MB
dump.rdb），适合定时 scp 到异地、做冷备
AOF 为什么安全但慢、占空间大
AOF 把每个写命令（如 set key val）按 Redis 协议格式追加到 appendonly.aof，重启时逐条重放。它本质是操作日志，所以能逼近“不丢”，但代价明显。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 同步策略决定安全性：
appendfsync always每次写都落盘，最安全但性能暴跌；appendfsync everysec（默认）折中，最多丢 1 秒数据；appendfsync no交给 OS，风险最高 - AOF 文件会不断膨胀，Redis 用
bgrewriteaof后台重写 —— 它不是简单压缩，而是读取当前内存状态，生成最小等效指令集，但重写过程仍需 fork，同样有内存压力 - 1GB 数据的 AOF 文件可能达 3–5GB（尤其含大量
del、incr等冗余操作），恢复时要重放几十万条命令，比 RDB 慢数倍
RDB + AOF 混合模式怎么配才不踩坑
Redis 4.0+ 支持混合持久化：aof-use-rdb-preamble yes。它让 AOF 文件前半部分是 RDB 快照，后半部分是增量命令 —— 兼顾加载速度和数据完整性。但启用前必须确认几点：
- 必须先开启 AOF（
appendonly yes），否则混合模式无效 - 混合 AOF 文件仍由
bgrewriteaof生成，不是自动切换；旧纯文本 AOF 不会自动升级，需手动触发重写 - 混合格式只被 Redis 4.0+ 识别，降级到老版本（如 3.2）会无法加载，跨版本迁移务必验证
- 不要同时关掉 RDB 自动触发（注释掉所有
save行）—— 混合模式依赖 RDB 快照能力，且bgsave仍是紧急备份的唯一可靠手段
真正麻烦的从来不是选 RDB 还是 AOF，而是没想清楚“能接受丢多少数据”和“恢复时间能不能超 30 秒”。很多故障复盘发现，问题不在机制本身，而在没关掉 stop-writes-on-bgsave-error yes 却没监控 bgsave 失败，结果磁盘满后 RDB 彻底停摆，只剩 AOF 独木难支。
