redis-benchmark不能直接测真实业务，因其默认使用固定Key和简单命令，无法模拟“查缓存→未命中→查DB→写回”等业务链路；真实压测需用memtier_benchmark或自定义脚本支持多阶段请求、随机Key及条件逻辑。
redis-benchmark 能不能直接测真实业务？
不能。它默认用固定 Key（key:__rand_int__）和简单命令（如 SET、GET），不模拟业务逻辑链路，比如「先查缓存 → 缓存未命中 → 查 DB → 写回缓存」这种组合操作。压出来的 QPS 是理论峰值，不是你服务能扛住的真实吞吐。
真正要测业务，得用 memtier_benchmark 或自己写脚本：前者支持多阶段请求（--pipeline + --command 组合）、随机 Key + 自定义数据格式；后者能嵌入 Lua 脚本、带条件判断、模拟客户端重试逻辑。
-
memtier_benchmark的--command="GET key1; SET key2 val2"可串行压测多个命令 - 用
-r参数生成随机 Key，避免哈希倾斜或热点 Key 误判性能 - 真实场景必须加
--test-time=60（而非只靠-n控制请求数），否则短时突发流量掩盖连接建立/超时重试问题
集群环境压测为什么 QPS 反而比单机低？
因为 redis-benchmark --cluster 模式下，客户端需自行解析 slot、重定向、维护多个连接池，额外开销大。尤其当 Key 分布不均（比如大量 Key 集中在少数 slot），会导致部分节点 CPU 打满、其余节点闲置——此时看到的“集群 QPS”其实是瓶颈节点的吞吐上限。
更靠谱的做法是：绕过代理直连各分片，分别压测每个节点（用 -h + -p 指定不同地址），再叠加结果；或者用 redis-py 的 cluster_async.py 脚本，它用异步 IO 减少连接等待时间，更能反映集群真实能力。
- Codis/Twemproxy 等代理层会引入额外延迟（Twemproxy 测试显示约 20% 性能损失）
- 集群模式下
PING命令返回值可能含MOVED或ASK重定向响应，redis-benchmark默认不处理，导致大量失败请求 - 务必确认压测客户端与 Redis 节点网络同 Region，跨机房压测会把网络延迟算进 Redis 延迟里
延迟 P99 飙高但平均延迟正常，怎么定位？
这是典型长尾问题，redis-benchmark 默认只输出平均延迟和 P50/P95，看不到 P99/P99.9。必须加 --latency-dist 参数，它会输出延迟分布直方图（单位微秒），一眼就能看出是否有少量请求卡在 10ms+。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
常见根因不是 Redis 本身，而是外部干扰：
- Linux
transparent_hugepage开启时，Redis 内存分配可能触发周期性内存整理，造成毫秒级暂停 - 持久化（RDB fork 或 AOF rewrite）期间，fork 子进程会复制父进程页表，若内存大、CPU 核少，fork 耗时可达数百毫秒
- 客户端没设
timeout，网络抖动时 TCP 重传等待长达数秒，被计入 Redis 延迟统计（实际是网络层问题）
验证方式：压测同时跑 redis-cli --stat 观察 instantaneous_ops_per_sec 是否断续下跌，再结合 INFO commandstats 查看 cmdstat_set.exes 的 usec_per_call 是否突增。
为什么压测结果每次波动很大？
根本原因是没锁住系统变量。同一台机器上，Redis 和压测工具共用 CPU、内存、网络栈，只要后台有 cron、logrotate、监控 agent 在跑，就会影响结果。
- 压测前必须关闭
swap（sudo swapoff -a），否则内存压力大会触发 swap，延迟爆炸 - 用
taskset -c 0-3绑定 Redis 进程到特定 CPU 核，避免调度抖动 - 压测客户端和 Redis 实例不要部署在同一台物理机——哪怕用 Docker，内核资源仍共享
-
redis-benchmark的-c并发数不是越大越好：当连接数超过net.core.somaxconn或 Redis 的maxclients，会触发连接拒绝，QPS 反降
真正稳定的压测，需要控制变量到内核参数级别。业务上线前那轮压测，建议在专用物理机上做，而不是开发机顺手一跑。
