Directory:

  • Basic concept

  • Distributed transaction theory

  • Distributed transaction solution 2PC

  • TCC for Distributed Transaction Solutions (This Chapter)

  • Reliable message final consistency for distributed transaction solutions

  • Best efforts notification for distributed transaction solutions

  • Distributed transaction synthesis case study

1. Basic concepts

2. Basic theory of distributed transactions

3. 2PC for Distributed Transaction Solution (Two-phase Commit)

4. TCC for distributed transaction solutions

4.1. What are TCC transactions

TCC stands for Try, Confifirm, and Cancel. TCC requires each branch transaction to perform three operations: preprocess a Try, confirm a Confifirm, and Cancel. The Try operation performs service check and resource reservation, the Confifirm operation performs service confirmation, and the Cancel operation performs a rollback operation opposite to the Try operation. TM will first initiate the try operation of all branch transactions. If the try operation of any branch transaction fails, TM will initiate the Cancel operation of all branch transactions. If the try operation succeeds, TM will initiate Confifirm operation of all branch transactions. If the Confifirm/Cancel operation fails, TM will retry.

** Branch transaction failure: **

TCC is divided into three phases:
  1. In the Try stage, services are checked (consistency) and resources are reserved (isolation). This stage is only a preliminary operation, which together with subsequent Confifirm can really constitute a complete business logic.
  2. In the Confifirm phase, confirm submission is performed. In the Try phase, Confifirm is executed after all branch transactions are successfully executed. Generally, TCC is used to assume that the Confifirm stage is infallible. If Try succeeds, Confifirm will succeed. If the Confifirm phase does fail, a retry mechanism or manual processing should be introduced.
  3. In the Cancel phase, a branch transaction is cancelled and reserved resources are released when a service execution error needs to be rolled back. In general, the Cancel phase is considered a certain success when TCC is used. If the Cancel phase does go wrong, a retry mechanism or manual processing should be introduced.

TM transaction manager, TM transaction manager can be implemented as an independent service, or global transaction initiator can act as TM. TM is independent in order to become a common component, to consider the system architecture and software reuse.

TM in a global transaction generated when global transaction records, throughout the distributed transaction chain, global transaction ID is used to record a transaction context, track and record the state, the failure Confifirm and cancel to retry, so need to implement for the idempotent, idempotence refers to the same operation no matter how many times the request, the results are the same.

4.2.TCC solution

