分布式事务相关解决方案

什么事分布式事务

分布式系统会把一个应用系统拆分为可独立部署的多个服务，因此需要服务与服务之间远程协作才能完成事务操作，这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务；
说白了就是保证两个甚至多个系统间的事务性，即acid（一致性，原子性，隔离性，持久性）

分布式事务的相关解决方案

1.2PC

2PC即两阶段提交，引入一个事务协调者的角色来协调管理各参与者的提交和回滚，二阶段分别指的是准备和提交两个阶段

image.png

客户端只跟协调者打交道，只有下游两个服务都执行成功时才提交，否则只要有一个失败就全部失败回滚；
2PC 是一种尽量保证强一致性的分布式事务，它是同步阻塞的，而同步阻塞就导致长久的资源锁定问题，总体而言效率低，并且存在单点故障问题，在极端条件下存在数据不一致的风险，适用于数据库层面的分布式事务场景。

3.3PC

3PC 的出现是为了解决 2PC 的一些问题，相比于 2PC 它在参与者中也引入了超时机制，并且新增了一个阶段使得参与者可以利用这一个阶段统一各自的状态。
3PC 包含了三个阶段，分别是准备阶段、预提交阶段和提交阶段；把 2PC 的提交阶段变成了预提交阶段和提交阶段，原理其实和2PC类似，只做了解；

TCC

2PC 和 3PC 都是数据库层面的，而 TCC 是业务层面的分布式事务，TCC 指的是Try - Confirm - Cancel；
TCC 对业务的侵入较大和业务紧耦合，还要保证业务幂等，因为有些业务存在重试，适用场景广，开发量大，可以跨数据库，跨不同业务实现；

本地消息表

即一个业务多个步骤的操作利用一个表中的一条记录的变更去实现，如果失败就根据消息去进行回滚，或者通过定时任务去补偿；

消息事务

这里典型的就是阿里开源的RocketMq实现的半消息，如图：

image.png

大概原理就是当上游成功以后，将之前发送的半消息由mq自动将该消息投递到真正的业务topic，然后消费者业务方需要保证执行成功，即使失败了也要通过重试等其他技术去保证，防止业务进行回滚，猜想如果这里执行失败了并且不可能成功了该怎么办，是不是只能调用上有服务提供的相关回滚接口去进行回滚，如果一个流程还好，但是如果中间存在了好几个分布式消息呢，这又该怎么办，是不是会变得很复杂；所以这里保证下游服务必须执行成功是有原因的；