RDB会丢数据是因为它基于定时快照，两次快照间宕机则新写入数据丢失；AOF看似更安全但若配置不当（如未启用重写、fsync策略不合理或文件损坏），反而导致恢复慢、磁盘满甚至启动失败。
Redis 默认只开 RDB，但光靠它扛不住数据强一致性要求；AOF 能补上这个缺口，但不是无脑开就完事——选错配置或混搭不当，反而拖慢性能、增大恢复时间。
为什么 RDB 会丢数据，而 AOF 看似“更安全”却不一定可靠
RDB 是定时快照，比如配置
，意味着“60 秒内有 1 万次写才触发一次
”。这期间若进程被 kill -9 或机器断电，所有新写入都没进
，直接丢失。AOF 默认是
，每秒刷一次盘，最坏丢 1 秒数据；设成
理论上不丢，但每次写都要
，QPS 高时延迟飙升，还可能卡住主线程。
更关键的是：AOF 文件本身会膨胀。比如一个
键执行了 10 万次，AOF 就记 10 万条命令；但实际值只是最终数字。不开启
和
，文件越滚越大，重启加载就变慢。
什么时候该关掉 RDB，只用 AOF
仅当满足以下全部条件时，才建议禁用 RDB（
）并纯用 AOF：
业务能接受
模式下最多 1 秒数据丢失
写流量稳定，没有突发批量写入（否则 AOF rewrite 可能抢 CPU，影响响应）
磁盘 I/O 足够快，且
所在分区不与其他高 IO 服务共用
已配好
和
，并监控
确保重写正常触发
别信“AOF 更安全所以必须开”——很多线上事故源于 AOF 重写失败后持续追加、磁盘写满、Redis 进程 OOM 被杀，反而比 RDB 丢得更多。
为什么混合使用 RDB + AOF 反而是主流选择
Redis 4.0+ 支持混合持久化（
），启动时先加载 RDB 快照，再重放 AOF 尾部增量命令。这既保留 RDB 加载快的优点，又避免 AOF 全量重放的慢启动问题。
Redis 8.2.3
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
下载
但要注意几个坑：
开启混合模式后，
文件开头是 RDB 二进制块，不能用文本工具直接查看或手动编辑
如果 AOF 文件损坏，
只能修复纯 AOF，对混合格式无效；得先用
提取 RDB 部分，再人工拼接
动态开启 AOF 时，不会自动启用混合模式，必须显式设
生产环境建议：RDB 保留基础快照（如
），AOF 开
+ 混合模式，禁用
。
故障恢复时，Redis 怎么决定用哪个文件
Redis 启动时按固定顺序检查持久化文件：
优先加载
（无论是否混合格式）
如果 AOF 文件不存在或被
关闭，才加载
如果两个文件都存在，但 AOF 文件末尾损坏，Redis 会直接 abort 启动，报错
，不会退回到 RDB
这意味着：不要以为留着
就算有兜底。一旦开了 AOF，就得确保它可读；定期用
校验，比等出事再救急靠谱得多。
save 60 10000 BGSAVEdump.rdbappendfsync everysecalwaysfsync()INCRauto-aof-rewrite-percentageauto-aof-rewrite-min-sizesave ""everysecappendonly.aofauto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mbredis-cli info persistence | grep aof_rewriteaof-use-rdb-preamble yesappendonly.aofredis-check-aof --fixredis-check-rdbCONFIG SET appendonly yesaof-use-rdb-preamble yessave 300 10everysecalwaysappendonly.aofappendonly nodump.rdbUnexpected EOF reading the append only filedump.rdbredis-check-aof --fix