首先什么是事务呢？

百度百科解释是：访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。我们简单的理解：事务就是用户定义的一系列执行SQL语句的操作，这些操作要么完全地执行，要么完全地都不执行，它是一个不可分割的工作执行单元。

分布式事务是指在分布式系统环境下由不同的服务之间通过网络远程协作下完成的事务。分布式事务是企业集成中的一个技术难点，也是每一个分布式系统架构中都会涉及到的一个东西，特别是在微服务架构中，几乎可以说是无法避免。

要搞清分布式事务首先要搞清楚：ACID、CAP、BASE理论。

ACID数据库事务正确执行的四个基本要素：

原子性（Atomicity）：

事务开始后所有操作，要么全部做完，要么全部不做，出错会全部回滚

一致性（Consistency）：

事务开始前和结束后，数据库的完整性约束没有被破坏

隔离性（Isolation）：

同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰

持久性（Durability）：

事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚

原子性是事务隔离的基础，隔离性和持久性是手段，最终目的是为了保持数据的一致性。

现在主流的数据库都是怎么实现ACID的呢？

目前主要有两种方式实现ACID：

第一种是Write ahead logging（WAL），也就是日志式的方式（现代数据库均基于这种方式）。在使用 WAL 的系统中，所有的修改在提交之前都要先写入 log 文件中。保证事务的原子性(undo log)和持久性(redo log)。

第二种是Shadow paging。shadow paging的缺点就是事务提交时要输出多个块（不同的数据文件放到不同的位置），这使得提交的开销很大，而且以块为单位，很难应用到允许多个事务并发执行的情况——这是它致命的缺点。

CAP

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容忍性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

一致性(C)：一致性是指写操作后的读操作可以读取到最新的数据状态，当数据分布在多个节点上，从任意节点读取到的数据都是最新的状态。

可用性(A)：在集群中一部分节点故障后，事务操作还可以得到响应结果，且不会出现响应超时或响应错误。

分区容忍性(P)：通常分布式系统的各个节点部署在不同的子网，这就是网络分区，不可避免的会出现由于网络问题而导致节点之间通信失败，此时仍可对外提供服务，这叫分区容忍性。

CAP是一个已经证实的理论：一个分布式系统最多只能满足CAP中的两项，对于大多数互联网应用的场景，节点众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到 N 个9（99.99…%），并要达到良好的响应性能来提高用户体验，因此一般都会做出如下选择：保证A和P,舍弃C强一致，即AP组合。通常实现 AP 都会保证最终一致性，后面讲的 BASE 理论就是根据 AP 来扩展的，一些业务场景比如：订单退款，今日退款成功，明日账户到账，需要用户可以接受在一定的时间内到账。

BASE理论

BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

CAP 中的一致性要求：在任何时间查询每个结点数据都必须一致，它强调的是强一致性，最终一致性是允许可以在一段时间内每个结点的数据不一致，但是经过一段时间每个结点的数据必须一致，它强调的是最终数据的一致性。

BASE 是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的缩写。BASE 理论是对 CAP 中 AP 的一个扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用但要保证核心功能可用，允许数据在一段时间内是不一致的，但最终达到一致状态。满足BASE理论的事务，我们称之为“柔性事务”。

BA基本可用：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。如电商网站交易付款出现问题了，商品依然可以正常浏览。

S软状态：由于不要求强一致性，所以BASE允许系统中存在中间状态（也叫软状态），这个状态不影响系统可用性，如订单的"支付中"、"数据同步中"等状态，待数据最终一致后状态改

为“成功”状态。

E最终一致：最终一致是指经过一段时间后，所有节点数据都将会达到一致。如订单的"支付中"状态，最终会变为"支付成功"或者"支付失败"，使订单状态与实际交易结果达成一致，但需要一定时间的延迟、等待。

总结：由于分布式系统环境下网络的不确定性，目前没有能够完美解决分布式事务问题的方案，我们只能在性能、一致性、可用性等方面做取舍，寻求某些特定场景偏好下的权衡。