redis-benchmark 不支持压测 publish/subscribe，因其采用请求-响应模型，无法维持 subscribe 长连接与并发收消息；实际执行时 subscribe 被静默跳过或报错，仅 publish 可单次发送后断连。
redis-benchmark 本身不支持直接压测 PUBLISH/SUBSCRIBE，这是它最常被忽略的硬限制——所有文档里写的“支持全命令压测”，唯独 PUB/SUB 是个例外。
为什么 redis-benchmark 无法测试 PUB/SUB
根本原因是 redis-benchmark 的设计模型是「请求-响应」式：每个客户端发一个命令，等一个回复，再发下一个。而 SUBSCRIBE 是长连接、无返回、持续接收消息的模式，redis-benchmark 的同步执行逻辑无法维持订阅状态，也无法模拟多 subscriber 同时收消息的并发行为。
- 执行
redis-benchmark -t publish,subscribe实际只会跑PUBLISH（且是单次发送后断连），SUBSCRIBE命令会被静默跳过或报错ERR only (P)SUBSCRIBE / (P)UNSUBSCRIBE / PING / QUIT allowed in this context - 即使强行传入
subscribe channel1，工具也会在建立连接后立即退出，无法保持订阅态 - 没有内置机制处理消息广播、客户端分流、消息积压、超时重连等真实 pub/sub 场景要素
替代方案：用 redis-cli + shell 脚本做轻量级 pub/sub 压测
不需要引入 JMeter 或专用工具，用系统自带的 redis-cli 就能快速验证基础吞吐能力。关键在于拆开压测 publisher 和 subscriber 两端，分别控制并发和节奏：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 启动 N 个后台
redis-cli --csv subscribe channel1进程，用nohup或screen持续监听（注意：每个redis-cli只能订阅一个 channel，多个 channel 需多个进程） - 用
for循环 +redis-cli publish控制发布速率，例如：for i in $(seq 1 10000); do redis-cli publish channel1 "msg_$i" > /dev/null; done - 观察
redis-cli info replication中的pubsub_channels和pubsub_patterns是否匹配预期数量 - 检查
redis-cli info clients的connected_clients和client_longest_output_list，后者持续增长说明 subscriber 处理不过来，有消息堆积
真实场景必须关注的三个隐藏瓶颈
Pub/Sub 不是“发得快就撑得住”，很多问题在简单压测中根本暴露不出来：
-
client-output-buffer-limit pubsub配置默认是32mb 8mb 60，一旦 subscriber 消费慢，buffer 溢出会强制断连，但redis-benchmark完全绕不开这个机制 - 单个 Redis 实例的 pub/sub 是单线程广播，1000 个 subscriber 并不比 10 个 subscriber 多占 CPU，但网络带宽和内核 socket 缓冲区可能先打满
- 如果用 pattern subscribe（
PSUBSCRIBE），匹配开销随 pattern 数量线性上升，而redis-benchmark根本不提供 pattern 压测能力
真正要测 pub/sub 极限，必须放弃 redis-benchmark，改用能维持长连接、可定制消费延迟、能统计丢包率的工具（比如自研 Python 脚本 + redis-py 的 PubSub 类），否则你看到的只是“能发出去”，不是“能稳稳收下来”。
