Azure CosmosDB中的数据一致性-ESG跨境

Azure CosmosDB中的数据一致性

Azure CosmosDB中的数据一致性

为了保证分布式数据库的高可用性和低延迟，我们需要在可用性、延迟和吞吐量之间进行权衡。

大多数商业分布式数据库要求开发者选择两种极端的数据库一致性:强一致性和终极一致性。

强一致性是数据库编程的黄金标准。然而，它需要较高的延迟，并且在故障期间其可用性较低。

另一方面，最终的一致性提供了更高的可用性和更好的性能，但是应用程序编程非常困难。

Azure Cosmos DB通过一定范围的选择实现数据一致性，而不是走向两个极端。

虽然强一致性和最终一致性处于极端，但在整个范围内有许多一致性选项。开发人员可以使用这些选项在高可用性或性能方面做出精确的选择和谨慎的权衡。

使用Azure Cosmos DB，开发人员可以在一致性范围内从五个定义良好的一致性模型中进行选择。

从最强到最弱，这些模型是强的、有界的陈旧性、会话、一致前缀和最终一致性。

该模型定义清晰且直观。它们可以用于特定的真实场景。每个模型都提供了可用性和性能之间的权衡，并受全面的SLA支持。下图以范围间隔的形式显示了不同的一致性级别。

一致性水平与地区无关。无论是从哪个区域提供读写，Azure Cosmos帐户关联的区域数量，还是帐户配置单个或多个写区域，所有的读操作都保证Azure Cosmos DB帐户的一致性级别。

与一致性级别相关的保证

Azure Cosmos DB提供的全面SLA可以保证100%的读取请求满足任何选定一致性级别的一致性保证。如果符合与一致性级别相关的所有一致性保证，则读取请求符合一致性SLA。

下面描述了5个一致性级别的描述:

Strong(强一致性):强一致性保证了读取操作，并且总是返回最新提交的版本。客户端永远不会看到未提交或未完成的写入。始终确保用户读取最新提交的写入。

有界陈旧性:读操作(Read)最多可以比写操作(Write)晚K个版本，即T个时间。如果我们选择有界陈旧性，陈旧性可以用两种方式设置:

版本号k

读操作可能落后于写操作的时间间隔(t)。

强一致性场景类似于有限过期的概念，但是过期窗口(过期窗口)是0。

当客户端在接受写操作的区域执行读操作时，有界陈旧的一致性提供的保证与强一致性提供的保证相同。

会话:会话一致性的范围仅限于客户端会话。

例如，假设我们支持多会话场景。其中一个客户端A在CosmosDB上进行添加、删除和查询操作，所以客户端只能看到自己提交的内容。

其他客户B、C等。，看不到客户端a执行操作的结果。

一致前缀:返回的更新包含所有更新的一些前缀，没有间隔。一致的前缀保证了读取永远不会看到无序的写入。

最终一致性): S2/]不保证阅读的顺序。如果任何进一步的写入丢失，拷贝将最终收敛。

接下来，我们举个例子:

让我们以棒球比赛为例。这场比赛目前在第七局中间。这是第七场比赛。目前客队25落后。

Azure CosmosDB保存主队和客队的分数。下表列出了五种不同一致性条件下读取主队和客队比分的情况。

有兴趣可以参考这篇文章:https://www . Microsoft . com/enus/research/WPcontent/uploads/2011/10/consistencyandbaseballreport . pdf。

特别声明：以上文章内容仅代表作者本人观点，不代表ESG跨境电商观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与ESG跨境电商联系。