如何借助 Nginx 缓存优化分布式系统的响应一致性

Nginx分布式缓存需统一cache_key、静态资源URL版本化、动态接口启用stale+background_update、发布后主动purge。关键在外部协同控制失效节奏与回源逻辑，而非节点间缓存同步。

Nginx 本身不提供分布式缓存同步能力，所谓“响应一致性”不是让所有节点缓存内容完全相同，而是确保用户看到的数据不陈旧、不冲突、不抖动。关键在于用外部机制控制失效节奏、统一命中逻辑、收敛回源路径。

统一 cache_key，避免缓存碎片
不同 Nginx 实例若使用默认或不一致的 proxy_cache_key，同一请求可能生成多个缓存条目。例如：

• 节点 A 用 $uri → /api/user?id=123
• 节点 B 用 $scheme$host$request_uri → https://example.com/api/user?id=123
  结果就是更新后部分节点仍返回旧数据。

必须显式定义并全局统一：

• 推荐写法：proxy_cache_key "$scheme$host$request_uri";
• 剔除易变变量：不包含 $cookie_session、$remote_addr、$http_user_agent 等
• 清洗无意义参数：用 map 过滤 utm_*、ref= 类跟踪参数，防止缓存爆炸

静态资源走 URL 版本化，从源头消灭过期问题
JS/CSS/图片等不变内容，更新即换 URL：

• 构建时生成哈希文件名，如 app.f3a8b2.js
• HTML 中引用该唯一路径，Nginx 不需干预缓存逻辑
• 配置强缓存策略：

  location ~* .(js|css|png|woff2?)$ {    expires 1y;    add_header Cache-Control "public, immutable";}

• 入口 HTML 单独设短 TTL（如 60s），确保用户能及时拉取含新哈希的新页面

动态接口启用 stale + background_update，防雪崩且保可用
对 /api/list 这类无法改 URL 的接口：

• 设置合理有效期：proxy_cache_valid 200 302 90s;（按业务更新频率调整）
• 允许过期后继续服务旧缓存：proxy_cache_use_stale error timeout updating http_500;
• 后台异步刷新：proxy_cache_background_update on;
  这样既能避免缓存集体过期引发回源洪峰，又不会让用户看到错误页

发布后集中 purge，不让 TTL 成为唯一依赖
不能等缓存自然过期——尤其内容变更后：

• 编译安装 ngx_http_proxy_cache_purge 模块
• 开放安全的 purge 接口（仅限内网调用）：

  location ~ /purge(/.*) {    allow 10.0.0.0/8;    deny all;    proxy_cache_purge my_cache $scheme://$host$1;}

• 发布脚本中批量执行：
  curl -X PURGE http://node1.example.com/api/news
curl -X PURGE http://node2.example.com/api/news

不复杂但容易忽略