分布式事务是面试经常被问到的一个问题,今天我们分析一下TCC事务
首先我们看一个场景，如下图
有个订单服务生成订单的时候，会调用库存服务,积分服务,仓储服务的接口,库存服务会进行扣减库存，积分服务进行增加积分，仓储服务更新出仓状态
但是,如果我们的库存服务因某种原因宕机，导致库存服务扣减成功，而其他他服务正常更新，那么数据就会有不一致的问题，因此我们在创建订单的时候，就必须保证各个系统要么都成功，要么都失败，所以就有了分布式事务的出现，
分布式事务有很多，今天我们就说其中一个事务TCC
T(try):一般就是锁定某个资源,设定一个预备类的状态,冻结部分数据，如下图
C(commit),当try阶段都执行成功，这里就是真正进行提交完成，如下图
C(cancel),当try阶段库存失败，这里就进行回滚的操作，如下图
以上就是TCC事务的基本操作, 事务中的每一个接口由原来的一个接口，变成了三个接口，分别是try接口，comfirm接口，cancel接口
- 先是调用所有服务的try接口
- 如果try都正常,TCC事务就进行Confirm接口
- 如果try某个的服务有异常,TCC事务就会进行回滚操作,调用cancel接口
其中我们可以发现，如果订单服务挂了,然后重启,那么之前没有执行完的事务如何处理
其实这里TCC框架会记录分布式事务的活动日志,可在磁盘的日志文件中记录，也可以记录到数据库,保存各个事务的运行阶段和状态
还有就是当cancel和comfirm执行失败，TCC框架也会根据日志记录和状态进行不断尝试，直到成功.
优点
1.保证的跨服务的操作的原子性,保证数据的最终一致性
2.性能的提高,缩小事务的粒度，不会锁定所有资源
缺点
1.和我们的业务耦合度比较高
2.必须保证接口的幂等性
3.记录日志也会是一种性能消耗
