TCC(事务补偿)
TCC(Try Confirm Cancel)方案是一种应用层面侵入业务的两阶段提交。
其核心思想是:针对每个操作,都要注册一个与其对应的确认和补偿(撤销)操作。
在 TCC 事务机制中认为,如果在 Try 阶段能正常的预留资源,那 Confirm 一定能完整正确的提交。
TCC分为两个阶段,分别如下:
1、Try 阶段:主要是对业务系统做检测及资源预留 (加锁,锁住资源)
这个阶段主要完成:完成所有业务检查( 一致性 ) 、预留必须业务资源( 准隔离性 ) 。
2、Confirm/Cancel 阶段:根据 Try 阶段服务是否全部正常执行,继续执行确认操作(Confirm)或取消操作(Cancel)。
Confirm(确认):在各个服务中执行真正的业务(执行业务,释放锁)
Cancle (取消):回滚,取消预留的资源(出问题,释放锁)
如果任何一个服务的业务方法执行出错,那么这里就需要进行补偿,就是执行已经执行成功的业务逻辑的回滚操作
最终一致性保证
1、TCC 事务机制以初步操作(Try)为中心的,确认操作(Confirm)和取消操作(Cancel)都是围绕初步操作(Try)而展开。
因此,Try 阶段中的操作,其保障性是最好的,即使失败,仍然有取消操作(Cancel)可以将其执行结果撤销。
2、Try阶段执行成功并开始执行 Confirm阶段时,默认 Confirm阶段是不会出错的。也就是说只要Try成功,Confirm一定成功(TCC设计之初的定义) 。
3、Confirm与Cancel如果失败,由TCC框架进行==重试==补偿
4、存在极低概率在CC环节彻底失败,则需要定时任务或人工介入
方案总结
TCC 事务机制相比于 XA 事务机制,有以下优点:
1、性能提升:具体业务来实现控制资源锁的粒度变小,不会锁定整个资源。
2、数据最终一致性:基于 Confirm 和 Cancel 的幂等性,保证事务最终完成确认或者取消,保证数据的一致性。
3、可靠性:解决了 XA 协议的协调者单点故障问题,由主业务方发起并控制整个业务活动,业务活动管理器也变成多点,引入集群。
缺点:
1、TCC 的 Try、Confirm 和 Cancel 操作功能要按具体业务来实现,业务耦合度较高,提高了开发成本。
1、Try-Confirm
2、Try-Canal
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。