Question

我在服务器场中使用捆绑和缩小，其中存在旧服务器和新服务器的交叉时段。

我遇到的问题是旧服务器正在缓存新的bundle cache buster URL的内容。

例如，使用新捆绑包网址缓存新 HTML：

<script src="/bundle.css?v=RBgbF6A6cUEuJSPaiaHhywGqT7eH1aP8JvAYFgKh"></script>

然后向旧服务器发出请求，该服务器尚未使用新的CSS代码进行更新，然后进行缓存。

对新捆绑包网址的任何后续调用都将返回旧代码。

因此有没有办法检查捆绑包的内容是否与哈希缓存破坏者匹配？如果它不会抛出404例如。

当请求回到捆绑包的旧服务器时，使用上面的示例，它将检查捆绑包的内容，生成内容哈希并将其与查询字符串进行比较。

在这种情况下，cache-buster不会与实际内容哈希匹配，并且会返回404.

最终，用户会使用捆绑请求点击新服务器，并且会缓存正确的内容。

Answer 1

我们很快就会遇到同样的问题，但我们一直只坚持使用2个更新域（将服务器分成两半，以便不超过一个版本运行一次）。

据我所知，有4种可能的选择：

让您的静态内容始终指向最新的服务器。这可以通过IP地址或使用您已知更新的URL（如果您的服务器先获得更新）完成（取决于您的配置）。
配置负载均衡器，以便来自同一IP地址的请求最终位于同一系统上（如果您的静态内容是从应用服务器提供的）。如果无法在负载均衡器级别完成此操作，则可以通过为不同环境配置不同的IP地址然后交换其DNS记录来进一步完成此操作。
在ASP.NET中实现一个侦听CSS文件的处理程序，并检查该bundle的哈希是否符合预期。当您的应用加载时，您可能需要单个对象来存储这些对象。然后，它可以返回404,301（以使它们重试）或返回旧版本，但指示它不缓存结果。请注意，使用HttpPipelining，您可能无法访问其他服务器，因此重定向可能无效。
在您进行部署时设置一个配置标记，将所有缓存无效的网址更改为当前日期。这将有效地禁用所有缓存，直到您的部署完成，这意味着任何＆＃34;错误＆＃34;交付的资产将不予保留。

这是您实际看到的问题，还是假设？除非您的网站流量非常高，并且您的部署需要几分钟时间，否则您不会看到它。你会想要回复404，因为有时错误的样式表比没有样式表更好。