如何避免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 组合，消费端阻塞等待，无任务时不空转，延迟低且无竞态。

立即学习“PHP免费学习笔记（深入）”；

• 生产端：用 $redis->lPush('queue:order', json_encode($orderData))
• 消费端：用 $redis->brPop(['queue:order'], 30)，超时自动重试，不卡死
• 失败任务别直接 DEL，先 lPush 回队列尾部，并在 payload 里加 retry_count 字段，防止死信堆积
• 单个 worker 进程建议跑完 1000 条任务后主动退出，靠 supervisord 拉起新进程，避免内存缓慢膨胀

缓存击穿不是小概率事件，互斥锁必须加在 DB 查询之前

热点 key（比如首页商品列表）过期瞬间，上百请求同时发现缓存为空，全部打到数据库，MySQL CPU 瞬间拉满——这不是假设，是上线当天就会发生的故障。

if (!$cache->get('goods:list')) { $data = $db->query(...); $cache->set(...); } 这种写法在并发下完全失效，因为多个请求几乎同时通过 get 判断，都进入查询分支。

• 加锁必须在 get 之后、query 之前：$redis->set('lock:goods:list', 1, ['nx', 'ex' => 5])，只有拿到锁的请求才查库
• 过期时间别写死：$ttl = 3600 + rand(1, 600)，让 key 失效时间分散开，防雪崩
• 空值也得缓存：$cache->set('goods:id:999', null, 60)，避免恶意或错误 ID 频繁穿透
• 别用 Memcached 的 cas() 做锁——PHP 的 Memcached::cas() 在高并发下成功率极低，Redis 的原子命令更可靠

OPcache 开启后仍要检查 realpath_cache_size

即使开了 OPcache，如果文件路径解析频繁（比如大量 require_once 或自动加载），realpath_cache 耗尽会导致每次请求都重新 stat 文件，I/O 暴增，CPU 被 sys 时间吃掉大半。

默认 realpath_cache_size = 4096，中小项目够用；但 Composer 自动加载 + 大量 vendor 类时，很容易打满。

• 检查是否打满：用 php -r "print_r(realpath_cache_get());" 看缓存条目数
• 调大配置：realpath_cache_size = 4096k（注意单位是 k，不是字节）
• 同时加大 realpath_cache_ttl = 600，避免每 2 分钟全量刷新一次路径缓存
• 这个配置改完必须重启 PHP-FPM，仅 reload 不生效

缓存和队列的逻辑写进代码只是第一步，真正难的是让它们持续稳定工作——比如 Redis 连接断了要不要自动重连、队列积压到 10 万条怎么告警、空值缓存被误删后如何兜底。这些细节不盯住，高并发场景下最先崩的往往不是数据库，而是你自以为“已经加了”的那层防护。