负载均衡配置与PHP高并发优化技巧

PHP高并发场景下的负载均衡绝非简单配置upstream即可，而是一套需深度协同会话管理（强制Redis集中存储并重启PHP-FPM生效）、进程模型（按内存倒推pm.max_children防OOM）、静态资源分流（Nginx直答避免PHP冗余处理）、OPcache优化（关闭时间戳验证、足额内存分配）及真实服务健康检查（自定义/healthz探针替代TCP探测）的系统工程——任一环节疏漏都会引发登录丢失、响应抖动或单点雪崩，本文直击生产环境最易踩坑的五大关键配置，给出可落地的参数组合与验证方法。

PHP高并发场景下，负载均衡不是“配了就完事”，而是必须和会话、缓存、进程模型联动配置，否则容易出现用户反复登录、接口响应忽快忽慢、某台服务器突然打满等问题。

nginx upstream 怎么写才不踩坑

Nginx 的 upstream 是 PHP 负载均衡的起点，但默认轮询在真实业务中往往不合适：

• 没加 max_fails=3 fail_timeout=30s？服务器挂了还会持续转发请求，造成超时堆积
• 用了 ip_hash 却没考虑 CDN 或 NAT 场景？大量用户 IP 被识别为同一个，流量全打到一台后端
• 权重设成 weight=5 和 weight=1，但两台机器内存/磁盘 IO 差距不大？结果高权重点反而因连接堆积先崩

推荐组合（传感/API 类长连接场景）：

upstream php_backend {
    least_conn;
    server 192.168.1.10:9000 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:9000 max_fails=3 fail_timeout=30s;
    server 192.168.1.12:9000 backup;
}

least_conn 比轮询更能适应 PHP-FPM 进程阻塞的真实状态；backup 节点只在其他全挂时启用，避免日常抢资源。

session 丢了？别怪负载均衡，先查 PHP 配置

负载均衡本身不管理 session，丢 session 的根因几乎都在 PHP 端配置错：

• session.save_handler 还是 files？那每个服务器各自存一份，切换节点必然丢失
• Redis 连接串写成 tcp://127.0.0.1:6379，但实际 Redis 在另一台机器？PHP 启动就静默失败，降级回 files 却无日志提示
• session.cookie_httponly 和 session.cookie_secure 在 HTTPS 反代下没同步设置？导致 Cookie 不被浏览器发送

正确做法（php.ini）：

session.save_handler = redis
session.save_path = "tcp://redis-server:6379?database=1"
session.cookie_httponly = 1
session.cookie_secure = 1

注意：改完必须重启 PHP-FPM，仅 reload Nginx 无效。

PHP-FPM 进程数怎么调才不 OOM

很多人把 pm.max_children 设得太高，以为能扛更多并发，结果内存爆掉，系统开始 kill 进程：

• 每个 PHP-FPM worker 平均占 25–40MB 内存（取决于扩展加载量），不是几 MB
• pm.max_children = 100 在 8GB 机器上 ≈ 吃掉 3GB+ 内存，再算上 Nginx、Redis、MySQL，极易触发 OOM Killer
• pm.max_requests = 500 是防内存泄漏的关键，但设太小（如 50）会导致频繁进程重启，反而增加开销

建议按内存倒推（以 4核8G 为例）：

pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 500

上线前用 ab -n 1000 -c 100 http://test.php 压测，观察 free -h 和 systemctl status php-fpm 是否有 restart 记录。

静态资源和 OPcache 必须拆开管

负载均衡只负责分发请求，但 PHP 应用里真正拖慢响应的，往往是重复读文件或解析代码：

• Nginx 直接返回 .js/.css/.jpg，别再甩给 PHP 处理 —— 配置漏掉 location ~* \.(js|css|png|jpg)$，所有静态请求都走 PHP-FPM，瞬间打满
• opcache.validate_timestamps = 1 在生产环境开着？每次请求都检查文件修改时间，IO 直接拉垮
• opcache.memory_consumption 小于 128MB？大项目 OPcode 缓存频繁淘汰，等于没开

关键配置（php.ini + nginx.conf）：

; php.ini
opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 0
; nginx.conf
location ~* .(js|css|jpg|jpeg|png|gif|ico|svg)$ {
expires 30d;
add_header Cache-Control "public, immutable";
}

改完记得 php-fpm -t && nginx -t && systemctl reload php-fpm nginx，缺一不可。

最常被忽略的一点：健康检查路径。Nginx 的 max_fails 只检测 TCP 连通性，不等于 PHP 服务可用。真要可靠，得配合自定义探针（如 /healthz 返回 200 且 DB 连通），否则数据库卡死，PHP 进程全部阻塞，Nginx 还在拼命转发。

以上就是《负载均衡配置与PHP高并发优化技巧》的详细内容，更多关于的资料请关注golang学习网公众号！