Redis Pub/Sub吞吐瓶颈在内存带宽、网络I/O和客户端处理能力，而非Redis CPU；单机超5–10万QPS且订阅者>100时会出现延迟抖动和丢消息。
Redis Pub/Sub 的吞吐量瓶颈到底在哪儿
Redis Pub/Sub 本身不落盘、不持久化、不保证送达，吞吐量上限主要卡在内存带宽、网络 I/O 和客户端处理能力上，而不是 Redis 主进程的 CPU。单机实测中，当发布端 PUBLISH 频率超过 5–10 万 QPS，且订阅者数量 > 100 时，延迟抖动和消息丢弃会明显上升——这不是配置问题，是架构层面的信号溢出。
怎么用 redis-benchmark 做有效压测
默认的 redis-benchmark -P 100 -r 1000000 -n 1000000 -t publish,subscribe 会创建大量独立连接，结果严重失真。真实场景里，订阅者复用连接、批量消费，所以必须模拟“固定连接数 + 持续流式发布”：
- 先用
redis-cli --csv SUBSCRIBE channel1手动确认订阅通道通路正常 - 压测命令改用：
redis-benchmark -c 50 -n 500000 -t publish -r 1000000 -d 64 -P 1（单 pipeline，50 连接，模拟轻量消息） - 同时开另一个终端跑
redis-cli --csv PSUBSCRIBE "channel*"观察实际接收速率，别只信 benchmark 输出的“requests per second” - 注意：benchmark 不测订阅端消费延迟，它只算发出去的时间，真正瓶颈常在客户端
READ调用是否及时
PUBLISH 吞吐受哪些参数影响
Redis 本身没有“Pub/Sub 专用调优参数”，但以下配置间接决定上限：
-
tcp-keepalive设为 60 可减少空闲连接被中间设备断开，避免重连风暴影响吞吐稳定性 -
maxmemory和maxmemory-policy对 Pub/Sub 无效（消息不进内存数据库），但若混用其他数据结构，OOM 会导致整个实例阻塞，连带 pub/sub 卡住 -
client-output-buffer-limit pubsub是关键！默认是32mb 8mb 60，意思是：单个订阅者输出缓冲区超 32MB 或连续 60 秒超 8MB 就断连。大消息或慢消费者极易触发，必须按预期消息体积和消费速度调整，比如：client-output-buffer-limit pubsub 256mb 64mb 300
为什么加机器不一定提升总吞吐
Pub/Sub 是广播模型，不是分片模型。加 Redis 实例不能自动分流 channel，除非业务层做 channel 前缀分片（如 order.001, order.002）并让客户端自己路由到对应实例。否则：
- 所有实例都得收到全部
PUBLISH，只是没人订阅就丢弃——白耗带宽和 CPU - 跨实例无法实现全局
PUBSUB NUMSUB统计，运维排查困难 - 客户端要维护多个连接池，异常时重连逻辑更复杂，反而降低有效吞吐
真正扩容路径只有两条：垂直（升级网卡/内存/内核 socket 参数）或逻辑分片（业务侧拆 channel + 多实例）。没做分片前，堆机器只是把瓶颈从 Redis 转移到网络交换机或客户端。
