Nginx跨节点缓存一致性需通过统一cache_key、主动purge失效、URL版本化及URI一致性哈希实现：强制proxy_cache_key对齐；启用ngx_http_proxy_cache_purge并发布即失效；静态资源采用内容哈希或版本参数；多节点回源时用consistent_hash $request_uri确保同一URI固定路由。
Nginx 本身不提供跨节点缓存状态同步能力，所有边缘实例的 proxy_cache 都是本地独占、相互隔离的。所谓“缓存一致性”，不是让所有机器缓存内容完全一样，而是确保业务行为可预期：同一资源更新后，用户不会持续看到旧内容；相同请求大概率命中本地缓存，不反复回源；不同节点之间不出现结果冲突。
统一 cache_key 是基础前提
如果各 Nginx 实例用的 proxy_cache_key 不一致（比如有的含 $args，有的不含；有的加了 $http_accept_encoding，有的没加），那同样的 URL 可能生成多个缓存条目，命中率骤降，还容易残留脏数据。必须强制对齐：
- 推荐写法：proxy_cache_key "$scheme$host$request_uri" —— 覆盖协议、域名、完整 URI（含参数），适合绝大多数静态与参数化动态资源
- 若参数含跟踪字段（如
utm_source=xxx或_t=1623456789），先用map过滤归一化，再参与哈希 - 避免使用
$cookie_xxx、$http_authorization等易变变量，否则会把个性化响应误缓存
主动失效比被动等待更可靠
依赖 TTL 到期清除旧缓存，延迟不可控，尤其在内容高频更新场景下极易出错。应建立发布即失效机制：
- 启用
ngx_http_proxy_cache_purge模块，在 location 中开放 purge 接口（如location ~ /purge(/.*)） - 源站发布系统触发时，向所有边缘节点并发调用
curl -X PURGE https://edge1.example.com/purge/xxx.js - 配合 HTTP 状态码控制：只允许 purge 成功返回 200 或 404（未命中也属正常），拒绝 5xx 响应并告警重试
用 URL 版本化规避缓存陈旧
对静态资源（JS/CSS/图片等），最稳妥的一致性手段其实是“不依赖缓存失效”，而是让新内容天然走新路径：
- 构建时在文件名中嵌入内容哈希，如
app.f3a8c2d4.js，发布即新 URL，旧缓存自然失效 - 或统一加版本参数，如
/style.css?v=2.4.1，发布时更新参数值 - 该方式对 CDN 和浏览器缓存同样生效，且无需任何 purge 操作，零运维风险
静态资源路由需绑定 URI 一致性哈希
当多台 Nginx 共享同一组后端源站时，若负载均衡策略导致同一 URI 落到不同 Nginx，每台都可能独立回源缓存，浪费带宽和 CPU。此时应在 upstream 中启用 consistent_hash：
- 确认已编译
with-http_upstream_consistent_hash模块（nginx -V | grep consistent） - upstream 块内仅写一行：consistent_hash $request_uri（不能与 ip_hash/hash 混用）
- 若参数含噪声，务必先 map 归一化，否则哈希结果不稳定
