Azure Cosmos DB 一致性级别

Azure Cosmos DB 一致性级别

阅读consistency-levels 学习笔记

分布式系统依赖于底层的复制机制来保证系统的高可用High availability，低延迟Low latency的特性。由于CAP理论的存在，在分布式系统设计中，没有什么解决方案是绝对的银弹，因此我们往往需要对于（读）一致性read condistency，可用性 availability，延迟 latency 以及吞吐量 throughput上面做trade-off。通常，在商业数据库模型中会要求开发者对于两个极端一致性模型进行选择，即强一致性(strong consistency)和最终一致性(eventual consistency)。对于线性一致性或者强一致性模型来说是数据开发（data programmability）的黄金法则，但是相应的它也会额外的增加写开销和降低可用性。 对于弱一致性，即最终一致性，它提供了更高的可用性和更好的性能，但是牺牲了一致性的保证，并且要实现最终一致性，对应用层面的编程实现提出了更高的挑战。

Azure Cosmos DB对于数据一致性提供了更细粒度(granular)的选择。用户可以根据自己的实际可用性和性能的需求来选择合适的一致性级别。

下图即为Azure Cosmos DB提供的一致性级别。包括强一致性strong，有界延迟一致性bouded staleness, 会话一致性session, 固定前缀一致性consistent prefix, 最终一致性eventual consistency. 为了准确性，之后的章节主要使用英文定义。

一致性级别是区域不感知（region-agnostic）的, 即所有操作都会保证相应的一致性级别，不管有多少底层的region，以及Azure Cosmos account配置了单region或多region。

一致性级别 TLA+ 定义

对于Azure Cosmos DB各个一致性级别有更为精确的定义。具体可参考Azure cosmos tla.

TLA+ 是有Lamport大神发明的以形式化，数理逻辑的形式来描述系统设计和算法的正确性。一般来说，正确性是难证明的，尤其是并发系统，分布式系统中。因为其行为变化的可能性太多。但是，如果能够把系统的行为/状态抽象成时序逻辑，再结合数学分析的方法，就可以判断系统是否正确。

Lamport大神也推动了TLA+在Azure Cosmos DB中的落地 Youtube: Foundations of Azure Cosmos DB (Multi-Master) with Dr. Leslie Lamport。按Lamport大神的话来说，开发者使用TLA+时，是以数学的方式来思考设计软件系统，这样会使得复杂系统更加准确。在设计并行系统，分布式系统时可以在写代码之前就可以系统设计的bug，这也是高级开发者所需要学习并掌握TLA+的原因。

TLA+ 有非常好的视频学习资源home page. 这本书Specifying system详尽的解释了TLA+。

一致性详解

Guarantees associated with consistency levels

Azure Cosmos DB是Quorum-based的系统。对于不同的一致性级别，Azure Cosmos DB有着对应不同Quorum Reads和Quorum Writes的要求。下面表格主要展示了不同一致性级别Quorums Read和Quorum Writes的关系。Cosmos DB中每个Local replica set是由4个副本replica组成。因此（本地少数）Local Minority是指2个replica，Local Majority是指3个replica。

以强一致性举例。对于强一致性的Global Major来说，首先要保证强一致性的Quorum write，就必须要保证写请求在所有region的上提交committed以后才能向客户端返回写请求成功。因此Global Majority（全球多数）的意思即为全部region数量。 对于强一致性的Quorum read因为Quorum write以及提供了强一致性保证。所有Quorum read只需要以Local Minority策略读，即读取本地的2个副本。更细节的讨论可参考azure docs issue。

下面就一致性级别由强至弱，一一介绍。

Strong consistency 强一致性

Strong consistency提供了线性一致性Linearizability的保证。线性一致性即读请求read总能读的最近提交的数据（most recent commmited version）。如下动图，很好的展示了强一致性。

