默认redis-benchmark压测只输出平均延迟和吞吐，无法暴露P99/P999毛刺，因未启用--latency-dist、-l长连接及足够并发（如-c 50），且单连接不能触发fork阻塞或fsync争抢，掩盖了RDB fork卡顿、appendfsync刷盘等真实延迟根源。
Redis持久化对业务延迟的影响不能靠“开或关”粗暴判断，必须用 redis-benchmark 捕获尾部延迟分布（尤其是 P99/P999），否则平均值会掩盖真实毛刺。
为什么默认 redis-benchmark 压测根本测不出延迟问题
直接跑 redis-benchmark -t set -n 100000 -c 50 只输出平均延迟和吞吐，完全看不到偶发的 100ms+ 尖峰。这些尖峰恰恰是 fork 阻塞、appendfsync 刷盘或 AOF 重写导致的，而业务最敏感的就是 P99 延迟是否突破 SLA。
- 必须加
--latency-dist，它才会每秒采样并输出直方图，暴露毛刺位置 - 单连接压测（默认）无法触发后台线程资源争抢，得用
-c 50或更高并发模拟真实客户端堆积 - 不加
-l（长连接）会导致频繁建连，把网络开销混进延迟，掩盖持久化本身的抖动 - 测试期间要同步运行
redis-cli INFO persistence | grep -E "rdb_bgsave_in_progress|aof_rewrite_in_progress"，确认毛刺时刻是否真有后台任务在执行
如何隔离测出 RDB fork 对延迟的真实冲击
RDB 的延迟风险不在 bgsave 过程本身，而在 fork() 系统调用那一瞬间——主线程要复制页表，内存越大、页越多，卡顿越明显。EC2 上 Xen 虚拟化环境尤其严重。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先清空自动触发：执行
redis-cli CONFIG SET save ""，避免测试中被 save 规则意外触发 - 手动触发一次
BGSAVE，再立刻跑压测命令：redis-benchmark -h 127.0.0.1 -c 100 -n 500000 -t set --latency-dist -l - 观察输出里是否出现 >50ms 的集中毛刺；若有，再查
cat /proc/$(pidof redis-server)/status | grep VmRSS算页数（VmRSS / $(getconf PAGESIZE)），页数超 200 万时 fork 很可能卡 100ms+ - 别信 “RDB 异步就没影响”——fork 是同步阻塞的，子进程干活时主线程早已恢复，但 fork 那一下已经把请求卡住了
appendfsync everysec 的毛刺不是错觉，是设计使然
appendfsync everysec 不是“每秒平滑刷盘”，而是主线程攒日志、后台线程每秒集中 fsync 一次。这一秒内的所有写操作都安全，但刷盘那一下会短暂抢占 I/O 和 CPU，导致 P99 延迟跳变。
- 压测时务必监控
INFO persistence中的aof_delayed_fsync：值大于 0 表示缓冲区已积压，后台线程来不及刷，正准备强制阻塞式同步 - 机械盘上，
everysec的毛刺可能达 20–50ms；SSD 上通常 - 不要在压测中同时开 RDB 自动保存——
bgsave和bgrewriteaof若撞车，fork 两次，延迟毛刺会叠加 -
appendfsync always在压测中仅用于对比极限损耗，生产环境禁用：它会让 QPS 直接跌到几百，P99 延迟常超 10ms
最容易被忽略的三个干扰项
压测结果不准，往往不是持久化配置的问题，而是其他参数没对齐或系统层未调优：
-
vm.overcommit_memory必须设为 1，否则大内存 Redis 在 fork 时可能因内核预估失败而报Cannot allocate memory，QPS 归零 -
maxmemory-policy若设成noeviction，写入压力大时会直接返回 OOM 错误，和持久化无关，但现象类似延迟飙升 - 没关
activedefrag且内存碎片率mem_fragmentation_ratio > 1.5时，碎片整理会和持久化争抢 CPU，放大延迟毛刺
真正影响业务延时的，从来不是“有没有持久化”，而是 fork 耗时、fsync 时机、后台任务调度这三者的耦合点——它们只在高并发写入下才暴露，必须用带分布统计的压测才能揪出来。
