必须开启aof，业务不能容忍分钟级丢失时需设appendonly yes且appendfsync everysec；redis重启优先加载aof而非rdb，即使rdb更新也无效。
Redis默认启用RDB，但仅靠RDB无法满足多数生产环境的数据安全性要求；AOF才是保障“最多丢1秒数据”的实际底线，RDB更适合做辅助备份或快速恢复。
什么时候必须开AOF
AOF不是可选项，而是数据可靠性兜底的必需配置。只要业务不能容忍分钟级数据丢失（比如订单、支付、用户状态变更），就必须开启appendonly yes。常见错误是只配了save规则却关着AOF，结果一断电就丢掉最近5分钟所有写入。
- Redis 7.0+ 默认仍不开启AOF，需手动在
redis.conf中取消appendonly no的注释并改为yes - 即使开了AOF，若
appendfsync设为no，实际依赖操作系统刷盘，可能丢数分钟——生产环境必须设为everysec - 开启AOF后，
redis-cli CONFIG GET appendonly应返回1，不是0或报错
RDB和AOF同时开启时谁生效
Redis重启时优先用AOF恢复，不是RDB。这是硬编码逻辑，不受配置顺序或文件时间影响。哪怕dump.rdb比appendonly.aof新，只要AOF文件存在且未损坏，Redis就会忽略RDB直接加载AOF。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 验证方法：停掉Redis → 手动删掉
appendonly.aof→ 启动 →redis-cli KEYS *看是否为空；再恢复AOF文件重试，数据应完整重现 - 例外情况：AOF文件末尾损坏（如断电导致截断），Redis启动会报
Bad file format reading the append only file，此时需用redis-check-aof --fix修复，否则拒绝启动 -
stop-writes-on-bgsave-error yes只影响RDB失败时的写入，对AOF无约束；但stop-writes-on-repl-error等参数不控制持久化本身
混合持久化（RDB+AOF）的实际效果
Redis 4.0引入的aof-use-rdb-preamble yes不是“双保险”，而是用RDB快照替代AOF前半部分冗余命令，让AOF文件更小、加载更快。它不会提升数据安全性，但能缓解AOF重写压力。
- 开启后，AOF文件开头是标准RDB二进制格式，后面才是追加的命令；
redis-check-aof仍能识别并修复 - 重写触发条件不变：
auto-aof-rewrite-percentage和auto-aof-rewrite-min-size照常工作，只是重写产出的文件含RDB头 - 注意：混合模式下，
redis-cli BGREWRITEAOF仍会阻塞新写入命令的记录（直到重写完成），这点和纯AOF一致
为什么不能只靠BGSAVE定时快照
因为save配置的触发条件是“或关系”，但实际落地依赖子进程fork和磁盘IO，高负载时极易失效。例如save 60 10000本意是“1分钟内改1万次就存”，但若这期间CPU满载，fork子进程超时失败，redis.log里会出现Failed to fork for BGSAVE: Cannot allocate memory，而主进程照常收请求——数据就此裸奔。
-
info persistence里的rdb_last_bgsave_status必须是ok，rdb_last_save_time要持续更新，否则说明RDB已失活 - 监控项重点看：
latest_fork_usec（超过100ms需警惕）、rdb_changes_since_last_save（长期为0说明没触发）、aof_pending_bio_fsync（非0表示AOF刷盘积压） - 真正可靠的兜底是AOF +
everysec，而不是调低save阈值——后者只会让fork更频繁，加剧系统抖动
最易被忽略的一点：AOF重写（BGREWRITEAOF）本身也是fork子进程操作，和RDB一样受内存与CPU制约；如果AOF文件已达GB级，重写过程可能持续数秒，期间父进程内存占用会短暂翻倍（COW机制下脏页复制）。这不是配置问题，而是设计使然——别指望用配置绕过这个物理限制。
