FastCGI 仅为通信协议，高可用集群依赖 Nginx upstream + 多实例 PHP-FPM + 健康检查；需 TCP 监听、upstream 配置权重/故障转移/会话保持、fastcgi_pass 指向 upstream 并设置关键参数，辅以外部健康探测提升可靠性。
FastCGI 本身不是集群组件，它只是 Nginx 与后端语言解释器（如 PHP-FPM）通信的协议。真正实现高可用集群下的“动态分发”，靠的是 Nginx 的 upstream 机制 + PHP-FPM 多实例部署 + 健康检查策略，而不是 FastCGI 协议自身具备集群能力。
PHP-FPM 实例需独立部署为多节点
单机上启多个 PHP-FPM pool（如 www、api、admin），或跨机器部署多个 PHP-FPM 服务（如 10.8.102.70:9000、10.8.102.71:9000），是构建基础集群的前提。每个实例应监听 TCP 端口（不推荐 Unix socket，因跨机不可用），并启用 pm.status_path 暴露状态页，供 Nginx 或外部监控探测健康状况。
Nginx upstream 配置支持动态权重与故障转移
在 nginx.conf 中定义 FastCGI 后端集群时，需使用 upstream 块，并开启连接级健康检查：
- 配置 max_fails=3 fail_timeout=30s，让 Nginx 自动屏蔽连续失败的 PHP-FPM 节点
- 使用 ip_hash 或 hash $request_uri consistent 实现会话保持或缓存友好分发（视业务需要）
- 添加 backup 标记备用节点，主节点全挂时自动切流
- 可配合 slow_start=60s 防止新上线的 PHP-FPM 实例被瞬间压垮
FastCGI 请求转发需显式指定后端地址
不同于 HTTP 代理用 proxy_pass http://backend，FastCGI 分发必须通过 fastcgi_pass 指向 upstream 名称，并补全必要参数：
-
fastcgi_pass php_backend;（对应 upstream php_backend { … }） - 必须包含
fastcgi_param SCRIPT_FILENAME和fastcgi_param PATH_INFO等关键变量，否则脚本路径解析错误 - 建议统一启用
fastcgi_intercept_errors on;，配合error_page 502 = @fallback实现降级逻辑
配合外部健康检查提升可靠性
Nginx 原生对 FastCGI 的健康检查较弱（仅基于 connect/fail），生产环境建议叠加：
- 用 nginx-plus 或开源模块 nginx_upstream_check_module 实现 HTTP 状态页探测（访问 /status?json）
- 用 Consul + registrator 自动注册/注销 PHP-FPM 实例，再通过 Lua 或 OpenResty 动态更新 upstream
- 将 PHP-FPM 进程纳入 systemd 监控，异常退出时自动拉起并触发告警
