了解一致性模型

在分布式数据库系统中，当数据通过广域网复制到其他区域，以便为用户提供更高的可用性或更低的读取延迟时，必须在数据在整个数据库中完全一致和数据写入延迟较高之中做出权衡，因为数据以同步方式提交到其他区域。

与其他数据存储解决方案提供的传统强弱选项不同，Azure Cosmos DB 提供具有多种选项的可缩放一致性。

Sliding scale of consistency with five options

这五个一致性级别中的每一个都有明确的定义，相互比较时有明确的优缺点：

一致性级别	说明
非常	线性一致性。数据在所有已配置的区域进行复制和提交，然后确认为已提交且对所有客户端可见。
有限过期	读取滞后于写入，在时间或项上滞后于配置的阈值。
会话	在特定会话（SDK 实例）中，用户可以读取自己的写入。
一致前缀	读取可能滞后于写入，但读取永远不会出现乱序。
最终	读取最终将与写入一致。

非常一致性

强一致性保证所有读取操作都将返回项的最新版本。由于延迟或不一致，客户端应用程序永远不会读取过时的项。写入操作在所有其他区域中准备就绪之前，不会完全提交。

此特性导致强一致性具有最高的延迟，因为它必须等待提交跨较大的地理距离进行复制。

有限过期与强一致性类似，但允许读取滞后于写入最多达到定义的阈值。该阈值可定义为：

对于需要较低写入延迟但需要强制一致性达到合理阈值的应用程序而言，有限过期是一种很好的折衷方案。

提示

有限过期在写入数据的区域内提供强大的一致性保证。

会话一致性可以在单个客户端会话中或在 SDK 和客户端之间传递会话令牌时提供读取自己的写入保证。除此之外，一致性保证会放宽为“前缀一致”或“最终”一致性。

对于最终用户需要立即查看他们刚刚进行的任何事务的应用程序，会话一致性是一个不错的选择。

前缀一致性可提供更松散的一致性和更高的性能，同时保证滞后于写入的读取按写入顺序显示。

前缀一致性非常适合读取操作的顺序比延迟更重要的应用程序。

最终一致性是最弱的一致性形式，其中读取滞后于写入，并且读取可能乱序显示。但是，与其他选项相比，最终一致性将具有最低的写入延迟、最高的可用性并可能实现最大的读取可伸缩性。

对于不需要任何线性或一致性保证的应用程序，最终一致性是一个不错的选择。