Redis PUB/SUB不能削峰，因其无缓冲、不落盘、同步阻塞且断连丢消息；需用STREAM或LIST缓冲+PUB/SUB广播实现削峰与实时通知分离。
Redis 的 PUB/SUB 本身不能削峰，它只是个“喊一嗓子就散场”的广播系统；想靠它扛住流量高峰再通知下游，等于让快递员边跑边扔包裹——没人接就没了。真要削峰+实时通知，得用 STREAM 或 LIST 做缓冲，再用 PUB/SUB 作轻量广播。
为什么不能直接用 PUBLISH 扛突发流量
PUBLISH 是同步阻塞操作：Redis 主线程会挨个往每个订阅者连接写数据。一旦有 1000 个订阅者，其中某个网络延迟高或处理慢，整个 PUBLISH 调用就会卡住，上游业务线程被拖死。实测向 5000 订阅者发一次消息，延迟可能突破 200ms，且无重试、无 ACK、断连即丢。
- 它不落盘、不排队、不缓冲，消息生命周期仅限于“当前在线的订阅者”
- 高频
PUBLISH会迅速耗尽maxclients（默认 10000，但活跃订阅连接实际撑不过 2000） - PHP 中反复调用
subscribe()或 Java 客户端未复用连接，极易触发ERR max number of clients reached
用 STREAM 削峰 + PUBLISH 广播的组合方案
核心思路：业务写入 STREAM（持久、可回溯、支持消费者组），由后台 worker 异步消费并触发 PUBLISH 通知——把“重活”和“轻通知”彻底拆开。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 订单创建后执行：
XADD orders * order_id 123 status created - worker 启动时建组：
XGROUP CREATE orders wg1 $ MKSTREAM（注意必须带MKSTREAM，否则组无法读历史） - worker 拉取并 ACK：
XREADGROUP GROUP wg1 c1 COUNT 10 STREAMS orders > - 处理完业务逻辑后，只发一条轻量广播：
PUBLISH notify:order_created {"order_id":"123"}
这样既保留了 STREAM 的削峰填谷能力（积压消息可查、可重放、可分摊负载），又利用 PUBLISH 的低开销实现秒级通知，避免把通知逻辑耦合进核心链路。
PHP 和 Java 客户端的实际避坑点
PHP 的 subscribe() 回调函数里，只能用 SUBSCRIBE/PSUBSCRIBE/UNSUBSCRIBE/PUNSUBSCRIBE 这四条命令——你不能在回调里调 rPop、发 HTTP 请求或连数据库，否则会报错或阻塞整个连接。正确做法是把具体业务逻辑交给另一个常驻进程处理（比如用 php artisan queue:work 拉取 phone 队列发短信）。
- Java 用 Lettuce 时，默认每个
MessageListener启一个新连接，务必配置ClientResources.create()共享连接池 - 不要在循环里反复
SUBSCRIBE，订阅一次即可；重复执行会返回ERR already subscribed to this channel - 需要模式匹配时，用
PSUBSCRIBE alert.*，别拆成SUBSCRIBE alert.error alert.warn alert.info—— 每个频道都占一个连接
真正难的不是写通 PUBLISH 和 SUBSCRIBE，而是想清楚哪部分必须可靠（用 STREAM）、哪部分可以尽力而为（用 PUB/SUB），以及怎么让两者不互相拖垮。很多线上事故，都是因为把“通知”当成“交付”，结果流量一来，通知没发出去，订单也丢了。
