我正在跨越旧服务器和新服务器的服务器场使用捆绑和分类.
我遇到的问题是旧服务器正在缓存新的捆绑缓存无效化URL的内容.
例如,使用新的捆绑URL缓存新的HTML：
<script src="/bundle.css?v=RBgbF6A6cUEuJSPaiaHhywGqT7eH1aP8JvAYFgKh"></script>
然后,这个请求到尚未使用新的CSS代码更新的旧服务器,然后缓存.
因此,是否有一种检查捆绑内容与散列缓存无效的匹配方法？如果它不抛出404,例如.
当请求返回到捆绑包的旧服务器时,使用我的示例,它将检查捆绑包的内容,生成内容哈希值并将其与查询字符串进行比较.
在这种情况下,缓存破坏者将不匹配实际的内容哈希,并返回404.
解决方法
我们很快就会遇到同样的问题,但是我们一直坚持只有2个更新域(将服务器分成两半,以便一次运行的版本不超过一个).
据我所见,有四种可能的选择：
>让您的静态内容始终指向最新的服务器.这可以通过IP地址或通过使用您已知更新的URL完成(取决于您的配置)(如果您的服务器首先被更新).
>配置您的负载平衡器,以便相同IP地址的请求最终在同一个系统上(如果您的静态内容由应用服务器提供).如果在负载平衡器级别无法进行此操作,则可以通过为不同的环境配置不同的IP地址,然后交换其DNS记录来进一步实现.
>在ASP.NET中实现一个侦听CSS文件的处理程序,并检查捆绑包的哈希是否是预期的.当您的应用加载时,您可能需要一个单例对象来存储这些对象.这可以返回404,301(让他们重试)或返回旧版本,但是指示它不缓存结果.请注意,使用HttpPipelining,您不可能访问其他服务器,因此重定向可能无效.
>在执行部署时设置一个配置标志,该标志会将所有缓存已清除的URL更改为当前日期.这将有效地禁用所有缓存,直到部署完成,这意味着任何“错误”的资产都不会被保留.
这是你真正看到的问题,还是假设？除非你的网站流量很高,而且你的部署需要好几分钟,这不是你可能看到的东西.你会想要返回404s,因为有时错误的样式表比没有样式表更好.
