上篇文章：
https://blog.csdn.net/sniper_fandc/article/details/149945898?fromshare=blogdetail&sharetype=blogdetail&sharerId=149945898&sharerefer=PC&sharesource=sniper_fandc&sharefrom=from_link目录
在微服务场景中，以往的事务只能保证单个服务上的数据一致性和完整性，无法保证多个服务之间的数据一致性和完整性。这是因为原来一个较大的服务被拆分成多个微服务，自然数据库也要随之分库分表，因此就存在多个服务之间操作不满足原子性。
比如订单服务、支付服务、库存服务，当订单支付时，支付服务要保证金额的正确扣除，订单服务要保存订单数据并保证订单状态及时修改，库存服务要保证商品数量及时变化。如果其中某个服务出现问题执行失败，其它服务就不应该执行下去，也就是说微服务之间要么同时成功，要么同时失败。这样才能保证分布式服务之间的数据一致性和完整性，这就是分布式事务。
注意：上述微服务系统作为后续演示代码的系统。
1 BASE理论
由于CAP理论无法同时兼顾一致性和可用性，但是实际使用中用户的体验是核心目标，因此需要保证可用性。BASE理论就是牺牲数据强一致性保证服务的高可用性。BASE理论具有三个特性：
基本可用（Basically Available）：分布式系统出现故障，允许牺牲一部分功能的可用性（非必要功能）保证核心功能可用。
软状态（Soft state）：允许数据存在中间状态，即数据同步之间存在延时。
最终一致性（Eventually Consistent）：中间状态的数据最终会保持一致性，即最终实现了数据同步。
2 X/Open分布式事务模型
X/Open组织定义了一种X/Open DTP(Distributed Transaction Process Reference Model)分布式事务标准，然后由不同的数据库生产商实现该标准。DTP分布式事务模型由两阶段提交协议实现（2PC），该模型包含三种角色，具体流程如下：
AP(Application)：应用程序。
RM(Resource Manager)：资源管理器，又称参与者，AP通过RM对资源进行操作，比如数据库就是RM（资源就是数据）。
TM(Transaction Manager)：事务管理器，又称为协调者，分布式系统中某个节点并不知道其它节点的事务执行情况，因此需要TM来负责协调多个子事务的执行情况，如果所有RM都执行成功就提交（commit）；否则就回滚（rollback）。
注意：TM会向RM通知全局事务和子事务，RM会向TM汇报子事务的执行情况，二者之间通过XA协议来完成分布式事务的执行和管理。
X/Open DTP模型执行流程如下：
1.配置TM，把多个RM注册到TM；
2.AP从RM中获取连接，比如数据库连接JDBC；
3.AP开启事务，即向TM创建事务，再由TM开启全局事务生成XID，该XID会通知给所有的RM；
4.AP通过RM完成业务操作，操作时会把事务所属的XID也会传输给RM；
5.AP结束全局事务，由TM通知所有RM全局事务结束，并根据RM执行情况决定提交还是回滚。
3 两阶段提交协议（2PC）
3.1 执行流程
两阶段提交协议包含角色有协调者和众多参与者，TM作为协调者，RM作为参与者。事务的执行分为两个阶段：准备阶段和提交阶段。
3.1.1 准备阶段
协调者向所有参与者发送“准备提交”请求，并进入等待状态。参与者执行各自事务，但是不提交事务，并进行持久化（写undo日志和redo日志）。参与者执行成功返回“准备成功”响应，执行失败返回“准备失败”响应。
3.1.2 提交阶段
根据准备阶段所有参与者的响应分为两种情况：
如果所有参与者都返回“准备成功”的响应，在提交阶段，协调者持久化本地事务状态，并向所有参与者发送“提交”指令。所有参与者提交事务，并返回ACK给协调者。协调者收到所有参与者的ACK后完成事务的提交。
如果有任何一个参与者都返回“准备失败”的响应，或出现超时未应答，在提交阶段，协调者持久化本地事务状态，并向所有参与者发送“回滚”指令。所有参与者根据undo日志回滚事务，并返回ACK给协调者。协调者收到所有参与者的ACK后完成事务的回滚。
3.2 优缺点
优点：2PC协议的优点是简单直观，能确保全局一致性。
缺点：但是局限性也很明显，性能较差，存在同步阻塞问题，因为协议本身的事务处理逻辑就处于阻塞状态，即参与者和协调者之间一直处于互相等待状态，资源被长时间锁定。同时，还存在单点故障问题，如果某参与者或协调者长时间故障，整个事务将被阻塞。
针对2PC协议可能出现的问题，比如超时未应答导致阻塞、协调者参与者互相等待导致资源被长时间锁定，引入超时机制和预提交阶段，把两阶段改成三阶段，就有了性能更好的三阶段提交协议。
4 三阶段提交协议（3PC）
4.1 执行流程
三阶段提交协议是对两阶段提交协议的改进，通过增加预提交（PreCommit）阶段，试图减少由于参与者或协调者故障而导致系统进入阻塞的风险。
在三阶段提交协议中，第一阶段CanCommit阶段相当于两阶段提交协议的准备阶段，但是不锁定资源。第二阶段PreCommit阶段，如果CanCommit阶段所有的参与者均可以进行提交，则参与者进入预提交状态，锁定资源并向协调者回复“可以提交”的响应。DoCommit阶段如果所有的参与者都是可以提交的，则协调者发送“提交”请求，参与者提交事务并返回确认，从而协调者完成整个事务的提交。
如果有参与者返回的响应是没有准备成功，那么在DoCommit阶段，协调者会发送回滚消息，则所有参与者进行回滚，确保数据一致性。同时，3PC中引入超时机制，所有参与者在超时未应答后可以自行提交。
4.2 优缺点
3PC通过引入PreCommit阶段，减少了2PC的阻塞问题。但是却降低了强一致性，比如如果因为网络通信问题，触发了参与者的超时机制从而自动提交事务，就会导致数据一致性问题。并且，3PC的理论更加复杂，实现需要3个RTT（网络通信的往返时间），比2PC需要的开销更大，因此在工业界没有得到广泛使用。
5 TCC事务
5.1 执行流程
TCC（Try-Confirm-Cancel）事务是实现分布式事务的一种补偿策略，用于确保在分布式系统中事务的最终一致性。TCC事务不同于2PC和3PC，2PC和3PC属于数据库层面需要遵循的协议，而TCC事务是业务层面的分布式事务协议（属于2PC的变种）。TCC事务将一个全局事务分为三个阶段：Try、Confirm和Cancel：
5.1.1 Try阶段（尝试执行）
这一阶段是用来尝试执行业务操作并预留必须的资源（隔离性）。在Try阶段，要检查操作的可行性并锁定必要的资源，以便为提交做好准备。需要注意，Try阶段不会执行提交操作。
5.1.2 Confirm阶段（确认提交）
在Try阶段成功完成后，进入Confirm阶段。Confirm阶段是真正执行提交操作的阶段，这一阶段应该是确保成功的，因为所有的资源都已经在Try阶段成功锁定。如果没有成功，就需要重试或人工处理。
5.1.3 Cancel阶段（取消操作）
如果在Try阶段的某一个地方失败，或者全局事务的某部分需要回滚，则进入Cancel阶段。Cancel阶段负责释放Try阶段所锁定的资源，回滚所做的操作，使系统恢复到初始状态。
具体流程如下：
如果任何一个参与者在Try阶段返回给事务管理器的结果是失败，事务管理器就会给所有参与者发送Cancel请求，各参与者释放锁定资源，并回滚操作，保证数据的一致性。即TCC事务是通过让具体业务先试执行事务，如果所有的子事务都执行成功就让所有参与者提交事务；否则，就采取补偿措施，把因为事务执行失败的而导致的结果恢复到初始状态。
5.2 优缺点
TCC利用预留资源和补偿机制进行事务控制，适合于需要精细流程控制的场景。它比两阶段提交（2PC）更灵活，允许在事务的各个阶段进行应用业务逻辑。但是由于TCC要求开发者自行管理资源的预留和补偿操作，增加系统实现的复杂性。并且如果服务增多，回滚的风险也就更大，因此使用场景也到受限制。
下篇文章：