Azure Cosmos DB 中的一致性级别Consistency levels in Azure Cosmos DB

适用于: SQL API Cassandra API Gremlin API 表 API Azure Cosmos DB API for MongoDB

依赖于复制实现高可用性和/或低延迟的分布式数据库必须在 PACLC 定理定义的读取一致性、可用性、延迟和吞吐量之间进行基本权衡。Distributed databases that rely on replication for high availability, low latency, or both, must make a fundamental tradeoff between the read consistency, availability, latency, and throughput as defined by the PACLC theorem. 非常一致性模型的可线性化是数据可编程性的黄金标准。The linearizability of the strong consistency model is the gold standard of data programmability. 但是,由于数据必须跨远距离进行复制和提交,因此写入延迟较高,从而增加了高昂的成本。But it adds a steep price from higher write latencies due to data having to replicate and commit across large distances. 由于数据无法在每个区域中复制和提交,因此非常一致性也可能因可用性降低(在失败期间)而受到影响。Strong consistency may also suffer from reduced availability (during failures) because data cannot replicate and commit in every region. 最终一致性提供了更高的可用性和更好的性能,但更难对应用程序编程,因为数据可能不会在所有区域完全一致。Eventual consistency offers higher availability and better performance, but its more difficult to program applications because data may not be completely consistent across all regions.

目前市场上大多数商业用途的分布式 NoSQL 数据库只能提供非常一致性和最终一致性。Most commercially available distributed NoSQL databases available in the market today provide only strong and eventual consistency. Azure Cosmos DB 提供五个妥善定义的级别。Azure Cosmos DB offers five well-defined levels. 按最强到最弱的顺序,级别分别为:From strongest to weakest, the levels are:

  • 非常Strong
  • 有限过期Bounded staleness
  • 会话Session
  • 一致前缀Consistent prefix
  • 最终Eventual

每个级别在可用性与性能方面各有利弊。Each level provides availability and performance tradeoffs. 下图以范围区间形式显示了不同的一致性级别。The following image shows the different consistency levels as a spectrum.

范围形式的一致性

一致性级别与区域无关,无论在哪个区域为读取和写入操作提供服务、与 Azure Cosmos 帐户关联的区域数量是多少,或者帐户是配置了单个还是多个写入区域,都可以保证所有操作获得这种一致性。The consistency levels are region-agnostic and are guaranteed for all operations regardless of the region from which the reads and writes are served, the number of regions associated with your Azure Cosmos account, or whether your account is configured with a single or multiple write regions.

一致性级别和 Azure Cosmos DB APIConsistency levels and Azure Cosmos DB APIs

Azure Cosmos DB 为常用数据库提供对与线路协议兼容的 API 的本机支持。Azure Cosmos DB provides native support for wire protocol-compatible APIs for popular databases. 这些数据库包括 MongoDB、Apache Cassandra、Gremlin 和 Azure 表存储。These include MongoDB, Apache Cassandra, Gremlin, and Azure Table storage. 使用 Gremlin API 和表 API 时,会使用 Azure Cosmos 帐户上配置的默认一致性级别。When using Gremlin API and Table API, the default consistency level configured on the Azure Cosmos account is used. 有关 Cassandra API 或适用于 MongoDB 的 API 与 Azure Cosmos DB 的一致性级别之间的一致性级别映射的详细信息,请参阅 Cassandra API 一致性映射适用于 MongoDB 的 API 一致性映射For details on consistency level mapping between Cassandra API or the API for MongoDB and Azure Cosmos DB's consistency levels see, Cassandra API consistency mapping and API for MongoDB consistency mapping.

读取一致性的范围Scope of the read consistency

读取一致性适用于逻辑分区范围内的单个读取操作。Read consistency applies to a single read operation scoped within a logical partition. 读取操作可能由远程客户端或存储过程发出。The read operation can be issued by a remote client or a stored procedure.

配置默认一致性级别Configure the default consistency level

随时都可在 Azure Cosmos DB 帐户中配置默认的一致性级别。You can configure the default consistency level on your Azure Cosmos account at any time. 在帐户中配置的默认一致性级别适用于该帐户下的所有 Azure Cosmos 数据库和容器。The default consistency level configured on your account applies to all Azure Cosmos databases and containers under that account. 针对某个容器或数据库发出的所有读取和查询默认使用指定的一致性级别。All reads and queries issued against a container or a database use the specified consistency level by default. 有关详细信息,请参阅如何配置默认一致性级别To learn more, see how to configure the default consistency level. 还可以覆盖特定请求的默认一致性级别,若要了解详细信息,请参阅如何覆盖默认一致性级别一文。You can also override the default consistency level for a specific request, to learn more, see how to Override the default consistency level article.

