如何避免PHP在高并发请求中的架构陷阱？

本文共计1102个文字，预计阅读时间需要5分钟。

它直接决定你这台机器最多能同时处理多少个请求，但提高了反而不是会拖慢系统。进程数翻倍，内存和CPU以及上下文切换开销不是线性增长，而是指数级上升。

常见错误是看服务器有 16G 内存就盲目设成 200，结果每个 PHP 进程平均吃掉 80MB，光 FPM 就占满 16GB，系统开始频繁 swap，响应时间从 100ms 拉到 2s+。

• 估算公式：pm.max_children ≈ 可用内存 × 0.8 ÷ 单进程平均内存（用 ps aux --sort=-%mem | head -n 10 观察真实占用）
• 必须配 pm.max_requests = 500，否则长期运行的子进程容易因未释放资源导致内存缓慢泄漏
• 禁用 pm = ondemand：启动慢、突发流量下子进程创建不及时，极易触发 502/504

Redis List 做队列时别用 GET/SET 模拟

用 SET key value EX 30 + 定时轮询“查有没有新任务”，本质是伪队列：CPU 白耗、并发冲突、延迟不可控，QPS 上千就撑不住。

真正轻量可靠的方案是 LPUSH + BRPOP 组合，消费端阻塞等待，无任务时不空转，延迟低且无竞态。