表存储服务（Azure 的 nosql 实现）与 Windows Azure 缓存（非结构化内存缓存）

Question

我们想在 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. 稍微快一点

Answer 1

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

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

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

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

对于内存缓存，请使用 Windows Azure 缓存（您认为共享缓存是遗留的），并根据您的需要，查看其他缓存技术，如 memcached。缓存和表存储没有可比性。表存储是为了长期持久化。不要不必要地修改表存储来做缓存——让表存储临时创建一大堆你需要担心的事情，比如过期和失效。