redis-benchmark不能直接测持久化性能，它默认仅压测纯内存操作；要间接验证rdb/aof开销，需配合手动触发bgsave或aof重写、监控延迟毛刺与qps下跌，并关闭监控日志等干扰项。
redis-benchmark 能测持久化性能吗？不能直接测，但能间接验证
很多人误以为 redis-benchmark 加上 -t set 就能测出 RDB 或 AOF 的真实开销——其实它默认压测的是纯内存操作，不触发持久化。真正影响性能的 fork、磁盘写入、AOF fsync 等环节，redis-benchmark 本身不会主动拉满这些路径。
要测持久化性能，必须让压测流量真实“撞上”持久化行为。关键在于两点：一是让 Redis 处于持续写入状态（触发 save 条件或 AOF flush），二是监控对应阶段的吞吐与延迟变化。
- 关闭
save配置后跑redis-benchmark -t set -n 1000000 -c 50，得到的是“无持久化”基准值 - 打开
save 60 10000并持续压测 60 秒以上，观察第 60 秒附近是否出现 QPS 下跌、P99 延迟跳升（fork 阻塞 + 写盘竞争） - 对 AOF 测试，需配合
appendfsync everysec，并用info persistence查看aof_delayed_fsync是否非零——该值上升说明 fsync 被延迟，已形成瓶颈
如何构造真实持久化压力场景？用写入节奏控制触发时机
RDB 和 AOF 的性能损耗不是恒定的，而是集中在特定时刻：RDB 在 BGSAVE 执行时，AOF 在 fsync 调用瞬间。所以测试必须让这些事件可复现、可观测。
推荐做法是绕过自动配置，手动触发 + 定时压测组合：
- 先停掉所有自动 save 规则（注释掉
redis.conf中所有save行），避免干扰 - 启动 Redis 后，用
redis-cli BGSAVE手动触发一次快照，记录耗时：redis-cli info | grep rdb_last_bgsave_time_sec - 接着用
redis-benchmark -t set -c 100 -n 500000 --pipeline 100持续灌入数据（pipeline 减少网络开销，聚焦服务端压力） - 在压测进行中，每 20 秒执行一次
BGSAVE，同时用redis-cli --stat观察instantaneous_ops_per_sec是否骤降
注意：不要用 SAVE，它会阻塞主线程，测出来的是最差情况，不代表生产常态。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
AOF rewrite 期间性能怎么观察？重点看延迟毛刺和 write blocked
AOF 重写（bgrewriteaof）本质是另起子进程做全量命令压缩，虽不阻塞主线程，但会抢 CPU 和磁盘 I/O。生产中最常见的问题是：重写开始后，业务 P99 延迟突然升高 2–5 倍，且 redis-cli info | grep aof_rewrite_in_progress 显示为 1 的时间远长于预期。
实操建议：
- 先用
redis-cli CONFIG GET auto-aof-rewrite-percentage和auto-aof-rewrite-min-size查当前阈值 - 人工制造 AOF 文件膨胀：连续执行
SET key{i} value（i 从 1 到 100 万），再DEL其中一半，让 AOF 包含大量冗余 - 触发重写：
redis-cli BGREWRITEAOF，立刻执行redis-cli --latency监控实时延迟，重点关注 10ms+ 毛刺是否密集出现 - 检查
INFO stats中的total_commands_processed增速是否变缓，以及blocked_clients是否非零（说明客户端因等待写缓冲区被 block）
为什么压测时要关监控和日志？因为它们会掩盖真实瓶颈
很多团队在压测 Redis 持久化时，开着 Prometheus 抓取 INFO、开着慢日志（slowlog-log-slower-than）、甚至开着 audit log，结果发现 QPS 上不去，归因于 RDB 或 AOF，其实是监控自身吃掉了 15%–30% 的 CPU。
真实生产压测前必须清理干扰项：
- 临时关闭
slowlog-log-slower-than（设为 0）或调高阈值（如 100000 微秒） - 停掉所有外部采集器（Prometheus、Zabbix、ELK），改用本地
redis-cli --stat或INFO手动轮询 - 确认
loglevel是notice或warning，避免verbose级别日志刷盘拖慢 AOF - 如果用容器部署，检查
/proc/sys/vm/swappiness是否为 0——swap 会极大放大 fork 延迟
持久化性能的复杂点不在配置本身，而在于它和操作系统调度、磁盘队列深度、内核 dirty_ratio 设置深度耦合。一次有效压测，必须把 Redis 放在“裸金属感”的环境里跑，否则你优化的只是假象。
