分布式 Web 应用的 Azure DocumentDB 一致性答案

【问题标题】：Azure DocumentDB Consistency for Distributed Web Apps分布式 Web 应用的 Azure DocumentDB 一致性
【发布时间】：2017-03-14 18:38:32
【问题描述】：

我有一个非常标准的 (Asp.Net Core) Web 应用程序，它部署在 Azure 中。我正在使用多个不使用会话亲和性的应用服务器，因此同一用户可能会在后续请求期间访问不同的服务器。

我想使用 Azure DocumentDB 为我处理一些数据存储。使用模式是每个登录用户每分钟最多发出 10 次命令来读取并更新数据记录。每个用户将读取和写入一条记录。每个用户都有自己的记录。

在阅读了有关一致性的 DocumentDB 文档后，我对它们的工作方式有几个疑问。

我的要求是

我想我需要使用“会话”一致性，但我不确定如何在网络农场场景的上下文中处理 SessionToken。

我想我可以将 SessionToken 存储为 cookie，但是 DocumentDB“会话”的生命周期是多少？文档似乎对此保持沉默。另外，如果用户注销并重新登录并且会话已过期，会发生什么情况？

也许我不完全了解如何在 DocumentDB 中复制写入，以及如何配置 DocumentDB 的读/写区域来解决所有这些问题？

如果我的主要数据中心区域有一个主要的读/写 DocumentDB，而另一个区域有一个辅助“读取” DocumentDB，这是否满足我的一致性和故障转移要求？

任何澄清将不胜感激！

【问题讨论】：

【解决方案1】：

DocumentDB 会话令牌永不过期。您当然可以遵循 cookie 模式来保证用户在登录/注销时的强一致性。如果帐户设置为有限陈旧，您还可以通过使用仅从帐户的写入区域读取的第二个 DocumentClient 来保证强读取。

【讨论】：

所以要澄清一下……读取在同一区域内总是具有强一致性？所以只要我只使用一个区域，我就不必担心一致性？在这种情况下，我只会在故障转移事件期间从次要区域读取数据？
如果您的帐户使用有限陈旧性，可以。编辑了我的答案
因此，为多区域部署配置 Bounded Staleness 需要允许至少 100,000 个滞后操作。那只是为了复制区域吗？我已经阅读了docs.microsoft.com/en-us/azure/documentdb/…，但由于“Bounded Staleness”设置，我找不到任何暗示来自主要区域的读取操作具有强一致性的内容。
是的，这适用于副本（读取区域）。在主要区域内，您会获得具有有限陈旧性的强读取。我会将其添加到文档中。