azure - 我可以为 cosmosdb 使用客户端构建的 session token 吗？

Question

我已经对在 cosmosdb 的 dotnet v3 sdk 中使用 session token 进行了一些研究，到目前为止，我发现这两个链接给了我一些关于如何使用它的提示:utilize-session-tokens和 how-to-convert-session-token .

在我们的场景中，如果更新属于同一个userId，我们希望具有强一致性(但我们不想对所有数据都使用强一致性)，这样当一个实例更新该用户下的数据，其他人将立即看到结果。我们还想使用 cosmosdb 作为另一个场景的锁。

但是，上面的链接仅显示如何重用创建文档时返回的 token 。我想知道我是否可以构建自己的 session token 并使用它来实现强一致性。

例如，如果我想更新特定 userId 下的数据，我将使用 {userId}:-1#1 作为 session token 。这是使用 session token 的有效方法吗？我也不确定 pkrangeid、Version、GlobalLSN 字段的含义以及它们在 cosmosdb 处理一致性时扮演什么角色。

提前致谢!

Answer 1

session token 包含客户端无法创建的 LSN。 session token 必须由服务颁发，因为它是为 session 一致性提供一致性保证的唯一方法。

为了获得区域内强一致性，或更准确地说，读取您自己的写入由 session 一致性提供的保证，并且使用您将使用的 Cosmos 客户端的单个实例已经读取了您自己的写入保证。您不需要管理 session token 。 Cosmos SDK 会为您做这件事。

如果您的场景是在不同的进程中拥有多个 Cosmos DB 客户端实例，并且希望读取您自己的写入保证，那么您有两种选择。

1. 实现有界过时一致性，为该区域中的所有 Cosmos 客户端实例读写提供区域内强一致性。它通过读取两个副本来做到这一点。由于 Cosmos DB 始终写入 3 个副本，因此您可以保证始终读取最新数据，因为 Cosmos DB 将检查两个副本中的 LSN，如果不匹配，则从较高的 LSN 中返回数据。这种方法的优点是非常容易实现。缺点是点读取(即 ReadItemAsync())的成本是从两个副本读取的两倍。

2. 使用 session 一致性并使用持久函数中的有状态实体或类似的东西，这将允许您实现分布式互斥体以跨多个 Cosmos 客户端实例存储和更新 session token 。这里的优点是点读取仍然是 1 RU，缺点是这种复杂性，而且所有写入都被序列化，因为它们需要根据互斥体对所有写入进行排队，而互斥体需要由每个客户端实例更新。注意:如果您的客户端位于同一进程但位于多个线程上，您可以使用并发集合，它更简单，但仍然需要同步线程，因此在高并发时会影响客户端的写入吞吐量。