生产环境应启用AOF并配合RDB混合持久化：RDB存在快照时间窗口丢数据风险，AOF单独使用易膨胀且恢复慢，混合模式兼顾安全性与恢复效率。
生产环境建议默认启用 AOF，并配合 RDB 做混合持久化——不是二选一，而是用 AOF 保数据安全，用 RDB 加速恢复。
为什么不能只用 RDB？
RDB 的快照机制天然存在时间窗口风险。比如配置了 save 60 10000，但业务在第 59 秒突增写入后宕机，这 59 秒的全部变更就丢了。实际生产中，哪怕只丢几秒订单或用户会话，都可能触发资损或投诉。
常见错误现象：redis-server 重启后发现最近几分钟的 key 全部消失，但日志里没报错——这就是纯 RDB 在“安静地丢数据”。
- RDB 是周期性快照，无法保证任意时刻的数据完整性
- 主从全量同步依赖 RDB 文件，但若主节点刚 fork 出子进程就崩溃，RDB 文件可能不完整
-
SAVE命令会阻塞主线程，BGSAVE虽不阻塞，但 fork 大内存实例时可能失败（尤其在vm.overcommit_memory=0的系统上）
为什么不能只用 AOF？
纯 AOF 在大流量场景下会快速膨胀。比如一个高频计数器每秒 incr 1000 次，AOF 文件一小时就能增长上百 MB；更麻烦的是，redis-check-aof 重写过程本身要读取整个 AOF 并执行命令，内存占用可能翻倍，容易触发 OOM。
使用场景差异明显：appendfsync always 看似最安全，但每条写命令都 fsync()，QPS 直接掉 50%+；而 appendfsync no 把刷盘交给 OS，断电可能丢 30 秒数据——这已超出多数业务容忍范围。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 默认
appendfsync everysec是平衡点，但要注意：Linux 的dirty_ratio和dirty_expire_centisecs会影响实际刷盘时机 - AOF 重写（
bgrewriteaof）期间，父进程仍需持续追加新命令到旧 AOF，同时子进程生成新 AOF，磁盘 IO 压力陡增 - Redis 7.0+ 的多文件 AOF（base +增量）虽缓解了单文件膨胀，但故障恢复时需按顺序加载 base + 所有增量文件，耗时未必比 RDB 短
混合持久化怎么配才靠谱？
Redis 4.0+ 支持 aof-use-rdb-preamble yes，开启后 AOF 文件前半部分是 RDB 格式快照，后半部分是增量命令——既保留 RDB 的紧凑与加载速度，又继承 AOF 的写操作可追溯性。
实操建议直接抄这个最小安全集：
appendonly yes appendfilename "appendonly.aof" appendfsync everysec aof-use-rdb-preamble yes auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
关键点：
- 不要禁用 RDB（即别配
save ""），因为 AOF 重写和主从同步仍依赖 RDB 快照能力 -
auto-aof-rewrite-percentage设太低（如 50）会导致频繁重写，设太高（如 500）会让 AOF 文件过大 - 务必定期检查
redis-cli info persistence中的aof_last_rewrite_status和rdb_last_bgsave_status，失败时不报警等于裸奔
真正容易被忽略的是：持久化只是数据兜底手段，不是免责金牌。AOF 重写卡住、磁盘写满、fork() 失败这些故障不会自动告警，得靠 INFO persistence 输出 + 磁盘监控 + fork 耗时指标（latest_fork_seconds）三者联动才能提前发现。
