同时使用InProc和Azure AppFabric缓存

本文关键字：Azure AppFabric 缓存 InProc | 更新日期: 2023-09-27 18:27:10

先来点背景。我目前有一个由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在下面提到的）。

更新日期：2012年3月16日在意识到这一点后，我还在大多数页面上禁用了SessionState。我的大多数页面都不需要它，因此这会迅速减少我在重负载下对缓存的调用。我还为大多数页面禁用了ViewState，只是为了稍微加快页面加载时间。

同时使用InProc和Azure AppFabric缓存

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

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

否则，使用MemoryCache是一个可行的方案。我已经在我的应用程序中做到了这一点，你只需要小心避免缓存不连贯的问题。

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

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

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

我不建议使用inproc，因为没有服务器相关性。

使用Windows Azure缓存，避免每小时配额限制的一个选项是增加缓存大小。幸运的是，价格并不是线性增长的。例如：128MB 45美元，256MB 55美元。因此，一种选择是将缓存增加到下一个大小。不过，您需要通过性能计数器来监控计算性能，因为无法实时监控缓存使用情况。

另一种选择是将会话状态移动到SQL Azure，它现在是Azure 1.4（2011年8月-请参阅本文了解更多信息）正式支持的会话状态提供程序。根据最新的SQL Azure定价更新，如果数据库保持在100MB以下，则月费为4.99美元，而不是最初的9.99美元。它是每天摊销的，所以即使您有短暂的峰值并进入1+GB的范围，您仍然有一个价格合理的缓存存储库。

另一种可能的解决方案是使用粘性会话，如以下示例：

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

相关文章：