与一致性级别关联的保证Guarantees associated with consistency levels

Azure Cosmos DB 可保证 100% 的读取请求满足所选一致性级别的一致性保证。Azure Cosmos DB guarantees that 100 percent of read requests meet the consistency guarantee for the consistency level chosen. azure-cosmos-tla GitHub 存储库中提供了 Azure Cosmos DB 中使用 TLA+ 规范语言精确定义的五个一致性级别。The precise definitions of the five consistency levels in Azure Cosmos DB using the TLA+ specification language are provided in the azure-cosmos-tla GitHub repo.

下面描述了五个一致性级别的语义:The semantics of the five consistency levels are described here:

  • 非常一致性:非常一致性提供可线性化保证。Strong: Strong consistency offers a linearizability guarantee. 可线性化是指并发处理请求。Linearizability refers to serving requests concurrently. 保证读取操作返回项的最新提交版本。The reads are guaranteed to return the most recent committed version of an item. 客户端永远不会看到未提交或不完整的写入。A client never sees an uncommitted or partial write. 始终保证用户读取最新确认的写入。Users are always guaranteed to read the latest committed write.

    下图以乐谱形式演示了非常一致性。The following graphic illustrates the strong consistency with musical notes. 将数据写入“中国北部 2”区域后,当你从其他区域读取这些数据时,将会获得最新的值:After the data is written to the "China North 2" region, when you read the data from other regions, you get the most recent value:

    非常一致性级别的插图

  • 受限停滞一致性:保证读取操作遵循一致性前缀保证。Bounded staleness: The reads are guaranteed to honor the consistent-prefix guarantee. 读取操作可以滞后于写入操作最多“K”个项版本(即“更新”)或“T”时间间隔,以先达到者为准。The reads might lag behind writes by at most "K" versions (that is, "updates") of an item or by "T" time interval, whichever is reached first. 换言之,如果选择有限过期,则可以通过两种方式配置“过期”:In other words, when you choose bounded staleness, the "staleness" can be configured in two ways:

    • 项的版本数 (K)The number of versions (K) of the item
    • 时间间隔 (T) 读取操作可以滞后于写入操作The time interval (T) reads might lag behind the writes

    对于单区域帐户,K 和 T 的最小值为 10 个写入操作或 5 秒 。For a single region account, the minimum value of K and T is 10 write operations or 5 seconds. 对于多区域帐户,K 和 T 的最小值为 100,000 个写入操作或 300 秒 。For multi-region accounts the minimum value of K and T is 100,000 write operations or 300 seconds.

    有限过期在“过期窗口”之外提供全局整体顺序。Bounded staleness offers total global order outside of the "staleness window." 当客户端在接受写入的区域中执行读取操作时,有限过期一致性提供的保证与非常一致性的保证相同。When a client performs read operations within a region that accepts writes, the guarantees provided by bounded staleness consistency are identical to those guarantees by the strong consistency. 随着过期窗口接近时间或更新(以更近者为准),服务将限制新写入,以允许复制跟上并遵守一致性保证。As the staleness window approaches for either time or updates, whichever is closer, the service will throttle new writes to allow replication to catch up and honor the consistency guarantee.

    在过期窗口内,有限过期提供以下一致性保证:Inside the staleness window, Bounded Staleness provides the following consistency guarantees:

    • 对于具有单个写入区域的帐户,同一区域中的客户端的一致性为“非常”Consistency for clients in the same region for an account with single write region = Strong
    • 对于具有单个写入区域的帐户,不同区域中的客户端的一致性为“一致前缀”Consistency for clients in different regions for an account with single write region = Consistent Prefix
    • 对于具有多个写入区域的帐户,写入单个区域的客户端的一致性为“一致前缀”Consistency for clients writing to a single region for an account with multiple write regions = Consistent Prefix
    • 对于具有多个写入区域的帐户,写入不同区域的客户端的一致性为“最终”Consistency for clients writing to different regions for an account with multiple write regions = Eventual

    预期写入延迟较低,但需要保证全局整体顺序的多区域分布式应用程序经常选择“有限过期”。Bounded staleness is frequently chosen by multiple-regionally distributed applications that expect low write latencies but require total global order guarantee. 有限过期非常适合提供小组协作和共享、股票行情、发布-订阅/排队等功能的应用程序。下图以乐谱形式演示了有限过期一致性。Bounded staleness is great for applications featuring group collaboration and sharing, stock ticker, publish-subscribe/queueing etc. The following graphic illustrates the bounded staleness consistency with musical notes. 将数据写入“中国北部 2”区域后,“中国东部 2”和“澳大利亚东部”区域将会根据所配置的最大滞后时间或最大操作数目读取写入的值:After the data is written to the "China North 2" region, the "China East 2" and "Australia East" regions read the written value based on the configured maximum lag time or the maximum operations:

    有限过期一致性级别的插图

  • 会话一致性:在单个客户端会话中,将保证读取操作遵循一致前缀、单调读取、单调写入、读取写入和读取后写入保证。Session: Within a single client session reads are guaranteed to honor the consistent-prefix, monotonic reads, monotonic writes, read-your-writes, and write-follows-reads guarantees. 这采用单个“写入器”会话,或者多个写入器共享会话令牌。This assumes a single "writer" session or sharing the session token for multiple writers.

    在会话外部执行写入的客户端将获得以下保证:Clients outside of the session performing writes will see the following guarantees:

    • 对于具有单个写入区域的帐户,同一区域中的客户端的一致性为“一致前缀”Consistency for clients in same region for an account with single write region = Consistent Prefix
    • 对于具有单个写入区域的帐户,不同区域中的客户端的一致性为“一致前缀”Consistency for clients in different regions for an account with single write region = Consistent Prefix
    • 对于具有多个写入区域的帐户,写入单个区域的客户端的一致性为“一致前缀”Consistency for clients writing to a single region for an account with multiple write regions = Consistent Prefix
    • 对于具有多个写入区域的帐户,写入多个区域的客户端的一致性为“最终”Consistency for clients writing to multiple regions for a account with multiple write regions = Eventual

    “会话一致性”是最广泛用于单个区域以及多区域分布式应用程序的一致性级别。Session consistency is the most widely used consistency level for both single region as well as multiple-regionally distributed applications. 它不仅提供与最终一致性相当的写入延迟、可用性和读取吞吐量,还提供一致性保证,从而满足了编写为在用户上下文中运行的应用程序的需求。It provides write latencies, availability, and read throughput comparable to that of eventual consistency but also provides the consistency guarantees that suit the needs of applications written to operate in the context of a user. 下图以乐谱形式演示了会话一致性。The following graphic illustrates the session consistency with musical notes. “中国北部 2 写入器”和“中国北部 2 读取器”正在使用同一个会话(会话 A),因此它们会同时读取相同的数据。The "China North 2 writer" and the "China North 2 reader" are using the same session (Session A) so they both read the same data at the same time. 而“澳大利亚东部”区域正在使用“会话 B”,因此,它会稍后才会接收到数据,但接收顺序与写入顺序相同。Whereas the "Australia East" region is using "Session B" so, it receives data later but in the same order as the writes.

    会话一致性级别的插图

  • 一致前缀:返回的更新包含所有更新的一些前缀,不带间隔。Consistent prefix: Updates that are returned contain some prefix of all the updates, with no gaps. 一致前缀一致性级别保证读取操作永远不会看到无序写入。Consistent prefix consistency level guarantees that reads never see out-of-order writes.

    如果写入是按 A, B, C 顺序执行的,则客户端会看到 AA,BA,B,C,但永远不会看到类似于 A,CB,A,C 的失序排列情况。If writes were performed in the order A, B, C, then a client sees either A, A,B, or A,B,C, but never out-of-order permutations like A,C or B,A,C. 一致前缀的延迟、可用性和读取吞吐量与最终一致性相当,但还会提供顺序保证,以适应顺序非常重要的方案的需求。Consistent Prefix provides write latencies, availability, and read throughput comparable to that of eventual consistency, but also provides the order guarantees that suit the needs of scenarios where order is important.

    下面是一致前缀的一致性保证:Below are the consistency guarantees for Consistent Prefix:

    • 对于具有单个写入区域的帐户,同一区域中的客户端的一致性为“一致前缀”Consistency for clients in same region for an account with single write region = Consistent Prefix
    • 对于具有单个写入区域的帐户,不同区域中的客户端的一致性为“一致前缀”Consistency for clients in different regions for an account with single write region = Consistent Prefix
    • 对于具有多个写入区域的帐户,写入单个区域的客户端的一致性为“一致前缀”Consistency for clients writing to a single region for an account with multiple write region = Consistent Prefix
    • 对于具有多个写入区域的帐户,写入多个区域的客户端的一致性为“最终”Consistency for clients writing to multiple regions for an account with multiple write region = Eventual

    下图以乐谱形式演示了一致前缀一致性。The following graphic illustrates the consistency prefix consistency with musical notes. 在所有区域中,读取操作永远不会看到无序写入:In all the regions, the reads never see out of order writes:

    一致前缀的插图

  • 最终一致性:不保证读取的顺序。Eventual: There's no ordering guarantee for reads. 如果缺少任何进一步的写入,则副本最终会收敛。In the absence of any further writes, the replicas eventually converge.
    最终一致性是最弱的一致性形式,因为客户端可能会读取比之前读取的值还要旧的值。Eventual consistency is the weakest form of consistency because a client may read the values that are older than the ones it had read before. 最终一致性非常适合不需要任何顺序保证的应用程序。Eventual consistency is ideal where the application does not require any ordering guarantees. 示例包括推文、点赞或无回复评论的计数。Examples include count of Retweets, Likes, or non-threaded comments. 下图以乐谱形式演示了最终一致性。The following graphic illustrates the eventual consistency with musical notes.

    最终一致性的插图

