redis持久化对延迟影响取决于配置而非开关本身：默认rdb几乎无感，aof的everysec仅在写密集时引发毫秒抖动；真正导致飙升的是appendfsync always或高负载下bgrewriteaof。
Redis开启RDB或AOF后，延迟真的会突增吗？
多数人担心持久化拖慢响应，但真实影响取决于配置方式而非“开或关”本身。默认配置下 RDB 几乎无感知，而 AOF 的 appendfsync everysec 也只在写密集场景带来毫秒级抖动；真正导致延迟飙升的是误配 appendfsync always 或在高负载时触发 bgrewriteaof。
如何用redis-benchmark复现真实延迟波动？
直接跑 redis-benchmark -q -n 100000 只能测吞吐，看不出延迟分布。必须加 -l（长连接）和 --latency-dist 才能捕获 P99/P999 延迟毛刺：
redis-benchmark -h 127.0.0.1 -p 6379 -t set,get -n 500000 -c 50 --latency-dist
关键点：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
-c 50模拟多客户端并发，单连接压测无法触发持久化线程争抢 - 必须搭配
--latency-dist，否则输出里只有平均值，掩盖尾部延迟 - 测试期间用
redis-cli info persistence | grep -E "aof_rewrite|bgsave"监控后台任务是否正在执行
RDB和AOF对延迟影响的差异在哪？
RDB 是 fork 子进程全量快照，主要风险在 fork 阶段：如果 Redis 实例内存达 10GB+，fork 可能卡住主线程几百毫秒（尤其在内存页未预分配、启用了透明大页 THP 的系统上）。AOF 则是主线程写日志+子进程重写，延迟更平滑但有两处硬伤：
-
appendfsync always强制每次写都刷盘 → 吞吐暴跌，P99 延迟常超 10ms（机械盘更甚） -
bgrewriteaof过程中若 AOF 缓冲区持续增长，会触发阻塞式同步（aof-rewrite-incremental-fsync yes可缓解但不根治） -
RDB的save配置项（如save 900 1）若设得太激进，小流量也会频繁触发bgsave
生产环境该选哪种持久化策略？
没有银弹，得看你的数据容忍度和负载特征：
- 纯缓存、可丢失数据 → 关掉所有持久化，
save ""+appendonly no - 需要分钟级容灾、写QPS RDB，调大
save间隔（如save 300 1000），禁用auto-aof-rewrite-percentage - 强一致性要求、写流量稳定 → 开
AOF+appendfsync everysec，但必须确保磁盘 IOPS 足够（SSD，不与日志/数据库共盘） - 绝对不能同时开
RDB和AOF的自动触发 ——bgsave和bgrewriteaof可能撞车，造成双倍 fork 卡顿
最常被忽略的一点：持久化延迟不是独立变量，它和 maxmemory 策略、key 过期扫描频率、以及是否启用 activedefrag 共同作用。压测前务必确认这些参数处于线上同态。
