一、事务简介

事务(Transaction): 是访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。

• 在关系数据库中，一个事务由一组SQL语句组成。
• 事务应该具有4个属性：原子性、一致性、隔离性、持久性, 这四个属性通常称为ACID特性。

原子性（atomicity）: 一个事务是一个不可分割的工作单位，事务中包括的诸操作要么都做，要么都不做

一致性（consistency）: 事务必须是使数据库从一个一致性状态变到另一个一致性状态，事务的中间状态不能被观察到的。

隔离性（isolation）: 一个事务的执行不能被其他事务干扰。

• 即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。
• 隔离性又分为四个级别：
  • 读未提交(read uncommitted)、
  • 读已提交(read committed，解决脏读)
  • 可重复读(repeatable read，解决虚读)
  • 串行化(serializable，解决幻读)

持久性也称永久性（permanence）: 指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。 任何事务机制在实现时，都应该考虑事务的ACID特性，包括：本地事务、分布式事务，及时不能都很好的满足，也要考虑支持到什么程度。

二、本地事务 和 分布式事务区别

2.1 本地事务 @Transational

大多数场景下，我们的应用都只需要操作单一的数据库，这种情况下的事务称之为本地事务(Local Transaction)。

本地事务的ACID特性是数据库直接提供支持。本地事务应用架构如下所示：

在JDBC编程中，我们通过java.sql.Connection对象来开启、关闭或者提交事务。代码如下所示：

 // 1.获取数据库连接
 Connection conn = ... ;
 // 2.开启事务
 conn.setAutoCommit(false); 
 try{
  // 3....执行增删改查sql

  // 4.提交事务       
  conn.commit();
 } catch (Exception e) {
  // 5.事务回滚
  conn.rollback();
 } finally {
  // 6.关闭链接
  conn.close(); 
}

2.2 分布式事务

当下互联网发展，绝大部分公司都进行了数据库拆分和服务化(SOA)。 在这种情况下，完成某一个业务功能可能需要横跨多个服务，操作多个数据库。 这就涉及到到了分布式事务，用需要操作的资源位于多个资源服务器上，而应用需要保证对于多个资源服务器的数据的操作，要么全部成功，要么全部失败。 本质上来说，分布式事务就是为了保证不同资源服务器的数据一致性。 典型的分布式事务场景：

跨库事务: 一个应用某个功能需要操作多个库，不同的库中存储不同的业务数据。

笔者见过一个相对比较复杂的业务，一个业务中同时操作了9个库。

下图演示了一个服务同时操作2个库的情况：

分库分表: 通常一个库数据量比较大或者预期未来的数据量比较大，都会进行水平拆分。

对于分库分表的情况，一般开发人员都会使用一些数据库中间件来降低sql操作的复杂性。

如，对于sql：insert into user(id,name) values (1,"张三"),(2,"李四")。

这条sql是操作单库的语法，单库情况下，可以保证事务的一致性。 但是由于现在进行了分库分表，开发人员希望将1号记录插入分库1，2号记录插入分库2。所以数据库中间件要将其改写为2条sql，分别插入两个不同的分库， 此时要保证两个库要不都成功，要不都失败，因此基本上所有的数据库中间件都面临着分布式事务的问题。

下图演示了一个将数据库B拆分成了2个库情况：

微服务应用业务逻辑必然非常复杂，对于开发人员是极大的挑战，应该拆分成不同的独立 服务，以简化业务逻辑。拆分后，独立服务之间通过RPC框架来进行远程调用，实现彼此的通信。

Service A 完成某个功能需要直接操作数据库。

• 同时需要调用Service B和Service C。
• Service B 又同时操作了2个数据库。
• Service C 也操作了一个库。 需要保证这些跨服务的对多个数据库的操作要不都成功，要不都失败，实际上这可能是最典型的分布式事务场景。

下图演示了一个3个服务之间彼此调用架构:

