多后端架构下Varnish部署期间返回陈旧内容的问题

这种新旧版本资源混搭的坑，在缓存+滚动部署的场景里真的太常见了！结合你提到的CSS文件名带内容HASH的特性，我给你整理几个落地性强的解决方案：

1. 利用HASH文件名的天然优势，做永久缓存+原子化部署 #

既然你的CSS已经用了file-HASH.css这种命名方式，这本身就是解决缓存一致性的绝佳基础：

• 给所有静态资源设置永久缓存规则，在Nginx里配置：

  location ~* \.(css)$ {
      add_header Cache-Control "max-age=31536000, immutable";
      expires 1y;
  }
  

  这样Varnish会把这些HASH命名的CSS缓存到过期，而且不会主动刷新（immutable标识告诉客户端和缓存服务器不要去验证资源是否更新）。
• 部署时调整顺序：先把所有Nginx后端更新到版本B，确保所有服务器都能返回file-B.css，再切换前端HTML指向新的CSS URL。或者用蓝绿部署：先把版本B的后端集群搭建好，流量切过去之后再更新HTML，彻底避免中间阶段部分后端没有新CSS的情况。

2. 部署前主动预热Varnish缓存 #

如果滚动部署的流程没法改，那可以在正式对外发布新版本之前，主动把所有新版本的CSS资源加载到Varnish缓存里：

• 写个简单的脚本，遍历新版本的静态资源清单，向Varnish发送请求预热：

  # 假设你的资源清单是static-resources.txt，每行一个资源URL
  while read url; do
      curl -X GET "https://your-domain.com$url" -H "Host: your-domain.com"
  done < static-resources.txt
  

• 预热完成后再开始部署后端和更新HTML，这样用户请求新版本HTML时，Varnish已经有对应的file-B.css缓存了，不会出现回源到还没更新的后端的情况。

3. 给缓存键添加版本标识，强制区分资源版本 #

通过在请求头里加入版本信息，让Varnish把不同版本的资源当成独立的缓存条目：

• 在Nginx里，部署版本B时统一添加自定义请求头：

  add_header X-App-Version "B";
  

• 修改Varnish的VCL配置，把这个版本头加入缓存键的计算逻辑：

  sub vcl_hash {
      # 如果请求带有版本头，把它加入缓存键
      if (req.http.X-App-Version) {
          hash_data(req.http.X-App-Version);
      }
      return (lookup);
  }
  

  这样即使文件名相同（不过你这里是HASH命名，其实不会，但这个方法通用），Varnish也会根据版本头区分缓存，不会混淆新旧资源。

4. 滚动部署阶段临时跳过新版本资源的缓存 #

如果担心预热或者版本头的配置太麻烦，可以在部署期间让Varnish暂时不缓存新版本的CSS，直接回源到后端：

• 临时修改Varnish的VCL配置，添加规则：

  sub vcl_recv {
      # 匹配新版本的CSS URL，跳过缓存直接回源
      if (req.url ~ "^/file-B\.css$") {
          return (pass);
      }
  }
  

• 等所有Nginx后端都更新到版本B之后，再把这段规则去掉，让Varnish正常缓存新版本CSS。

总结 #

最省心的还是第一种方案——因为你已经用了HASH命名的CSS，天生适配永久缓存，只要把部署顺序调整成后端全量更新→切换HTML资源指向，就能从根源上杜绝这种新旧资源混合的问题。

内容的提问来源于stack exchange，提问作者Thomas Decaux