Webman无法直接支撑千万级广告点击追踪，因其单机极限仅5–15万RPS，必须依赖Nginx+Lua前置频控、Kafka缓冲削峰、ClickHouse批量归因的分层架构。
Webman 本身不是为千万级并发设计的框架，直接用它扛住千万级广告点击追踪，在默认配置和常规架构下会立刻崩——这不是调优问题，是模型瓶颈。
Webman 基于 Swoole，单机极限通常在 5–15 万 RPS（取决于硬件、协议、业务逻辑复杂度），而“千万级并发”意味着每秒数百万次点击请求，必须靠架构分层消化，不是靠改 config.php 或调大 worker_num 就能解决。
为什么不能只靠 Webman 跑满千万 QPS
Webman 是同步协程模型，每个请求仍需执行 PHP 代码路径：路由匹配、中间件、控制器、DB/Redis 调用。哪怕逻辑精简到只写 Redis incr，单机也难超 30 万 QPS（实测 i9-14900K + 64GB + Redis Cluster 直连）。更现实的是：广告点击链路必须做去重、频控、归因、落库，这些操作天然带延迟和锁竞争。
-
worker_num设太高反而导致上下文切换开销剧增，Swoole 会主动限流或报ERRNO 1002: Too many connections - PHP 层做
file_put_contents或直连 MySQL 写点击日志？磁盘 I/O 和连接池瞬间打满 - 所有节点共享同一个 Redis 实例？
INCR在热点 key 下会成为线性瓶颈，CPU 100% 卡在 single-thread event loop
必须剥离核心路径：用 Nginx + Lua 做前置透传
真正扛住流量洪峰的不是 PHP，是 Nginx 的 lua-resty-limit-traffic 和 balancer_by_lua*。广告点击 URL（如 /clk?id=xxx&pid=yyy）应该由 Nginx 直接解析参数、做毫秒级频控、记录到共享内存（shdict），再异步发往后端队列。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 不经过 PHP-FPM 或 Webman，避免进程创建/协程调度开销
- 用
ngx.timer.at()批量 flush 到 Kafka，而非实时写 Redis - 点击 ID 用 Snowflake 或
time() . rand(1000,9999)生成，避免自增主键冲突 - Nginx 配置里禁用
access_log，改用log_by_lua异步投递
Webman 只负责消费与归因，别让它接原始请求
把 Webman 定位成「离线消费者」或「准实时归因服务」，而不是「入口网关」。它从 Kafka 拉取点击原始数据（JSON 格式），做设备指纹解析、渠道匹配、去重（布隆过滤器）、写入 ClickHouse 或 Doris。
- 用
webman/plugin-kafka插件，设置max_poll_records=500，避免单次拉取太多卡住协程 - 去重用
redis-bloom扩展，比SETNX+ TTL 更省内存，支持亿级判重 - 不要在 Webman 中调
pdo->exec()写 MySQL，ClickHouse 的INSERT INTO ... VALUES批量写入吞吐高 10 倍以上 - 归因逻辑尽量无状态，依赖外部规则引擎（如 Drools 编译后的 JSON 规则），避免 PHP 解析耗时
压测时最容易忽略的三个硬伤
很多人跑通了本地 demo 就以为 ready，但线上真实链路中，这三个点一出问题，整个系统就雪崩：
- Kafka 网络分区没配
acks=all+retries=3，丢点击不报错，只默默跳过 - Webman 的
task_worker_num设为 0，所有异步任务挤在 worker 进程里，CPU 满载后协程调度延迟飙升 - 广告主传来的
click_id含特殊字符（如空格、换行、%00），Nginx 默认不解码，Lua 里ngx.var.arg_id取到脏数据，后续全链路乱码
Webman 在这个场景里，只是整条流水线中一个可靠、可控的环节。真正的弹性来自 Nginx 的前置卸载、Kafka 的缓冲削峰、ClickHouse 的列存聚合——别让框架背锅，要让它各司其职。
