首页 > 解决方案 > Azure Cosmos 会话一致性与同一区域中具有多个实例的微服务的有界陈旧一致性

问题描述

假设我正在开发一个社交媒体应用程序。我们在同一区域部署了多个后端服务实例。现在,每当重新加载应用程序页面时,后端服务实例之一将接收请求并联系 cosmos。问题如下-:

T1 - 已加载应用页面。服务实例 1 向 cosmos 发出读取请求。

T2 - 用户 A 添加的评论。服务的实例 2 在 cosmos 中发出了写入。

T3 - 再次加载应用页面。服务实例 3 向 cosmos 发出读取请求。

如果我们使用会话一致性,时间 T2 和 T3 的会话令牌将不同,因为写入查询由不同的实例发出,而读取查询由不同的实例发出。因此,可能会出现在时间 T3,当应用页面加载时,用户 A 添加的评论没有加载,因为会话一致性稀释到一致前缀,以防同一区域中的不同会话令牌。

为了解决这个问题,我们可以使用有限的陈旧性,但我认为这可能是矫枉过正。

我们如何处理这些具有会话一致性的多实例服务场景?

标签: azureazure-cosmosdb

解决方案


使用会话令牌执行此操作的唯一方法是实现分布式互斥锁。虽然这会起作用,但它可能会对性能产生不利影响,因为令牌资源可能会在请求的高并发时被锁定。

Cosmos DB 中的所有写入都是多数仲裁(3/4 副本)。对于只有一个区域的帐户,Bounded staleness 通过执行 2 个副本读取,然后比较每个副本的 LSN 来确保没有过时的读取。如果 LSN 匹配,则数据是最新的并返回给客户端。如果 LSN 不匹配,则返回较高的,因为这将是最新的。

在执行分布式互斥体和使用有限陈旧性之间的权衡是构建分布式互斥体需要时间和精力,并且会对延迟产生不利影响。使用 Bounded Staleness 需要零努力,但每次读取的成本是 Session 的 2 倍,因为它是 2 副本读取,而不是具有 Session 一致性的单个副本。


推荐阅读