前言
分布式事务就是一个业务操作，是由多个细分操作完成的，而这些细分操作又分布在不同的服务器上，事务，就是这些操作要么全部成功执行，要么全部不执行。分布式事务用于在分布式系统中保证不同节点之间的数据一致性。
简单来说，一次业务操作需要夸多个数据源或者需要跨多个系统（服务）进行远程调用，就会产生分布式事务问题，每一个服务都是独立的，比如：
下订单-》减库存-》扣余额-》改订单状态
这样全局数据一致性问题没法保证。
本文首先先介绍分布式事务的第一种处理方案，基于XA协议阶段提交。
XA协议（需要数据库层面支持，数据库控制事务）
两阶段提交：
第一阶段（prepare）：每个参与者执行本地事务但不提交，进入ready状态，并通知协调者已经准备就绪。
第二阶段（commit）：当协调者确认每个参与者都ready后，通知参与者进行commit操作；如果有参与者fail则发送rollback命令，各参与者做回滚。
XA出现的问题：
- 单点故障：一旦事务管理器出现故障，整个系统不可用（参与者都会阻塞住）
- 数据不一致：在阶段二，如果事务管理器支发送了部分commit消息，此时网络发生异常，那么部分参与者接收到commit消息，也就是说只有 部分参与者提交了事务，使得系统数据不一致。
- 响应时间较长：参与者和协调者资源被锁住（数据库SQL复杂，行锁，响应时间很长），提交或者回滚之后才能释放
- 不确定性：当事务管理器发送commit之后，并且此时只有一个参与者收到了commit，那么当该参与者与事务管理器同时死机之后，重新选举的事务管理器无法确定该条消息是否发送提交成功。
三阶段提交：主要是针对两阶段提交的优化，解决了2PC单点故障的问题，但是性能问题和不一致问题仍然没有解决
引入了超时机制解决参与者阻塞的问题，超时后本地提交，如果协调者迟迟没有响应，参与者就会自己提交本地事务；
其实2pc也有超时机制，只是协调者有，是等待参与者响应，如果参与者迟迟没有响应，协调者就认为该参与者超时
第一阶段：can commit阶段，协调者询问事务参与者，是否有能力完成此次事务，如果都返回yes，则进入第二阶段，否则中断事务，向所有参与者发送abort请求
另外两阶段就是2PC，也就是上述讲解的两阶段。
我正在参与2023腾讯技术创作特训营第四期有奖征文，快来和我瓜分大奖！
