核心业务“绝对可用”需限流与多级缓存协同：第一层接入层粗粒度限流+静态资源强缓存；第二层网关层按业务维度限流+动态接口分级缓存；第三层后端健康感知+缓存自动熔断，且缓存键须与限流维度一致确保隔离。
核心业务“绝对可用”不是靠单一机制实现的，而是通过限流与多级缓存形成协同防御：限流拦住恶意/突发流量，缓存兜住后端不可用时的请求。两者在 Nginx 中可深度耦合，关键在于分层拦截、分级响应、故障自动降级。
第一层：接入层限流 + 静态资源强缓存
在最外层（如边缘 Nginx 或 CDN 下游）做粗粒度限流，同时对不带身份标识的公开内容直接缓存：
- 用 limit_req_zone $binary_remote_addr zone=global:10m rate=100r/s 控制单 IP 总请求速率，burst=20 防止偶发抖动误杀
- 对 location ~* \.(js|css|png|woff2)$ 启用强缓存：add_header Cache-Control "public, max-age=31536000, immutable"，命中即返回，完全不触达后端
- 该层不校验 token 或 session，只服务公共资源，既减压又提速
第二层：网关层按业务维度限流 + 动态接口分级缓存
在核心 API 网关层（如 /api/v1/order/）启用细粒度控制，把限流和缓存策略绑定到业务语义上：
- 定义用户级限流区：limit_req_zone $http_authorization zone=user_api:10m rate=5r/s（提取 Bearer Token 做哈希），避免一个恶意 token 拖垮全局
- 在对应 location 中同时配置：limit_req zone=user_api burst=3 nodelay + proxy_cache my_cache
- 设置缓存策略：proxy_cache_valid 200 304 5m；proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504，后端出问题时仍可返回旧数据
- 开启 proxy_cache_lock on，防止缓存失效瞬间大量请求穿透回源
第三层：后端健康感知 + 缓存自动熔断
当上游服务开始异常，Nginx 不仅要缓存旧响应，还要主动规避故障节点，让缓存真正“活”起来：
- 配置 proxy_next_upstream error timeout http_502 http_503 http_504，请求失败后自动转发至其他健康 upstream 节点
- 搭配 health_check interval=3 rise=2 fall=3 主动探测后端存活，剔除不可用实例
- 若所有 upstream 均不可用，配合 proxy_cache_use_stale 和预置的兜底页面（如 /maintenance.html），由 Nginx 直接返回本地缓存的 HTML，实现“有内容的中断”
关键协同点：缓存键必须兼容限流维度
如果限流按 $http_authorization 区分用户，缓存 key 就不能忽略它，否则不同用户会命中同一份缓存：
- 错误写法：proxy_cache_key "$host$request_uri"（所有用户共享缓存）
- 正确写法：proxy_cache_key "$host$request_uri$is_args$args$cookie_session_id" 或 "$host$request_uri$http_authorization"，确保缓存隔离与限流维度一致
- 对无状态接口（如商品详情），可省略身份字段；但对用户专属数据，必须显式纳入 key
