Swoole实现万级TCP长连接网关高阶教程
要在Swoole中稳定承载万级并发TCP长连接，必须避开默认配置陷阱、防范内存泄漏风险、防止事件循环阻塞，并在连接生命周期的每个环节进行精细化控制——仅靠调用SwooleServer启动是远远不够的。
确实，仅仅启动Swoole Server就想支撑万级连接远远不够。一个真正的高阶网关，必须在起步阶段就正确完成以下关键配置校准。
搭建Swoole网关：初始化前的核心配置校准
第一步：合理配置reactor_num与worker_num的比例。 Reactor线程负责网络IO，Worker进程处理业务逻辑。在万级连接场景下，如果reactor_num值太小（例如默认仅为2），单个Reactor线程需要轮询上万个fd，CPU软中断飙升，吞吐量会迅速下降。建议设置为CPU核心数的1.5～2倍，以8核机器为例，可设为12。
第二步：关闭daemonize并将task_worker_num设为0。 调试阶段必须能够实时查看日志。Task进程虽然可以异步化耗时操作，但额外的IPC开销会拖慢连接建立路径——长连接网关的onConnect和onReceive回调需要零延迟响应，严禁在此阶段开启Task Worker。
第三步：显式设置max_connection=100000并同步调整系统限制。 Swoole不会自动读取/etc/security/limits.conf，仅靠ulimit -n 65535仍可能触发“Too many open files”错误。必须在代码中硬编码连接上限，同时确保sysctl -w fs.file-max=2097152已生效。
连接管理：使用协程与连接池取代传统全局数组
传统做法是将fd存入全局$connections数组，但在万级连接下，PHP数组动态扩容会引发严重的内存碎片。更优的方案是以下两种。
方法一：基于Swoole\Coroutine\Channel构建连接注册中心
在onConnect回调中，不再将fd存入全局数组，而是向协程通道push(['fd' => $fd, 'ip' => $server->getClientInfo($fd)['remote_ip'], 'ts' => time()])。通道容量设为1024，超容时自动丢弃旧连接元数据——内存占用保持恒定，彻底避免内存碎片问题。
方法二：用Redis Sorted Set持久化连接状态
将fd作为member，score设为时间戳，执行zadd gateway:online $ts $fd写入。心跳包到达时通过zadd更新score，定时任务使用zremrangebyscore清理超时连接。这样Worker崩溃重启后，连接状态不会丢失。但需注意：必须使用Pipeline批量写入，单次zadd在万级QPS下会迅速成为Redis瓶颈。
心跳与断连检测的精准实现
第一步：在onReceive中识别心跳帧。 约定二进制协议头第1字节为0x01即心跳，收到后立即$server->send($fd, "\x02")响应，不经过任何业务逻辑层。
第二步：为每个连接启动独立心跳协程。 连接建立后立即go(function() use ($server, $fd) { while(true) { co::sleep(25); if (!@$server->exist($fd)) break; $server->send($fd, "\x01"); } });。25秒间隔留出3次重传窗口，避免因网络抖动误判断连。
第三步：在onClose中执行原子性清理。 先执行redis->zrem('gateway:online', $fd)，再unset($this->connectionPool[$fd])，最后记录日志。顺序不可颠倒——若先删本地缓存再删Redis，期间新请求可能通过Redis误判连接仍在线。
内存隔离：为每个连接分配独立协程栈
在onReceive回调开头插入Co::set(['stack_size' => 2 * 1024 * 1024]);。默认协程栈仅256KB，处理大payload或嵌套JSON解码时极易栈溢出，导致协程静默退出。2MB栈空间可覆盖99%的协议解析场景，万级连接下总内存增幅可控（10000×2MB=20GB，实际因共享代码段远低于此）。
另外，必须禁用所有global变量和静态属性存储连接上下文。每个协程必须通过context参数或闭包use传递必要数据，否则跨协程变量污染会导致连接间数据错乱——有真实案例因复用static $buffer导致A用户收到B用户的加密密钥。
压测与瓶颈定位的实操指令
使用swoole-benchmark发起真实流量：php bench.php --host=127.0.0.1 --port=9501 --concurrency=20000 --requests=1000000 --timeout=10。重点关注netstat -ant | grep :9501 | wc -l是否稳定在设定值，以及cat /proc/$(pgrep php)/status | grep VmRSS确认内存未持续增长。
当连接数卡在8000不再上升时，立即执行strace -p $(pgrep php) -e trace=epoll_wait,poll -T -t。若发现epoll_wait返回超时而非活跃fd，说明Reactor线程已满载，需增加reactor_num；若poll频繁返回0，则是Worker阻塞在同步IO，需检查是否有file_get_contents或curl_exec未改造成协程客户端。