Shulou(Shulou.com)06/02 Report--

Problems that 2PC must pay attention to

We introduced the common scenarios, typing, origin and process of 2PC for distributed transactions above. Unfortunately, there are still several problems with 2PC:

1. Synchronous blocking of the whole process: whether it is the first stage or the second stage, all the participating nodes are transaction blocking. When participants occupy public resources, other third-party access to public resources may have to be blocked.

2. TM single point of failure: because the whole process depends on the coordination of TM, once the TM fails. The participants will block all the time. Especially in the second phase, when the TM fails, all participants are still in a state of locking transaction resources and cannot continue to complete the transaction operation. All participants must wait for TM to come back online (TM re-election) before continuing to work.

3. TM brain fissure causes data inconsistency: in the second stage, when TM sends commit requests to participants, a local network exception occurs or TM fails in the process of sending commit requests, which causes only some participants to receive commit requests. After this part of the participant receives the commit request, the commit operation is performed. However, other machines that do not receive a commit request cannot perform a transaction commit. As a result, the whole distributed system has the phenomenon of data inconsistency.

4. TM brain fissure causes uncertain transaction status: the TM goes down after sending the commit message, and the participant who receives the message also goes down. So even if a new TM is generated through the election protocol, the status of the transaction is uncertain, and no one knows whether the transaction has been committed.

Here comes the detailed explanation of 3PC

I. definition of 3PC

2PC is a rigid transaction of CP, which pursues strong data consistency. However, from our above analysis, we can know that TM brain fissure may cause data inconsistency and transaction state uncertainty. Unable to achieve the perfect state of CP. Therefore, 3PC appeared in the industry, which is used to deal with the data inconsistency and transaction state uncertainty caused by TM brain fissure.

Because 3PC is to completely solve the problem of data inconsistency and transaction state uncertainty of 2PC. According to this premise, coupled with the author's understanding of 3PC, the comments of 3PC are summarized:

1) 3PC ensures data consistency under any branch

2) 3PC ensures that up to 3 handshakes in any branch get the final result (timeout mechanism)

3) the transaction status after RM timeout must be obtained from TM. 2PC only has the timeout mechanism of TM, and 3PC adds the timeout mechanism of RM, which not only helps to solve the transaction / transaction problem of 2PC, but also reduces the problem of synchronous blocking. Wikipedia defines 3PC as a "non-blocking" protocol because of the two-way timeout mechanism of TM and RM.

Second, elegant 3PC process

3PC is divided into three stages: CanCommit (preparation stage), PreCommit (alignment stage) and DoCommit (submission stage). According to the materials, the author makes a more appropriate translation of the three stages, unofficial translation.

Preparation phase: similar to the voting phase of 2PC, TM sends a commit request to the participant. If the participant can submit it, it returns Yes, otherwise it returns No. The default participant for query timeout is No. The only difference is at the SQL level: only SQL processing is done in the preparation phase, and transaction logs are not recorded (Undo and Redo)

Alignment phase: TM and each participant align the transaction status, and TM notifies each participant of the final transaction status. If each participant does not receive the transaction alignment notification, it will reverse check the transaction status from TM after the timeout to achieve transaction state alignment. At the SQL level: after the transaction state is aligned, record the transaction log (Undo and Redo)

Commit phase: this is the stage where the real transaction commits. According to the transaction status results obtained in the second phase, each participant commits / abort or automatically commits / abort after timeout according to the notification command of TM.

The following figure is a 3PC flow chart that the author thinks is more reasonable based on the data and personal understanding:

III. Summary

Maybe 3PC is not perfect, there are many flow charts and explanations of various versions of 3PC on the Internet. Some even have obvious problems, which bring more suffering to the understanding of 3PC. As an architect, you need to pursue the essence, understand the past and present life of 3PC, grasp the nature of 3PC, and it is easy to understand 3PC.

For data consistency, Mike Burrows, the author of Google Chubby, said: "there is only one consensus protocol, and that's Paxos"-all other approaches are just broken versions of Paxos. "

There is only one consistency algorithm in the world, and that is Paxos, and all other consistency algorithms are incomplete versions of Paxos.

More free materials and videos

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.