4

我们想在 Azure 中实现缓存有两个主要原因：

  1. 加快重复数据访问
  2. 减轻数据库压力

以下是我们计划缓存的数据的特征：

  1. 相对较小（1 - 100 kb）
  2. 针对每个客户
  3. 不是私人的，但我们真的不希望随机的人浏览我们的整个缓存
  4. XML 或 JSON
  5. 由 C# 使用（即不直接在 html 中链接）
  6. 大多数星期数据不会改变，尽管有些日子数据可能会改变几次

对于这个特定目的，表存储似乎比 Blob 存储更好（我们只是为图像、CSS 和 JavaScript 实现了 Blob 存储）并且Windows Azure 缓存似乎比 Windows Azure 共享缓存更好（也许几乎总是更好，并且共享缓存主要是遗留的此时的功能）。

两者的编程 API 看起来很简单。与我们为云站点支付的费用相比，每个站点的成本似乎可以忽略不计。

到目前为止，由于我们认为 Azure 缓存的优缺点，我们倾向于表存储。作为老 .Net 人，我们对内存缓存比 NoSql 风格的解决方案更熟悉：

Windows Azure 缓存的问题：

  1. 如果将 VM 移动到不同的服务器（由 Microsoft 出于负载平衡或其他原因），内存中的缓存是否会原封不动地移动？
  2. 我们猜测，每当我们将更改发布到云时，它都会清除现有的内存缓存
  3. 虽然用户在进行更改时很少对缓存数据进行更改，但他们可能会在几秒钟内进行多次更新，我们不确定这将如何处理位于运行 Web 角色的多个节点的缓存，尤其是在流量增加的情况下. （这可能也是表存储的一个问题！）
  4. 表存储看起来更容易调试

Windows Azure 缓存的优势

  1. 快一些
4

1 回答 1

5

您对内存缓存的熟悉程度是您在 Windows Azure 上实现缓存所需了解的模型。“NoSql 风格”不是缓存，而是存储。因此，表存储代替了 SQL，而不是代替了缓存。表存储用于持久、可靠的存储——具有内存缓存不存在的所有延迟和其他持久性缺点。

写入缓存始终是次要的。当您的用户“对缓存数据进行更改”时，您将始终将数据写入磁盘（例如 SQL），然后将相同的数据写入缓存，因为您也可以这样做，因为您手头有数据（尽管对写入数据的次要影响可能意味着您应该使缓存项无效或重新读取）。

机器回收时清除数据应该不是什么大问题，因为数据存储在其他地方。每次从缓存中读取都应该跟一个“如果未找到则从数据库中读取”类型的语句。当角色开始预填充您知道将需要的项目时，您可以预热缓存。

Azure 上的缓存分布在节点上，更新现有项目将始终在它所在的节点上更新。快速更新可能没有您想象的那么严重。

对于内存缓存，请使用 Windows Azure 缓存（您说得对，共享缓存是遗留的），并且根据您的需要，查看其他缓存技术，例如 memcached。缓存和表存储没有可比性。表存储是为了长期持久化。不要不必要地破解表存储来进行缓存——使表存储成为临时存储会产生一大堆你需要自己担心的事情，比如过期和失效。

于 2013-03-12T16:10:53.390 回答