传统事务ACID是基于单数据库的本地事务，仅支持单机事务，并不支持跨库事务。但随着微服务架构的普及，业务的分库分表导致一个大型业务系统往往由若干个子系统构成，这些子系统又拥有各自独立的数据库。往往一个业务流程需要由多个子系统共同完成，而且这些操作可能需要在一个事务中完成，这种事务即为“分布式事务”。当更新内容同时分布在不同库中，不可避免会带来跨库事务问题。跨分片事务也是分布式事务，没有简单的方案，一般可使用"XA协议"和"两阶段提交"处理。分布式事务能最大限度保证了数据库操作的原子性。但在提交事务时需要协调多个节点，推后了提交事务的时间点，延长了事务的执行时间。导致事务在访问共享资源时发生冲突或死锁的概率增高。随着数据库节点的增多，这种趋势会越来越严重，从而成为系统在数据库层面上水平扩展的枷锁。
对于那些性能要求很高，但对一致性要求不高的系统，往往不苛求系统的实时一致性，只要在允许的时间段内达到最终一致性即可，可采用事务补偿的方式。与事务在执行中发生错误后立即回滚的方式不同，事务补偿是一种事后检查补救的措施，一些常见的实现方法有：对数据进行对账检查，基于日志进行对比，定期同标准数据来源进行同步等等。事务补偿还要结合业务系统来考虑。
1.3.1、CAP
Consistency Acailability Partition tolerance 的简写
Consistency：一致性
对某个客户端来说，读操作能够返回最新的写操作结果
Acailability：可用性
非故障节点在合理的时间内返回合理的响应
Partition tolerance：分区容错性
当出现网络分区后，系统能够继续提供服务。什么是网络分区？
因为分布式系统中系统肯定部署在多台机器上，无法保证网络做到100%的可靠，所以网络分区一定存在，即P一定存在；在出现网络分区后，就出现了可用性和一致性的问题，我们必须要在这两者之间进行取舍，因此就有了两种架构：CP架构，AP架构；
1.3.2、AP和CP的选取
由于网络分区一定存在，所以要根据业务场景选取保证强一致性或可用性。
CP：强一致性的方案便是CP架构，即通过牺牲可用性来保证一致性，这种方案适用于对一致性要求很高的场景，比如金融交易等。
AP：在分布式系统中，除了特殊强一致性要求高的场景，业务往往更多追求的是可用性，它的关注程度比强一致性要高。AP更注重最终一致性，进而引出BASE理论。
1.3.3、BASE理论
BASE理论本质上是对CAP理论的延伸，是对 CAP 中 AP 方案的一个补充。BASE理论指的是基本可用 Basically Available，软状态 Soft Stat，最终一致性 Eventual Consistency，核心思想是即便无法做到强一致性，但应该可以有采用适合的方式保证最终一致性，BASE：Basically Available Soft Stat Eventual Consistency的简写。
BA：Basically Available 基本可用
分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用
S：Soft Stat 软状态\n\n允许系统存在中间状态，而该中间状态不会影响系统整体可用性
E：Consistency 最终一致性
系统中的所有数据副本经过一定时间后，最终能够达到一致的状态
1.3.4、柔性事务和刚性事务
提供强一致性的事务称之为刚性事务，把提供最终一致性的事务称之为柔性事务。刚性事务可以完全满足ACID四个特性，柔性事务一般遵循的是分布式领域中的BASE理论。
柔性事务（如分布式事务）为了满足可用性、性能与降级服务的需要，降低一致性（Consistency）与隔离性（Isolation）的要求，遵循 BASE 理论，传统的 ACID 事务对隔离性的要求非常高，在事务执行过程中，必须将所有的资源对象锁定，因此对并发事务的执行极度不友好，柔性事务（比如分布式事务）的理念则是将锁资源对象操作从本地资源对象层面上移至业务逻辑层面，再通过放宽对强一致性要求，以换取系统吞吐量的提升。此外，虽然柔性事务遵循的是 BASE 理论，但是还需要遵循部分 ACID 规范。
刚性事务（如单一数据库事务）完全遵循 ACID 规范，即数据库事务的四大基本特性ACID, 刚性事务满足ACID理论, 柔性事务满足BASE理论，追求基本可用，最终一致。
二阶段提交（Two-phase Commit），是指，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法(Algorithm)。通常，二阶段提交也被称为是一种协议(Protocol)。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此，二阶段提交的算法思路可以概括为： 参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。2PC是强一致性的算法。
二阶段提交算法的成立基于以下假设：