谈谈你对分布式事务的理解

说到分步式事务 ，

1,我们熟悉的基于xa规范的两阶段提交，比如 开源框架atomilkos，以及阿里的seata at模式，不过at模式是两阶段的一个演变，第一阶段提交了，第二阶段类似于undolog的反向补偿， 比如，我们在保存商品的时候，有时候要保存优惠券，积分，需要用到分布式事务，最适合seata事务

2,TCC柔性事务，为什么要说柔性事务呢，因为它遵循base理论，阿里的seata tcc模式 ，最终一致性，允许一定时间内 不同的节点的数据不一致，但是要求最终一致性

3,最大努力通知，适用一些最终一致性要求不高的业务，不保证一定能通知到，但是可以提供接口查询，比如，付款成功后的通知，，这种就特别适合

4 ,可靠消息最终一致性方案，一两有两种实现： 

a,本地消息表方案，这个方案最初有ebay提出，此方案的核心是通过本地事务保证数据业务操作和消息的一致性，然后通过定时任务将消息发送到消息中间件，待确认消息发给消费方成功后，再把消息删除.

 b,rocket事务消息

 这些强一致的方案并不适合高并发的场景，因为有很多全局锁

我们一般使用的是终一致性的方案

====================================================

2PC :缺点：单点故障问题， 一旦协调者出现问题，参与者将会处于锁定事务资源的状态中，而无法继续完成事务操作

3pc:  引入超时机制 解决了单点故障问题，由于网络原因，由于网络原因参与者之间存在数据不    协调者所在的节点和参与者无法进行正常的网络通信，节点会自动提交数据，，这必然出现数据     的不一致性。

TCC基本流程：

Try：通过Try操作来检查、预留需要的库存，比如需要2台iphone12并进行冻结

Confirm：真正执行业务操作，在之前预留的资源基础上完成购买和创建订单

Cancel：在Try阶段预留2台iphone12失败，则取消所有业务资源的预留（也就是恢复try之前）

优点：

性能提升：  依据业务来控制资源锁的粒度，不会控制整个资源

效了的避免了XA两阶段提交占用资源锁时间过长导致的性能地下问题。

不足：. 代码侵入性强：开发量很大；且如果要保证数据一致性，需要自己实现幂等性

。为了满足一致性的要求，confirm和cancel接口还必须实现幂等。