Java面试题总结18之springcloud四种分布式事务解决方案
XA规范：分布式事务规范，规定了分布式事务模型
四个角色：事务管理器（协调者TM），资源管理器（参与者RM），应用程序AP，通信资源管理器CRM
全局事务：一个横跨多个数据库的事务，要么全部提交，要么全部回滚
JTA事务时Java对XA规范的实现，对应JDBC的单库事务
两阶段协议
第一阶段（prepare）：每个参与者执行本地但不提交，进入ready状态，并通知协调者已经准备就绪。
第二阶段（commit）：但协调者确认每个参与者都ready后，通知参与者进入commit操作，如果有参与者fail，则发送rollback命令，各参与者做回滚。
问题：
单点故障：一旦事务管理器出现故障，整个系统不可用
数据不一致：在阶段二，如果事务管理器只发送了部分commit消息，此时网络发生异常，那么只有部分参与者接受到commit消息，也就是说只有部分参与者提交了事务，使得系统数据不一致。
效应时间较长：参与者和协调者资源都被锁住，提交或者回滚之后才能释放
不确定性：当协事务管理器发送commit之后，并且此时只有一个参与者收到了commit，那么当该参与者与事务管理器同时宕机之后，重新选举的事务管理器无法缺点该条信息是否提交成功
三阶段协议：
针对两阶段的优化，解决了2PC单点故障的问题，但是性能问题和不一致问题仍然没有根本解决
引入了超时机制解决参与者阻塞的问题，超时后本地提交，2pc只有协调者有超时机制
第一阶段:CanCommit阶段，协调者询问事务参与者，是否有能力完成此次事务。如果都返回yes，则进入第二阶段，有一个返回no或等待响应超时，则中断事务，并向所有参与者发送abort请求
第二阶段:PreCommit阶段，此时协调者会向所有的参与者发送PreCommit请求，参与者收到后开始执行事务操作。参与者执行完事务操作后(此时属于未提交事务的状态)，就会向协调者反馈"Ack”表示我已经准备好提交了，并等待协调者的下一步指令。
第三阶段:DoCommit阶段，在阶段二中如果所有的参与者节点都返回了Ack，那么协调者就会从“预
提交状态”转变为“提交状态”。然后向所有的参与者节点发送"doCommit"请求，参与者节点在收到
提交请求后就会各自执行事务提交操作，并向协调者节点反馈“Ack”消息，协调者收到所有参与者的Ack消息后完成事务。相
反，如果有一个参与者节点未完成PreCommit的反馈或者反馈超时，那么协调者都会向所有的参与
者节点发送abort请求，从而中断事务。
TCC（补偿事务）Try，Confirm，Cancel
针对每个操作，都要注册一个与其对应的确认和补偿(撤销)操作
Try操作做业务检查及资源预留，Confirm做业务确认操作，Cancel实现一个与Try相反的操作既回
滚操作。TM首先发起所有的分支事务的try操作，任何一个分支事务的try操作执行失败，TM将会发
起所有分支事务的Cancel操作，若try操作全部成功，TM将会发起所有分支事务的Confirm操作，
其中Confirm/Cancel操作若执行失败，TM会进行重试。
TCC模型对业务的侵入性较强，改造的难度较大，每个操作都需要有try、confirm、cancel三个接
口实现confirm 和 cancel接口还必须实现幂等性。
消息队列的事务消息
发送prepare消息到消息中间件
发送成功后，执行本地事务
（1）如果事务执行成功，则commit，消息中间件将信息下发至消费端（commit前，消息不会被消费）
（2）如果事务执行失败，则回滚，消息中间件将这条prepare消息删除
消费端收到消息进行消费，如果消费失败，则不断重试