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 整体吞吐的，从来不是“怎么发”，而是“发什么”和“谁来收”。