php不适合高并发实时统计主干逻辑，宜作调度/聚合/兜底/展示层；高频写入易致文件锁或db锁争用、响应延迟飙升；redis分片key可缓解单点写热，真正高并发须交由kafka+flink或clickhouse。
PHP 本身不适合做高并发实时统计的主干逻辑，但可以作为调度、聚合、兜底或展示层参与其中——关键在选对技术边界，别硬扛。
为什么不能直接用 file_put_contents 或 INSERT INTO 实时累加
每秒几百次写请求下，文件锁争用或数据库行锁/连接池耗尽会迅速拖垮服务。常见现象包括：MySQL Deadlock、Warning: file_put_contents(): Permission denied（其实是锁超时）、响应延迟飙升到秒级。
- 单次
INSERT或fopen(..., 'a')是原子操作，但高频调用不等于高吞吐，IO 成为瓶颈 - PHP-FPM 进程模型决定了它无法长期持有内存状态，
static变量在不同请求间不共享 - 即使加 Redis
INCR，若所有请求都打到同一个 key，也会出现 Redis 单点写热点
用 Redis + 分片 key 做轻量级实时计数
适合 UV/PV/接口调用量等场景，核心是把“一个 key 累加”变成“多个 key 轮询累加”，再定时归并。
- 生成分片 key：比如按秒级时间戳哈希，
$key = "stat:pv:" . date('His') . ':' . ($uid % 16) - 写入用
INCR（毫秒级，无锁），不要用GETSET或事务 - 读取时用
KEYS stat:pv:20240520*（仅调试）或更安全的SCAN配合服务端聚合 - 注意：
redis-cli --scan --pattern "stat:pv:20240520*"比KEYS更友好，避免阻塞
真正高并发场景必须交给 Kafka + Flink 或 ClickHouse
PHP 只负责把原始事件推入消息队列，后续流式处理完全脱离 PHP 生命周期。
立即学习“PHP免费学习笔记（深入）”；
- PHP 中用
rdkafka扩展发消息，设置'queue.buffering.max.messages' => 100000提升吞吐 - 避免在 PHP 中解析 JSON 后再拼 SQL——直接序列化原始数组，由下游消费端做 schema 解析
- 如果必须用 PHP 做消费（极不推荐），至少用
pcntl_fork启多个常驻进程，配合declare(ticks=1)处理信号，否则容易僵死 - ClickHouse 的
ReplacingMergeTree引擎能自动去重合并，比 MySQL 的INSERT ... ON DUPLICATE KEY UPDATE更适合实时宽表更新
pcntl 和 ev 扩展不是万能解药
它们能让你在 PHP 里写常驻进程，但解决不了语言层面对高并发 IO 的根本限制：没有真正的轻量级协程，也没有内建背压控制。
-
pcntl_fork创建子进程成本高，且子进程崩溃后父进程需主动pcntl_wait回收，否则变僵尸 -
ev_timer不等于 Node.js 的 event loop，它只是封装了epoll，仍需手动管理 fd 生命周期 - 哪怕用了
swoole，也别在onReceive里做耗时 DB 查询或远程 HTTP 调用——必须投递到协程池或task进程
真正卡住多数人的，从来不是“怎么写代码”，而是没想清楚哪部分该由 PHP 做、哪部分该甩给专业组件。比如用户行为埋点，PHP 只需保证消息不丢地发进 Kafka；而分钟级热榜计算，应该由 Flink 窗口函数完成——PHP 最好连这个结果都不查，只从 Redis 缓存里 GET 一下。
