事务协调器在调用TCC效劳的一阶段Try操作时，能够会出现因网络拥堵而招致的超时，此时势务协调器会触发二阶段回滚，调用TCC效劳的Cancel操作，Cancel调用未超时；在此之后，拥堵在网络上的一阶段Try数据包被TCC效劳收到，出现了二阶段Cancel央求比一阶段Try央求先执行的状况，此TCC效劳在执行晚到的Try之后，将永远不会再收到二阶段的Confirm或许Cancel，形成TCC效劳悬挂。
所以在完成TCC效劳时，要允许空回滚，但也要拒绝执行空回滚之后Try央求，要避免出现悬挂。
补偿型TCC下面解说的是通用型TCC，它需求对散布式事务相关的一切业务有掌控权。但有时分（例如调用的是别的公司的接口），通用型TCC行不通。
因此存在补偿型TCC，可以了解为没有Try的TCC方式。由于未提供Try接口，可以以为是Saga机制的另一种方式。
比如坐飞机需求换乘，换乘的飞机又是不同的航空公司，比如从A飞到B，再从B飞到C，只要A-B和B-C都买到票了才有意义。
这时分就直接接调用航空公司的买票操作，当两个航空公司都买成功了那就直接成功了，假设某个公司买失败了，那就需求调用取消订票接口。
相当于直接执行TCC的第二阶段，需求重点关注回滚操作。假设回滚失败得有记载报警和人工介入等。
总结TCC事务将散布式事务从资源层提到业务层来完成，可以让业务灵敏选择资源的锁定粒度，并且全局事务执行进程中不会不断持有锁，所以系统的吞吐量比2PC形式要高很多。
由于TCC事务的带来的工程复杂度、网络延迟和效劳管理难度的提高，所以除非是与支付买卖相关的中心业务场景（对分歧性要求很高），其他业务场景不要运用TCC事务。
Saga事务Saga事务，也是一种补偿事务。同补偿型TCC一样，没有Try阶段，而是把散布式事务看作一组本地事务构成的事务链。
Saga事务基本协议如下：
每个Saga事务由一系列幂等的有序子事务(sub-transaction，担任参与者的身份) Ti 组成。
每个Ti 都有对应的幂等补偿举措Ci，补偿举措用于撤销Ti形成的结果。
事务链中假设包含有业务顺序的逻辑，一定要合理放置事务链的顺序（以项目利益为优先，假设出现纰漏可以人工补齐的准绳，例如先扣款后发货；先退货再退款）
由于Saga模型中没有Prepare阶段，因此事务间不能保证隔离性，当多个Saga事务操作同一资源时，就会产生更新丧失、脏数据读取等成绩，这时需求在业务层控制并发，例如：在运用层面加锁，或许运用层面预先解冻资源。
下面以下单流程为例，整个操作包括：扣减库存（库存效劳）、创立订单（订单效劳）、支付（支付效劳）等等。
事务正常执行完成T1, T2, T3, ...,Tn，例如：扣减库存(T1)，创立订单(T2)，支付(T3)，依次有序停止，但支付效劳出现报错，此时Saga有两种策略可以运用。
Saga事务的恢复策略Saga定义了两种恢复策略。
向前恢复(forward recovery)
适用于必需要成功的场景，发作失败停止重试，执行顺序是相似于这样的：T1, T2, ..., Tj(失败), Tj(重试),..., Tn，其中j是发作错误的子事务(sub-transaction)。
显然，向前恢复没有必要提供补偿事务，假设业务中子事务（最终）会成功，或补偿事务难以定义或不能够，向前恢复更契合需求。
过度积极的重试策略（例如距离太短或重试次数过多）会对下游效劳形成不利影响，所以需求运用一个比较合理的重试机制。
向后恢复(backward recovery)
这种做法的效果是撤销掉之前一切成功的子事务，使得整个Saga的执行结果撤销。
下面解说的示例均为向后恢复策略。
Saga事务协调形式Saga执行事务的顺序称为Saga的协调逻辑。这种协调逻辑有两种形式，协调(Orchestration)和事情编排(Event Choreography)辨别如下：
协调(Orchestration)：Saga提供一个控制类，方便子事务的协调任务。事务执行的命令从控制类发起，按照逻辑顺序央求Saga的子事务，从子事务那里接遭到反应以后，控制类再发起向其他子事务的调用。一切Saga的子事务都围绕这个控制类停止沟通和协调任务。
以电商订单的例子为例：
事务发起方的主业务逻辑央求控制类开启订单事务
控制类向库存效劳央求扣减库存，库存效劳回复处置结果。
控制类向订单效劳央求创立订单，订单效劳回复创立结果。
控制类向支付效劳央求支付，支付效劳回复处置结果。
主业务逻辑接纳并处置事务处置结果回复。
控制类必须事前知道执行整个订单事务所需的流程。假设有任何失败，它担任经过向每个子事务发送命令来撤销之前的操作来协调散布式的回滚。基于控制类协调一切时，回滚要容易得多，由于控制类默许是执行正向流程，回滚时只需执行反向流程即可。
事情编排(Event Choreography)：子事务之间的调用、分配、决策和排序，经过交流事情停止停止。是一种去中心化的形式，子事务之间经过音讯机制停止沟通，经过监听器的方式监听其他子事务收回的音讯，从而执行后续的逻辑处置。由于没有中间协调点，靠子事务停止相互协调。
以电商订单的例子为例：
事务发起方的主业务逻辑发布末尾订单事情
库存效劳监听末尾订单事情，扣减库存，并发布库存已扣减事情
订单效劳监听库存已扣减事情，创立订单，并发布订单已创立事情
支付效劳监听订单已创立事情，停止支付，并发布订单已支付事情
主业务逻辑监听订单已支付事情并处置。
完成方式比照基于协调的Saga的优点如下：
效劳之间关系复杂，避免子事务之间的循环依赖关系，由于Saga控制类会调用Saga子事务，但子事务不会调用控制类。
顺序开发复杂，子事务只需求完成本身的义务，不用思索处置音讯的方式，降低子事务接入的复杂性。
易维护扩展，假设事务需求添加新步骤，只需修正控制类，保持事务复杂性保持线性，回滚更容易管理。
容易测试，测试任务集中在集中在控制类上，其他效劳独自测试功用即可。
基于协调的Saga的缺陷如下：
控制类集中太多逻辑的风险，招致难以维护。
控制类存在单点缺点风险。
基于事情编排的Saga的优点如下：
避免控制类单点缺点风险。
子事务之间经过订阅时间沟通，组合会更灵敏。
基于事情编排的Saga的缺陷如下：
效劳之间存在循环依赖的风险。
当触及的步骤较多，效劳间关系混乱。假设没有完善的文档支撑，了解整个事务的执行进程只能经过阅读代码完成。添加开发人员了解和维护代码的难度。
基于本地音讯表机制 (责任编辑：admin)