Nginx 中 FastCGI 如何配合限流降级组件保障系统高可用

Nginx通过分层协同实现FastCGI限流、熔断与缓存兜底：用limit_req限流防压垮PHP-FPM，max_fails+fail_timeout熔断异常实例，fastcgi_cache_use_stale兜底5xx返回旧页面，三者递进协作无需改PHP代码。

FastCGI 本身不处理限流和降级，但 Nginx 可通过 分层协同，让 FastCGI（如 PHP-FPM）在流量激增或后端异常时，仍保持页面可访问、关键路径不雪崩。核心是把限流、熔断、缓存兜底三者串成一条链路，全部落在 Nginx 配置层，无需改 PHP 代码。

用 limit_req 控制入口流量，防压垮 PHP-FPM

PHP 应用通常资源消耗高、响应慢，一旦并发突增，容易触发进程耗尽或超时。应在 Nginx 入口处按 IP 或 URI 限速：

1. 定义限流区：limit_req_zone $binary_remote_addr zone=php_limit:10m rate=10r/s;
2. 对动态接口启用限流：location ~ .php$ { limit_req zone=php_limit burst=20 nodelay; ... }
3. 配合 limit_req_status 429 返回标准限流响应，前端可识别重试逻辑

用 max_fails + fail_timeout 实现 PHP-FPM 熔断

当某台 PHP-FPM 实例卡死、崩溃或响应超时，Nginx 要快速隔离它，避免持续转发请求：

1. 在 upstream 中配置：upstream php_backend { server 127.0.0.1:9000 max_fails=3 fail_timeout=15s; }
2. 启用失败重试与判定：fastcgi_next_upstream error timeout http_500 http_502 http_503 http_504;
3. 失败计数达阈值后，该 PHP 实例被标记为 down，15 秒内不再分发请求

用 fastcgi_cache_use_stale 实现“过期但可用”的兜底

当所有 PHP-FPM 都不可用时，用户不该看到 502/504，而应看到一个稍旧但结构完整的页面：

1. 必须提前缓存 5xx 响应：fastcgi_cache_valid 500 502 503 504 30s;
2. 启用 stale 触发条件：fastcgi_cache_use_stale error timeout http_500 http_502 http_503 http_504;
3. 确保 key 稳定（剔除 Cookie、时间戳等）：fastcgi_cache_key "$scheme$request_method$host$request_uri";
4. 敏感请求跳过缓存：fastcgi_cache_bypass $skip_cache; fastcgi_no_cache $skip_cache;（配合 if 判断登录态或后台路径）

组合使用：让降级有层次、有边界

这三者不是独立开关，而是递进关系：

1. 正常流量 → 走限流控制，保 PHP-FPM 不过载
2. 单点故障 → 熔断机制自动踢出坏节点，剩余节点继续服务
3. 全集群不可用 → stale 缓存生效，返回最近一次成功生成的 HTML 页面
4. 整个链路无依赖外部组件（如 Redis/Lua），部署简单、故障面小