PHP如何用Redis PubSub实现实时通知

本文深入剖析了PHP中利用Redis Pub/Sub实现真正可用的实时通知系统时必须避开的关键陷阱：直接在Web请求中调用subscribe()会导致PHP-FPM进程阻塞、超时雪崩，任何PHP层的超时绕过手段都无效；正确解法是彻底分离关注点——由长期运行的CLI守护进程负责监听Redis频道并持久化消息到List或Stream，Web接口仅非阻塞拉取，前端通过配置得当的SSE（EventSource）高效消费，从而在保证可靠性、可扩展性和用户体验的前提下，构建出生产就绪的实时通知架构。

PHP 的 subscribe() 不能直接用在 Web 请求里

它会卡死整个 PHP 进程，不是“不工作”，而是根本不符合 Web 架构。Apache/Nginx + PHP-FPM 下，subscribe() 一执行就阻塞，worker 进程被占住，超时（通常是 30 秒）后被 PHP-FPM 强制杀掉，前端看到的就是空白或 502。

• set_time_limit(0) 和 ignore_user_abort(true) 压根没用——网关和 PHP-FPM 层的超时你绕不过去
• 浏览器发起一次 HTTP 请求，期望快速响应；而 subscribe() 是长连接、永不停止的监听，两者语义冲突
• 哪怕强行跑通，一个用户连上就吃掉一个 PHP worker，100 个并发 = 100 个卡死进程，服务直接雪崩

真正能落地的架构：Pub/Sub + CLI 守护进程 + Web 接口分层

把“监听 Redis 频道”这件事，从 Web 请求生命周期里彻底剥离出去，交给一个长期运行的 PHP CLI 脚本干。

• CLI 进程用 subscribe() 或 psubscribe() 监听 notifications 等频道，收到消息后立刻写入 Redis List（如 user:123:inbox）或 Redis Stream（更推荐，支持消费组和消息回溯）
• Web 接口（比如 /api/notifications）只做一件事：非阻塞地从 user:123:inbox 里 LRANGE 或从 Stream 里 XREAD 拉取新消息，然后返回 JSON
• 前端用 EventSource（SSE）轮询这个接口，比 AJAX 长轮询省资源，浏览器原生支持自动重连

为什么别硬刚 publish() + subscribe() 一把梭

Pub/Sub 本身是“发完即焚”模型，没有持久性、无 ACK、不保证送达。它适合广播类通知（比如系统公告），但不适合用户私有消息（比如私信、订单状态变更）。

• 用户 A 订阅了 user:123 频道，但中途断网 5 分钟——这 5 分钟所有发到该频道的消息全丢，Redis 不存
• 频道名必须提前约定好，无法动态生成（比如按用户 ID + 设备 ID 组合），否则订阅端不知道订啥
• 如果用模式订阅（psubscribe('user:*')），所有匹配频道的消息都会推给同一个回调，你得自己 parse $channel 字符串来区分接收者，容易出错且难调试

用 SSE 接 Web 层时，ob_flush() 和 flush() 不是万能钥匙

它们只是告诉 PHP 把输出缓冲区内容推给 Web 服务器，但 Nginx/Apache 可能还自带缓冲，甚至加了 gzip 压缩，导致消息卡住不下发。

• 务必在 Nginx 配置里关掉代理缓冲：proxy_buffering off;，并设置 proxy_cache off;
• PHP 脚本开头加：header('Content-Type: text/event-stream');、header('Cache-Control: no-cache');、header('X-Accel-Buffering: no');（针对 Nginx）
• 每次推送消息后，记得输出换行+双换行：echo "data: ".json_encode($msg)."\n\n";，否则浏览器收不到完整事件

实际跑通的关键不在“怎么写 publish”，而在于接受“Web 和实时通信天然是两套体系”——得用进程分离、协议分层、存储兜底的方式把它们粘牢。否则越调越怀疑人生。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《PHP如何用Redis PubSub实现实时通知》文章吧，也可关注golang学习网公众号了解相关技术文章。