要在swoole中稳定支撑万级并发tcp长连接，必须绕过默认配置陷阱、规避内存泄漏风险、避免事件循环阻塞，并在连接生命周期各环节做精细化控制——单纯调用swoole\server启动远远不够。
要在Swoole中稳定支撑万级并发TCP长连接，必须绕过默认配置陷阱、规避内存泄漏风险、避免事件循环阻塞，并在连接生命周期各环节做精细化控制——单纯调用Swoole\Server启动远远不够。
初始化服务前的关键配置校准
第一步：启用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已生效。
连接管理：用协程+连接池替代传统全局数组
方法一：基于Swoole\Coroutine\Channel构建连接注册中心
在onConnect回调中，不把fd存入全局$connections数组，而是向协程通道push(['fd'=>$fd, 'ip'=>$server->getClientInfo($fd)['remote_ip'], 'ts'=>time()])。通道容量设为1024，超容时丢弃旧连接元数据——内存占用恒定，避免PHP数组动态扩容引发的内存碎片。
方法二：用Redis Sorted Set持久化连接状态
将fd作为member，score设为时间戳，写入zadd gateway:online $ts $fd。心跳包到来时执行zadd更新score，定时任务用zremrangebyscore清理超时连接。这样Worker崩溃重启后，连接状态不丢失，【注意：必须用Pipeline批量写入，单次zadd在万级QPS下会成为Redis瓶颈】。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
心跳与断连检测的精准实现
第一步：在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未改造成协程客户端。
