父文章:
两阶段: 持有资源整体锁 见附录1 的比较
tcc: 将资源提前锁住 见附录2的比较
saga:
1. TCC两阶段补偿型
3. 分布式事务:Saga模式 ,Saga相比TCC的缺点是缺少预留动作,导致补偿动作的实现比较麻烦
合力 Seata 分布式事务框架( 将蚂蚁xts 和 阿里 txc合并)
2007 开始,蚂蚁金服自主研发了分布式事务中间件 XTS,在内部广泛应用并解决金融核心场景下的跨数据库、跨服务数据一致性问题,最终以 DTX 的云产品化展现并对外开放。
而与此同时,阿里巴巴中间件团队发布 TXC,为集团内应用提供分布式事务服务,经过多年的技术沉淀,于 2016 年产品化改造为 GTS,通过阿里云解决方案在众多外部客户中落地实施。
2019 年 1 月,基于技术积累,阿里巴巴中间件团队发起了开源项目 Fescar,蚂蚁金服也开源了自己的分布式事务框架,并与 Fescar 合并一起共建分布式事务解决方案。这个发展既在情理之中,也在意料之外,我确实好奇这期间发生了什么,是如何和 SOFA 中间件团队的发展结合的,他们下一步会有什么计划?
鲁直说:“分布式事务是蚂蚁金服在 2007 年做的创新,是基于TCC 原理,我们在内部实现了这个模式。TCC 理论相对还是比较简单的,但是它要落地,需要花费比较长的工程实现上的打磨才行。分布式事务这个技术在蚂蚁金服已经走过了12年的时间了。在蚂蚁金服最核心一些业务上,包括支付、交易、账务等等系统都在使用这套分布式事务框架解决和孵化的。”
在分布式事务这一块领域上,在业界来看目前相对来说比较空白,还没有非常好的分布式事务框架。说起来合并的初衷,鲁直表示,“既然阿里巴巴和蚂蚁金服都在这个方向做了一些开源的工作,所以我们把这两个部分的努力结合起来,取长补短,以适用于更多的分布式事务业务场景,蚂蚁金服加入 Seata 社区共建,在 Seata 0.4.0 版本中加入了 TCC 模式,为大家提供一个更加宽泛的分布式事务的解决方案。”
具体来说,“阿里巴巴的 Seata 提供是 AT 模式,对业务来说,不用有太多感知,但是它覆盖的场景有限,如果可以接受这样的情况,用 AT 模式更好。而蚂蚁金服因为有更强的金融方面的要求,就需要采用 TCC 模式,业务接入成本更高,但是它能做到非常好的分布式执行。未来还会提供像 XA 这样的模式,去适应更宽泛业务场景,这在这一块上,蚂蚁金服和阿里巴巴会结合在一起提供一个融合的框架。”
Seata 为解决微服务架构下的分布式事务问题交出了一份与众不同的答卷。而 Seata 的愿景是让分布式事务的使用像本地事务的使用一样简单和高效,希望可以让 Seata 适用于所有的分布式事务场景。
那些Java架构师必知必会的技术
拜托,面试请不要再问我TCC分布式事务的实现原理!【石杉的架构笔记】
终于有人把“TCC分布式事务”实现原理讲明白了!
[分布式事务-TCC] 1. 分布式事务的由来和TCC的核心思想和工作流程
[分布式事务-TCC] 3. TCC两个阶段的流程图
[分布式事务-TCC] 6. TCC的优化方案之三:二阶段异步化
分布式事务提供方需要实现: 幂等,实现空回滚,防悬挂(实现"空try" ,类似关单排斥创单逻辑 ). 如果不实现"空回滚"将会导致数据错误,严重导致平台资损(提现)或者用户资金损失(支付)
防悬挂实: try阶段 insert 流水状态是try. 和cancel流水,状态是cancel 互斥. 通过共同insert来并发互斥. 类似关单排斥创单逻辑. 一张排斥流水表. cancel里面先select for update 如果没有,再insert
关单排斥创单, 如果没有,再insert.