PHP-FPM 多站点部署怎么隔离：进程池、慢请求与回滚边界

订单站和报表站都挂在同一台 Nginx 后面时，最容易被忽略的不是 Nginx 本身，而是背后的 PHP-FPM 进程池：报表接口一次查询几十秒，就会把池内所有工作进程占满，登录、下单这类短请求也只能在队列里排队等待。多站点部署更稳妥的做法，是按业务负载拆分独立池子，再用 pm.max_children、慢日志和灰度回滚机制把资源边界彻底固定下来。

先把订单流量和报表流量放进不同的池

假设一台机器承载 shop.example.com 和 report.example.com。订单站的请求通常 200 毫秒内就能结束，报表站却可能扫描 sales_daily 表并导出生成 CSV 文件。两类请求混用同一个池子时，报表的长耗时请求会把原本看起来毫无关联的登录请求一起拖慢。

从架构层面看，独立进程池的价值不是凭空提升机器并发能力，而是缩小故障影响范围。订单池优先保障短请求处理能力，报表池则允许更低的并发上限并搭配更严格的超时规则。Nginx 只需要把不同站点的 fastcgi_pass 指向不同的 Unix Socket 即可完成配置：

server {
    server_name shop.example.com;
    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/php8.4-fpm-shop.sock;
    }
}

server {
    server_name report.example.com;
    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/php8.4-fpm-report.sock;
    }
}

这里的池名和 Socket 文件名要保持一一对应。修改完配置后先用 nginx -t 做语法校验，再分别访问两个域名的健康检查接口，确认请求确实转发到了目标进程池。

用内存和下游连接数算 pm.max_children

PHP-FPM 最常见的错误配置，就是网上随便抄一份“高并发”参数直接套用。更可靠的计算起点是先测出单个 PHP 工作进程的常驻内存。比如订单池的进程稳定占用 55 MB 左右内存，机器给 PHP-FPM 预留 2 GB 空间，再预留 20% 内存给突发流量和管理进程，那么内存侧的上限大概是：

可用内存 = 2048 × 0.8 = 1638 MB
订单池上限 = floor(1638 / 55) = 29 个 worker

这只是内存侧的计算上限，最终取值还要和 CPU、MySQL 连接预算对比，取三者里的最小值。假设订单池每个工作进程最多占用一个数据库连接，而 MySQL 给这台机器的连接配额是 40，订单池和报表池的合计进程数就不能把 pm.max_children 配到 60。

动态进程池可以在 pm.min_spare_servers 到 pm.max_spare_servers 之间弹性扩容，但不要把“允许创建更多进程”等同于“下游服务能承载更多请求”。报表池的配置尤其要保守，比如先把上限设为 pm.max_children = 6，通过压测验证后再逐步往上调整。

把慢日志、状态页和超时配置成同一套证据

如果只有一份全局慢日志，排查问题时会非常含糊：到底是订单池资源耗尽了，还是报表查询拖慢了整个数据库？给每个进程池配置独立日志，至少要记录入口脚本和调用栈相关线索：

[shop]
slowlog = /var/log/php8.4-fpm/shop-slow.log
request_slowlog_timeout = 2s
request_terminate_timeout = 8s
pm.status_path = /fpm-status-shop

[report]
slowlog = /var/log/php8.4-fpm/report-slow.log
request_slowlog_timeout = 5s
request_terminate_timeout = 30s
pm.status_path = /fpm-status-report

订单池的请求终止时间应该短于报表池，这本身就是业务优先级的直接体现。状态页不要直接暴露到公网，可以只允许内网监控节点访问。重点观察 listen queue、max active processes 和 max children reached：队列积压持续大于 0，说明请求已经在进程池外排队等待；达到 max children 上限则说明进程池的处理能力已经成为当前瓶颈。

发布顺序要支持回滚，而不是只会重载服务

修改进程池配置后，先在单台节点上执行配置检查，再重载 PHP-FPM 服务。健康检查不能只校验接口返回 200 状态，还要覆盖一次真实的数据库读操作，避免 Socket 连接正常但业务逻辑已经不可用的问题。

php-fpm8.4 -t
sudo systemctl reload php8.4-fpm
curl -fsS https://shop.example.com/health/db
curl -fsS https://report.example.com/health/db

灰度观察 5 到 10 分钟，记录两类站点的 P50/P95 耗时、502 报错比例、FPM 状态页队列积压量和 MySQL 活跃连接数。如果订单 P95 耗时上升、max children reached 持续增加，优先回滚新的进程池配置；如果只有报表池出现超时，就降低报表并发上限或者缩短报表查询的扫描范围，不要直接把全机的进程数调大。

回滚用的配置文件最好带上版本号，例如 /etc/php/8.4/fpm/pool.d/shop.conf.20260720。重载完成后再次访问两个站点的健康检查接口，确认慢日志的时间线已经恢复正常。先别急着清空旧日志，保留故障窗口的原始记录，后续才能判断修复动作是否真的生效。

常见问题：PHP-FPM 多站点隔离怎么判断

为什么只增加 pm.max_children 配置，响应反而变慢了？

因为更多工作进程会同时争抢 CPU、内存或者 MySQL 连接资源。先查看进程池状态和下游服务的运行指标，确认瓶颈位置后再决定是否上调并发数。

两个站点必须启动两个独立的 PHP-FPM 服务吗？

不一定。核心是进程池和 Socket 对应的资源边界相互独立；可以用同一个主服务管理多个进程池，也可以按权限和发布节奏拆分成完全独立的服务。

PHP-FPM 状态页能直接暴露给公网吗？

不建议。状态页包含大量进程和请求统计信息，应该通过内网访问、IP 白名单或者监控代理转发访问，不要在公网的 Nginx 配置里留下可猜测的公开路径。

报表站是否应该单独部署到另一台机器？

当报表查询的负载已经持续影响订单池运行，或者数据库读负载完全无法隔离时，单独部署机器、拆分只读库或者接入异步报表链路，比继续调大进程数更合适。

上线前的最小检查清单

• 每个站点的 fastcgi_pass、进程池名和 Socket 存储路径是否一一对应。
• pm.max_children 是否同时符合内存、CPU、MySQL 连接三项资源预算。
• 慢日志、状态页、请求终止时间是否已经按业务优先级做了独立配置。
• 是否配置了单节点灰度、自定义健康检查、指标观察窗口和带版本号的回滚配置文件。

多站点场景下的 PHP-FPM 调优，核心不是追求一个好看的并发数字，而是把订单、报表和异常请求都放进可观测、可限制、可回退的边界里。边界划分清楚之后，参数调整才有实际意义。