PHP+MySQL下临时实时通信选长轮询还是SSE？

这个说法在常规LNMP默认部署模式下完全成立，核心原因有两个：

• 传统PHP运行模式以php-fpm为例，采用请求-进程强绑定模型：每个进来的请求会独占一个worker进程，直到请求响应完成才会释放进程资源处理下一个请求。SSE是持久化长连接，用户打开页面期间连接不会主动断开，高流量场景下会瞬间占满所有php-fpmworker，直接导致普通页面请求无法响应，出现大面积502错误。
• 持久连接会连带占用数据库资源：如果SSE请求逻辑里持有MySQL连接不释放，很快会打满MySQL的最大连接数，拖垮整个数据库服务。
  只有使用Swoole/Workerman这类常驻内存的PHP服务模式时，SSE才能稳定承载高流量，但绝大多数普通PHP站点默认都不是这类部署架构。

直接选择已经在线上跑通验证的长轮询方案，不要选用SSE，无论从上线成本还是服务器负载角度，长轮询都是更稳妥、更不容易过载的选择：

• 服务器负载远低于SSE：长轮询不需要维持长时间不挂断的连接，一般请求进来后最多等待3-5秒，不管有没有新通知都会返回结果、释放worker和数据库连接，不会出现资源被长连接长期占满的问题。而且对于纯服务端推送通知的场景，长轮询和SSE的前端体验没有任何可感知的差别，用户完全感知不到底层实现的区别。
• 复用现有能力，无额外踩坑成本：你聊天板块已经有成熟的长轮询链路，通知功能只要在现有逻辑上扩展即可，不需要额外调整Nginx超时配置、处理SSE的反向代理缓存兼容、浏览器端异常断连重连等杂七杂八的问题——这类边缘场景的小坑非常多，仅用1-2个月的临时方案完全没必要花时间排错，上线速度快，稳定性已经经过线上流量验证。
• 优化成本极低：通知轮询接口不用每次直查MySQL，前面加一层Redis缓存存储用户未读通知标记，轮询请求先查缓存，只有命中未读标记时才查库拉取通知详情，能把数据库压力降到几乎可以忽略的水平。

不要为了这两个月的临时方案去调整现有PHP部署架构、改动服务运行模式，等后续切Socket.io的时候本来就要做连接层和业务层分离、服务常驻的架构改造，相关适配到时候统一处理即可。

内容的提问来源于stack exchange，提问作者Pascal