refer to:
http://blog.csdn.net/mine_song/article/details/64118963
http://www.cnblogs.com/dinglang/p/5679542.html
1. What is a distributed transaction
Distributed transaction means that transaction participants, transaction-supporting servers, resource servers, and transaction managers are located on different nodes of different distributed systems. The above is the explanation of Baidu Encyclopedia. In short, a large operation consists of different small operations. These small operations are distributed on different servers and belong to different applications. Distributed transactions need to ensure that these small operations or all Succeed, or fail at all. Essentially, distributed transactions are to ensure data consistency across different databases.
2. Common distributed transaction solutions
1) Two-phase commit based on XA protocol
XA is a distributed transaction protocol, proposed by Tuxedo. XA is roughly divided into two parts: the transaction manager and the local resource manager. Among them, the local resource manager is often implemented by the database. For example, commercial databases such as Oracle and DB2 implement the XA interface, and the transaction manager, as the global scheduler, is responsible for committing and rolling back each local resource. The principle of XA implementing distributed transactions is as follows:
In general, the XA protocol is relatively simple, and once a commercial database implements the XA protocol, the cost of using distributed transactions is relatively low. However, XA also has a fatal disadvantage, that is, the performance is not ideal, especially in the transaction order link, the concurrency is often high, and XA cannot meet high concurrency scenarios. Currently, XA is ideally supported in commercial databases, but it is not ideally supported in MySQL databases. The XA implementation of MySQL does not record logs in the prepare phase. Switching back to the active and standby databases causes data inconsistencies between the main database and the standby database. Many nosqls also do not support XA, which makes the application scenarios of XA very narrow.
2) Message transaction + eventual consistency
The so-called message transaction is a two-phase commit based on the message middleware, which is essentially a special use of the message middleware. It puts the local transaction and the message in a distributed transaction to ensure that either the local operation is successful or successful. And the outgoing message is successful, or both fail. The open source RocketMQ supports this feature. The specific principles are as follows:
1. System A sends a prepared message to the message middleware
2. The message middleware saves the prepared message and returns success
3. A executes the local transaction
4. A sends a commit message to the message middleware
A message transaction is completed through the above 4 steps. For the above 4 steps, each step may generate errors, the following analysis:
- As soon as the step is wrong, the entire transaction fails, and the local operation of A will not be performed
- If there is an error in step 2, the entire transaction fails, and the local operation of A will not be performed.
- There is an error in step 3. At this time, the prepared message needs to be rolled back. How to roll back? The answer is that system A implements a callback interface for message middleware. The message middleware will continuously execute the callback interface to check whether the execution of transaction A is successful. If it fails, it will roll back the prepared message.
- There is an error in step 4. At this time, the local transaction of A is successful, so does the message middleware need to roll back A? The answer is no. In fact, through the callback interface, the message middleware can check that the execution of A is successful. At this time, there is no need for A to send a submission message. The message middleware can submit the message by itself, thus completing the entire message transaction.
Two-phase commit based on message middleware is often used in high concurrency scenarios, splitting a distributed transaction into a message transaction (local operation of system A + message sending) + local operation of system B, where the operation of system B is determined by the message Driver, as long as the message transaction is successful, then the A operation must be successful, and the message must be sent. At this time, B will receive the message to perform the local operation. If the local operation fails, the message will be retransmitted until the B operation is successful, which is disguised The distributed transaction between A and B is realized. The principle is as follows:
Although the above scheme can complete the operations of A and B, A and B are not strictly consistent, but eventually consistent. We sacrifice consistency here in exchange for a substantial improvement in performance. Of course, this kind of gameplay is also risky. If B has been unsuccessful, the consistency will be destroyed. Whether or not to play depends on how much risk the business can take.