一致性保证的实践Consistency guarantees in practice

在实践中,你可能经常会获得更强的一致性保证。In practice, you may often get stronger consistency guarantees. 读取操作的一致性保证对应于所请求的数据库状态的新旧程度和顺序。Consistency guarantees for a read operation correspond to the freshness and ordering of the database state that you request. 读取一致性与写入/更新操作的排序和传播有关。Read-consistency is tied to the ordering and propagation of the write/update operations.

如果未在数据库上执行任何写入操作,具有“最终”、“会话”或“一致前缀”一致性级别的读取操作可能产生与具有非常一致性级别的读取操作相同的结果 。If there are no write operations on the database, a read operation with eventual, session, or consistent prefix consistency levels is likely to yield the same results as a read operation with strong consistency level.

如果使用非常一致性以外的一致性级别配置了 Azure Cosmos 帐户,则可以通过查看概率有限过期 (PBS) 指标,找到客户端获得工作负荷的非常一致读取的概率。If your Azure Cosmos account is configured with a consistency level other than the strong consistency, you can find out the probability that your clients may get strong and consistent reads for your workloads by looking at the Probabilistically Bounded Staleness (PBS) metric. 此指标在 Azure 门户中公开,若要了解详细信息,请参阅监视概率有限过期性 (PBS) 指标This metric is exposed in the Azure portal, to learn more, see Monitor Probabilistically Bounded Staleness (PBS) metric.

