Azure CosmosDB (4) 在一致性(Consistency)可用性(Availability)和性能(Performance)之间的权衡

　　《Windows Azure Platform 系列文章目录》

　　我个人感觉，这个概念和分布式系统中的CAP原则是类似的：

　　CAP原则指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼

　　Azure CosmosDB有五种一致性级别，从数据一致性角度来说，我们按照最强的一致性，到最低的一致性，排序如下：

　　1.Strong (强一致性)

　　2.Bounded Staleness

　　3.Session (会话一致性)

　　4.Consistent prefix (一致性前缀)

　　5.最终一致性 (Eventual Consistency)

　　每一种级别都在一致性(Consistency)可用性(Availability)和性能(Performance)之间进行了权衡，并且有SLA (Service Level Agreement)

　　一致性级别和延迟

　　对所有一致性级别的读操作延迟，在第99位百分位的延迟小于10毫秒。该读操作的延迟是有SLA保障的。

　　The read latency for all consistency levels is always guaranteed to be less than 10 milliseconds at the 99th percentile. This read latency is backed by the SLA.

　　平均的读延迟，在第50个百分位的延迟小于2毫秒。The average read latency, at the 50th percentile, is typically 2 milliseconds or less

　　跨多个Azure区域且配置了Strong (强一致性)的CosmosDB账户，不在上面的性能指标范围内。

　　对所有一致性级别的写操作，在第99位百分位的延迟小于10毫秒。该写操作的延迟也是有SLA保障的。

　　The write latency for all consistency levels is always guaranteed to be less than 10 milliseconds at the 99th percentile. This write latency is backed by the SLA.

　　平均的写操作，在第50个百分位的延迟小于5毫秒

　　当Azure CosmosDB账户跨一个Azure数据中心区域，且配置了强一致性(Strong)的场景情况下，

　　写入延迟保证小于两个最远Azure区域中任何一个之间的往返时间（RTT）的两倍，加上第99百分位数的10毫秒。

　　这里举个例子，假设我们创建了Azure CosmosDB账户，且跨越了：Azure 新加坡数据中心、Azure香港数据中心和Azure东京数据中心，配置了强(Strong)一致性的场景。

　　写入的延迟=区域中任何一个之间的往返时间（round-trip time，RTT）的两倍=Azure新加坡数据中心<--->Azure东京数据中心之间的往返时间(RTT)的两倍，再加上第99百分位数的10毫秒

　　因为在分布式系统中，针对于强一致性(Strong)写入的场景，需要在所有分布式节点都执行了写入操作后，才会被确定返执行成功。

　　此选项目前处于预览状态

　　准确的往返时间(round-trip time, RTT)取决于光的速度和Azure网络拓扑结构。 Azure 网络不会针对任意两个 Azure 区域之间的 RTT 提供任何延迟 SLA。

　　对于你的 Azure Cosmos 帐户，将在 Azure 门户中显示复制延迟。 可以使用 Azure 门户监视与你的帐户关联的各个区域之间的复制延迟

　　一致性级别和吞吐量

　　在相同Request Unit (是CosmosDB的性能指标，我们会在后面的章节做详细的介绍)情况下，Session (会话一致性)，Consistent prefix (一致性前缀)和最终一致性 (Eventual Consistency)的读取操作的吞吐量，是Strong (强一致性)和Bounded Staleness的两倍

　　对于给定类型的写入操作（例如插入、替换、更新插入和删除），所有一致性级别在相同的Request Unit情况下，写入吞吐量是相同的

　　

　　一致性界别和数据持久化

　　在Azure多区域分布式数据库环境中，当发生区域范围的服务中断时，一致性级别与数据持续性之间存在直接关系。 制定业务连续性计划时，需了解应用程序在中断事件发生后完全恢复之前的最大可接受时间。 应用程序完全恢复所需的时间称为恢复时间目标 (RTO)。 此外，还需要了解从中断事件恢复时，应用程序可忍受最近数据更新丢失的最长期限。 可以承受更新丢失的时限称为恢复点目标 (RPO)。

　　下表定义了当发生区域范围的服务中断时，一致性模型与数据持续性之间的关系。 请务必注意，在分布式系统中，由于 CAP 定理的存在，即使一致性较高，也不可能存在 RPO 和 RTO 为零的分布式数据库

Azure区域	复制模式	一致性级别	RPO	RTO
1	单主或多主 Single or Multi-Master	任何一致性级别	<240分钟	<1周
>1	单主 Single Master	Session (会话一致性) Consistent prefix (一致性前缀) 最终一致性 (Eventual Consistency)	<15分钟	<15分钟
>1	单主 Single Master	Bounded Staleness	K&T	<15分钟
>1	多主 Multi-Master	Session (会话一致性) Consistent prefix (一致性前缀) 最终一致性 (Eventual Consistency)	<15分钟	0
>1	多主 Multi-Master	Bounded Staleness	K&T	0
>1	单主或多主 Single or Multi-Master	Strong (强一致性)	0	<15分钟

　　K = 某个项的“K”版本（更新）的数目。

　　T =时间“T”，自上次更新以来的时间间隔。