如何使用Webman构建高性能的任务抢占系统-php教程-PHP中文网

webman本身不支持任务抢占，需通过worker进程+redis zset+协程信号量组合实现；http接口仅负责入队，抢占逻辑由常驻进程异步扫描zset并用lua脚本原子执行。

如何使用webman构建高性能的任务抢占系统

Webman 本身不支持“任务抢占”——它没有内置的抢占式调度器、优先级队列或实时中断机制；所谓“高性能任务抢占系统”，本质是用 Webman 做控制面（接收任务、校验、入队、状态反馈），把抢占逻辑下沉到 Worker 进程 + Redis ZSET + 协程信号量组合实现。

为什么不能直接在 Webman 路由里做抢占判断

常见错误现象：max_execution_time 超时、502 Bad Gateway、Redis WATCH 失败后死循环重试导致 CPU 100%。根本原因是 Webman 的 HTTP 请求生命周期短（默认 30 秒）、无状态、且每个请求独占一个协程上下文，无法维持长期锁或监听任务状态变化。

所有抢占决策必须异步化：HTTP 接口只负责写入抢占请求（如 task_id、priority、timeout_at），不执行实际抢占
抢占动作必须由常驻 Worker 进程驱动：用 Timer::tick() 每 100ms 扫描 Redis ZSET 中的高优先级待抢占任务
禁止在控制器中调用 Redis::zRangeByScore() 后再 Redis::del() —— 这不是原子操作，会引发竞态；必须用 Lua 脚本封装抢占逻辑

用 Redis ZSET 实现带优先级的任务队列

ZSET 是唯一能同时满足“按分值排序 + 原子性 pop + 支持范围查询”的数据结构，比 List + Sorted Set 组合更可靠，也比纯内存数组可扩展。

Webman 2.2.0

Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。

下载

任务入队用 ZADD tasks_queue $priority $task_json，其中 $priority 是数值型分值（越小越优先），例如紧急任务设为 0，普通任务设为 1000
抢占扫描用 ZRANGEBYSCORE tasks_queue -inf ($now LIMIT 0 1 获取当前最高优待处理任务（注意括号表示开区间，避免重复抢到同一任务）

抢占执行用 Lua 脚本保证原子性：

local task = redis.call('ZRANGEBYSCORE', KEYS[1], '-inf', ARGV[1], 'LIMIT', 0, 1)
if #task == 0 then return nil end
redis.call('ZREM', KEYS[1], task[1])
return task[1]

不要用 BRPOPLPUSH：它不支持按分值弹出，也无法表达“超时自动降级”语义

Worker 进程内如何安全抢占并防止饿死

单个 Worker 进程若同时处理多个抢占任务，容易因长耗时任务阻塞事件循环，导致低优先级任务永远得不到执行。

每个抢占任务必须运行在独立协程中：go(function () use ($task) { ... });，避免串行阻塞
设置硬性超时：用 Co::sleep($timeout_ms) 替代 sleep()，并在关键 IO 操作（如 DB 查询、HTTP 调用）显式加 timeout 参数
防饿死策略：每轮扫描最多执行 3 个高优任务，然后 yield 一次（Co::yield()），让其他协程有机会运行
记录抢占日志必须异步：不要直接 file_put_contents()，改用 Log::channel('async')->info(...) 或发到 Redis Stream

抢占失败后的降级与可观测性怎么做

抢占不是 100% 成功的，网络抖动、Redis 主从延迟、Worker 进程重启都可能导致任务丢失或重复抢占。

每次抢占前先检查任务状态：用 GET task:status:$task_id 确认是否已被其他 Worker 锁定，避免无效竞争
抢占失败后写入降级队列：LPUSH task_fallback_queue $task_json，由低频 Worker（如每 5 分钟一轮）兜底消费
暴露抢占指标：通过 /metrics 接口返回 task_preempt_total{status="success"}、task_preempt_duration_seconds 等 Prometheus 格式数据
关键字段必须打标：每个任务 JSON 中强制包含 trace_id 和 source，便于在 ELK 中关联抢占日志与业务链路