Redis Pub/Sub带宽=单条消息大小×订阅数×QPS×集群节点数（7.0前），SPUBLISH可降约89%；需启用shard-subscribe-enabled且禁用混用。
带宽压力不是“可能大”，而是明确可算：单条消息 × 订阅客户端数 × 每秒发布次数，再乘以集群节点数（7.0 之前）。不控制就容易爆网卡。
Redis Pub/Sub 带宽怎么算？直接套公式
Pub/Sub 是纯广播，不是共享内存。PUBLISH ch:log "msg" 发出去，每个订阅者都收到一份完整副本。
- 单客户端订阅：下行带宽 ≈
消息字节数×QPS - 100 个客户端订阅同一 channel：下行带宽 ≈
消息字节数× 100 ×QPS - Redis 6.x 集群（5 主节点），任意节点执行 PUBLISH：实际网络开销 ≈
消息字节数× 100 ×QPS× 5 × 4（每节点向其余 4 节点转发）
例如：200 字节消息、100 QPS、100 订阅者 → 单机下行已到 2 MB/s；若还在 9 节点集群里用传统 PUBLISH，内部转发流量轻松破 100 MB/s。
Redis 7.0 的 SPUBLISH 能省多少带宽？
SPUBLISH 不是“稍微优化”，是彻底改写路由逻辑：消息只发给负责该 shardkey 的那个节点，不再全集群广播。
- 旧版 PUBLISH：N 节点集群，每条消息被复制 N−1 次（跨节点转发）
-
SPUBLISH order:notify 1001 "data"：只落到哈希值为 1001 所在的 slot 对应节点，其他节点完全不参与 - 带宽下降幅度 ≈ (N−1)/N，9 节点集群就是降约 89%
但注意：SSUBSCRIBE 和 SUBSCRIBE 互不兼容，混用等于没用；且必须配 shard-subscribe-enabled yes，否则 SPUBLISH 直接报错 ERR Sharded Pub/Sub is disabled。
为什么压缩消息不能解决根本问题？
用 lz4.frame.compress() 确实能减小单条消息体积，但掩盖不了广播模型的本质缺陷。
- 压缩后消息从 200B → 80B，100 订阅者仍要发 100 份 80B，总带宽只降 60%，不是线性改善
- CPU 开销转移：服务端压缩 + 客户端解压，主线程或订阅端 CPU 可能先扛不住
- 无法缓解慢消费者问题——输出缓冲区满照样断连，压缩后反而更难定位是网络还是解压卡住
真正该优先做的，是控制订阅者数量（比如用业务 ID 分片替代全局 channel）、限制 client-output-buffer-limit pubsub，而不是靠压缩“硬撑”。
最容易被忽略的带宽放大点：连接复用和多订阅
很多人以为“一个 client 订阅多个 channel”省资源，其实正相反。
- 一个 client 执行
SUBSCRIBE ch1 ch2 ch3，Redis 内部仍为每个 channel 单独复制消息体，不是合并发送 - 用同一个
redis.Redis()实例启动 10 个pubsub对象，底层共用 socket，但每个pubsub的 listen() 循环会竞争读缓冲区，导致消息堆积、重发、甚至触发client-output-buffer-limit - 真实压测中，30 个独立连接 × 1 个 channel，比 1 个连接 × 30 个 channel 更稳、带宽更可控
频道名本身也吃带宽：user:123456789:order:status:update 比 u123:o:st 多传 30+ 字节/次，QPS 高时不容忽视。
