Azure CosmosDB (2) CosmosDB中的数据一致性

　　《Windows Azure Platform 系列文章目录》

　　为了保证分布式数据库的高可用性和低延迟性，我们需要在可用性、延迟和吞吐量之间进行权衡。

　　绝大部分的商业分布式数据库，要求开发人员选择两个极端的数据库一致性：强一致性(Strong Consistency)和最终一致性(Eventual Consistency)

　　强一致性(Strong Consistency)是数据库编程的黄金标准。但是却需要更高的延迟，且在故障期间可用性较低。

　　另一方面，最终一致性(Eventual Consistency)提供更高的可用性，和更好的性能，但是应用编程的难度很大。

　　Azure Cosmos DB 通过某种选择范围来实现数据一致性，而不会走两种极端。

　　虽然强一致性和最终一致性处于极端，但在整个范围中有许多一致性选择。 开发人员可以使用这些选项在高可用性或性能方面做出精确的选择和细致的取舍。

　　借助 Azure Cosmos DB，开发人员可以在一致性范围内从五个明确定义的一致性模型中进行选择。

　　从最强到最弱，这些模型为“Strong”、“Bounded Staleness”、“Session”、“Consistent Prefix”和“Eventual Consistency”。

　　模型定义明确且直观。 它们可用于特定的真实场景。 每个模型均提供可用性和性能权衡，并由综合 SLA 提供支持。 下图以范围区间形式显示了不同的一致性级别。

　　

　　一致性级别与区域无关。 无论从哪个区域提供读取和写入、与 Azure Cosmos 帐户关联的区域数量是多少或帐户是配置了单个还是多个写入区域，所有读取操作都保证 Azure Cosmos DB 帐户的一致性级别。

　　与一致性级别关联的保证

　　Azure Cosmos DB 提供的综合 SLA 可保证 100% 的读取请求满足所选任何一致性级别的一致性保证。 如果满足与一致性级别关联的所有一致性保证，则读取请求满足一致性 SLA。

　　

　　下面描述了5种一致性级别的描述：

　　Strong (强一致性): 强一致性保证读取操作，总是返回最新提交的版本。客户端永远不会看到未提交或者不完整的写入。始终保证用户读取最新提交的写入操作

　　Bounded Staleness: 读取操作(Read)可以晚于写入操作(Write) 最多K个版本，或者T个时间。如果我们选择Bounded Staleness，Staleness可以通过两种方式设置：

　　- 版本号K

　　- 读取操作可以滞后于写入操作的时间间隔 (T)

　　强一致性(Strong)的场景，和Bounded Staleness的概念类似，但是过期窗口(Staleness Windows)为0

　　当客户端在接受写入的区域中执行读取操作时，Bounded Staleness的一致性提供的保证与强一致性的保证相同。

　　Session(会话一致性):会话一致性的范围限制在客户端会话。

　　举个例子，假设我们支持多会话(Multi Session)的场景。其中一个客户端A对CosmosDB执行增删改查操作，那该客户端仅能看到自己提交的内容。

　　其他客户端B、C等，不能看到客户端A执行的操作结果

　　Consistent prefix(一致性前缀)：返回的更新包含所有更新的一些前缀，不带间隔。 一致前缀保证读取永远不会看到无序写入

　　最终一致性(Eventual Consistency)：不保证读取的顺序。 如果缺少任何进一步的写入，则副本最终会收敛。

　　接下来我们举个例子：

　　我们以棒球比赛为例。这场比赛目前处于第七局的中段。这是第七局的比赛。目前客队以2比5的比分落后。

	1	2	3	4	5	6	7	8	9	比分
客队	0	0	1	0	1	0	0			2
主队	1	0	1	1	0	2				5

　　

　　Azure CosmosDB保存主队和客队的比分。下表列出了使用五种不同的一致性情况下，读取主队和客队比分的情况。

一致性级别	说明	分数
Strong (强一致性)	返回最新提交的版本	2-5
Bounded Staleness	最多一个已过期的回合比分	2-3、2-4、2-5
Session(会话一致性)	会话一致性的范围限制在客户端会话	写入者：2-5 写入者以外的任何人：0-0、0-1、0-2、0-3、0-4、0-5、1-0、1-1、1-2、1-3、1-4、1-5、2-0、2-1、2-2、2-3、2-4、2-5 读取 1-3 后：1-3、1-4、1-5、2-3、2-4、2-5
Consistent prefix(一致性前缀)	所有过去的写入操作	0-0、0-1、1-1、1-2、1-3、2-3、2-4、2-5
最终一致性(Eventual Consistency)	不保证读取的顺序	0-0、0-1、0-2、0-3、0-4、0-5、1-0、1-1、1-2、1-3、1-4、1-5、2-0、2-1、2-2、2-3、2-4、2-5

　　

　　

　　如果大家有兴趣，可以参考这篇文章：https://www.microsoft.com/en-us/research/wp-content/uploads/2011/10/ConsistencyAndBaseballReport.pdf