publish 不支持 pipeline 批量执行，因其服务端采用即时广播机制，每条命令独立触发完整推送流程；提升吞吐需在业务层聚合消息后单次发送，并控制大小、频率与订阅端解析开销。
PUBLISH 不支持 Pipeline 批量执行，这是 Redis 协议层的硬性限制，强行用 pipeline 包裹多个 PUBLISH 命令不会提升 QPS，反而可能引入误导和额外开销。
PUBLISH 为什么不能走 Pipeline
- Redis 服务端对
PUBLISH的处理是“即时广播”：收到一条就立即遍历订阅者列表、逐个推送，不缓存、不排队、不合并 -
pipeline只是客户端把多条命令打包发过去，但服务端仍按顺序逐条解析并执行每个PUBLISH，每条都触发一次完整广播流程 - 网络往返（RTT）没减少：你发了 10 条
PUBLISH，Redis 还是返回 10 条响应，不是 1 条聚合响应 - 订阅端会收到 10 次独立回调，无法感知“这批消息本是一组”，不利于消费端做批量处理或限流
业务层聚合才是唯一可行的批量方案
想降低发布频率、提升吞吐，必须在应用代码里做消息聚合，再调用一次 PUBLISH 发送结构化数据：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 把原本要发 50 次的
PUBLISH channel1 "msg_a"、PUBLISH channel1 "msg_b"… 合成一个 JSON 数组：PUBLISH channel1 '["msg_a","msg_b",...]' - 设置合理触发条件，例如：
- 时间窗口：100ms 内累积的消息统一发出
- 数量阈值：满 20 条就 flush
- 大小上限：序列化后不超过 1MB，避免网络分包或 Redis 内存压力
- Golang 中可用
time.Ticker+sync.Mutex或chan实现缓冲；Python 可用threading.Timer或异步任务（如asyncio.create_task延迟提交）
订阅端反序列化与处理成本常被低估
聚合后性能瓶颈容易从网络/Redis 转移到消费端：
-
json.Unmarshal解析大数组比单次小字符串慢数倍，尤其当消息体含嵌套结构时 - 若订阅端对每条子消息都起 goroutine 或新线程处理，可能触发大量调度和 GC
- 更稳妥的做法是：
- 只聚合轻量标识（如
["order_id_123", "order_id_456"]），具体数据由订阅方按需查 DB 或缓存 - 控制单次 publish 总大小，避免超过 Redis 默认协议限制（通常 512MB，但实际建议压到 1–2MB 以内）
- 在订阅逻辑里加简单长度校验，防止恶意或异常超长 payload 导致进程卡死
- 只聚合轻量标识（如
真正影响 PubSub 整体吞吐的，从来不是“怎么发”，而是“发什么”和“谁来收”。
