"Distributed Transaction" solution Rollup--2pc/tcc/Transaction message/1pc

When it comes to distributed transactions, online articles are voluminous, theories are many, and practice is many. Some clearly explain the problem, some more confused.
I've also written a distributed transaction article, "distributed Message Queuing rocketmq– transactional messaging – Best practices for solving distributed transactions," which focuses on 2 implementations of the 1 solutions for "transactional messaging". This article will be based on the article, I think the other solutions are systematically organized. 2PC Problem 2PC Introduction

When it comes to distributed transactions, it mentions 2pc. What 2pc is, here's a brief description. There are too many articles online. Do not draw a detailed elaboration.

2PC involves 2 stages and 3 operations:
Phase 1: "Ready to commit." The Coordinator initiates prepare to all participants, and all participants answer yes/no.
Phase 2: "Formally submitted". If all participants answer yes, a commit is initiated to all participants; otherwise, rollback is initiated for all participants.
Therefore, to achieve 2pc, all participants have to implement 3 interfaces: Prepare/commit/rollback. implementation of the 2PC

About 2pc, the corresponding implementation level, which is the XA protocol. There is a Atomikos open source library that also implements this protocol. Interested can go and see how to use. 2PC Problem

(1) Phase 2, the coordinator of the transaction is hung, then all participants are not accepted to the Commit/rollback directive and will be in a "suspended" state
(2) Stage 2, where one of the participants timed out or went wrong, and the other participant was a commit or a rollback. I'm not sure.

In order to solve the 2pc problem, the introduction of 3pc. 3pc has a similar hang how to solve the problem, so still can not completely solve the problem, here is not detailed. TCC

In order to solve the distributed transaction problem in the SOA system, Alipay proposed the TCC. 2PC is usually at the db level of the cross-Library, and the TCC Essence is an application-level 2PC.

Similarly, in TCC, each participant requires 3 operations: Try/confirm/cancel, also 2 stages.
Phase 1: "Resource reservation/resource Check", that is, the transaction Coordinator invokes the try operation of all participants
Phase 2: "Commit together". If all the try succeeds, execute confirm together. Otherwise, all of the execution cancel. How does TCC solve the problem of 2PC?

Key: After the try phase succeeds, confirm fails (either the coordinator hangs or a participant times out) and retries continuously.
Again, cancel fails, and retries are repeated. This requires that the Confirm/cancel must be idempotent operations.

The following is an example of a 1 transfer case to illustrate the TCC process:
There are 3 accounts a, B, and C, which operate through the transfer service provided by the SOA. A, b at the same time to the C-turn 30, 50 yuan, the last account of C +80,a, b respectively minus 30, 50.

Phase 1: A account lockout 30,b account lockout 50, check the legality of C account (such as C account is not illegal to be frozen, C account has been written off ...) ）。
Therefore, the corresponding "deduction" of the try operation is "locked", the corresponding "plus money" try operation is to check the validity of the account

Phase 2: A, B, C all try successfully, execute confirm. That is, a, b minus money, C plus money. If any one fails, keep retrying.

As can be seen from the above example, the try operation is mainly to "ensure that the precondition of business operation is satisfied", and then in the confirm phase, because the precondition is satisfied, so it can be retried to ensure success. transactional Messages – eventual consistency

There are 2 more implementations of final consistency, which are described in detail in the distributed Message Queuing rocketmq– transaction messages – Best practices for solving distributed transactions, which are no longer expanded here. 1pc–saga– Transaction Compensation

We know that there are 2 stages in TCC. The 1th phase is "locking resources" in order to ensure that the 2nd phase commits do not fail in business.
And 1pc, is to abandon the 1th stage, do not do the resource lock, directly to the 2nd phase of the submission. If the characteristics of a business can allow for no locking of resources, then the 1th phase can be omitted, and the 2nd phase will be done directly.

If the 2nd stage fails, there are 2 strategies: Strategy 1, like TCC, is also constantly retrying commit, the bite on the bullet, strategy 2, rollback, that is, transaction compensation, to do before the operation of the counter operation.

About 1pc, personal understanding is not particularly in place, interested can refer to Cqrs saga.
Http://www.cnblogs.com/netfocus/p/3149156.html