Redis Pub/Sub 无法用标准 JMeter 插件真实压测，因插件仅支持同步命令，不支持SUBSCRIBE长连接；必须自研Java Request Sampler或改用redis-benchmark、Go/Python脚本等专用方案。
直接说结论：Redis Pub/Sub 无法用标准 JMeter 插件做真实压测，因为 jp@gc - Redis Data Set 和 Redis Sampler 都只支持同步命令（如 GET、SET、LPOP），不支持阻塞式、长连接的 SUBSCRIBE 流式监听。强行配置只会卡住线程、假死或报超时错误。
为什么 Redis Pub/Sub 在 JMeter 里“看起来能配，实际跑不通”
常见错误现象包括：
-
java.net.SocketTimeoutException: Read timed out—— 因为SUBSCRIBE后连接必须保持打开，而 JMeter 默认所有取样器都走“请求-响应”单次模型，没有持续监听机制 - 线程组运行后无任何日志输出，JMeter GUI 卡在“Running”状态，CPU 占用低但线程不释放
- 即使加了
BeanShell Sampler手动调用 Jedis，也容易因未正确处理订阅回调、线程生命周期管理不当，导致内存泄漏或连接堆积
根本原因：JMeter 的核心调度模型是「同步事务驱动」，而 Pub/Sub 是「事件驱动 + 长连接 + 多消息异步分发」，二者范式冲突。
可行替代方案：用 Java Request + 自定义 Sampler 模拟真实订阅行为
如果你必须用 JMeter 框架承载压测逻辑（比如要复用现有线程组、定时器、监听器），唯一可靠路径是绕过插件，自己写 Java Request 取样器：
- 依赖
jedis-4.4.3.jar（适配 Redis 7.x 的最新稳定版）和commons-pool2-2.11.1.jar，放入JMETER_HOME/lib - 继承
AbstractJavaSamplerClient，重写runTest：在其中启动独立线程执行jedis.subscribe(new JedisPubSub(), "channel")，注意不要阻塞主线程 - 用
AtomicInteger或ConcurrentLinkedQueue统计收到的消息数，并在teardownTest中汇总上报到 JMeter 结果树 - 务必设置
setDaemon(true)订阅线程，否则 JMeter 停止时 JVM 不会退出
示例关键片段（非完整类）：
public class RedisSubscribeSampler extends AbstractJavaSamplerClient {
private final AtomicInteger msgCount = new AtomicInteger(0);
private Jedis jedis;
<pre class='brush:php;toolbar:false;'>public void setupTest(JavaSamplerContext context) {
jedis = new Jedis("127.0.0.1", 6379);
jedis.auth("yourpass");
}
public SampleResult runTest(JavaSamplerContext context) {
SampleResult result = new SampleResult();
result.sampleStart();
// 启动后台订阅线程
new Thread(() -> {
jedis.subscribe(new JedisPubSub() {
public void onMessage(String channel, String message) {
msgCount.incrementAndGet();
}
}, "test-channel");
}).start();
result.sampleEnd();
result.setSuccessful(true);
return result;
}}
更推荐的做法：脱离 JMeter，用专用工具或脚本直连压测
对 Pub/Sub 场景，JMeter 已不是最优解。生产级验证应优先考虑：
- 用
redis-benchmark -r 10000 -n 100000 -P 50 -t subscribe,publish快速验证服务端吞吐基线（注意：它只测单次命令往返，不能模拟真实业务订阅逻辑） - 写轻量 Go/Python 脚本：用
github.com/go-redis/redis/v9或redis-py启动 N 个 goroutine/thread，每个持有一个PubSub连接，按需发布+监听，自行统计延迟与丢包率 - 若需全链路埋点（比如“用户上线 → 订阅房间 → 收到系统广播”），建议把 Pub/Sub 环节抽离成独立微服务，用 JMeter 压测其 HTTP 接口，内部再转成 Redis 操作——这样既可控，又符合监控体系
真正容易被忽略的一点：Pub/Sub 的性能瓶颈往往不在 Redis 本身，而在客户端连接数、网络带宽、消息序列化开销（比如 JSON vs Protobuf）、以及消费者处理速度是否匹配发布节奏。压测前务必确认你的“订阅端逻辑”是否已优化到足够轻量——否则测出来的只是你自己代码的瓶颈。
