分布式事务之tcc文章搜集

父文章:

   分布式事务 同库模式 remote模式

 两阶段: 持有资源整体锁 见附录1 的比较

tcc: 将资源提前锁住 见附录2的比较

saga:

1. TCC两阶段补偿型

2. 终于有人把“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] 2. TCC的异常场景及应对机制

[分布式事务-TCC] 3. TCC两个阶段的流程图

[分布式事务-TCC] 6. TCC的优化方案之三：二阶段异步化

分布式事务提供方需要实现: 幂等,实现空回滚,防悬挂(实现"空try" ,类似关单排斥创单逻辑 ).  如果不实现"空回滚"将会导致数据错误,严重导致平台资损(提现)或者用户资金损失(支付)

防悬挂实: try阶段 insert 流水状态是try. 和cancel流水,状态是cancel 互斥. 通过共同insert来并发互斥. 类似关单排斥创单逻辑. 一张排斥流水表. cancel里面先select for update 如果没有,再insert 

关单排斥创单, 如果没有,再insert.