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