概率有限过期表明了最终一致的最终程度。Probabilistic bounded staleness shows how eventual is your eventual consistency. 通过此指标可深入了解在 Azure Cosmos 帐户中目前配置的一致性级别之间获得更非常一致性的频率。This metric provides an insight into how often you can get a stronger consistency than the consistency level that you have currently configured on your Azure Cosmos account. 换句话说,可看到获得写入和读取区域组合的非常一致读取的概率(以毫秒计量)。In other words, you can see the probability (measured in milliseconds) of getting strongly consistent reads for a combination of write and read regions.

一致性级别和延迟Consistency levels and latency

所有一致性级别的读取延迟始终保证在第 99 百分位小于 10 毫秒。The read latency for all consistency levels is always guaranteed to be less than 10 milliseconds at the 99th percentile. 平均(在第 50 百分位)读取延迟通常不超过 4 毫秒。The average read latency, at the 50th percentile, is typically 4 milliseconds or less.

所有一致性级别的写入延迟始终保证在第 99 百分位小于 10 毫秒。The write latency for all consistency levels is always guaranteed to be less than 10 milliseconds at the 99th percentile. 平均(在第 50 百分位)写入延迟通常不超过 5 毫秒。The average write latency, at the 50th percentile, is usually 5 milliseconds or less. 跨多个区域且使用非常一致性配置的 Azure Cosmos 帐户不在此保障内。Azure Cosmos accounts that span several regions and are configured with strong consistency are an exception to this guarantee.

