1　什么是分布式事务

1.1　单体项目 - 单数据源事务

在单体项目中如果只有一个数据库是不存在分布式事务问题的，通过@Transactional事务管理器就可以管理该数据库事务。

1.1　单体项目 - 多数据源事务

单体项目中如果有多个数据源时，每个数据源都有自己独立的事务管理器，所以会存在事务问题（同一个方法中调用到了两个数据源），

主流解决方案：jta+atomikos解决多数据源事务。

1.1　微服务项目事务

在微服务项目中，每个微服务应用都可能会有自己的数据库，@Transactional是无法跨服务的，就会存在分布式事务的问题。

如上图所示，用户续费会员后需要增加积分，会员服务member调用积分服务integral，增加积分成功后，会员服务方法突然报错，此时积分服务是无法回滚的，只有会员服务会回滚；就会导致会员续费失败，但是增加了积分。

2　两阶段提交协议(2PC)

第一阶段P指的是：准备阶段

第二阶段C指的是：提交阶段

实现分布式事务的关键就是两阶段提交协议；在分布式系统中，每个节点虽然可以知晓自己的操作是成功或者失败，却无法知道其他节点的操作的成功或失败。

因此当一个事务跨越多个节点（多个服务）时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点参与者，由协调者来统一管理所有节点上的事务，来控制是否全部提交、全部回滚。

2PC算法思路：参与者将操作成败或成功通知给协调者，再由协调者根据所有参与者的反馈情况决定所有参与者是提交还是回滚。

优点：两阶段提交（2PC），对业务侵⼊很小，它最⼤的优势就是对代码是无侵入的，用户可以像使⽤本地事务⼀样。

缺点：2PC是一个强一致性的同步阻塞协议，事务执⾏过程中需要将所需资源全部锁定，也就是俗称的刚性事务。

3　三阶段提交协议(3PC)

2PC只有协调者设置了超时时间；

2PC问题：一旦协调者发生故障，参与者会一直阻塞下去。

而3PC对于协调者和参与者都设置了超时时间，主要避免了参与者在长时间无法与协调者节点通信的情况下，无法释放资源的问题，参与者在超时后会自动进行本地commit从而释放资源，降低事务阻塞范围。

通过Seata解决分布式事务问题

点击跳转 - Seata解决分布式事务问题落地