前言

分布式事务拆开来其实就是分布式、事务两个概念，分布式简单讲就是不同进程间的系统进行通信；事务狭义上我们经常把它看作是数据库的事务，事务具有 ACID 特性即：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability），通俗来说就是同一个事务中对于数据库的更新操作来说要么都成功，要么都失败；广义上来说同一个事务中的一批操作（非局限于数据库操作）要么都成功，要么都失败；综合来说就是事务的参与者分别位于不同的进程节点中。

分布式理论

既然和分布式有关，那我们很有必要了解一下分布式系统的几个理论 CAP 和 Base 理论；

CAP 理论

一个分布式系统不可能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三个基本需求，最多只能同时满足其中的两项；

一致性：所有节点在同一时间具有一致的数据，以下单为例：用户订单生成，库存减少，用户付钱等操作要么一起成功要么一起失败；可用性：服务一直可用，而且是正常响应时间；分区容错性：分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

对于一个分布式系统而言，分区容错性可以说是一个最基本的要求；所以大部分情况其实都是在 CA 两者之间进行权衡；分布式事务同样存在这样的抉择，比如下面要介绍的 X/Open XA 协议，更加倾向于一致性；但是面对互联网的高并发，这种强一致性引发了很大的性能问题，而基于 BASE 理论的柔性事务可能是更好的一个选择；

BASE 理论

BASE 是 Basically Available (基本可用)、Soft state (软状态) 和 Eventually consistent (最终一致性) 三个短语的简写。很明显 BASE 理论更加倾向满足 CAP 理论中的 AP，既满足可用性，分区容忍性的系统，通常可能对一致性要求低一些；

BASE 理论和 ACID 可以说是完全相反的，ACID 保证的是强一致性牺牲可用性，BASE 理论是用最终一致性代替强一致性保证可用性；在实际的场景中，不同的业务对数据的要求是不一样的，所以大部分情况下 BASE 理论和 ACID 是结合起来使用的；

基于 BASE 理论的柔性事务典型方案：最大努力通知型，TCC，异步确保型等；

关于 CAP，ACID，BASE 理论可以通过如下图做一个直观的了解：

分布式事务场景

在介绍分布式事务场景之前，我们首先对本地事务做一个简单的了解，也是我们平时最常用的事务，基本上主流的数据库都支持本地事务，也基本上都满足 ACID 这几个特性；