ACID：一个解决本地事务或集中式事务处理数据一致性问题的经典方

事务（Transaction）是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元（Unit），狭义上的事务特指数据库事务。一方面，当多个应用程序并发访问数据库时，事务可以在这些应用程序之间提供一个隔离方法，以防止彼此的操作互相干扰。另一方面，事务为数据库操作序列提供了一个从失败中恢复到正常状态的方法，同时提供了数据库即使在异常状态下仍能保持数据一致性的方法。

事务具有四个特征，分别是原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持久性(Durability)，简称为事务的ACID特性。

A原子性

事务的原子性是指事务必须是一个原子的操作序列单元。事务中包含的各项操作在一次执行过程中，只允许出现其中一种状态：全部成功执行 和全部不执行。

任何一项操作失败将导致整个事务失败，同时其他已经被执行的操作将被撤销并回滚，只有所有的操作全部成功，整个事务才算是成功完成。

C一致性

事务的一致性是指事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行之前和执行之后，数据库都必须处于一致性状态。也就是说，事务执行的结果必须是使数据库从一个一致性状态转变到另一个一致性状态，因此当数据库只包含成功事务提交的结果时，就能说数据库处于一致性状态。而如果数据库系统在运行过程中发生故障，有些事务尚未完成就被迫中断，这些未完成的事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态。

I隔离性

事务的隔离性是指在并发环境中，并发的事务是相互隔离的，一个事务的执行不能被其他事务干扰。也就是说，不同的事务并发操纵相同的数据时，每个事务都有各自完整的数据空间，即一个事务内部的操作及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间不能互相干扰。

在标准 SQL 规范中，定义了 4 个事务隔离级别，不同的隔离级别对事务的处理不同，如未授权读取、授权读取、可重复读取和串行化。

1) 未授权读取也被称为读未提交( Read  Uncommitted)，该隔离级别允许脏读取，其隔离级别最低。如果一个事务正在处理某一数据，并对其进行了更新，但同时尚未完成事务，因此还没有进行事务提交；而与此同时，允许另一个事务也能够访问该数据。举个例子，事务B能够看到在事务A操作过程中的所有中间值（如1变成2、2变成3等），而对这一系列的中间值的读取就是未授权读取。

疑问：事务未完成但数据如何更新的？

2) 授权读取也被称为读已提交（Read  Committed），它和未授权读取非常相近，唯一的区别就是授权读取只允许获取已经被提交的数据。事务B无法看到在事务 A 操作过程中的所有中间值，只能看到最终的10，即授权读取允许不可重复读取(针对事务B来说，不可重复读取到值1)。

3) 可重复读取（Repeatable Read），保证在事务处理过程中，多次读取同一个数据时，其值都和事务开始时刻是一致的。因此该事务级别禁止了不可重复读取和脏读取，但是有可能出现幻影数据。所谓幻影数据，就是指同样的事务操作，在前后两个时间段内执行对同一个数据项的读取，可能出现不一致的结果。可重复读取隔离级别能够保证事务 B 在第一次事务操作过程中，始终对数据项读取到 1，但是授权提交中，未结束的事务B采用同样的查询方式，就可能会读取到10或20。

4) 串行化（Serializable）是最严格的事务隔离级别。它要求所有事务都被串行执行，即事务只能一个接一个地进行处理，不能并发执行。

以上4个隔离级别的隔离性依次增强，分别解决不同的问题，下表对这4个隔离级别进行了一个简单的对比。

事务隔离级别越高，就越能保证数据的完整性和一致性，但同时对并发性能的影响也越大。通常，对于绝大多数的应用程序来说，可以优先考虑将数据库系统的隔离级别设置为授权读取(读已提交)，这能够在避免脏读取的同时保证较好的并发性能。尽管这种事务隔离级别会导致不可重复读、虚读和第二类丢失更新等并发问题，但较为科学的做法是在可能出现这类问题的个别场合中，由应用程序主动采用悲观锁或乐观锁来进行事务控制。

D持久性

事务的持久性也被称为永久性，是指一个事务一旦提交，它对数据库中对应数据的状态变更就应该是永久性的。换句话说，一旦某个事务成功结束，那么它对数据库所做的更新就必须被永久保存下来——即使发生系统崩溃或机器宕机等故障，只要数据库能够重新启动，那么一定能够将其恢复到事务成功结束时的状态。

---

ACID是一个解决本地事务和集中式事务处理的经典方法论，是一个很成熟的已经被实践证明的处理数据一致性的模型。

当然分布式事务也可以被定义为一种嵌套型的事务，同时也就具有了ACID事务特性。由于在分布式事务中，各个子事务的执行是分布式的，因此要实现一种能够保证ACID特性的分布式事务处理系统就显得格外复杂。

什么是分布式事务？

指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于分布式系统的不同节点之上。通常一个分布式事务中会涉及对多个数据源或业务系统的操作。

一个最典型的分布式事务场景：

一个跨银行的转账操作涉及调用两个异地的银行服务，其中一个是本地银行提供的取款服务，另一个则是目标银行提供的存款服务，这两个服务本身是无状态并且是互相独立的，共同构成了一个完整的分布式事务。如果从本地银行取款成功，但是因为某种原因存款服务失败了，那么就必须回滚到取款前的状态，否则用户可能会发现自己的钱不翼而飞了。

从上面这个例子中，我们可以看到，一个分布式事务可以看作是由多个分布式的操作序列组成的，取款服务和存款服务，通常可以把这一系列分布式的操作序列称为子事务。有没有发现要保证ACID特性的分布式事务处理比本地事务或集中式事务处理更复杂些。

如何解决分布式事务处理的一致性问题？下文再续。

摘取自倪超《从Paxos到Zookeeper：分布式一致性原理与实践》