Collection | For the first time, someone said "distributed transactions" so simple and clear
I don’t know if you have ever encountered such a situation. You went to a small shop to buy something and paid for it, but because the owner of the shop had handled some other things, he forgot that you paid and asked you to pay again.
Author: caffe latte Source: coffee latte micro-channel public number | 2018-08-14 09:28
Favorites
share it
Or when I shop online, I have already deducted money, but it tells me that there is no transaction. This series of situations are caused by no transaction. This illustrates some of the importance of affairs in life.
Once you have a business, you go to a small shop to buy something, and that means paying for it and delivering it. With the transaction, you go shopping online, and the deduction will generate an order transaction.
The specific definition of the transaction
Transaction provides a mechanism to incorporate all operations involved in an activity into an indivisible execution unit. All operations that make up a transaction can only be submitted when all operations can be executed normally. As long as any operation fails, it will Causes the rollback of the entire transaction.
Simply put, transactions provide a mechanism of "either do nothing, or do all (All or Nothing)".
Database local transaction
ACID
When it comes to database transactions, I have to say, the four major characteristics of database transactions ACID:
A: Atomicity, all operations in a transaction are either completed or not completed at all, and will not end in an intermediate link.
If an error occurs during the execution of the transaction, it will be rolled back (Rollback) to the state before the transaction started, as if the transaction had never been executed.
Just like when you buy something, you must pay and receive the goods together, or you will refund the money if it is not shipped.
C: Consistency. The consistency of a transaction means that the database must be in a consistent state before and after the execution of a transaction.
If the transaction is successfully completed, then all changes in the system will be applied correctly and the system is in a valid state.
If there is an error in the transaction, all changes in the system will be automatically rolled back and the system returns to the original state.
I: Isolation (Isolation) means that in a concurrent environment, when different transactions manipulate the same data at the same time, each transaction has its own complete data space.
Modifications made by concurrent firms must be isolated from modifications made by any other concurrent firms. When a transaction views data updates, the state of the data is either the state before another transaction modifies it, or the state after another transaction modifies it. The transaction does not view the data in the intermediate state.
For example, the matter of buying things does not affect other people.
D: Durability, which means that as long as the transaction ends successfully, the updates it makes to the database must be saved.
Even if a system crash occurs, after restarting the database system, the database can be restored to the state when the transaction ended successfully.
For example, when you buy something, you need to record it on the ledger, even if the boss forgets that, it is well documented.
InnoDB implementation principle
InnoDB is a storage engine of MySQL. Most people are familiar with MySQL. Here is a brief introduction to some basic principles of database transaction implementation.
In local affairs, services and resources can be regarded as one under the package of affairs, as shown below:
Our local affairs are managed by the resource manager:
The ACID of the transaction is guaranteed by InnoDB logs and locks. Transaction isolation is achieved through the database lock mechanism, durability is achieved through Redo Log (redo log), and atomicity and consistency are achieved through Undo Log.
The principle of Undo Log is very simple. In order to satisfy the atomicity of transactions, before operating any data, first back up the data to a place (this place where data backup is stored is called Undo Log). Then modify the data.
If an error occurs or the user executes a Rollback statement, the system can use the backup in Undo Log to restore the data to the state before the transaction started.
Contrary to Undo Log, Redo Log records a backup of new data. Before the transaction is committed, only the Redo Log needs to be persisted, and the data does not need to be persisted.
When the system crashes, although the data is not persisted, the Redo Log has been persisted. The system can restore all data to the state of *** according to the content of Redo Log. Students who are interested in the specific implementation process can search for extensions by themselves.
Distributed transaction
What is distributed transaction
Distributed transaction means that the participants of the transaction, the server supporting the transaction, the resource server and the transaction manager are located on different nodes of different distributed systems.
Simply put, 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 either succeed or fail.
Essentially, distributed transactions are to ensure data consistency in different databases.
Reasons for distributed transactions
From the above local affairs, we can be divided into two parts:
- Service generates multiple nodes
- Resource generates multiple nodes
Service multiple nodes
With the rapid development of the Internet, service architecture models such as microservices and SOA are being used on a large scale.
For a simple example, within a company, the user's assets may be divided into multiple parts, such as balance, points, coupons, etc.
In the company, it is possible that the points function is maintained by a microservice team, and the coupons are maintained by another team.
In this case, there is no guarantee that the coupon can be successfully deducted after the points are deducted.
Resource multiple nodes
Similarly, the Internet is developing too fast. Generally speaking, the data installed in MySQL must be divided into databases and tables.
For an Alipay transfer business, if you transfer money to a friend, it is possible that your database is in Beijing, and your friend's money is in Shanghai, so we still cannot guarantee that they can succeed at the same time.
The basis of distributed transactions
From the above point of view, distributed transactions have emerged with the rapid development of the Internet, which is inevitable.
We said before that the four ACID characteristics of the database can no longer satisfy our distributed transactions. At this time, some new bigwigs put forward some new theories.
CAP
The CAP theorem is also called Brewer's theorem. For architects who design distributed systems (not just distributed transactions), CAP is your introductory theory.
C (Consistency): For a specified client, a read operation can return a *** write operation.
For data distributed on different nodes, if the data is updated at a node, if the data of this *** can be read in other nodes, it is called strong consistency. If there is a node If it is not read, it is a distributed inconsistency.
A (Availability): Non-faulty nodes return a reasonable response within a reasonable time (not an error and timeout response). The two keys to usability are reasonable time and reasonable response.
Reasonable time means that the request cannot be blocked and should be returned in a reasonable time. A reasonable response means that the system should clearly return the result and the result is correct. The correctness here means that, for example, it should return 50 instead of 40.
P (Partition fault tolerance): When a network partition occurs, the system can continue to work. For example, there are multiple machines in the cluster, and one machine has a network problem, but the cluster can still work normally.
Anyone familiar with CAP knows that the three cannot be shared. If you are interested, you can search for the proof of CAP. In a distributed system, the network cannot be 100% reliable. Partitioning is actually an inevitable phenomenon.
If we choose CA and give up P, then in order to ensure consistency when a partition occurs, the request must be rejected at this time, but A does not allow it, so it is theoretically impossible to choose a CA architecture for a distributed system, and can only choose CP Or AP architecture.
For CP, giving up availability and pursuing consistency and partition fault tolerance, our ZooKeeper is actually the pursuit of strong consistency.
For AP, giving up consistency (the consistency mentioned here is strong consistency) and pursuing partition fault tolerance and availability is the design choice of many distributed systems. The following BASE is also extended according to AP.
By the way, the CAP theory ignores network delay, that is, when the transaction is submitted, there is no delay in replicating from node A to node B, but in reality this is obviously impossible, so there will always be a certain amount of time inconsistency.
At the same time choosing two in CAP, for example, if you choose CP, it does not tell you to give up A. Because the probability of P appearing is too small, you still need to guarantee CA most of the time.
Even if the partition appears, you have to prepare for the subsequent A. For example, through some logging methods, other machines are restored to use.
BASE
BASE is an abbreviation for the three phrases Basically Available, Soft state and Eventually consistent, and is an extension of AP in CAP.
Basically available: When a distributed system fails, it is allowed to lose part of the available functions to ensure that the core functions are available.
Soft state: Allows an intermediate state in the system. This state does not affect system availability. This refers to the inconsistency in the CAP.
Final consistency: Final consistency means that after a period of time, all node data will reach consistency.
BASE solves the theory that there is no network delay in CAP, and uses soft state and final consistency in BASE to ensure consistency after delay.
BASE is the opposite of ACID. It is completely different from ACID's strong consistency model. Instead, it gains availability by sacrificing strong consistency, and allows data to be inconsistent for a period of time, but eventually reach a consistent state.
Distributed transaction solution
With the above theoretical foundation, here is the introduction of several common distributed transaction solutions.
Do you really want distributed transactions
Before talking about the plan, you must first make it clear whether you really need distributed transactions?
I mentioned two reasons for distributed transactions, one of which is because of too many microservices. I have seen too many teams maintain a few microservices by one person, and too many teams over-design and make everyone tired.
Too many microservices will lead to distributed transactions. At this time, I will not recommend you to adopt any of the following schemes. Instead, please aggregate the microservices that require transactions into a single server, using the local transactions of the database.
Because no matter what kind of scheme will increase the complexity of your system, the cost is too high, do not introduce unnecessary cost and complexity just because of the pursuit of certain designs.
If you are sure that you need to introduce distributed transactions, you can look at the following common scenarios.
2PC
Speaking of 2PC, I have to talk about XA Transactions in database distributed transactions.
There are two stages in the XA protocol:
- The transaction manager requires each database involved in the transaction to precommit this operation and reflect whether it can be committed.
- The transaction coordinator requires each database to commit data or roll back data.
advantage:
- Try to ensure the strong consistency of the data, and the implementation cost is low. It has its own implementation in major mainstream databases. MySQL is supported from 5.5.
Disadvantages:
- Single point problem: The role of the transaction manager in the entire process is very critical. If it goes down, for example, the *** phase has been completed, and the transaction manager goes down when the second phase is about to commit. Will be blocked forever, causing the database to be unusable.
- Synchronous blocking: After being ready, the resource in the resource manager has been blocked until the submission is completed and the resource is released.
- Data inconsistency: Although the two-phase commit protocol is designed for strong consistency of distributed data, there is still the possibility of data inconsistency.
For example, in the second stage, suppose that the coordinator issued a notification of transaction Commit, but because of network problems, the notification was only received by some participants and the Commit operation was performed, and the remaining participants were blocked because they did not receive the notification. State, at this time data inconsistency has occurred.
In general, the XA protocol is relatively simple and low in cost, but its single point problem and its inability to support high concurrency (due to synchronization blocking) are still its weaknesses.
TCC
The concept of TCC (Try-Confirm-Cancel) was first proposed by Pat Helland in a paper entitled "Life beyond Distributed Transactions: an Apostate's Opinion" published in 2007.
Compared with the XA described above, the TCC transaction mechanism solves the following shortcomings:
- The single point of the coordinator is solved, and this business activity is initiated and completed by the main business party. The business activity manager has also become multipoint, introducing clusters.
- Synchronous blocking: Introduce timeout, compensate after timeout, and will not lock the entire resource, transform the resource into business logic form, and reduce the granularity.
- Data consistency, after having a compensation mechanism, the business activity manager controls the consistency.
Explanation of TCC:
- Try phase: Try to execute, complete all business checks (consistency), and reserve necessary business resources (quasi-isolation).
- Confirm phase: Confirm the actual execution of the business, without any business inspection, only use the business resources reserved in the Try phase, and the Confirm operation satisfies idempotence. Idempotent design is required, and a retry is required after Confirm fails.
- Cancel phase: Cancel the execution, release the business resources reserved in the Try phase, and the Cancel operation satisfies idempotence. The exception handling scheme of the Cancel phase is basically the same as that of the Confirm phase.
To give a simple example: if you buy a bottle of water for 100 yuan, the Try stage: you need to check with your wallet whether it is enough for 100 yuan and lock the 100 yuan. Water is the same.
If one fails, Cancel (release the 100 yuan and the bottle of water). If Cancel fails, retry Cancel regardless of failure, so it needs to remain idempotent.
If all are successful, proceed to Confirm to confirm that the 100 yuan has been deducted and the bottle of water has been sold. If the Confirm fails, no matter what fails, it will retry (it will rely on the activity log to retry).
Some suitable for TCC:
- Strong isolation, strict consistency requirements for active business.
- Businesses with shorter execution time.
Implementation reference: https://github.com/liuyangming/ByteTCC/.
Local message table
The local message table proposal was originally proposed by eBay, eBay’s complete proposal https://queue.acm.org/detail.cfm?id=1394128.
The core of this solution is to asynchronously execute tasks that require distributed processing through message logs. The message log can be stored in a local text, database or message queue, and then retry can be initiated automatically or manually through business rules.
Manual retries are more commonly used in payment scenarios, and the reconciliation system is used to deal with post-event problems.
The core of the local message queue is to transform large transactions into small transactions. Let's take the example of buying a bottle of water with 100 yuan.
1. When you deduct money, you need to add a new local message table on the server where you deduct money, you need to write your deducted money and water deducted inventory into the local message table, and put it in the same transaction ( Rely on database local transactions to ensure consistency).
2. At this time, there is a timed task to poll the local transaction table, throw the unsent message to the commodity inventory server, and ask it to subtract the water inventory. After reaching the commodity server, it must be written to the server first. The transaction table is then deducted. After the deduction is successful, the status in the transaction table is updated.
3. The commodity server scans the message table through timed tasks or directly informs the deduction server, and the deduction server updates the status in the local message table.
4. For some abnormal situations, periodically scan the unsuccessfully processed messages and resend them. After the commodity server receives the message, it first judges whether it is a duplicate.
If it has been received, then judge whether to execute it. If it is executed immediately, the transaction will be notified; if it has not been executed, it needs to be re-executed by the business to ensure idempotence, that is, no extra bottle of water will be deducted.
The local message queue is the BASE theory and is the final consistent model, suitable for situations where consistency is not high. Need to pay attention to the idempotence of retries when implementing this model.
MQ transaction
Distributed transactions are implemented in RocketMQ, which is actually an encapsulation of the local message table, and the local message table is moved inside MQ.
Here is a brief introduction to MQ transactions. If you want to learn more about it, you can refer to: https://www.jianshu.com/p/453c6e7ff81c.
The basic process is as follows:
- ***Prepared message, you will get the address of the message.
- The second phase executes local affairs.
- The third stage uses the address obtained in the *** stage to access the message and modify the status. The message recipient can use the message.
If the confirmation message fails, the RocketMQ Broker provides a message that the status of the regular scan has not been updated.
If a message is not confirmed, it will send a message to the message sender to determine whether to submit it. In RocketMQ, it is sent to the sender in the form of Listener for processing.
If the consumption times out, you need to retry all the time, and the message receiver needs to be idempotent. If the message consumption fails, it needs to be processed manually at this time, because the probability is low, if you design this complicated process for such a small probability time, the gain is not worth the loss.
Saga affairs
Saga is a concept mentioned in a database ethics 30 years ago. The core idea is to split a long transaction into multiple local short transactions, which are coordinated by the Saga transaction coordinator. If it ends normally, it will be completed normally. If a step fails, the compensation operation will be called once in the reverse order.
Composition of Saga: Each Saga is composed of a series of sub-transaction Ti, and each Ti has a corresponding compensation action Ci. The compensation action is used to undo the result caused by Ti. Each T here is a local transaction.
As you can see, compared with TCC, Saga does not have a "reserved try" action, and its Ti is directly submitted to the library.
There are two execution sequences of Saga:
- T1 ， T2 ， T3 ， ... ， Tn。
- T1, T2,..., Tj, Cj,..., C2, C1, where 0 <j <n.
Saga defines two recovery strategies:
- Backward recovery, that is, the second execution order mentioned above, where j is the sub-transaction in which the error occurred. The effect of this approach is to cancel all previous successful sub-transations, so that the execution result of the entire Saga is cancelled.
- Forward recovery, suitable for scenarios that must be successful, the execution sequence is similar to this: T1, T2,..., Tj (failure), Tj (retry),..., Tn, where j is an error Sub-transaction. Ci is not needed in this case.
It should be noted here that isolation cannot be guaranteed in Saga mode, because no resources are locked, other transactions can still cover or affect the current transaction.
Let's take the example of buying a bottle of water for 100 yuan. Here is the definition:
- T1 = 100 yuan deduction, T2 = add a bottle of water to the user, T3 = reduce the inventory of a bottle of water.
- C1 = add 100 yuan, C2 = deduct a bottle of water for the user, C3 = add a bottle of water to the inventory.
We perform T1, T2, and T3 at a time. If a problem occurs, perform the reverse of the C operation where the problem occurred.
The isolation problem mentioned above will occur if you need to perform a rollback at this time when the execution reaches T3, but the user has already drunk the water (another transaction), you will find that you cannot reduce the user by one during the rollback. Bottle of water.
This is the problem of no isolation between transactions. It can be seen that the impact of Saga mode without isolation is still great. You can refer to Huawei's solution: starting from the business level, add a Session and lock mechanism to ensure serialization of operating resources.
It is also possible to isolate this part of resources at the business level by freezing funds in advance. *** can obtain updates of *** by reading the current status in time during business operations. (Specific example: You can refer to Huawei Service Comb)
***
Again, if you don't need distributed transactions, you don't need to. If you have to use it, combine your own business analysis to see which one is more suitable for your business, whether you care about strong consistency or final consistency.
***After summarizing some questions, you can come down to find the answers from the article:
- Is the CA of ACID and CAP the same?
- What are the advantages and disadvantages of common solutions for distributed transactions? What scenario is it suitable for?
- Why does distributed transaction appear? What pain points are used to solve?