redis pub/sub在单线程下支撑十万级并发，关键在于publish仅做内存拷贝与缓冲区追加，不执行网络发送；真正瓶颈是客户端输出缓冲区的堆积与清空效率，而非命令执行本身。

Redis 的 PUB/SUB 在单线程模型下能支撑十万级并发分发，关键不在于“它多快”，而在于它根本没在主线程里做真正的“分发”——所有订阅者的消息投递，都是同步写入客户端输出缓冲区，不涉及遍历、序列化、网络发送等耗时环节。

为什么 PUBLISH 命令本身几乎不耗时

当你执行 PUBLISH channel message，Redis 主线程只做三件事：

• 查出所有订阅了 channel 的客户端（通过内部的哈希表 pubsub_channels 或模式匹配表 pubsub_patterns）
• 对每个匹配的客户端，把消息内容（含协议头）直接追加到其 client->buf 或 client->reply 链表中
• 标记该客户端为“有数据待写出”，由后续 I/O 多路复用循环统一处理

整个过程全是内存拷贝 + 指针操作，没有系统调用、没有锁竞争、不触发网络 write()。哪怕 10 万个客户端都订阅了同一个 channel，只要它们的输出缓冲区还有空间，PUBLISH 就能在微秒级完成。

client->buf 和 client->reply 缓冲区才是吞吐瓶颈所在

真正制约 PUB/SUB 并发分发能力的，不是命令执行，而是客户端缓冲区的堆积与清空效率：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• client->buf 是固定大小的字节数组（默认 16KB），写满后自动切换到 client->reply（sds 链表）
• 如果某个订阅者消费慢（比如网络卡顿、客户端不及时读），它的缓冲区会持续增长，最终触发 client-output-buffer-limit pubsub 限制（默认 32MB/60s）
• 一旦超限，Redis 会强制关闭该连接 —— 这是保护主线程不被拖垮的核心机制
• 缓冲区清理依赖于 I/O 多路复用事件循环：只有当 socket 可写时，主线程才调用 writeToClient() 尝试发送，失败则继续挂起

为什么不能靠多线程加速 PUB/SUB 分发

即使你强行把消息分发逻辑拆到后台线程，也会立刻撞上三个硬伤：

• 主线程必须保证 PUBLISH 的原子性：要么全部客户端收到，要么一个都不发（实际做不到，但语义上要求“发即可见”）。多线程写不同 client 缓冲区会破坏这个隐含契约
• 多个线程同时修改同一 client 的 reply 链表，需要加锁或 CAS，反而引入竞争和开销，得不偿失
• 网络 write() 本身仍需主线程参与（Redis 6.0+ 的 IO 线程只负责 read 和解析，write 仍在主线程）；分发再快，卡在 socket 写不出去也没用

真实压测中容易被忽略的点

十万级 PUB/SUB 并发分发在实验室能跑通，但在生产环境常因以下原因断崖式下跌：

• 大量小消息导致频繁内存分配（sdsnewlen 调用增多），触发主线程 CPU 占用上升
• 客户端未启用 TCP_NODELAY，导致 Nagle 算法把多个小响应包合并，增大端到端延迟
• 使用 pattern subscribe（PSUBSCRIBE）且 pattern 数量多，每次 PUBLISH 都要遍历全量 pattern 表，复杂度从 O(N_subscribers) 变成 O(N_subscribers × N_patterns)
• 监控只看 redis-cli --stat 的 ops/sec，却没观察 client_longest_output_list 和 connected_clients 是否持续上涨

真正决定 PUB/SUB 承载力的，从来不是“单线程能不能干”，而是“你有没有让主线程一直忙于无效等待”。缓冲区管理、网络参数、订阅拓扑设计，比线程数重要得多。