Cosmos DB的5种事物一致性

TP和AP最重要的区别就是事物。事务是指对系统进行的一组操作，为了保证系统的完整性，事务需要具有ACID特性，具体指原子性（Atomic）一致性（Consistency）隔离性（Isolation）持久性（Durability）。

微软Build 2017发布的Cosmos数据库比较有意思，同时支持5个级别一致性。

一致性指的是事务的执行必须使资料库从一个一致性状态迁移至另一个一致性状态，事务的一致性决定了一个系统设计和实现的复杂度。

最常见的两种模式是强制一致性（Strong consistency）与最终一致性（EventuallyConsistency），但Azure Cosmos DB额外提供了介于上述两者之间的 有边界一致性（ Bounded Staleness）、事物一致性（Session）与单调一致性（ConsistentPrefix）等模式，允许开发人员依据程式的需求选择适用的模式。

事务可以不同程度的一致性：

强一致性：读操作可以立即读到提交的更新操作

Bounded Staleness：提交的更新操作，不一定立即会被读操作读到，此种情况会存在一个不一致窗口，指的是读操作可以读到最新值的一段时间。

会话一致性：保证客户端和服务器交互的会话过程中，读操作可以读到更新操作后的最新值。

单调一致性：如果一个进程已经读到一个值，那么后续不会读到更早的值。

最终一致性：是弱一致性的特例。事务更新一份数据，最终一致性保证在没有其他事务更新同样的值的话，最终所有的事务都会读到之前事务更新的最新值。如果没有错误发生，不一致窗口的大小依赖于：通信延迟，系统负载等。

Cosmos DB在许多方面借鉴了DocumentDB，这不足为奇。其中一个方面就是拥有可调整的一致性模型（consistency model）。如果你平时不常考虑全局分布式数据库，那么一致性模型对你来说根本不是那么重要，但是大多数与之竞争的数据库系统（包括谷歌最近发布的Cloud Spanner，https://cloud.google.com/spanner/）只有两种一致性模型：强一致性（strong consistency）和最终一致性（eventualconsistency）。比如说，就强一致性而言，只要数据被写入到数据库，所有的不同节点（这些节点可能分布于全球各地的数据中心）都要先就一个新的值达成一致，之后新的值才出现在应用程序中。任何时刻，任何用户或节点都可以读到最近一次成功更新的副本数据。由于这种方法增添了延迟，这在性能方面显然存在着一些不足。最终一致性实际上是一种比较宽容的系统；所有节点并不同时更新，而是只有在一段时间没有任何最近的更新后，才就某个值达成一致。

CosmosDB不同寻常的地方在于，它提供了不同的一致性模型，那样用户可以在获得多强的一致性与承受多大的性能开销之间作一个取舍。比如说，对于Cosmos DB（以及之前的DocumentDB）而言，那意味着，你可以选择这种一致性模型：允许读取操作比写入操作只延后某一段时间（毫秒级），也可以选择这种一致性模型：专注于为某种特定的客户会话提供一致性（比如在类似Twitter的应用中），但是每个用户在同一时间（或者以完全一样的顺序）看到每次写入的数据又不是那么重要。

ACID另外三个概念分布是：

1.原子性（Atomic）
一个事务包含多个操作，这些操作要么全部执行，要么全都不执行。实现事务的原子性，要支持回滚操作，在某个操作失败后，回滚到事务执行之前的状态。
回滚实际上是一个比较高层抽象的概念，大多数DB在实现事务时，是在事务操作的数据快照上进行的（比如，MVCC），并不修改实际的数据，如果有错并不会提交，所以很自然的支持回滚。
而在其他支持简单事务的系统中，不会在快照上更新，而直接操作实际数据。可以先预演一边所有要执行的操作，如果失败则这些操作不会被执行，通过这种方式很简单的实现了原子性。

2. 隔离性（Isolation）
   并发事务之间互相影响的程度，比如一个事务会不会读取到另一个未提交的事务修改的数据。在事务并发操作时，可能出现的问题有：
   脏读：事务A修改了一个数据，但未提交，事务B读到了事务A未提交的更新结果，如果事务A提交失败，事务B读到的就是脏数据。
   不可重复读：在同一个事务中，对于同一份数据读取到的结果不一致。比如，事务B在事务A提交前读到的结果，和提交后读到的结果可能不同。不可重复读出现的原因就是事务并发修改记录，要避免这种情况，最简单的方法就是对要修改的记录加锁，这回导致锁竞争加剧，影响性能。另一种方法是通过MVCC可以在无锁的情况下，避免不可重复读。
   幻读：在同一个事务中，同一个查询多次返回的结果不一致。事务A新增了一条记录，事务B在事务A提交前后各执行了一次查询操作，发现后一次比前一次多了一条记录。幻读是由于并发事务增加记录导致的，这个不能像不可重复读通过记录加锁解决，因为对于新增的记录根本无法加锁。需要将事务串行化，才能避免幻读。
   事务的隔离级别从低到高有：
   Read Uncommitted：最低的隔离级别，什么都不需要做，一个事务可以读到另一个事务未提交的结果。所有的并发事务问题都会发生。
   Read Committed：只有在事务提交后，其更新结果才会被其他事务看见。可以解决脏读问题。
   Repeated Read：在一个事务中，对于同一份数据的读取结果总是相同的，无论是否有其他事务对这份数据进行操作，以及这个事务是否提交。可以解决脏读、不可重复读。
   Serialization：事务串行化执行，隔离级别最高，牺牲了系统的并发性。可以解决并发事务的所有问题。
   通常，在工程实践中，为了性能的考虑会对隔离性进行折中。

3. 持久性（Durability）
   事务提交后，对系统的影响是永久的。

标签：事务,DB,更新,并发,提交,一致性,操作,Cosmos
来源： https://blog.51cto.com/15127539/2662518