写入延迟和强一致性Write latency and Strong consistency

对于配置了强一致性(与多个区域一致)的 Azure Cosmos 帐户,99% 的情况下写入延迟等于任意两个最远区域之间的往返时间 (RTT) 的两倍加上 10 毫秒。For Azure Cosmos accounts configured with strong consistency with more than one region, the write latency is equal to two times round-trip time (RTT) between any of the two farthest regions, plus 10 milliseconds at the 99th percentile. 区域之间的高网络 RTT 将转变为 Cosmos DB 请求的更高延迟,因为只有在确保已将操作提交到帐户中的所有区域之后,强一致性才会完成该操作。High network RTT between the regions will translate to higher latency for Cosmos DB requests since strong consistency completes an operation only after ensuring that it has been committed to all regions within an account.

确切的 RTT 延迟取决于光速距离和 Azure 网络拓扑。The exact RTT latency is a function of speed-of-light distance and the Azure networking topology. Azure 网络不会针对任意两个 Azure 区域之间的 RTT 提供任何延迟 SLA。Azure networking doesn't provide any latency SLAs for the RTT between any two Azure regions. 对于你的 Azure Cosmos 帐户,将在 Azure 门户中显示复制延迟。For your Azure Cosmos account, replication latencies are displayed in the Azure portal. 可以使用 Azure 门户(转到“指标”边栏选项卡,选择“一致性”选项卡)监视与 Azure Cosmos 帐户关联的各个区域之间的复制延迟。You can use the Azure portal (go to the Metrics blade, select Consistency tab) to monitor the replication latencies between various regions that are associated with your Azure Cosmos account.

重要

由于写入延迟大,默认情况下会阻止区域跨越 5000 英里(8000 公里)以上的帐户的强一致性。Strong consistency for accounts with regions spanning more than 5000 miles (8000 kilometers) is blocked by default due to high write latency. 若要启用此功能,请联系支持人员。To enable this capability please contact support.

一致性级别和吞吐量Consistency levels and throughput

  • 对于强一致性和有限过期一致性,将针对一个四副本集中的两个副本(少数仲裁)进行读取,以提供一致性保证。For strong and bounded staleness, reads are done against two replicas in a four replica set (minority quorum) to provide consistency guarantees. 会话一致性、一致前缀一致性和最终一致性执行单副本读取。Session, consistent prefix and eventual do single replica reads. 结果是,在请求单位数量相同的情况下,强一致性和有限过期一致性的读取吞吐量是其他一致性级别的一半。The result is that, for the same number of request units, read throughput for strong and bounded staleness is half of the other consistency levels.

  • 对于给定类型的写入操作(例如插入、替换、更新插入和删除),所有一致性级别为请求单元提供的写入吞吐量是相同的。For a given type of write operation, such as insert, replace, upsert, and delete, the write throughput for request units is identical for all consistency levels.

    一致性级别Consistency Level 仲裁读取Quorum Reads 仲裁写入Quorum Writes
    非常Strong 本地少数Local Minority 全局多数Global Majority
    有限过期Bounded Staleness 本地少数Local Minority 本地多数Local Majority
    会话Session 单个副本(使用会话令牌)Single Replica (using session token) 本地多数Local Majority
    一致前缀Consistent Prefix 单个副本Single Replica 本地多数Local Majority
    最终Eventual 单个副本Single Replica 本地多数Local Majority

    备注

    就读取成本 (RU/s) 而言,本地少数读取是较弱一致性级别的两倍,因为读取从两个副本进行,以便为非常和有限过期提供一致性保证。The RU/s cost of reads for Local Minority reads are twice that of weaker consistency levels because reads are made from two replicas to provide consistency guarantees for Strong and Bounded Staleness.

一致性级别和数据持续性Consistency levels and data durability

在多区域分布式数据库环境中,当发生区域范围的服务中断时,一致性级别与数据持续性之间存在直接关系。Within a multiple-regionally distributed database environment there is a direct relationship between the consistency level and data durability in the presence of a region-wide outage. 制定业务连续性计划时,需了解应用程序在中断事件发生后完全恢复之前的最大可接受时间。As you develop your business continuity plan, you need to understand the maximum acceptable time before the application fully recovers after a disruptive event. 应用程序完全恢复所需的时间称为 恢复时间目标 (RTO)。The time required for an application to fully recover is known as recovery time objective (RTO). 此外,还需要了解从中断事件恢复时,应用程序可忍受最近数据更新丢失的最长期限。You also need to understand the maximum period of recent data updates the application can tolerate losing when recovering after a disruptive event. 可以承受更新丢失的时限称为 恢复点目标 (RPO)。The time period of updates that you might afford to lose is known as recovery point objective (RPO).

下表定义了当发生区域范围的服务中断时,一致性模型与数据持续性之间的关系。The table below defines the relationship between consistency model and data durability in the presence of a region wide outage. 需要注意的是,在分布式系统中,即使具有非常一致性,根据 [CAP 定理](https://en.wikipedia.org (THIS WEB SITE IS NOT AVAILABLE ON AZURE CHINA CLOUD) (THIS WEB SITE IS NOT AVAILABLE ON AZURE CHINA CLOUD) /wiki/CAP_theorem),也不可能拥有 RPO 和 RTO 为零的分布式数据库。It is important to note that in a distributed system, even with strong consistency, it is impossible to have a distributed database with an RPO and RTO of zero due to [CAP Theorem](https://en.wikipedia.org (THIS WEB SITE IS NOT AVAILABLE ON AZURE CHINA CLOUD) (THIS WEB SITE IS NOT AVAILABLE ON AZURE CHINA CLOUD) /wiki/CAP_theorem).

区域Region(s) 复制模式Replication mode 一致性级别Consistency level RPORPO RTORTO
11 单个或多个写入区域Single or Multiple write regions 任何一致性级别Any Consistency Level < 240 分钟< 240 Minutes <1 周<1 Week
>1>1 单个写入区域Single write region 会话、一致的前缀或最终Session, Consistent Prefix, Eventual < 15 分钟< 15 minutes < 15 分钟< 15 minutes
>1>1 单个写入区域Single write region 有限过期Bounded Staleness K & TK & T < 15 分钟< 15 minutes
>1>1 单个写入区域Single write region Strong 00 < 15 分钟< 15 minutes
>1>1 多个写入区域Multiple write regions 会话、一致的前缀或最终Session, Consistent Prefix, Eventual < 15 分钟< 15 minutes 00
>1>1 多个写入区域Multiple write regions 有限过期Bounded Staleness K & TK & T 00

K = 某个项的“K”版本(即更新)的数目。 K = The number of "K" versions (i.e., updates) of an item.

T = 自上次更新以来的时间间隔“T”。 T = The time interval "T" since the last update.

对于单区域帐户,K 和 T 的最小值为 10 个写入操作或 5 秒 。For a single region account, the minimum value of K and T is 10 write operations or 5 seconds. 对于多区域帐户,K 和 T 的最小值为 100,000 个写入操作或 300 秒 。For multi-region accounts the minimum value of K and T is 100,000 write operations or 300 seconds. 这定义了使用有限过期时数据的最小 RPO。This defines the minimum RPO for data when using Bounded Staleness.

非常一致性和多个写入区域Strong consistency and multiple write regions

具有多个写入区域的 Cosmos 帐户不能配置为实施非常一致性,因为分布式系统不可能在提供为零的 RPO 的同时提供为零的 RTO。Cosmos accounts configured with multiple write regions cannot be configured for strong consistency as it is not possible for a distributed system to provide an RPO of zero and an RTO of zero. 另外,将非常一致性与多个写入区域配合使用时,没有写入延迟优势,因为对任何区域的任何写入必须在复制后提交到帐户中的所有已配置区域。Additionally, there are no write latency benefits on using strong consistency with multiple write regions because a write to any region must be replicated and committed to all configured regions within the account. 这导致写入延迟与单写入区域帐户相同。This results in the same write latency as a single write region account.

其他阅读材料Additional reading

若要详细了解一致性的概念,请阅读以下文章:To learn more about consistency concepts, read the following articles:

后续步骤Next steps

要详细了解 Azure Cosmos DB 中的一致性级别,请阅读以下文章:To learn more about consistency levels in Azure Cosmos DB, read the following articles: