必须从进程模型、协程调度、io处理和资源复用四层面同步优化：worker_num设为cpu核心数1～2倍，耗时操作交task_worker处理，全局启用协程并替换所有阻塞io调用，构建mysql/redis连接池，调优网络参数并实施并发熔断策略。
要让Swoole服务端在高流量下不卡顿、不超时、不丢连接，必须从进程模型、协程调度、IO处理和资源复用四个层面同步优化，而不是只调大worker_num参数。
合理配置进程与任务工作模型
启动服务前先明确业务类型：纯计算型任务走task进程，IO密集型任务优先用协程，混合型任务需组合使用。
第一步：设置worker_num为CPU核心数的1～2倍，例如4核服务器设为6；【worker_num超过CPU核心数太多会导致上下文切换开销剧增】
第二步：对耗时超50ms的逻辑（如日志归档、邮件发送、第三方API回调）启用task_worker，数量设为worker_num的1/3～1/2；
第三步：在onTask回调中必须调用$server->finish($result)，否则客户端永远收不到响应；
第四步：禁用默认的max_request限制，改用平滑重启机制——当worker处理请求数达8000时主动退出，由master进程拉起新worker。
全面启用协程并替换阻塞调用
所有IO操作必须运行在协程环境，否则协程优势归零。
方法一：全局启用协程支持，在服务启动入口第一行写swoole_enable_coroutine(true)；
方法二：用Swoole\Coroutine\Http\Client替代curl_exec，用Swoole\Coroutine\MySQL替代mysqli_connect；
方法三：文件读写必须用Swoole\Coroutine\System::readFile()和writeFile()，原生file_get_contents会直接阻塞整个worker进程；
注意：不要在协程里调用sleep()或usleep()，改用co::sleep()，否则协程调度器无法接管控制权。
构建数据库与缓存连接池
连接池不是可选项，是高并发下的生存必需。
① 创建MySQL协程连接池：实例化Swoole\Coroutine\Pool，预分配16～32个连接，最大空闲时间设为60秒；
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
② Redis连接复用：用Swoole\Coroutine\Redis客户端，每次请求从连接池取连接，use后立即close()归还；
③ 本地热点数据缓存：用Swoole\Table创建共享内存表存储配置项、开关状态等低频变更数据，避免每次请求都查Redis；
④ 缓存穿透防护：对查询为空的key，统一回填null值并设置短过期（如30秒），防止恶意请求打穿缓存直击数据库。
优化网络层与事件循环
底层网络参数不当会让万级并发变成千级瓶颈。
将listen_socket的backlog设为65535，避免SYN队列溢出导致连接被内核丢弃；
关闭TCP延迟确认（tcp_nodelay = true），对WebSocket和HTTP长连接类服务至关重要；
启用SO_REUSEPORT选项，让多个worker进程能同时绑定同一端口，消除惊群效应；
设置open_tcp_nodelay = true + open_http2 = true（如需HTTP/2支持），这两项配置必须同时生效才起作用。
精准控制并发与熔断策略
无节制的并发等于自我拒绝服务。
方法一：在onRequest回调开头加入计数器判断，当前活跃协程数超过300时直接返回503，避免雪崩；
方法二：对下游依赖接口（如支付网关、短信平台）设置协程超时，go(function () { co::sleep(0.8); $client->send(); }) → 超过800ms强制中断；
方法三：使用Swoole\Atomic做全局请求数统计，每秒请求数突破阈值时自动降级非核心功能（如关闭用户行为埋点）；
方法四：配置max_conn_per_ip = 100，防止单IP恶意建连耗尽fd资源。
