17370845950

PHP-FPM并发瓶颈在max_children配置不当、进程复用不足及空闲回收过激，导致请求排队；MySQL需持久连接与合理wait_timeout；Redis应启用连接池；Swoole协程须全链路非阻塞改造。

PHP-FPM 进程模型与并发瓶颈在哪

PHP 本身是同步阻塞的，高并发压力下卡在 max_children 和 pm.max_requests 配置上。不是 PHP 慢，而是默认的 pm = dynamic 模式下子进程复用不充分、空闲进程回收过激，导致请求排队等 php-fpm.sock 可用连接。

• pm.max_children 不是越大越好：超过系统可用内存（比如每个 worker 占 30MB，设 100 就要 3GB），会触发 OOM Killer 杀进程
• pm.start_servers 建议设为 min_spare_servers 和 max_spare_servers 的中间值，避免冷启动抖动
• 把 request_terminate_timeout 从 0 改成 30s，防止单个慢脚本拖垮整个池

MySQL 连接池与长连接失效问题

PHP-FPM 每个 worker 是独立进程，mysqli 或 PDO 默认不复用连接，频繁 new PDO() 会导致 MySQL 的 max_connections 快速打满，甚至出现 Too many connections 错误。

• 用 PDO::ATTR_PERSISTENT => true 开启持久连接，但注意它只在单个 worker 生命周期内复用，不是跨 worker 共享
• 避免在循环里反复 new PDO()，应把连接实例化提到函数外或用依赖注入容器管理
• MySQL 端需调大 wait_timeout（默认 28800 秒），否则空闲连接被服务端断开后，PHP 下次用会报 MySQL server has gone away

Redis 作为缓存层时的连接管理陷阱

直接用 new Redis() + connect() 在每次请求中建连，会在高并发下产生大量 TIME_WAIT 状态连接，耗尽本地端口，同时 Redis 服务端也面临连接数压力。

• 用 Predis\Client 并配置 'scheme' => 'tcp' + 'connection_timeout' => 0.2，比原生扩展更可控
• 务必启用连接池：Laravel 的 phpredis 扩展不自带池，得靠 RedisCluster 或 Swoole 的 Swoole\Coroutine\Redis；否则建议改用 phpredis 的 pconnect()（注意它不支持所有命令，如 SELECT）
• 缓存 key 务必加统一前缀（如 cache:article:123），避免不同环境 key 冲突，也方便 redis-cli --scan --pattern "cache:*" | xargs redis-cli del 清理

Swoole 协程改造的关键取舍点

想突破 PHP-FPM 的并发天花板，Swoole 是主流选择，但不是“装上就变快”。协程模型要求整个调用链路非阻塞，而多数传统扩展（如 mysql_connect()、file_get_contents()）仍是同步的。

• 必须用 Swoole\Coroutine\MySQL 替代 mysqli，用 Swoole\Coroutine\Redis 替代 Redis 类，否则协程会退化成同步等待
• Co::sleep() 替代 sleep()，Co::httpGet() 替代 file_get_contents()，否则协程调度器无法切走
• 不要在协程里调用 exec()、shell_exec() 等阻塞系统调用，它们会让整个 Worker 进程卡住

use Swoole\Coroutine\MySQL;
$mysql = new MySQL();
$mysql->connect([
'host' => '127.0.0.1',
'user' => 'root',
'password' => '123456',
'database' => 'test',
]);
$result = $mysql->query('SELECT * FROM user WHERE id = 1');

真实高并发场景里，最常被忽略的是日志写入和配置热加载——error_log() 直写文件在每秒上千请求时会成为 I/O 瓶颈，而 opcache.revalidate_freq=2 导致每次修改代码都要等 2 秒才生效，调试时误以为是逻辑问题。