我们有一个网站，其中包含大量缓存对象，这些对象存储在App_Code中的静态变量中。每当我们将App_Code更改推送到我们的生产Web服务器时，它都会回收IIS池并刷新缓存。当我们推出对.aspx和.aspx.cs文件的更改时，它不会刷新缓存。
我需要有一堆类，每天会更新几次，以便能够在App_Code中引用。我想要我的App_Code的一部分，我可以每天更新几次而无需循环IIS并刷新我的缓存，或者能够从App_Code中引用App_Code之外的类。
是否有符合我问题的解决方案？
答案 0 :(得分：4)
App_Code或/ bin /的更新总是回收您的应用程序池我相信。如果您说您有部署方案，其中.aspx.cs文件更新不会回收您的应用程序池，并且您可以引用页面类型本身，也许您可以将代码移动到.aspx中。 cs文件，以防止回收发生。但这可能是一个丑陋的选择。
一个建议是修改您的设计，以减少每天所需的源代码更新次数。也许使用XML或数据库存储，并将您的应用程序设计为更通用，并且不太容易进行二进制更新。
或者将应用程序划分为几个较小的虚拟应用程序。这样做的工作量可能更高，但在这种情况下，如果您的应用程序更加分区，则不必在每个部署中回收整个应用程序。您只需要回收受部署影响的模块。
另一个建议可能是设置群集服务器架构。安排部署应用于一个群集节点，在发生预定更新时仅保留其他群集节点，然后在第一个节点更新完成后将应用程序池循环再次发布到第二个节点的更新。
另一个建议是将部署时间更改为非高峰时间，如果可行的话。
频繁更新是否因为发生了很多发展变化而发生？
答案 1 :(得分：2)
另一个角度是使用分布式缓存解决方案而不是HttpRuntime缓存。
HttpRuntime缓存有两个主要缺点：
1）当你的应用领域回收时，它会被刷新。默认情况下，这是每29小时完成一次，即使您没有修改App_Code。
2）它本地化为单个Web服务器。因此，如果您的Web服务器需要扩展到更大的Web场，则缓存变得越来越不有效，因为所有Web服务器上的缓存条目都不同步。
分布式缓存解决方案通过在您的Web层和后端数据源之间创建单独的缓存层来回避这些问题。
示例解决方案：
当然，这将导致更复杂的架构，并且需要更多硬件或虚拟机。