You can refer to Zhihu related articles, which are easier to understand
2PC
This inconsistency plagues everyone. If one side makes an error and wants to roll back the other side, it is not a simple database rollback (because it has been successfully submitted at this time), but needs to do the reverse operation of the business, and the reverse operation of different businesses is different, resulting in increased complexity. Considering that the execution of the database transaction is actually first writing the execution operation to the binlog, and then finally updating the contents of the binlog to the table through a commit command, or rolling back the contents of the binlog halfway through a rollback command. Therefore, it is conceivable to use two stages to perform this process. The first stage is to write to binlog; the second stage is to execute commit or rollback. This is known as the Two-Phase Commit Protocol (2PC) . If you think about it carefully, you will find that the two-phase protocol does not solve the problem, but only reduces the probability of errors, because the second phase also has the above two situations. Note that the final state is the result of the state && of multiple machines. Here is the timing diagram for the two-phase protocol:
1. Consider the response in the prepare phase (because both the request phase and the execution phase can be reflected in the final response). For a distributed environment, consider 3 states at any time: success, failure, and timeout.
a. to succeed. Do not need to deal with it, execute the subsequent action commit.
b. Failed. This is an error in the execution phase, and the subsequent behavior rollback is executed.
c. Timeout. It may be that the execution phase is too slow, or the network phase is too slow or packet loss, but if handled conservatively, the timeout can be regarded as an error.
It can be seen that the problems in the prepare stage can be completely avoided.
2. Consider the commit phase, and also consider the three states of success, failure and timeout.
a. to succeed. The entire transaction executes successfully
b. Failed. If there is an error in the submission, assuming that the previous B has been submitted successfully at this time, it is also faced with the problem that B needs to be rolled back but cannot be rolled back, because B has been submitted successfully.
c. Timeout. Ditto.
There is also an exception, that is, A hangs up after the prepare phase is completed, then B and C enter a state of being overwhelmed.
It can be seen that transactions in 2PC cannot be as secure as a single machine, but the probability of problems is reduced.
3PC
A 3-phase commit protocol emerged for how to resolve exceptions in 2PC . The main improvement of stage 3 is to divide the prepare of stage 2 into two stages, canCommit and preCommit.
1. Consider the response of the cancommit phase.
a. to succeed. Don't have to deal with it, execute the subsequent action precommit.
b. Failed. The description cannot be executed without subsequent commit or rollback behavior.
c. Timeout. Treated conservatively, timeouts can be treated as failures.
2. Consider the response in the precommit phase.
a. to succeed. Do not have to deal with it, perform the subsequent action docommit.
b. Failed. An error occurs in the execution phase, and the subsequent behavior rollback is executed.
c. Timeout. The execution phase is too slow, and the network phase may be too slow or packet loss, but conservative processing, timeout can be regarded as an error.
3. Consider the response of the cancommit phase.
a. to succeed. The entire transaction executes successfully.
b. Failed. If there is an error in the submission, assuming that the previous B has been submitted successfully at this time, it also faces the problem that it cannot be rolled back.
c. Timeout. Treated conservatively, timeouts can be treated as failures.
XTS
What is the application of distributed transactions in the industry? You can refer to the well-known distributed framework XTS of Baobao.
XTS is essentially 2PC (in fact, if 3PC is introduced, there will be 2n more network interactions, which will be more insecure when the volume is large). XTS introduces the server part of coordinator A, which is actually a large cluster, which is configured to access various services that require distributed transactions. The cluster is maintained by a dedicated team to ensure its availability and performance; coordinator A's client Part of it is called by the initiator. In the prepare stage, the client sends the transaction information to the server first, stores it in the database, and then immediately pushes the prepare request to B and C. When the response from B and C is received, their status is stored in the database. , if it is normal, make a commit; otherwise, it will use a timed task to push the unfinished state until it is completed. After the above-mentioned prepare, the coordinator A hangs up, which rarely happens under the guarantee of the server cluster. For all the above-mentioned timeouts, you can get a certain state through the push of scheduled tasks instead of blindly choosing to roll back or submit. In addition, since B and C are both clusters, it rarely happens that multiple requests have not responded in the past. Until the last situation is that B succeeds and C fails when committing, or vice versa, B fails and C succeeds. This situation becomes a suspended transaction and finally waits for manual resolution. It is said that there are several to dozens of transactions every day.
Undoubtedly, as the application of 2PC in the industry, XTS is quite a remarkable design. It avoids various possible inconsistencies in various ways and achieves a balance in performance and efficiency.
TCC（Try/Confirm/Cancel）
The basic idea of the business compensation type is to perform a reverse operation on each business operation. Once it succeeds, it will perform the forward business, and if it fails, the reverse operation of the business will be performed. It is usually better to use it when the business logic is simple and the forward and reverse operations are clear.
query compensation
A typical scenario is that a transfer request is sent to the bank and no clear return code of success or failure is obtained. In this case, the query of the business result is performed first, and the corresponding processing is performed according to the result. For example, if the query result is successful, the status is set to success. Do the corresponding business compensation, if the query result is unknown, continue the query.
Message Transactions and Message Retry
Transaction messages and message retry essentially hand over some general transactions to message middleware, which ensures the eventual consistency of messages.
In fact, the message transaction solves this kind of problem, that is, the local transaction and the message should have consistency, it is more troublesome to solve this consistency, such as the message middleware and the business implement XA at the same time; or use some more complex methods, such as the message table It is placed in the same database as the business table, and the transaction of the database is used to ensure consistency, and the message system only needs to train the message table in rotation; of course, there is also a two-phase submission + compensation method for messages. The message transaction solves the consistency problem between the message initiator, that is, the producer and the message middleware.
- try{
- //database operation
- // message delivery
- }catch(Exception e){
- // rollback
- }
Principle and Practice of Distributed Open Messaging System (RocketMQ)http://www.jianshu.com/p/453c6e7ff81c
Message middleware (1) A comparison of transaction consistency solutions in distributed systems, who is the best? http://blog.csdn.net/lovesomnus/article/details/51785108