When it comes to distributed transactions, there are many articles on the Internet, many theories and many practices. Some clearly explain the problem, while others become more and more confused.
I also wrote an article on distributed transactions before, "Distributed Message Queue RocketMQ - Transaction Message - Best Practices for Solving Distributed Transactions", which mainly talks about two implementations of the "transaction message" solution. . This article will systematically sort out other reliable solutions that I think are based on that article.
2PC's problem
2PC Introduction
When it comes to distributed transactions, 2pc is mentioned. What is 2pc, I will briefly explain it here. There are too many articles online. I won't describe in detail.
2pc involves 2 phases, 3 operations:
Phase 1: "Prepare to commit". The transaction coordinator initiates prepare to all participants, and all participants answer yes/no.
Phase 2: "Formal Commitment". If all participants answer yes, commit to all participants; otherwise, initiate rollback to all participants.
Therefore, to implement 2pc, all participants must implement 3 interfaces: prepare/commit/rollback.
Implementation of 2PC
Regarding 2pc, the corresponding implementation level is the XA protocol. There is an Atomikos open source library that also implements this protocol. If you are interested, you can see how to use it.
2PC's problem
(1) In stage 2, if the transaction coordinator hangs up, all participants will not be able to accept the commit/rollback command and will be in a "pending" state
(2) In stage 2, if one participant times out or makes an error, the other participants will Is it a commit or a rollback? also not sure
In order to solve the problem of 2pc, 3pc was introduced. 3pc has a similar problem of how to solve the problem, so it still can't solve the problem completely, so I won't go into details here.
TCC
In order to solve the distributed transaction problem in SOA system, Alipay proposed TCC. 2PC is usually at the cross-database DB level, and TCC is essentially an application-level 2PC.
Similarly, in TCC, each participant needs 3 operations: Try/Confirm/Cancel, which are also 2 stages.
Phase 1: "Resource Reservation/Resource Check", that is, the transaction coordinator calls the Try operation of all participants
Phase 2: "Commit together". If all the Try is successful, execute Confirm together. Otherwise, all execute Cancel.
How does TCC solve the 2PC problem?
Key: After the Try phase is successful, if Confirm fails (whether the coordinator hangs up or a participant times out), keep retrying! !
Likewise, Cancel fails and keeps retrying. This requires Confirm/Cancel to be idempotent operations.
The following takes a transfer case as an example to illustrate the process of TCC:
there are three accounts A, B, and C, which are operated through the transfer service provided by SOA. At the same time, A and B need to transfer 30, 50 yuan to C respectively, and finally C's account +80, A, B minus 30, 50 respectively.
Stage 1: Account A is locked for 30, account B is locked for 50, and the legitimacy of account C is checked (for example, whether account C is illegally frozen, whether account C has been cancelled...).
Therefore, the corresponding Try operation of "deducting money" is "locking", and the corresponding Try operation of "adding money" is to check the legitimacy of the account.
Stage 2: A, B, and C are all successful and Confirm is executed. That is, A, B minus money, C plus money. If either one fails, keep retrying!
As can be seen from the above case, the Try operation is mainly to "ensure that the preconditions of the business operation are satisfied", and then in the Confirm phase, because the preconditions are satisfied, it can be retried continuously to ensure success.
Transactional Messages - Eventual Consistency
Regarding eventual consistency, there are two more implementations, which have been elaborated in "Distributed Message Queue RocketMQ - Transaction Message - Best Practices for Solving Distributed Transactions", and will not be expanded here.
1PC – Saga – Transaction Compensation
We know that in tcc, there are 2 stages. The first stage is "locking resources", the purpose is to ensure that the submission of the second stage will not fail in business.
And 1pc is to abandon the first stage, do not do resource locking, and directly submit the second stage! If the characteristics of the business allow no need to lock resources, then the first stage can be omitted and the second stage can be done directly.
If the second stage fails, there are two strategies: strategy 1, like TCC, is to retry the commit continuously, bite the bullet; strategy 2, rollback, that is, transaction compensation, do the reverse operation of the previous operation.
Regarding 1pc, my personal understanding is not particularly in place. If you are interested, you can refer to the saga of cqrs.
Recommend an exchange and learning group: 650385180 will share some videos recorded by senior architects: Source code analysis of Spring, MyBatis, Netty, principles of high concurrency, high performance, distributed, microservice architecture, JVM performance optimization, these become architects Necessary body of knowledge. You can also receive free learning resources, which are currently benefiting a lot: