Question

首先是一些背景知识。我目前有一个托管Windows Azure的站点，有多个实例，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

您是使用缓存来提供SessionState存储，还是通过应用程序提供常规数据存储，或者两者都使用？它并不完全清楚，因为InProc通常引用SessionState，但您的示例代码看起来不像SessionState。

假设您正在存储可以在本地安全缓存的数据，那么我建议您查看AppFabric Local Caching。它基本上完成你想要的，并且不需要编写任何单独的代码（我认为......）。

否则，如您所述使用MemoryCache是一个可行的方案。我已在我的应用程序中完成此操作，您只需要小心避免缓存不连贯问题。

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

Answer 2

我做的一件事是使用HttpContext.Items。这只是每个请求缓存，但根据系统的性质可能很有用。

Answer 3

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

Answer 4

我不建议使用inproc，因为没有服务器亲和力。

使用Windows Azure Cache避免每小时配额限制的一个选项是提高缓存大小。幸运的是价格没有线性扩展。例如：128MB 45美元，256MB 55美元。因此，一种选择是将缓存提升到下一个尺寸。您需要通过perf计数器监控Compute性能，因为无法实时监控缓存使用情况。

另一个选择是将会话状态移动到SQL Azure，从Azure 1.4开始，它现在是官方支持的会话状态提供程序（2011年8月 - 有关详细信息，请参阅this article）。使用最新的SQL Azure pricing updates，如果数据库保持在100MB以下，则每月费率为4.99美元，而不是原来的9.99美元基线。它每天摊销，所以即使你有瞬态峰值并进入1 + GB范围，你仍然有相当实惠的缓存存储库。

Answer 5

另一种可能的解决方案是使用Sticky Sessions，例如：

http://dunnry.com/blog/2010/10/14/StickyHTTPSessionRoutingInWindowsAzure.aspx

一起使用InProc和Azure AppFabric Cache

5 个答案: