TCC
是由支付宝架构师提供的一种柔性解决分布式事务解决方案,主要包括三个步骤:服务器
TCC
的关键流程以下图(如下单和扣减库存为例子)
Q: 预生成订单失败了,为何要经过TCC
执行预处理数据回滚?架构
A: 可能预生成订单成功,可是接口返回失败(超时失败),因此预处理在某些状况下是有预处理数据,须要清理分布式
在整个流程,咱们主要须要关注的是cancel
失败和confirm
失败引发的数据不一致现象spa
TCC
服务支持接口失败重试,因此对TCC
暴露的接口都须要知足幂等性(根据事务Id很好知足)设计
基于TCC
的中心化事务一致性解决方法,各个应用服务器若是须要感知某次事务是否成功的成本很高,因此对于自身而言进行事务补偿成本就会很高.举个例子:code
1⃣️每次成功的执行本应用服务器的事务之后,都须要把成功执行的事务Id记录
2⃣️继续confirm
或者将confirm
完的数据回滚,对用户都很不友好,特别是须要confirm
订单或者回滚订单数据
3⃣️能够根据事务开始的时间,而且设计一个事务超时时间,若是在这个时间范围之外事务尚未处理完成,就能够当作这个事务已经失败,将预处理数据删除
整体来讲,事务补偿机制,心智负担过于沉重.因此只能依赖TCC
服务器的失败重试机制,若是失败重试机制不能处理,只能人肉去处理(建议全程人肉,由于同时进行失败重试和人肉的话,由于若是失败重试和人肉都在操做同一条数据,还须要考虑这种竞争的场景,对重试次数须要限定)接口
是否必定须要TCC服务器?
不必定,可让交易链路来充当TCC
服务器的角色,可是长期来看,TCC
至关因而一个公用的组件,因此其它地方也须要TCC
分布式事务,能够公用这一个组件(交易链路能够完成TCC
所能完成的一切操做,把TCC
单独部署一个服务,仅仅是考虑整个系统的抽象结构和功能复用)图片
这里说的预处理,指的是什么?
在整个分布式事务中预处理的含义其实很普遍,好比订单,所谓的预处理就是生成订单,可是用户真实是看不到这些订单的,至于具体实现是在一张新表中记录仍是在原有的订单表是加上标记位,具体实现方式由本身统筹考虑(固然还须要考虑记录事务Id);像减库存这种预处理,能够直接减小原始库存,再经过另一张表来记录此次事务Id操做了哪一个Sku的库存数量,固然也能够不减小库存只记录操做,可是这种方式在计算实际库存的时候复杂度会提升(须要减掉预处理的那部分)事务