作者：ptti
来源：恒生LIGHT云社区
经过前面的文章《seata入门介绍与seata-service布置与验证》，咱们对seata已经有一个大体的知道，而且也了解到seata分布式业务AT形式，今天咱们介绍SEATA分布式业务结构中TCC业务结构。打算从原理、实践原型演示、推荐的应用场景、注意事项等这几个维度去介绍TCC分布式业务。
首先介绍一下TCC，关于TCC（Try-Confirm-Cancel）的概念，最早是由Pat Helland于2007年宣布的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。
TCC作为一种与渠道无关的抽象的开放的计划，有很多厂商有自己的实践。已知比较流行的有开源结构有ByteTCC, SEATA，恒生电子也有自己的TCC实现。了解SEATA TCC原理推荐阅读以下两个材料：
SEATA的官方介绍：SEATA.io/zh-cn/docs/…
蚂蚁金服相关开发者共享：www.bilibili.com/video/BV1pK…
关于TCC的解释:
- Try阶段：测验履行,完成一切业务查看（一致性）,预留有必要业务资源（准阻隔性）
- Confirm阶段：承认履行真实履职业务，不作任何业务查看，只运用Try阶段预留的业务资源，Confirm操作满意幂等性。要求具有幂等规划，Confirm失利后需求进行重试。
- Cancel阶段：取消履行，开释Try阶段预留的业务资源 Cancel操作满意幂等性Cancel阶段的反常和Confirm阶段反常处理计划基本上一致。
对TCC的了解概括如下：
- 依据Confirm 与 Cancel使命履行必定成功的假设下，TCC仍然是一个2PC协议。
- 在分布式环境下，它没有供给一个大局的锁的机制去操控资源竞争，仅是约定一个反常时处理回滚操作的流程。
原型演示:
本文触及demo 依据Springcloud + Feign。选用Spring Boot工程，整合Spring Cloud Feign，业务数据库选用的Mysql8.0。
1、业务DB初始化，运用相关脚本构建业务db。
2、maven project布置，包括三个业务模块：account用户中心，order订单中心，storage库存中心。
order是全体业务的进口。
要害依赖
- spring-cloud-alibaba-SEATA-x.x.x.RELEASE-sources.jar SEATA与 Spring Cloud 原生组件(Feign, Hystrix …）适配与集成。
- SEATA-all-x.x.x.jar SEATA 的中心业务逻辑。
- SEATA-spring-boot-starter.x.x.x.jar 与spring boot的集成。
业务一致性中心接口
OrderTccAction.java
AccountTccAction.java
StorageTccAction.java
3、全体逻辑如下图：
4、初始化数据信息
账户余额表
订单数据表
库存信息表
场景演示1：演示一次正常下单成功进程
恳求回来正常
数据库符合预期
场景演示2：演示一次库存缺乏下单失利进程
注：撤销订单的进程可能是异步完成；
中心代码：
成果演示
数据验证，订单并未生成
以上，演示结束，当然能够规划更多场景进行验证，这儿不再展开。
关于seata的TCC形式的一些注意事项与推荐实践
1、关于空回归，悬挂和幂等问题，现在TCC形式下，业务同学有必要自己处理这3个问题。怎么规划业务查询表去处理这3个问题是具有一定的技能难度的。例如选用了一个大局的静态的ConcurrentHashMap ResultHolder.map 作为业务查询表处理了幂等问题，供参阅。需求到网上查找更多相关材料学习。当然SEATA现在已经实现了一个通用的业务查询表功能，结构有能力自己去处理这3个问题。
2、二阶段的动作有必要成功：一阶段成功后，二阶段的Confirm与Cancel 动作有必要成功是TCC形式的约定与条件。开发者需求依据自己实践的业务场景，去判断相关的业务逻辑是放在Try中还是放在Confirm中。 在示例代码中存在一个比较典型的业务区分的办法，即在Try中操作frozen 字段确定账户金额/产品库存，在Confirm中操作used字段去正式扣款/扣库存。如果没有frozen字段，那么扣款/扣库存的动作应该放置于Try办法中而不是Confirm办法中。
3、默认不支撑并发多线程。
依据SEATA的源码剖析与实践代码验证；TCC形式自身对多线程并发履行支撑有限。
如果拓荒其他线程履行使命调用（无论是本地调用，还是RPC/HTTP长途调用），不会加入本地大局业务。
依据此问题，已经在社区有相关实践经验的开发者承认，经过自己获取xId加入到相关线程的ThreadLocalMap中就能够把当时线程履行的使命join到大局业务中；
处理了本地调用场景的条件下，理论上长途调用的场景不需求再做额定处理，因为结构会在RPC/Http发起之前拦截恳求，将相关的大局业务信息从Thread中获取，写入到恳求中。
下面这个项目值得参阅github.com/caohdgege/s…一下，他一定程度上处理了多线程场景的问题，但是尚未验证。因时刻有限，这儿并未进一步承认该计划是否100%准确无误。
4、TCC无默认数据阻隔性。TCC经过约定了一个反常回滚的调用流程，仅仅是处理了分布式环境下业务的原子性问题。无论是分布式环境下，还是单机环境下的数据阻隔性问题，完全需求业务同学自己考虑。在本Demo中能够看到Try or Confirm办法大多会被@Transactional 要害字修饰；单库的ACID性还需求依赖DB自身供给。
5、二阶段（Confirm与Cancel）可能会异步处理。TCC计划比较适合高并发的业务场景。依据confirm 与 rollback操作必定成功的假设条件，二阶段异步处理会极大提升高峰期业务的性能。比如本demo中的示例，客户落单后能够先只是冻住账户金额，并不直接划拨金钱，比及业务高峰期结束，再约定一个时刻（可能时某个定时使命）统一划拨，然后到达削峰的效果。
到此seata分布式业务TCC形式原理和运用共享完成。
想向技能大佬们多多取经？开发中遇到的问题何处讨论？怎么获取金融科技海量资源？
恒生LIGHT云社区，由恒生电子建立的金融科技专业社区渠道，共享实用技能干货、资源数据、金融科技职业趋势，拥抱一切金融开发者。
