Distributed transaction (the first 05) Distributed Transaction Solution -TCC

What is a TCC

TCC each transaction branch are divided into three parts (Try, Confirm, Cancel):

Try: Business checks and resource reservation.
Confirm: real implementation of business, do not do any business check. Try using a stage reserved resources.
Cancel: to achieve rollback operation, the release of resources.

Two TCC achieve a distributed transaction processes

The first stage: global transaction manager calls are all branches of the transaction, all branch transactions Try operation, when all branch transactions Try operations succeed, or a part of the branch affairs Try the operation fails, have entered the second stage.
Phase II: If the first phase of all branches of affairs Try successfully executed, the global transaction manager notifies all branch transactions Confirm operation, otherwise notify all branch transactions Cancel operation.

Success Legend:

Failure Legend:

Illustrate three processes TCC

Scene: A transfer account to the account 30 B, AB in the different services.

plan 1:

A服务：
    Try{
        检查A账户余额是否大于30元。
        A账户扣减30元。
    }
    
    Confirm{
        空。
    }
    
    Cancle{
        A账户增加30元。
    }

B服务：
    Try{
        B账户增加30元。
    }
    
    Confirm{
        空。
    }
    
    Cancle{
        B账户扣减30元。
    }

Scenario 1 existing problems :

Due to network reasons, Try A service is not performed, the branch timeout, the global transaction notify all branch transactions Cancel, then A accounts on more than 30 yuan.
Try, Confirm, Cancel all have a separate thread to perform, and there will be called repeatedly, does not support idempotency.
After the service performs Try B B accounts increased by 30 yuan, 30 yuan use these other services, and for some reason after AB branch transactions need to perform Cancel, B 30 yuan the account is not enough.
And 1 type, Try B services not performed, branch timeout, the global transaction notify all branch transactions Cancel, then B would account less than 30 yuan.

Problem solving :

A service executed before the Cancel determine whether the service A Try.
AB increased service idempotency.
B service in the Confirm achieved an increase of 30 yuan.
B Service B Service before performing Cancel determine whether a Try.

The optimized Scenario 2:

A服务：
    Try{
        增加幂等性。
        判断是否已经执行了Cancel。若Cancle已执行，则不执行Try，反之则执行Try。
        检查A账户余额是否大于30元。
        A账户扣减30元。
    }
    
    Confirm{
        空。
    }
    
    Cancle{
        增加幂等性。
        判断是否已经执行了Try。若Try未执行，则不执行Cancel，反之则执行Cancel。
        A账户增加30元。
    }

B服务：
    Try{
       空。 
    }
    
    Confirm{
        增加幂等性。
        B账户增加30元。
    }
    
    Cancle{
        空。
    }

From this we can see the use of TCC needs to pay attention to some problems.

Four TCC three sets of needs attention exception:

Empty rollback
is necessary to determine whether the current transaction branch has been executed Try executing Cancel.
悬挂
执行Try时需要判断当前分支事务是否已经执行Cancel。
幂等性
由于Confirm和cancel失败需进行重试，因此需要实现幂等性。

五 TCC与2PC区别

TCC本质上也是二阶段提交协议，但他们又有很大不同：

TCC作用与服务层，2PC作用于资源层。（TCC开发人员通过业务代码实现数据提交与回滚，2PC基于数据库厂商原生协议，由数据库层面实现数据提交与回滚。）
TCC三个接口逻辑由开发人员编写，2PC由数据库厂商或第三方编写。
由于以上两原因，TCC可以自由控制资源锁定的粒度。
TCC侵入业务逻辑过强，每个分支事务都需要实现Try、Confirm、Cancel三个接口，改造成本高。

六 TCC缺点

代码侵入性太强，每个分支事务都得实现Try、Confirm、Cancel。（这一点我可难了，代码量庞大，耦合性高..手动狗头）
幂等性难以控制。

七 TCC的实现框架

ByteTCC，TCC-transaction，Hmily。