Redis 6.0+ 的 Pub/Sub 不阻塞主线程，因消息分发改由独立客户端上下文异步处理；而 5.x 及更早版本中 publish 同步遍历订阅者，网络慢或缓冲区满时会阻塞主线程。
Redis 6.0+ 的 Pub/Sub 不会阻塞主线程，但旧版本有风险
Redis 6.0 引入了多线程 I/O（由 io-threads 配置控制），但更关键的是：从 6.0 开始，pubsub 消息的分发逻辑已从主线程事件循环中剥离，改由单独的客户端连接上下文异步处理。这意味着即使大量订阅者同时接收消息，redisServer.el 主事件循环也不会被长耗时的 sendReply 卡住。
而 Redis 5.x 及更早版本中，publish 命令执行后，会**同步遍历所有匹配频道的订阅客户端**，逐个调用 addReply 写入响应缓冲区。若某个订阅客户端网络慢、缓冲区满或处于 CLIENT PAUSE 状态，整个 PUBLISH 调用就会阻塞主线程——直接影响所有其他命令的响应延迟。
- Redis PUBLISH 阻塞 → 全局延迟升高
- Redis ≥ 6.0：每个订阅客户端的写入在各自连接的输出缓冲区阶段异步完成，主线程只做轻量广播调度
- 注意：
io-threads默认为 1，它不加速 Pub/Sub 分发，真正起作用的是内部连接状态机重构
如何验证当前 Redis 版本是否受 Pub/Sub 阻塞影响
最直接的方式是模拟一个“卡住”的订阅端，观察 PUBLISH 延迟是否飙升：
# 终端 A：启动一个订阅者，并手动暂停其读取（模拟网络卡顿）
redis-cli SUBSCRIBE test-channel
# 然后按 Ctrl+Z 挂起该进程（或用 nc 手动建连接后不 recv）
<h1>终端 B：反复 publish 并测延迟</h1><p>for i in {1..10}; do time redis-cli PUBLISH test-channel "msg$i"; done</p><div class="aritcle_card flexRow">
<div class="artcardd flexRow">
<a class="aritcle_card_img" href="/xiazai/skill3464" title="Redis Skill - 高性能缓存管理"><img
src="https://img.php.cn/upload/skill/000/000/081/178960683454849.jpg" alt="Redis Skill - 高性能缓存管理" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a href="/xiazai/skill3464" title="Redis Skill - 高性能缓存管理">Redis Skill - 高性能缓存管理</a>
<p>Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。</p>
</div>
<a href="/xiazai/skill3464" title="Redis Skill - 高性能缓存管理" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a>
</div>
</div>在 Redis 5.0 中，第二次及之后的 PUBLISH 很可能延迟跳到几百毫秒甚至秒级；6.2+ 则基本稳定在 0.1–0.3ms（本地环回）。也可以查日志：CONFIG GET latency-monitor-threshold 配合 LATENCY LATEST，看是否有 command 类型的尖峰，且发生在 PUBLISH 后。
- 别依赖
INFO clients里的connected_clients数——它不反映实际写入压力 -
INFO stats中的total_commands_processed若在PUBLISH后明显滞涨，说明主线程被卡住 - Redis 6.0+ 仍可能因
client-output-buffer-limit pubsub触发强制断连，但这属于保护机制，不等于阻塞
client-output-buffer-limit pubsub 是关键防线，不是可忽略的默认值
这个配置决定了每个 Pub/Sub 客户端输出缓冲区的硬限制，一旦超过就会被服务器主动断开连接。它的默认值是 32mb 8mb 60（软限制 32MB、硬限制 8MB、超时 60 秒），但很多人没意识到：这个“硬限制”触发时，Redis 并不会等缓冲区清空，而是立即 freeClient ——对发布方完全透明，但对订阅方就是意外掉线。
- 如果你的订阅端消费慢（比如 Python 脚本每秒只处理 10 条，但上游每秒发 1000 条），很快就会 hit limit
- 调大数值不能解决根本问题，反而掩盖背压——应优先优化消费者吞吐或加中间队列（如 Kafka）
- 可通过
CLIENT LIST TYPE pubsub查看各客户端当前omem值，实时监控缓冲区水位
Pub/Sub 不适合高可靠、低丢消息场景，别把它当消息队列用
Redis Pub/Sub 的设计目标是轻量广播，不是持久化消息传递。所有消息都只存在于内存中，没有 ACK、没有重试、没有 offset 管理。一旦订阅者断开（包括被 client-output-buffer-limit 断开），它错过的所有消息永久丢失。
- 用
SUBSCRIBE后立刻CLIENT SETNAME无法恢复断线前状态——名字只是标识，不绑定历史 -
PSUBSCRIBE的模式匹配在服务端完成，高频 pattern 可能增加 CPU 开销（尤其 5.x），6.0+ 优化了 pattern tree 查询路径 - 如果业务要求“至少一次”投递，必须自行实现确认 + 重发逻辑，或换用
Stream（支持XREADGROUP和ACK）
真正容易被忽略的点是：Pub/Sub 的“无状态”特性让它看起来简单，但一旦混进生产环境的可靠性链路里，故障定位会非常隐蔽——你以为是网络问题，其实是某台 Redis 因缓冲区溢出默默踢掉了关键订阅者，而日志里只有 Client closed connection due to output buffer overflow 这一行。
