Nginx分布式缓存一致性需统一cache_key、主动purge失效、静态资源URL版本化、动态接口启用stale+background_update机制。
Nginx 本身不支持多节点间缓存状态自动同步，分布式环境下缓存过期与更新不同步，本质是各实例缓存完全独立、无共享机制。要实现业务可接受的一致性，关键不是“让所有节点缓存内容一样”，而是让失效可控、命中稳定、不返回脏数据。
统一缓存键，避免同一请求散列到不同缓存条目
不同 Nginx 实例若使用不同的 proxy_cache_key，相同 URL 可能生成多个缓存副本，导致部分节点未更新而其他节点已刷新。必须强制统一：
- 所有实例配置一致的 key，例如：
proxy_cache_key $scheme$host$request_uri$is_args$args; - 移除易变变量（如
$cookie_xxx、$remote_addr），除非业务明确需要按用户隔离 - 对含认证头或动态参数的接口，用
proxy_cache_bypass $http_authorization $arg_token显式跳过缓存
发布即失效：通过 purge 接口主动清除边缘缓存
静态资源或 API 内容变更后，不能依赖 TTL 被动过期。应由发布系统在部署完成后，批量调用各边缘节点的清除接口：
- 启用
ngx_http_proxy_cache_purge模块（需编译时加入或宝塔插件安装） - 配置 purge location，限制仅内网或指定 IP 可访问：
location ~ /purge(/.*) {<br> allow 10.0.0.0/8;<br> deny all;<br> proxy_cache_purge my_cache $scheme://$host$1;<br>} - 发布脚本中执行：
curl -X PURGE http://node1/purge/api/news
URL 版本化：从源头规避缓存陈旧问题
对 JS/CSS/图片等静态资源，最彻底的方式是让 URL 本身携带内容指纹，使更新 = 新 URL：
- 构建阶段生成哈希文件名，如
app.d41d8cd9.js，HTML 中引用该唯一路径 - Nginx 配置强缓存：
location ~* \.(js|css|png|woff2?)$ { expires 1y; add_header Cache-Control "public, immutable"; } - 入口 HTML 单独处理：
location = /index.html { expires 60s; }，确保用户能及时拉取含新哈希链接的新 HTML
过期后平滑回源：用 stale + background update 消除请求风暴
对无法改 URL 的动态接口（如 /api/list），需容忍短时旧数据，但要避免缓存集体过期引发回源洪峰：
- 设置合理有效期：
proxy_cache_valid 200 302 90s;（根据业务更新节奏调整） - 启用后台更新：
proxy_cache_background_update on; - 授权返回旧内容：
proxy_cache_use_stale updating error timeout http_502 http_503;（updating 必须显式写出） - 加锁防并发：
proxy_cache_lock on; proxy_cache_lock_timeout 3s; - 验证响应头：
add_header X-Cache-Status $upstream_cache_status;，看到 STALE 表示机制生效
