Azure CosmosDB 在一致性(Consistency)可用性(Availability)和性能(Performance-ESG跨境

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

Azure CosmosDB在一致性、可用性和性能之间的权衡

个人感觉这个概念类似于分布式系统中的CAP原理:

CAP原则是指在分布式系统中，一致性、可用性和分区容忍度不能兼得。

Azure CosmosDB有五个一致性级别。从数据一致性的角度来看，我们按照一致性最强到最低的顺序排列如下:

1.强(强一致性)

2.有限的陈旧

3.会话(会话一致性)

4.一致前缀(一致前缀)

5.终极一致性(最终一致性)

每个级别都有一致性、可用性和性能之间的权衡，并有SLA(服务级别协议)。

一致性级别和延迟

对于所有一致性级别，第99个百分位数的读取延迟小于10毫秒。这个读操作的延迟由SLA保证。

在第99百分位，所有一致性级别的读取延迟始终保证小于10毫秒。SLA支持这种读取延迟。

在第50百分位，平均读取延迟小于2毫秒。第50个百分位的平均读取延迟通常为2毫秒或更少

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

对于所有一致性级别的写入，第99个百分点的延迟小于10毫秒。这个写操作的延迟也由SLA保证。

在第99个百分点处，所有一致性级别的写入延迟始终保证小于10毫秒。SLA支持这种写入延迟。

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

当Azure CosmosDB帐户跨越Azure数据中心区域并且配置了强一致性场景时，

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

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

写入延迟=任何一个地区之间往返时间(RTT)的两倍=Azure Singapore数据中心lt；gt；东京Azure数据中心之间往返时间(RTT)的两倍，加上第99百分位的10毫秒。

因为在分布式系统中，对于强写的场景，需要在所有分布式节点都进行了写操作后，才能确定执行成功。

此选项当前处于预览状态。

准确的往返时间，RTT)取决于光速和Azure网络拓扑。Azure network不会为任何两个Azure区域之间的RTT提供任何延迟SLA。

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

一致性级别和吞吐量

同样的请求单元(CosmosDB的性能指标，后面章节会详细介绍)，Session(会话一致性)、Consistent prefix(一致性前缀)和final consistency(最终一致性)读操作的吞吐量是Strong(强一致性)和有界一致性的两倍。

对于给定类型的写操作(如插入、替换、更新插入和删除)，所有一致性级别在同一请求单元下具有相同的写吞吐量。

一致性扇区和数据持久性

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

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

K=一个项目的“k”个版本(更新)的数量。

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

特别声明：以上文章内容仅代表作者本人观点，不代表ESG跨境电商观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与ESG跨境电商联系。