【干货整理】Swoole 中的协程排队与限流面试题-Swoole-PHP中文网

swoole面试中协程排队与限流考查的是onrequest毫秒级入口内并发控制、状态同步、维度隔离三者协同能力；channel因协程级隔离且多worker不共享而无法用于跨请求排队，须用swoole\table+atomic实现单机限流，redis全局限流必须用eval脚本保障原子性并设熔断降级。

【干货整理】swoole 中的协程排队与限流面试题

协程排队和限流在 Swoole 面试里，从来不是考你能不能手写一个队列类，而是看你能不能在 onRequest 这个毫秒级入口里，把并发控制、状态同步、维度隔离三件事同时做对——漏掉任意一环，线上就可能被压垮。

为什么用 `Swoole\Coroutine\Channel` 做排队会失效

很多人第一反应是“用 Channel 控制并发数”，但 Channel 是协程级的，每个请求进来都 new 一个新 Channel，根本起不到排队作用；更危险的是，在多 Worker 进程下，每个进程都有自己的 Channel 实例，完全不共享，限流阈值直接乘以 Worker 数。

Channel 适合协程间协作（比如生产者-消费者模型），不适合跨请求排队
真正要排队，得用进程间共享结构：Swoole\Table 存等待队列长度 + Swoole\Atomic 控制入队原子性
若必须用 Channel，只能放在全局变量里（如 $server->taskworker 中预创建），但需配合超时清理，否则 Channel 积压导致内存泄漏

`Swoole\Table` 实现单机限流的三个硬约束

Table 是单机限流最常用方案，但它不是“开了就能用”，有三个运行时硬约束必须手动满足：

Swoole 6.1.1

Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。

下载

Table 必须在 WorkerStart 回调中创建，不能在 onRequest 里动态 new —— 否则每次请求都新建，内存爆炸
key 设计必须包含限流维度，例如 "limit:ip:".$request->header['x-real-ip']，否则所有 IP 共用一个计数器
incr 操作后必须立刻判断返回值是否超阈值，不能先 incr 再 get —— 因为 incr 本身是原子的，get 会多一次查表开销且破坏原子语义

Redis 全局限流为什么不能只用 `INCR` + `EXPIRE`

两步操作在高并发下必然出现竞态：INCR 成功但 EXPIRE 失败，导致 key 永久存在；或者多个请求同时 INCR 后都去 EXPIRE，浪费性能。

必须用 EVAL 脚本封装原子逻辑，例如：redis.call("INCR", KEYS[1]) if tonumber(redis.call("GET", KEYS[1])) == 1 then redis.call("EXPIRE", KEYS[1], ARGV[1]) end return redis.call("GET", KEYS[1])
脚本中 KEYS[1] 必须带完整限流维度（如 "rate:uid:1001:/api/order"），否则不同用户或接口会互相覆盖
别忽略 Redis RT：单次 EVAL 在万级 QPS 下可能拖慢整个 onRequest，建议加熔断（如连续 5 次 >50ms 就降级走本地 Table）