分布式事务理论基础

事务是数据库执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。 事务有四个特性，习惯上被称为 ACID 特性：

• Atomicity(原子性)

• Consistency(一致性)

• Isolation(隔离性)

• Durability(持久性)

本地事物

在系统发展初期，单体应用对应一个数据库，整个服务操作只涉及一个数据库资源，通过数据库自带的事务很容易实现 ACID，这类基于单个服务单一数据库资源访问的事务，被称为本地事务(Local Transaction)。

分布式事务

随着互联网的发展，微服务架构大规模的普及，软件系统由原来的单体应用转变为分布式应用。分布式系统一般由多个独立的子系统组成，多个子系统通过网络通信互相协作配合完成各个功能。

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。比如在一个电商系统中，一条订单的生成涉及库存、订单、支付等不同的服务，不同的服务之间要么全成功、要么全失败，保证事务的 ACID 特性。

本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

在分布式系统中数据一致性又可以划分出多个一致性模型

• 强一致性：任何一次读都能读到某个数据的最近一次写的数据。系统中的所有进程，看到的操作顺序，都和全局时钟下的顺序一致。简言之，在任意时刻，所有节点中的数据是一样的。

• 弱一致性：数据更新后，如果能容忍后续的访问只能访问到部分或者全部访问不到，则是弱一致性。

• 最终一致性：不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。简单说，就是在一段时间后，节点间的数据会最终达到一致状态。

在解决分布式事物的数据一致性问题上，产生了多个相关的理论。

CAP 理论

CAP 定理又被称作布鲁尔定理，是加州大学的计算机科学家布鲁尔在 2000 年提出的一个猜想。2002 年，麻省理工学院的赛斯·吉尔伯特和南希·林奇发表了布鲁尔猜想的证明，使之成为分布式计算领域公认的一个定理。

• C : Consistency 一致性 , 所有实例节点同一时间看到是相同的数据

• A : Availability 可用性 , 不管是否成功，确保每一个请求都能接收到响应

• P : Partition tolerance 分区容错性 , 系统任意分区后，在网络故障时，仍能操作

CAP 理论是指在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性、可用性、分区容错性者中的两个，另外一个必须被牺牲。

在真实的分布式环境下，如果我们选择了 CA（一致性 + 可用性） 而放弃了 P（分区容错性），那么当发生分区现象时，为了保证 C（一致性），系统需要禁止写入，当有写入请求时，系统返回 error（例如，当前系统不允许写入），这又和 A(可用性) 冲突了，因为 A（可用性）要求返回 no error 和 no timeout。因此虽然在 CAP 理论定义是三个要素中只能取两个，但放到分布式环境下来，必须选择 P（分区容错）要素，因为网络本身无法做到 100% 可靠，有可能出故障，所以分区是一个必然的现象。 也就说在真是环境下我们只能选择 CP（一致性 + 分区容错性） 或者 AP （可用性 + 分区容错性）架构，在一致性和可用性做折中选择。

虽然 CAP 理论告诉我们分布式系统只能选择 AP 或者 CP，但实际上并不是说整个系统只能选择 AP 或者 CP，在 CAP 理论落地实践时，我们需要将系统内的数据按照不同的应用场景和要求进行分类，每类数据选择不同的策略（CP 还是 AP），而不是直接限定整个系统所有数据都是同一策略。

BASE 理论--CAP 理论的延伸

由于在分布式系统中 C、A、P 三者都无法抛弃，但 CAP 定理限制三者无法同时满足，这种情况，我们会选择尽量靠近 CAP 定理，即尽量让 C、A、P 都满足，在此所趋下，出现了 BASE 定理。

BASE 是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent （最终一致性）三个短语的缩写。核心思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。

• BA：Basically Available 基本可用，分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。
  电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。

• S：Soft State 软状态，允许系统存在中间状态，而该中间状态不会影响系统整体可用性。
  分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。mysql replication 的异步复制也是一种体现。

• E: Eventual Consistency 最终一致性， 系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。

BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充。

BASE和ACID的区别与联系

• ACID是传统数据库常用的设计理念, 追求强一致性模型。

• BASE支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性

ACID和BASE代表了两种截然相反的设计哲学。
总的来说，BASE 理论面向大型高可用可扩展的分布式系统，与ACID这种强一致性模型不同，常常是牺牲强一致性来获得可用性，并允许数据在一段时间是不一致的。虽然两者处于（一致性-可用性）分布图的两级，但两者并不是孤立的，对于分布式系统来说，往往依据业务的不同和使用的系统组件不同，而需要灵活的调整一致性要求，也因此，常常会组合使用ACID和BASE。

柔性事务

不同于 ACID 的刚性事务，在分布式场景下基于 BASE 理论，就出现了柔性事务的概念。柔性事务下，在不影响系统整体可用性的情况下(Basically Available 基本可用)，允许系统存在数据不一致的中间状态(Soft State 软状态)，在经过数据同步的延时之后，最终数据能够达到一致。并不是完全放弃了 ACID，而是通过放宽一致性要求，借助本地事务来实现最终分布式事务一致性的同时也保证系统的吞吐。