必须同时启用RDB和AOF，因RDB存在定时快照导致的数据丢失窗口（如默认15分钟），且无法应对误删操作；AOF则易损坏、恢复慢、体积膨胀，单独使用风险高；混合模式通过AOF文件开头嵌入RDB快照并追加增量命令，兼顾恢复速度与数据完整性。
必须同时启用 RDB 和 AOF，不能只选其一。 单独用 RDB 会丢数据，单独用 AOF 容易损坏且恢复慢，官方推荐和生产环境实际落地的方案是两者共存、分工明确。
为什么不能只开 RDB？
RDB 是定时快照，两次快照之间的写入全部丢失。比如默认配置 save 900 1（15 分钟内至少 1 次修改），意味着宕机可能丢失最多 15 分钟数据。即使调高频率（如 save 60 10000），仍存在窗口期，且频繁 fork + 写大文件会拖慢主进程、增加内存压力。
- 触发条件靠写操作次数和时间，不是实时的
- 快照过程虽异步（
bgsave），但 fork 子进程在内存大时可能卡顿甚至失败 - 无法应对单次误删（
DEL、FLUSHALL）这类操作——快照里也存了这个“已删”状态
为什么不能只开 AOF？
AOF 文件本质是命令日志，长期运行后体积膨胀严重，重写（bgrewriteaof）本身也耗 CPU 和 I/O；更关键的是，它容易因磁盘满、断电、写中断等原因损坏，导致整个文件不可读。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
appendfsync always安全但性能暴跌，基本不用 -
appendfsync everysec是折中选择，但仍有最多 1 秒丢失风险 - 损坏后需用
redis-check-aof修复，修复失败就得丢数据或回退到 RDB - 重启加载时要逐条重放命令，1GB AOF 文件可能要几分钟
怎么配 RDB + AOF 混合模式？
Redis 4.0+ 支持混合持久化，即 AOF 文件开头是 RDB 格式快照，后面是增量命令——既压缩体积，又加速启动。但注意：混合模式不替代双备份逻辑，只是优化 AOF 文件结构。
- 开启 AOF：
appendonly yes，并设appendfsync everysec - 保留 RDB 触发规则（如
save 300 10），用于生成冷备快照 - 启用混合模式：
aof-use-rdb-preamble yes - 确保
dir目录有足够空间，appendfilename和dbfilename不冲突
启动时 Redis 优先加载 AOF；若 AOF 不存在或损坏，自动 fallback 到最新 dump.rdb；两者都坏才真正丢数据。
容易被忽略的细节
很多人以为开了 AOF 就万事大吉，却忘了检查 stop-writes-on-bgsave-error 和 stop-writes-on-bgrewriteaof-error 是否为 yes——一旦后台持久化失败（比如磁盘满），Redis 会直接拒绝写入，业务立刻报错。这不是 bug，是保护机制，但必须配合监控告警，否则问题会静默积累。
