纯缓存场景（如实时排行榜、会话缓存）可关闭rdb与aof：设save ""且appendonly no，实测p99延迟从12ms降至3ms；高qps下推荐混合持久化（aof-use-rdb-preamble yes），需配合appendfsync everysec及低频rdb（如save 3600 1）。

什么时候该关掉RDB或AOF

不是所有业务都需要持久化。比如实时排行榜、会话缓存这类纯缓存场景，数据丢失可接受，且写入QPS常超5万+/秒，开启AOF everysec都会因fsync抖动导致延迟毛刺。此时应直接禁用：save ""（清空所有RDB触发规则）+ appendonly no。某游戏公司实测，关掉AOF后P99延迟从12ms降到3ms。

RDB和AOF怎么组合才不拖慢QPS

混合持久化（aof-use-rdb-preamble yes）是高QPS场景的折中解：AOF重写时先写一段RDB二进制快照，再追加增量命令。相比纯AOF，重写耗时减少60%；相比纯RDB，崩溃恢复速度提升4倍。但注意两个硬约束：

redis-tools

按类别查找Redis命令、检测服务器连接、监控键数量和内存占用，支持离线速查表。

下载

• 必须配合appendfsync everysec，不能设always
• RDB快照频率要压低，例如save 3600 1（1小时1次修改就触发），避免BGSAVE频繁fork子进程

否则在单机QPS超8万时，fork开销会吃掉15% CPU。

数据量超10GB后AOF重写卡顿怎么办

AOF重写本质是读全量内存+序列化成命令流，数据量大时易阻塞主线程。解决方案不是调参数，而是拆结构：

• 把大key（如user:1001:profile含10MB JSON）拆成哈希字段，用HSET user:1001:profile name "Alice" age 28替代SET user:1001:profile "{...}"
• 冷热分离：高频更新字段（如last_login_time）单独存，低频字段（如bio）走另一key，避免每次重写都刷整块数据
• 监控info persistence中的aof_rewrite_in_progress和aof_last_rewrite_time_sec，若重写超30秒，立即检查是否有未拆分的大key

集群环境下持久化配置必须统一吗

必须。Redis Cluster节点间不共享持久化配置，但若混用（如3个节点开AOF、2个关AOF），故障转移时可能因主从数据不一致导致slot迁移失败。验证方法：redis-cli -h node1 info persistence | grep appendonly，逐台比对。更关键的是maxmemory-policy也需一致——曾有金融系统因某节点配volatile-lru、其余配allkeys-lfu，导致缓存淘汰行为错乱，QPS波动剧烈。

实际落地时最容易被忽略的点：持久化开关和淘汰策略是强耦合关系。比如开了AOF又配noeviction，一旦内存满，写请求直接报(error) OOM command not allowed when used memory > 'maxmemory'.，而运维只盯着used_memory_peak看，根本想不到是持久化配置引发的连锁反应。