事务就是指一个操作单元，操作单元中的所有操作要么同时成功要么同时失败。单体项目中的事务一般都是使用数据库提供的事务机制来完成的，但是分布式事务的事务参与者位于不同的节点上，也就是分布在不同的服务器上。分布式事务的最大问题就是各子事务的一致性问题，有两种解决思路，AP模式与CP模式，介绍这两种模式首先要介绍CAP定理与BASE理论。

分布式系统有三个指标：Consistency（一致性）（所有节点所有数据一致性）、Availability（可用性）（强调总能返回响应数据，但数据不一定都是最新数据）、Partition tolerance （分区容错性）（网络问题导致分区，仍能提供服务）。CAP定理指的就是这三个要素最多只能同时实现两点，不可能三者同时满足。

对于分布式系统来说，P（网络问题）必须要保证，A和C最多只能满足一个。如果要保证强一致性C，就必须等待网络回复，完成数据同步后，整个集群才对外提供服务，此时服务处于阻塞状态，不可用。如果要保证可用性A，就要马上返回结果，此时各个节点都未完成数据同步，返回的数据不一致。

 BASE理论就是对CAP中一致性和可用性进行权衡的结果，核心思想就是保证系统基本可用和最终一致性。Basically Available （基本可用）（允许损失部分可用性，保证核心可用即可）、Soft State（软状态）（允许出现中间状态，比如临时的不一致状态 ）、Eventually Consistent（最终一致性）（软状态结束后，最终数据一致）。

解决方案

1.两阶段提交（CP模式）：整个事务分为两个阶段：表决阶段（所有参与者都将本事务预提交，并将能否成功的信息反馈给协调者）+执行阶段（协调者根据所有参与者的反馈，通知所有参与者，步调一致执行提交或回滚）

在两阶段提交协议中，每个参与者都需要向一个协调者发送请求，并根据协调者的指示执行操作。这种方式可以保证在网络分区或节点故障发生时仍能够达成一致，从而保证数据的一致性。但是，在网络分区的情况下，可能会导致协调者失效，从而使得整个系统无法进行后续操作，因此它牺牲了可用性。

CP模式：各个子事务执行后相互等待，同时提交、同时回滚，达到强一致，事务等待过程中，处于弱可用状态。

2.TCC事务（Try Confirm Cancel ）（AP模式），属于补偿型分布式事务。

TCC实现分布式事务一共有三个步骤

Try：做业务检查及资源预留（冻结），这个阶段是初步操作，与后续Confirm一起才构成完整业务逻辑

Confirm：确认提交，Try阶段所有分支事务执行成功后开始Confirm（冻结清除）

Cancel：在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放（释放冻结进行恢复）

TCC是一种补偿性事务处理机制，它通过在业务逻辑中显式地定义Try阶段、Confirm阶段和Cancel阶段来保证分布式系统中的原子性。在TCC事务中，每个参与者都会尝试执行Try操作，确认执行Confirm操作，或者在需要时执行Cancel操作以进行回滚。这种方式下，即使某些节点发生故障，系统仍可以继续运行，牺牲了一致性，保证了可用性和分区容忍性。采用TCC的Confirm和Cancel阶段失败了，需引入重试机制或人工处理。

AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。