对于强一致性来说，Quorum read为Local Minority即读操作要在本地region的两个replica上执行。Quorum write为Global Majority即写操作要等待Azure Cosmos Account配置的所有Region写操作提交committed之后才返回成功。因为对于写操作的延迟是两个最远region之间RTT(round-trip time)的两倍 （write latency is equal to two times roud-trip RTT）。

Bounded staleness consistency 有界旧一致性

暂且称之为Bounded staleness为有界旧一致性。读请求会保证遵循一致性前缀保证(The reads are guaranteed to honor the consistent prefix guarantee)。读请求可能会读到滞后最多k个版本号的数据, 或者读情况会在写请求之后最多T时间内读到相应的更新。因此Bounded staleness可以以滞后的版本号个数或者延迟读的时间进行配置。Bounded staleness在staleness窗口之外提供了全局有序性保证。当在某个支持write-read的region上操作时，Bounded staleness提供的一致性和强一致性一样。下图很好的展示了Bounded staleness一致性。

在staleness window之外，该一致性提供了全局有序的保证，而在staleness window之内，Bounded staleness根据不同的情况，提供了如下的一致性保证。

• 单主机帐户的同一区域中客户端 = 强一致性
• 单主机帐户的不同区域中客户端 = 一致性前缀
• 为多主机帐户写入单个区域的客户端 = 一致性前缀
• 为多主机帐户写入不同区域的客户端 = 最终一致性

Session consistency 会话一致性

会话一致性，客户端即在一个会话内保证前缀一致性，且单调读monotonic read，单调写monotonic write，写后读read-your-writes 和读后写write-follows-read的保证。会话一致性，有点类似于在Strong consistency和Bounded staleness consistency上面增加了session partition的概念，以获得更低的写入延迟和更高的吞吐量。

会话一致性是适用于单个区域和全球分布式应用程序的广泛使用的一致性级别， 它提供了较低的写入延迟，更大的吞吐量，高可用，同时提供一致性保证，以满足在用户上下文context中运行的应用程序的需求。即处于同一个会话session中的读客户端可以以很低的延迟读到最新写入的数据。

下图演示会话一致性。 "美国西部2作者" 和 "美国西部2读者" 正在使用同一个会话（会话 A），因此他们同时读取相同的数据。 虽然 "澳大利亚东部" 区域正在使用 "Session B"，但它会在以后接收数据，但其顺序与写入的顺序相同。即对于不同的会话，会话一致性也提供了前缀一致性的保证。

Consistent prefix 前缀一致性

前缀一致性保证，读操作不会看到乱序的写操作。例如：写操作执行顺序是A, B, C，那么一个客户端只能看到A 或A, B 或 A, B, C。 且不会读到诸如A, C这样的数据。

下面是一致性前缀的一致性保证

• 单主机帐户的同一区域中客户端 = 一致性前缀
• 单主机帐户的不同区域中客户端 = 一致性前缀
• 为多主机帐户写入单个区域的客户端 = 一致性前缀
• 为多主机帐户写入多个区域的客户端 = 最终一致性

Eventual consistency 最终一致性

最终一致性对于读操作不提供有序性保证。最终一致性，顾名思义，即在没有写请求发生的最终状态下，所有副本最终都会一致收敛（eventually converge）。最终一致性是最弱的一致性保证，因为客户端可以读取到陈旧的数据。最终一致性适用于不需要任何有序性保证的情况。例如：转发tweet的数量，或者一些非线程的注释(non-threaded)的应用中。

Azure Cosmos DB提供了全球一致性，并且支持不同的一致性级别。而每个一致性级别之间都是相互关联的。强一致性会兼容支持弱的一致性的功能，且在不同的情况下，即在多master accout多region情况下，具体的每个一致性级别又提供了具体的一致性保证。在实际应用中，我们需要根据应用场景，选择适合应用场景的一致性级别。

最后，不得不说Azure的doc写的真的很用心，真的非常好理解，里面有很多分布式系统的设计理念。更多Azure Cosmos DB的相关信息可以看https://docs.microsoft.com/en-us/azure/cosmos-db/

Reference