三、CAP 定理和 BASE理论

3.1 CAP 定理

CAP定理 也叫布鲁尔定理（Brewer's Theorem），是2000年由加州大学伯克利分校（University of California, Berkeley）的计算机科学家埃里克·布鲁尔（Eric Brewer）在分布式计算原理研讨会（PODC）上提出的一个猜想。 虽然当时就命名为“CAP定理”，但还未被证实。 两年后，麻省理工学院的Seth Gilbert和Nancy Lynch教授证明了布鲁尔的猜想，CAP定理正式诞生。 CAP定理指出在一个异步网络环境中，对于一个分布式读写存储（Read-Write Storage）系统来说，只能满足以下三项中的两项，而不可能满足全部三项： 一致性(Consistency)、可用性(Availability)、分区容错性(Partition Tolerance)。

一致性(Consistency): 即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。

• 一致性分为3种类型:
  1. 强一致性（ACID）=> 要不一起成功，要不一起失败。
  2. 弱一致性
  3. 顺序一致性

可用性(Availability): 即服务一直可用，而且正常响应时间。

分区容错性(Partition Tolerance): 即分布式系统遇到某个节点或网络故障的时候，仍然能够对外提供满足一致性和可用性的服务。

如图所示:

CAP原则的精髓就是

• AP（高可用系统）: 如果在某个分布式系统中数据无副本，那么系统必然满足强一致性条件，因为只有独一数据，不会出现数据不一致的情况，

如: 服务达到到可用性99.9999%可以用。

• CP（强一致性系统）: 此时C和P两要素具备，但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统。

如: 金融系统，涉及到钱。

• AC (弱一致性系统）: 当前一般是通过分布式缓存中各节点的最终一致性来提高系统的性能，通过使用多节点之间的数据异步复制技术来实现集群化的数据一致性。 通常使用类似 memcached 之类的 NOSQL 作为实现手段。 虽然 memcached 也可以是分布式集群环境的，但是对于一份数据来说，它总是存储在某一台 memcached 服务器上。 如果发生网络故障或是服务器死机，则存储在这台服务器上的所有数据都将不可访问。 由于数据是存储在内存中的，重启服务器，将导致数据全部丢失。当然也可以自己实现一套机制，用来在分布式 memcached 之间进行数据的同步和持久化，但是实现难度是非常大的 。

如: 服务出现故障，可以通过停止服务，通过使用多节点之间的数据异步复制技术来实现集群化，最终数据一致性。

但是CAP不可同时满足, 因此在进行分布式架构设计时，必须做出取舍。

3.2 BASE 理论

BASE 理论是 eBay 的系统架构师 Dan Pritchett 于 2008 年在 ACM 上发表的论文《Base: An Acid Alternative》中提出的。 Base 理论是对 CAP 理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency）, 但可以采用合适的方式达到最终一致性（Eventually Consistent）。

基本可用 (Basically Available): 分布式系统出现故障的时候，允许损失部分系统的可用性，即保证核心可用。

例如: 电商大促，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降价服务。这就是体现部分可用性。

软状态 (Soft state): 软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。

• 分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。
• 例如: MySQL Replication 的异步复制也是一种体现。

最终⼀致性 (Eventually Consistent) : 最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

• ACID 是传统数据库常用的设计理念，追求强一致性模型。
• BASE 支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。
• ACID 和 BASE 代表了两种截然相反的设计哲学，在分布式系统设计的场景中，系统组件对一致性要求是不同的，因此 ACID 和 BASE 又会结合使用。

四、小结

• 上述讨论的分布式事务场景中，无一例外的都直接或者间接的操作了多个数据库。如何保证事务的ACID特性。
• 对于分布式事务实现方案而言，是非常大的挑战。同时，分布式事务实现方案还必须要考虑性能的问题。
• 如果为了严格保证ACID特性，导致性能严重下降，那么对于一些要求快速响应的业务，是无法接受的。