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

Question

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

1. 加速重复数据访问
2. 减少数据库压力

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

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

为此，Table storage 似乎比 Blob 存储更好（我们只是为图像、CSS 和 JavaScript 实现了 Blob 存储），Windows Azure Caching 似乎比 Windows Azure 共享缓存更好（可能几乎是always better 和共享此时缓存为mostly a legacy feature）。

两者的编程 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。缓存和表存储没有可比性。表存储是为了长期持久化。不要不必要地破解表存储来进行缓存 - 使表存储成为临时存储会产生一大堆您需要自己担心的事情，例如过期和失效。