PHP 怎么高并发处理

本文目录导读：

1. 第一阶段：基础设施层（最有效，成本最低）
2. 第二阶段：架构层（核心手段）
3. 第三阶段：代码层（具体实现）
4. 第四阶段：业务方案（降级与限流）
5. 不同场景的推荐路线
6. 一句话核心要点：

处理 PHP 高并发是一个系统工程，没有单一的“银弹”，核心思路是“横向扩展 + 异步化 + 缓存 + 削峰填谷”。

由于 PHP 传统上是“请求-响应”模型（每次请求结束后释放所有资源），其高并发处理策略与 Java（常驻内存）或 Go（协程）有本质区别。

以下是针对不同场景的分层处理方案，按优先级排序：

第一阶段：基础设施层（最有效，成本最低）

目标：让 PHP-FPM 尽可能“轻”，把压力转移到其他组件。

1. PHP-FPM 调优（减少 CPU 浪费）：

   • 开启 OPcache：这是 PHP 性能提升最明显的一步，避免每次请求都重新解析和编译 PHP 脚本（opcache.enable=1，opcache.memory_consumption=256，opcache.validate_timestamps=0 生产环境）。
   • 调整进程管理：使用 ondemand 模式（按需启动）或 dynamic 模式，不要开太多进程，避免上下文切换开销（根据服务器 CPU 核心数设置 pm.max_children，一般 2-4 倍 CPU 核心数）。

2. Web 服务器层（解除 PHP 瓶颈）：

   • Nginx + PHP-FPM：使用 Nginx 处理静态文件（图片、CSS、JS）和负载均衡，PHP 只处理动态逻辑，Nginx 的异步非阻塞模型能轻松扛住十万级并发连接，而 PHP-FPM 只接受经过 Nginx 过滤后的有效请求。
   • 启用 Gzip/Brotli 压缩：减少网络传输量，降低 I/O 压力。

3. 数据库层（最常见的瓶颈）：

   • 连接池/持久连接：PHP 本身不维护连接池，但可以使用 Swoole 或 PDO 的持久连接。更推荐：使用数据库中间件（如 ProxySQL）来管理连接复用。
   • 主从分离：读操作走从库，写操作走主库，分散数据库压力。

第二阶段：架构层（核心手段）

目标：将用户请求从“实时计算”变为“预计算或异步处理”。

1. 引入 Redis 缓存（缓存雪崩/穿透预防）：

   • 热数据缓存：页面片段、Session、排行榜、商品详情等高频访问数据直接放 Redis（SET/GET）中，绝不直接查 MySQL。
   • 使用锁：高并发下要注意“缓存击穿”，使用 Redis SET NX 实现分布式锁，保证只有一个请求去查数据库并回填缓存。
   • 数据预热：启动时或定时任务将热点数据预先加载到 Redis。

2. 消息队列削峰（异步化）：

   • 这是解决瞬时高并发（如秒杀、抢票）的必备方案。
   • 场景：用户点击“下单” -> 直接返回“排队中” -> 请求进入 RabbitMQ/Kafka -> 后端 Worker 平滑消费队列 -> 写数据库 -> 异步通知用户结果。
   • PHP 实现：使用 php-resque、RabbitMQ 客户端，或者将业务逻辑放到 Laravel 等框架的队列任务中。
   • 好处：PHP-FPM 处理请求的速度极快（微秒级），真正的业务逻辑在后台慢慢处理，不会拖垮 Web 服务器。

第三阶段：代码层（具体实现）

目标：让单个 PHP 进程更高效。

1. 建立连接复用（微优化）：

   • 避免在循环中重复建立 DB/Redis 连接。
   • 使用 Redis::pconnect()（持久连接）。

2. 使用 Swoole（进阶方案）：

   • 如果业务必须常驻内存（如 WebSocket 聊天室、TCP 长连接服务）或需要超高吞吐，传统 PHP 无法胜任。
   • Swoole 作为 PHP 扩展，将 PHP 变成了异步、协程的语言，它允许你通过协程在单进程内处理数千个并发连接，性能接近 Go 语言。
   • 注意：Swoole 需要重写部分代码逻辑，学习成本较高，不适用于所有项目。

3. 代码规范：

   • 减少重逻辑：避免在请求中做图片处理、复杂计算，交给后台异步任务。
   • 批量查询：不要循环单条查询，使用 INSERT ... VALUES (...), (...) 批量插入。

第四阶段：业务方案（降级与限流）

目标：保证系统在极端流量下不宕机。

1. 服务降级：

   当系统压力过大时,主动关闭非核心功能（如推荐位、详情页评论），只保留核心交易功能。

2. 接口限流：

   • 使用 Redis INCR + EXPIRE 实现滑动窗口限流。
   • 对关键接口（如登录、支付）设置每秒请求上限（QPS），超出直接返回“请求过于频繁”。

不同场景的推荐路线

• 场景 A：仅电商大促（突发流量）
  • 首选方案：Nginx + Redis 缓存 + MQ 削峰（先写 MQ 再写库）。
• 场景 B：API 接口服务（日常高流量）
  • 首选方案：多机器负载均衡 + MySQL 主从分离 + Redis 全站缓存。
• 场景 C：长连接/直播消息（实时性强）
  • 首选方案：弃用 PHP-FPM，使用 Swoole 或 Workerman 常驻内存服务。
• 场景 D：业务复杂且逻辑重（如数据分析）
  • 首选方案：将 PHP 仅作为交互层（前端 API），具体计算交给 Java/Go 微服务，PHP 通过 RPC 调用。

一句话核心要点：

PHP 只负责“接需求”，写缓存，发消息。 把数据库操作的瓶颈转换成Redis 操作，把同步等待转换成消息队列异步，把单机运算转换成分布式（负载均衡）运算。