结合使用InProc和Azure AppFabric缓存

Question

先了解一下背景。我现在有一个使用Windows托管的站点，它有多个实例，AppFabric也是我唯一的缓存提供程序。

一切都很顺利，直到今天早上我的车流量猛增。在实例重载并停止响应之后，一旦新实例启动，一切都会恢复正常。

然而，我开始收到来自AppFabric的消息，说我被勒死了，因为在给定的一小时内有太多的请求。这是公平的，这肯定是让它下地狱。

为了在将来避免这些消息，我计划在很短的时间内实现一个InProc缓存。所以它首先检查InProc，如果不是AppFabric，如果不是DB。

 ObjectCache cache = MemoryCache.Default;

 CacheItemPolicy policy = new CacheItemPolicy();
 policy.AbsoluteExpiration = DateTimeOffset.Now.AddMinutes(5);

我的问题是

• 这是处理这种情况的最好办法吗？
• 这会干扰AppFabric缓存吗？
• 有什么问题我忽略了吗？

更新--我只想说我选择了上面的方法，而且效果很好。我只将它用于一般数据存储，而不是会话状态。带有会话状态的MemoryCache在Azure上不能很好地工作，因为没有服务器关联(如下面的David所述)。

更新16-03-2012后，我实现了明显的，我也禁用了大多数页面的SessionState .我的大部分页面都不需要它，因此这会迅速减少我在重载下对缓存的调用。我还禁用了大多数页面的ViewState，只是为了更快的页面加载时间。

Answer 1

试试这个：http://msdn.microsoft.com/en-us/magazine/hh708748.aspx

Answer 2

您是使用缓存来提供SessionState存储，还是使用应用程序提供通用数据存储，还是两者兼而有之？还不完全清楚，因为InProc通常指的是SessionState，但是示例代码看起来不像SessionState。

假设您正在存储可以安全地在本地缓存的数据，那么我建议您查看AppFabric本地缓存。它基本上可以实现您想要的功能，并且不需要编写任何单独的代码(我认为.)。

否则，正如您所描述的那样使用MemoryCache是一种可行的方案。我已经在我的应用程序中这样做了，您只需要小心避免缓存不一致的问题。

根据应用程序的不同，您还可能希望通过在HttpContext.Items集合中存储数据来实现每个请求缓存。当您的代码的不同部分可能在单个请求期间请求相同的数据时，这是很有用的。

Answer 3

我做过的一件事就是使用HttpContext.Items。这只是每个请求缓存，但取决于系统的性质可能是有用的。