** There are many TCC frameworks on the market, such as the following: (Data collection date: July 11, 2019) **
Name of the framework Gitbub address Number of star
tcc-transaction [github.com/changmingxi…]. (https://github.com/changmingxie/tcc-transaction) 3850
Hmily [github.com/yu199195/hm…]. (https://github.com/yu199195/hmily) 2407
ByteTCC [github.com/liuyangming…]. (https://github.com/liuyangming/ByteTCC) 1947
EasyTransaction [github.com/QNJR-GROUP/…]. (https://github.com/QNJR-GROUP/EasyTransaction) 1690
Seata, as described in the previous section, also supports TCC, but the TCC mode of Seata does not support Spring Cloud. Our goal was to understand the principles of TCC and the process of transaction coordination, so we preferred a lightweight framework that was easy to understand, so we settled on Hmily.

Hmily is a high performance distributed transaction TCC open source framework. Based on Java language to develop (JDK1.8), support Dubbo, Spring Cloud and other RPC framework for distributed transactions. It currently supports the following features:

  • Nested transaction support is supported.
  • Disruptor framework for asynchronous reads and writes to transaction logs is no different from RPC framework performance.
  • Supports the springboot-starter project, which is easy to use.
  • RPC framework support: Dubbo, Motan, SpringCloud.
  • Local transactions storage support: redis, directing, zookeeper, fifile, mysql.
  • Transaction log serialization support: Java, Hessian, Kryo, ProtoSTUFFFF.
  • Seamless integration with Spring with Aspect AOP Aspect thinking, natural support for clustering.
  • RPC transaction recovery, timeout abnormal recovery, etc.
Hmily uses AOP to intercept local methods and remote methods involved in distributed transactions. Through multi-party interception, transaction participants can transparently call the other party’s Try, Confifirm and Cancel methods. Passing transaction context; And record transaction log, compensation, retry, etc.

Hmily don’t need a transaction coordination service, but there is a need to provide a data (mysql/mongo/zookeeper/redis/fifile) for logging stored.

The TCC service implemented by Hmily, like a normal service, only needs to expose one interface, its Try business. The Confifirm/Cancel business logic is provided only because of the need for global transaction commit/rollback, so the Confifirm/Cancel business only needs to be discovered by the Hmily TCC transaction framework, not by other business services that invoke it.

**TCC needs to be aware of three types of exception handling: empty rollback, idempotent, and suspension

Empty rollback:

The two-phase Cancel method is called without calling the TCC resource Try method, which needs to recognize that this is an empty rollback and return success directly.

The reason is that when the service of a branch transaction breaks down or the network is abnormal, the call of the branch transaction is recorded as failure. At this time, the Try stage is not executed. When the fault is recovered, the two-stage Cancel method will be called for the rollback of the distributed transaction, thus creating an empty rollback.

The key to the solution is to identify the empty rollback. The idea is simple: you need to know if a phase is executed, and if it is, it is a normal rollback; If it is not executed, it is an empty rollback. As mentioned earlier, TM generates a global transaction record when it initiates a global transaction, and the global transaction ID runs through the entire distributed transaction invocation chain. Add an additional branch transaction record table with the global transaction ID and branch transaction ID, and insert a record in the first phase Try method to indicate that the first phase has been executed. The Cancel interface reads the record. If the record exists, it is rolled back normally. If the record does not exist, it is a null rollback.

Idempotent:

As you have seen from the previous introduction, to ensure that TCC’s two-phase commit retry mechanism does not cause data inconsistencies, TCC’s two-phase Try, Confifirm, and Cancel interfaces are idempotent so that resources are not reused or released. If idempotent control is not done well, serious problems such as data inconsistencies can result.

Add the execution status to Branch Transaction Record and query the status before each execution.

** Suspension: **

Suspension is when, for a distributed transaction, the two-stage Cancel interface executes before the Try interface.

The reason is that when RPC calls the branch transaction try, the branch transaction is registered first and then the RPC call is executed. If the network of RPC calls is congested at this time, usually the RPC call has a timeout time. After THE RPC times out, TM will inform RM to roll back the distributed transaction. Only when the RPC request reaches the participant and is actually executed can the business resources reserved by a Try method be used only by the distributed transaction. The business resources reserved in the first stage of the distributed transaction are no longer able to be processed. In this case, we call it suspension, that is, the business resources cannot be processed after being reserved.

The solution is that if the two-phase execution is complete, the two-phase execution cannot be continued. When executing a one-phase transaction, determine whether there are already two-phase transaction records in the Branch Transaction Records table under the global transaction. If there are, do not execute a Try.

** For example, the scenario is that A transfers 30 yuan to B, and ACCOUNT A and ACCOUNT B are in different services. 天安门事件

Plan 1:

Account A 
Try to check the balance for $30 subtract $30 confirm cancel add $30 copy the codeCopy the code
Account B 
Try: adds 30 yuan confirm: empty Cancel: reduces the replication code by 30 yuanCopy the code
** Description of Solution 1: **

1) Account A, the balance here is the so-called business resources. According to the principle mentioned above, the business resources need to be checked and reserved in the first stage. Therefore, we first check whether the balance of account A is enough in the Try interface of TCC resources, if so, 30 yuan will be deducted. The Confifirm interface represents a formal commit, and since the business resource has been deducted from the Try interface, nothing can be done in the second phase of the Confifirm interface. The transaction is rolled back by executing the Cancel interface. If account A is rolled back, the $30 deducted from the Try interface is returned to the account.

2) Account B is added to account B in the Try interface of the first stage. The execution of Cancel interface indicates the rollback of the whole transaction. The rollback of account B requires subtracting the 30 yuan added to the Try interface.

Problem analysis of option 1: **
  1. If account A’s try is not executed at Cancel, it adds $30.
  2. Since try, cancel, and confifirm are all called by separate threads and repeated calls occur, they all need to be idempotent.
  3. Account B adds $30 to the try, which may be consumed by other threads when the try completes.
  4. If account B’s try is not executed at Cancel, that’s $30 more.
** Problem solving: **
  1. The cancel method of account A needs to check whether the try method is executed. Cancel can be executed only after the try method is executed properly.
  2. The try, cancel, and confifirm methods are idempotent.
  3. Account B is not allowed to update the account amount in try method, but in confifirm.
  4. The cancel method of account B needs to check whether the try method is executed, and cancel can be executed only after the try method is executed properly.
** Optimization scheme: **

Account A

Idempotent check try suspend processing check whether balance is sufficient for $30 deduct $30 CONFIRM empty cancel Idempotent check cancel Empty rollback processing increase available balance $30 Copy codeCopy the code
Account B 
Try: empty Confirm: confirm The idempotent check is formally added by 30 yuan cancel: emptyCopy the code