结论是：jmeter压测redis需配合redis-cli --latency实时监控真实延迟，线程数应按qps×平均耗时科学估算（如5000 qps×0.02s≈100线程），配ramp-up≥60秒、keep alive和constant timer模拟真实行为，避免连接池打爆或java层干扰掩盖redis真实性能瓶颈。
直接上结论：用 JMeter 做负载测试 + redis-cli --latency 实时盯 Redis 延迟，比只看接口响应时间更准。
JMeter 线程组怎么配才贴近真实场景
别一上来就设 1000 线程——这容易把连接池打爆，测的不是 Redis 性能，而是你自己的配置漏洞。
- 线程数按预估 QPS × 平均请求耗时（秒）来算，比如目标 5000 QPS、平均接口耗时 20ms，线程数 ≈ 100
- Ramp-up period 设为 60 秒以上，避免瞬间压垮连接池
- 勾选
Keep Alive，复用 HTTP 连接；否则每请求新建 TCP 连接，网络层就成瓶颈 - 加一个
Constant Timer（比如 100ms），模拟真实用户行为间隔，避免压测变成“暴力扫荡”
redis-cli --latency 是唯一能看清 Redis 真实心跳的工具
接口响应时间 50ms，不等于 Redis 慢——可能是网络抖动、序列化耗时、甚至 StringRedisTemplate 默认的 JDK 序列化在反序列化大对象时卡住。而 redis-cli --latency 绕过所有 Java 层，直连 Redis 测 PING 延迟。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在 Redis 服务器本机执行：
redis-cli --latency -h 192.168.56.100 -p 6379 - 持续运行 120 秒后看输出，重点关注
min/max/avg，如果max超过 5ms，说明 Redis 本身已承压 - 配合
redis-cli --stat观察instantaneous_ops_per_sec是否逼近你配置的max-active上限
为什么不能只信 Spring Boot Actuator 的 /actuator/metrics/cache.* 指标
这些指标统计的是“缓存命中/未命中次数”，但完全不反映延迟、序列化开销、连接争抢。尤其当用了 RedisTemplate 存对象时，GenericJackson2JsonRedisSerializer 反序列化失败或字段不匹配，会静默吞掉异常、返回 null，导致你以为“缓存命中了”，实际走的是 DB 回源。
- 务必在压测期间打开 Redis 日志：
slowlog-log-slower-than 1000（记录 >1ms 的命令） - 检查
redis-cli slowlog get 10，看是否有GET或HGETALL长期卡住 - 在代码里对
RedisTemplate.opsForValue().get()做 try-catch，并打 ERROR 日志——很多序列化问题就藏在这一步
真正卡点不在 Redis 本身，而在连接池和序列化器之间那几毫秒的博弈。调参时盯着 lettuce.pool.max-active 和 redis.timeout 的平衡，比盲目堆机器有用得多。
