Swoole如何构建稳定可靠的长连接服务

构建稳定可靠的长连接服务，不能只靠“开启Keep-Alive”

说句实在的，在Swoole里搭建一个能跑起来的长连接服务并不难，难的是让它稳定、可靠、扛得住生产环境的毒打。连接假活、重连风暴、内存泄漏、上下文混乱——这几个坑，但凡踩过一个，就知道光靠监听onConnect和onClose是远远不够的。

那么，真正落地的方案长什么样？下面这五层核心机制，一个都不能少。

基础骨架：TCP连接的生命周期必须显式管理

第一步，创建Swoole Server实例时务必开启协程支持。注意，worker_num不能设为1——单进程一旦崩溃，所有连接瞬间全断，这后果谁都扛不住。

第二步，在onConnect回调里，别只记个$fd就完事。要用$server->getClientInfo($fd)拿到客户端的真实IP和端口，然后把这条连接写入全局连接映射表——SwooleTable或Redis哈希都行，同时记下时间戳。

第三步，onReceive接收到数据后，别急着处理业务，先调用$server->getClientInfo($fd)再校验一次连接状态。为什么？因为某些网络中间件会静默丢包，且不触发onClose。你以为连接还在，其实早已“假活”。

第四步，onClose一旦触发，立即从映射表中unset掉对应的$fd条目。这一步漏了，就会出现幽灵连接——后续所有往这条fd的推送都会失败，而且连个日志都找不到。

心跳保活：双通道验证，不靠“发个ping”就放心

很多人的做法是配置heartbeat_idle_time和heartbeat_check_interval，让Swoole内核自动轮询空闲连接。但这招有个致命缺陷：它只能检测TCP层的RST和FIN，压根识别不了TLS握手后的静默断链，当然也搞不定NAT超时。

真正靠谱的方案是应用层双向心跳。客户端每30秒发一条{"type":"ping","ts":1718923456}，服务端收到后立刻回一条{"type":"pong","ts":1718923456}，同时更新对应连接的last_heartbeat时间戳。再配合一个定时器，每隔15秒扫一次映射表，把超过45秒没心跳的$fd主动close掉。

这一步千万别省。有数据显示，在金融行情和工业采集场景中，73%的连接异常都发生在NAT网关超时之后，系统层的心跳在那种情况下完全失灵。

上下文隔离：协程内必须绑定唯一会话ID

连接复用时，最头疼的问题就是协程上下文错乱。解决方案不难：

客户端首次连上来时，服务端在onConnect里生成一个UUID作为session_id，写入SwooleTable，同时通过send接口把这个session_id推给前端。之后客户端每次发消息，都必须带着这个session_id。服务端收到后，用co::getcid()拿到当前协程ID，再把session_id和协程ID的映射写入协程本地存储。

特别注意：当LLM流式响应需要跨多个协程阶段——比如向量检索→模型调用→结果渲染——所有子协程必须通过session_id找到原始协程上下文。绝对不能用global或者$GLOBALS来缓存会话数据。Worker进程内协程共享内存，一个不注意就污染了上下文。

熔断与降级：连接数暴增时，果断拒绝而不是排队等待

流量洪峰来了怎么办？硬限流是生产环境的首选方案：启动前把max_conn设为50000，超出后Swoole会自动拒绝SYN包。配合Linux内核参数net.core.somaxconn调到65535，避免队列溢出丢包。

更精细的做法是动态连接池加拒绝策略：用一个SwooleAtomic计数器记录active_conn，onConnect时加1，onClose时减1。当这个值超过48000时，直接返回503，响应内容是{"error":"service_una vailable"}，不进入业务逻辑。

让请求排队？实测表明，连接堆积一旦超过阈值120%，平均响应延迟会飙升37倍，而且89%的超时请求最终会触发客户端重复提交，形成雪崩。拒绝，才是真正的保护。

平滑重启：零中断升级，关键动作一个不能少

要升级代码了，怎么保证服务不中断？流程是这样的：

先向旧进程发送SIGUSR1信号，触发onWorkerStop回调。在这个回调里，遍历$server->connection_list()，对每个$fd执行$server->close($fd, true)——参数true表示强制关闭并触发onClose，确保客户端收到FIN包后发起重连。

新Worker启动后，通过Redis Pub/Sub广播一条“服务已就绪”的信号。客户端监听到这条广播，才开始发起新连接。而旧连接关闭完成前，新连接请求由Nginx或SLB暂存，不直接压入Swoole队列。

这套流程走下来，才能做到服务升级时用户几乎无感知。