选择适当的一致性级别Choose the right consistency level

依赖于复制以实现高可用性、低延迟或这两者的分布式数据库在读取一致性与可用性、延迟和吞吐量之间进行基本权衡。Distributed databases relying on replication for high availability, low latency or both, make the fundamental tradeoff between the read consistency vs. availability, latency, and throughput. 大多数商用分布式数据库都要求开发人员在两种极端一致性模型之间进行选择:非常一致和最终一致。 Most commercially available distributed databases ask developers to choose between the two extreme consistency models: strong consistency and eventual consistency. 开发人员使用 Azure Cosmos DB 可在五个妥善定义的一致性模型(非常、有限过期、会话、一致前缀和最终)之间进行选择。 Azure Cosmos DB allows developers to choose among the five well-defined consistency models: strong, bounded staleness, session, consistent prefix and eventual. 这些一致性模型中的每一种都具有明确的定义并直观呈现,可用于特定的真实场景。Each of these consistency models is well-defined, intuitive and can be used for specific real-world scenarios. 五种一致性模型中的每一种在精确的可用性与性能方面都进行了权衡,并有全面的 SLA 作为保障。Each of the five consistency models provide precise availability and performance tradeoffs and are backed by comprehensive SLAs. 可以在帐户级别配置默认一致性,并在请求级别替代它You can configure a default consistency at the account level and override it at the request level. 以下简单的注意事项将有助于你在许多常见方案中做出正确的选择。The following simple considerations will help you make the right choice in many common scenarios.

SQL API 和表 APISQL API and Table API

如果应用程序是使用 SQL API 或表 API 生成的,请注意以下几点:Consider the following points if your application is built using SQL API or Table API:

  • 对于许多真实场景中,会话一致性是最佳也是推荐的选项。For many real-world scenarios, session consistency is optimal and it's the recommended option. 有关详细信息,请参阅如何管理应用程序的会话令牌For more information, see, How-to manage session token for your application.

  • 如果应用程序需要非常一致,建议使用有限过期一致级别。If your application requires strong consistency, it is recommended that you use bounded staleness consistency level.

  • 如果需要比会话一致性和写入的个位数毫秒延迟所提供的更严格的一致性保证,建议使用有限过期一致性级别。If you need stricter consistency guarantees than the ones provided by session consistency and single-digit-millisecond latency for writes, it is recommended that you use bounded staleness consistency level.

  • 如果应用程序需要最终一致,建议使用一致前缀一致性级别。If your application requires eventual consistency, it is recommended that you use consistent prefix consistency level.

  • 如果需要的一致性不如会话一致性提供的那么严格的话,建议使用一致前缀一致性级别。If you need less strict consistency guarantees than the ones provided by session consistency, it is recommended that you use consistent prefix consistency level.

  • 如果需要最高可用性和最低延迟,请使用最终一致级别。If you need the highest availability and the lowest latency, then use eventual consistency level.

  • 如果需要更高的数据持久性而不想牺牲性能,可以在应用层创建自定义一致性级别。If you need even higher data durability without sacrificing performance, you can create a custom consistency level at the application layer. 有关详细信息,请参阅如何在应用程序中实现自定义同步For more information see, How-to implement custom synchronization in your applications.

Cassandra、MongoDB 和 Gremlin APICassandra, MongoDB, and Gremlin APIs

一致性保证的实践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.

  • 当一致性级别设置为“有限过期”时,Cosmos DB 保证客户端始终读取前一次写入的值,伴有一个受到过期窗口限制的延迟****。When the consistency level is set to bounded staleness, Cosmos DB guarantees that the clients always read the value of a previous write, with a lag bounded by the staleness window.

  • 当一致性级别设置为“强”时,过期窗口等于零,并且保证客户端读取写入操作的最新提交值****。When the consistency level is set to strong, the staleness window is equivalent to zero, and the clients are guaranteed to read the latest committed value of the write operation.

  • 对于剩余的三个一致性级别,过期窗口在很大程度上取决于你的工作负载。For the remaining three consistency levels, the staleness window is largely dependent on your workload. 例如,如果未在数据库上执行任何写入操作,具有“最终”、“会话”或“一致前缀”一致性级别的读取操作可能产生与具有非常一致级别的读取操作相同的结果************。For example, 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.

后续步骤Next steps

阅读以下文章中有关一致性级别的详细信息:Read more about the consistency levels in the following articles: