一致性、可用性和性能权衡Consistency, availability, and performance tradeoffs

依赖复制以实现高可用性和/或低延迟的分布式数据库必须做出权衡。Distributed databases that rely on replication for high availability, low latency, or both must make tradeoffs. 在读取一致性与可用性、延迟和吞吐量之间做出权衡。The tradeoffs are between read consistency vs. availability, latency, and throughput.

Azure Cosmos DB 通过某种选择范围来实现数据一致性。Azure Cosmos DB approaches data consistency as a spectrum of choices. 此方法包含多个选项,而不会走非常一致性和最终一致性这两种极端。This approach includes more options than the two extremes of strong and eventual consistency. 可以从一致性范畴的五个定义完善的级别中进行选择。You can choose from five well-defined levels on the consistency spectrum. 按最强到最弱的顺序,级别分别为:From strongest to weakest, the levels are:

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

每个级别均提供可用性和性能权衡,并由综合 SLA 提供支持。Each level provides availability and performance tradeoffs and is backed by comprehensive SLAs.

一致性级别和延迟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. 此读取延迟由 SLA 提供保障。This read latency is backed by the SLA. 平均(在第 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. 此写入延迟由 SLA 提供保障。This write latency is backed by the SLA. 平均(在第 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

一致性级别和数据持续性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 定理的存在,即使一致性较高,也不可能存在 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 the CAP Theorem. 若要详细了解原因,请参阅 Azure Cosmos DB 中的一致性级别To learn more about why, see Consistency levels in Azure Cosmos DB.

区域Region(s) 复制模式Replication mode 一致性级别Consistency level RPORPO RTORTO
11 单主或多主数据库Single or Multi-Master 任何一致性级别Any Consistency Level < 240 分钟< 240 Minutes <1 周<1 Week
>1>1 单主数据库Single Master 会话、一致的前缀或最终Session, Consistent Prefix, Eventual < 15 分钟< 15 minutes < 15 分钟< 15 minutes
>1>1 单主数据库Single Master 有限过期Bounded Staleness K & TK & T < 15 分钟< 15 minutes
>1>1 单主数据库Single Master Strong 00 < 15 分钟< 15 minutes
>1>1 多主数据库Multi-Master 会话、一致的前缀或最终Session, Consistent Prefix, Eventual < 15 分钟< 15 minutes 00
>1>1 多主数据库Multi-Master 有限过期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.

强一致性和多主数据库Strong consistency and multi-master

针对多主数据库配置的 Cosmos 帐户不能配置为实施强一致性,因为分布式系统不可能在提供为零的 RPO 的同时提供为零的 RTO。Cosmos accounts configured for multi-master 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 for using strong consistency with multi-master as any write into any region must be replicated and committed to all configured regions within the account. 这导致写入延迟与单主数据库帐户相同。This results in the same write latency as a single master account.

后续步骤Next steps

详细了解多区域分布,以及分布式系统中的常规一致性利弊。Learn more about multiple-region distribution and general consistency tradeoffs in distributed systems. 请参阅以下文章:See the following articles: