TCC 什么是 TCC分布式事务？

在过去的两年里，微服务变得越来越热门，各种框架和组件的出现促进了微服务的发展。

众所周知，每个微服务都是一个对应的小服务，多个服务可以很容易地组合起来形成更强大的服务。服务之间的数据和部署是独立的，因此故障可以相互隔离。但是它也带来了分布式应用程序将面临的问题:

如何保证多个服务之间的交易？如何保证操作的原子性和一致性？

对于传统的应用程序开发和部署，所谓的ACID可以通过数据事务来保证，但是在微服务场景中，数据库无法做到这一点。

这时候2PC和3PC轮流解决这样的问题。但是，在某些场景下，根据我们的实际需求，我们并不需要纯2PC。比如你只关心数据的原子性和最终一致性，那么你就受不了2PC阶段的堵塞，于是一些聪明人想出了一个新办法。这是我们今天要讨论的灵活交易TCC。

什么是灵活交易TCC？

我们今天说的灵活交易，“软”主要是相对于“传统”的ACID，灵活交易只需要遵循BASE原则。而TCC是一种柔性交易的实现。TCC是三个首字母，试-确认-取消。具体描述是将整个操作分为以上三个步骤。尝试在两个微服务之间同时进行。在尝试阶段，将进行数据验证、检查和资源预创建。如果两者都成功，则分别进行确认。如果两者都成功，整个TCC交易就完成了。如果确认时出现服务问题，会转到取消，相当于确认的反操作。

整个灵活交易有多种实现思路，比如:

特定用途

在之前的项目开发中，我们也有类似的场景来确保两个微服务之间的一致性。根据具体场景，采用TCC交易。当时是通过部门的一个基本组成部分和异步补偿来保证的。

基本实现原理

这些TCC框架基本都是“注释”的形式，其中声明了Confirm方法和Cancel方法，然后带有注释的方法被AOP统一截取，然后根据结果分别执行Confirm或者Cancel。

代码如下所示:

@可赔(confirmMethod = "confirmRecord "，cancelMethod = "cancelRecord "，transactionContextEditor = methotransactioncontexteditor . class)

公共字符串记录(事务上下文事务上下文，大写贸易订单到贸易订单到){

确认方法

public void confirm record(transaction context transaction context，CapitaL TradeOrder to TradeOrder to){

取消方法:

public void cancelRecord(transaction context transaction context，Redpackettradeordto tradeorderto){

基于相似的框架，可以更方便地满足我们的业务使用场景。欢迎留言添加您如何确保分布式场景中的一致性。