问题描述
我对在cosmosdb的dotnet v3 sdk中使用会话令牌进行了一些研究，到目前为止，我发现这两个链接为我提供了一些使用方法的提示：utilize-session-tokens和{{3} }。
在我们的方案中，如果更新属于同一userId，我们希望具有强一致性（但我们不想对所有数据使用强一致性），以便当一个实例在该用户，其他所有人将立即看到结果。
我们还希望将cosmosdb用作另一种情况的锁。
但是，上面的链接仅显示如何重用创建文档后返回的令牌。而且我想知道是否可以构造自己的会话令牌并将其用于强一致性。
例如，如果要更新特定userId下的数据，则可以使用{userId}:-1#1作为会话令牌。那是使用会话令牌的有效方法吗？我也不确定pkrangeid，Version，GlobalLSN字段的含义，以及当cosmosdb处理一致性时它们将扮演什么角色。
谢谢！
解决方法
会话令牌包含客户端无法创建的LSN。会话令牌必须由服务发布，因为这是为会话一致性提供一致性保证的唯一方法。
要获得区域内强的一致性，或更准确地说，请读取您自己的Session一致性提供的写入保证，并使用Cosmos客户端的单个实例，已经获得阅读您自己的写保证。您不需要管理会话令牌。 Cosmos SDK为您完成了此任务。
如果您有在单独的进程中拥有多个Cosmos DB客户端实例并且希望读取自己的写入保证的情况，则有两种选择。
-
实施有界陈旧性一致性，可为该区域中所有读写的Cosmos客户端实例提供区域内强一致性。它通过读取两个副本来做到这一点。由于Cosmos DB始终会写入3个副本，因此您可以确保始终读取最新数据，因为Cosmos DB将检查两个副本中的LSN，如果不匹配则从较高的LSN返回数据。这种方法的好处是，它非常容易实现。不利之处在于，点读取（即ReadItemAsync（））的成本是其两倍，因为它从两个副本中进行读取。
-
在耐用功能或类似功能中使用会话一致性并使用有状态实体，这将使您可以实现分布式互斥锁来跨多个Cosmos客户端实例存储和更新会话令牌。这里的好处是点读取仍然是1 RU，缺点是这种复杂性，而且所有写入都被序列化，因为它们需要将所有写入与需要由每个客户端实例更新的互斥体进行排队。注意：如果您的客户端处于同一进程中但在多个线程上，则可以使用并发集合，该并发集合更简单，但仍需要同步线程，因此在高并发时会影响客户端的写吞吐量。