Webman仅是承载广告业务的HTTP框架，高性能关键在于路由轻量、画像预存Redis、RTB异步处理、频次控制用Lua原子操作；它只应做前端门卫，不承担业务重逻辑。
直接用 Webman 写个 AdController 返回 JSON 广告位，跑得再快也撑不住每秒上万次请求——问题不在框架，而在你让框架承担了不该承担的事。下面说清楚几个关键实操点。
广告请求必须走轻量级路由 + 预校验中间件
广告 SDK 发起的请求（如 /ad/bid?slot=home_banner&uid=12345）要极快响应，不能进完整 MVC 生命周期：
- 路由定义必须用
Route::get('/ad/bid', [AdBidController::class, 'handle'])，禁用任何全局中间件（如 session、auth） - 在
AdBidController@handle开头就做三件事：校验slot是否白名单、uid是否合法格式、timestamp是否在 30 秒内（防重放） - 不要在控制器里查数据库或调远程 API——这些必须异步化或前置缓存
- 错误直接返回
400 Bad Request或403 Forbidden，不抛异常、不写日志（高并发下日志 I/O 是瓶颈）
用户画像和定向策略必须脱离 Webman 主进程
每次广告请求都要查用户兴趣标签、地域、设备、历史点击率？那会把 Webman worker 卡死。正确做法是：
- 用户画像数据预计算并写入 Redis 的
user:12345hash 结构，字段如interests、city、os、ctr_7d - Webman 中用
$redis->hGetAll('user:'.$uid)读取，单次O(1)，不走网络延迟 - 定向规则（如“游戏用户+安卓+深圳”）用 Lua 脚本在 Redis 侧执行，避免 PHP 层 if-else 堆叠
- 绝对不要在 Webman 里连 MySQL 查用户表——哪怕加了索引，QPS 上千时连接池也会打满
RTB 出价必须用独立 Workerman 进程异步处理
Webman 的 HttpServer 无法满足 RTB 对毫秒级 bid 响应的要求（通常要求 ≤ 100ms），且 onMessage 方法根本不存在于 Webman 实例中：
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 另起一个 Workerman
TcpServer或WebSocketServer专门接收 SSP 的 bid 请求（如端口8999） - 该服务不做鉴权、不查用户画像，只做协议解析 → 触发本地内存缓存匹配（如 LRU cache of ad campaigns）→ 组装 bid response → 发回
- Webman 只负责管理广告主后台、审核素材、统计曝光/点击——这些非实时操作走常规 HTTP 流程即可
- bid 日志写入 Kafka 而非文件，避免磁盘 I/O 拖慢主服务
频次控制和去重必须靠原子操作 + 短 TTL 缓存
防止同一用户 1 小时内看到同一条广告超过 3 次，不能靠 PHP 层计数器：
- 用 Redis
INCR+EXPIRE组合：键为freq:uid:ad_id:hour，TTL 设为3600 - 先
INCR，再GET判断是否 ≤ 3，整个过程用 Lua 保证原子性 - 不要用
cache()->remember()这类封装——底层仍是多条命令，竞态下会超限 - 缓存 key 必须包含时间维度（如小时/分钟），否则凌晨自动清空会导致突增曝光
最易被忽略的一点：广告引擎的「高性能」不是指 Webman 启动多少 worker 进程，而是指从请求到达、定向匹配、出价决策到响应返回这一整条链路中，每一个环节都剔除了阻塞点和共享资源竞争。Webman 只是这条链路上最前端的门卫，别让它干调度员、会计和保安的活。
