This article is the story of a donkey readers to contribute articles huperzine architecture notes, thank the students to share
In a distributed micro-services popular today, I believe we are not familiar with these terms. And when it comes to the benefits of using a distributed, or split the micro-services, you can certainly think of a lot.
For example, each person only needs to maintain its own separate service, not the previous various codes conflict. I want to test, to publish, to upgrade, only need to write their own code of Care on OK, very convenient very close!
However, everything has two sides, it will also bring some problems, today's article to talk about is a distributed system architecture which brings a thorny problem: Distributed Transaction!
What is a transaction?
First, throw out a question: What is a transaction Some would say that the transaction is a series of operations, at the same time either succeed or fail at the same time; then will start from the narrative of the transaction ACID properties (atomicity, consistency, isolation, durability)?.
Indeed, the transaction is to ensure that a series of operations can be performed properly, it must meet the ACID properties.
But today we are at another angle, we must not only know What (such as what is a transaction), but also to know the affairs Why (such as why there is this notion of a transaction? What matters is to solve the problem).
Sometimes, maybe there is not the same as another point of harvest.
From another perspective Affairs
Like the classic literary works are from life, but higher than life, the concept of a transaction from the same life, the introduction of a "transaction" is certainly in order to solve some problems, or who wants to do such silly things?
The simplest and most classic example: bank transfers, we transfer from account A to account B 1000.
Under normal circumstances, if, after the transfer from the account to B 1000 A, A 1000 Save account balance (this operation we Action1 Representative), B account balance plus 1000 (this operation we Action2 representative)
First, we must be clear that, Action1 and Action2 are two operations. Since then the two operations is bound to have the order executed.
Then it may appear when just getting ready to perform Action1 Action2 the implementation of End a problem (such as database load is too large to temporarily deny access).
Analogy to our lives, that is my friend turned to 1000 dollars, less the balance of 1000 and then my card, but my friend did not receive the money.
In order to solve this "Money where to go," the problem, the introduction of the concept of "affairs". That is, since I can not transfer when you can guarantee 100 percent success, such as the banking system can only guarantee 99.99% availability, then the above problem in that 0.01% of the time if there is a banking system operating directly rollback Action1 ? (1000 dollars that is added back to the balance)
For the banking system, it may be 0.01% of the time I can not guarantee success Action1 and Action2 the same time, then the problem in time, I promise Talia fail simultaneously. (Atomicity of transactions)
Through this example, we have answered two questions raised by the beginning of (transactions Why? What matters is to solve the problem?)
To summarize: it is through the transaction ACID properties, to ensure that a series of operations can be executed safely and correctly in any case.
Transactions in Java
After figuring out the transaction, we look at a familiar point, Java is how to play in the affairs of?
Java is the most we usually add @Transactional comment on the additions and deletions to the method of use of the Service layer, let us go and Spring managed transactions.
It will give us the bottom of the Service component generates a corresponding dynamic agent Proxy, so that all of the methods Service component by its corresponding Proxy to take over.
When the former Proxy when you call the corresponding business methods such as add (), Proxy AOP will be based on the idea of calling the real business method executes setAutoCommit (false) open transaction.
Then after the implementation of the Executive Commit method commits the transaction of business, when an exception occurs during the execution of business method executes Rollback to roll back the transaction.
Of course @Transactional annotation specific implementation details will not expand here, Topic this is not the focus of this article, this article is "distributed transaction" on @Transactional comment you are interested, you can break under their own point Debug source research, a source of true knowledge.
What is a distributed transaction?
Foreshadowing hot for so long, and finally to first focus Benpian first thought not:! Now that you have affairs, and the @Transactional Spring annotation to control transactions is so easy, then why did they have to engage in a distribution the concept of transaction out ah?
Furthermore, distributed transactions and general affairs in the end what is the relationship? What is the difference? Distributed transaction is to solve any problems?
A variety of questions followed, do not worry, with these reflections, we talk in detail on the following distributed transaction.
Now called a distributed transaction, then there must be something to it, and distributed! In simple terms, a distributed transaction refers to a distributed transaction system.
Well, let's continue, first of all look at the following chart:
As shown above, a monolithic system has three modules: Module employees, financial modules and leave the module. We now have an operational need in order to call to complete the three modules of the interface.
This operation is a whole contained in a transaction, either at the same time succeed or fail at the same time rollback. Or-break, this is no problem.
But when we split the monolithic system into a distributed system or micro-service architecture, so the above transaction is not to play.
First we look at the architecture view after the split into a distributed system as follows:
The figure is the same operation performed in the case of a distributed system. Staff module, financial module and leave the module are to be split into staff systems, financial systems and leave the system.
For example, a user performs an operation, the operation will need to call the staff of the system in advance to handle it, and then call interfaces financial system and leave the system for further processing via HTTP or RPC manner respectively, their operations need to fall into the database, respectively.
This series of operations actually three systems all need to be wrapped in the same distributed transaction, in which case these three operating systems, while either succeed or fail at the same time.
Distributed systems typically require a complete call among a plurality of cooperative systems and communication operations, such as the above example.
Three subsystems: the system will be among staff, financial system, leave the system via HTTP or RPC communication, rather than calls between different modules of a monolithic system, this is the biggest difference between distributed systems and single-block system .
Some students usually do not focus on distributed architecture, see here may say: I direct @Transactional Spring annotation on OK, ah, Guannameduo doing!
But the most important point here: monolithic system is running in the same JVM process, but each system running its own JVM process in a distributed system.
So you just add @Transactional annotation does not work, because it can only control the same JVM process transactions, but for this kind of transactions across multiple JVM processes incompetent and weak.
Several distributed transaction realization of ideas
To figure out what is distributed transaction, the distributed transaction in the end is how to play it? Below came to introduce several implementations of distributed transactions.
Reliable sources eventual consistency scheme
The overall flow chart is shown below:
We explain the process about this program:
- A system first sends a message to the MQ Prepared, if this fails then the message is sent Prepared cancel not performed directly, subsequent operations are not performed.
- If this message is sent succeeds, then perform A system of local affairs, fails to tell if a rollback MQ message, subsequent operations are not executed.
- A local transaction if the system is successful, it tells MQ sends a confirmation message.
- A delay in the system if it does not send a confirmation message it? At this point MQ will automatically poll all Prepared timed messages, then A system call interface provided in advance, through which anti-check whether the last local transaction A successful implementation of the system.
- If successful, it sends a confirmation message to the MQ; MQ rollback fails to tell the message. (Subsequent operations are not performed)
- At this time, the system B receives the acknowledgment message, and then perform local transactions, if the transaction is a local transaction is executed successfully completed normally.
- If the local transaction execution system B is supposed to fail? Retry slightly based on MQ, MQ will automatically continue to retry until successful, if it is not, it can send an alert to manually hand-rolled back and compensation.
Highlights of this program is to be based on MQ to continue to retry, eventually you will perform successfully.
Because of the general failure of the implementation of the network jitter or instant database load is too high, it is a temporary problem.
Through this program, 99.9% of the cases are ultimately ensures consistency of data, and the remaining 0.1 percent when something goes wrong, it is manually repair data chanting.
Applicable scene: Use this program is quite extensive, large domestic Internet companies are based on this idea of play.
Best to inform program
The overall flow chart is shown below:
The general process of this program:
- A system after executing the transaction locally, sending messages to the MQ.
- There will be a special consumption MQ utmost notification service, this service will be spending MQ, and then written to the database record, or is placed in a memory queue. Next call interface system B.
- If the system B is executed successfully on everything is OK, but if you perform System B fails?
- So at this time it is best to inform service timed attempt to re-call system B, repeated N times, the last to give up or not.
The difference between this program and the eventual consistency of the above programs to reliable sources: a reliable source program can guarantee eventual consistency is the completion of the transaction as long as the system A, by constantly (unlimited) to ensure that the transaction will always retry system B is completed .
But the best efforts program is different, if the local transaction execution system B fails, then it will retry after retry N times longer, local transaction system B may not complete. As for how you want to control it "many efforts", the need to combine their businesses to configure.
For example, for the electricity supplier system, send SMS notification after placing the order the user a single successful business scenario, orders completed normally, but to send text messages of this session due to the short message service is temporarily a problem, leading to retry three times or failed.
Then the time will no longer try to send a message, because we believe in this scene three times had been regarded as the best of the "best effort" was.
Brief summary: that is, within a specified number of retries, if executed successfully so happy, if more than the maximum number of retries to give up, not to try again.
Applicable scene: generally used in less critical business operations, is the kind of complete words are icing on the cake, but if it fails for me there is no bad influence on the scene.
For example, the top part of the notification messages electricity supplier mentioned, it is more appropriate to use this program to do its utmost to ensure notification of distributed transactions.
TCC strong consistency scheme
TCC stands for:
- Try (try)
- Confirm (Confirm / submitted)
- Cancel (rollback)
In fact, this is the use of the notion of compensation, divided into three stages:
- Try Stage: This stage talking to each service's resources to do testing and resource locking or reserved.
- Confirm Phase: This phase is to say actual operation is performed in each service.
- Cancel stages: if a business method any service execution error, this needs to be compensated, that has been executed successfully execute business logic rollback.
Or give you an example:
For example, when the inter-bank transfers, to be involved in a distributed transaction two banks, if the program is implemented by TCC, the idea is this:
- Try stages: the first two bank accounts frozen the funds to not let it operate.
- Confirm stages: performing the actual transfer operations, capital A bank account deductions and increase capital B bank account.
- Cancel stages: if the operator fails to perform any of a bank, you need to roll back to compensate, for example, it is if A bank account has been deducted, but the increase in funds from bank accounts B fails, then you have to add funds to a bank account A go back.
Applicable scene: this program to tell the truth almost rarely used, we use is relatively small, but there are scenarios used.
Because this transaction rollback actually rely heavily on write your own code to rollback and compensation, and the code will cause huge compensation, very sick.
For instance, we generally associated with money, dealing with money, payment, transaction-related scenes, we will use the TCC, ensure strict distributed transaction either all succeed or all automatic rollback, and strictly ensure the correctness of funds the problem appears not allowed in the capital.
More suitable scenes: Unless you are really asking for too much consistency, your system is the core of the core of the scene, such as the common type of scene is money, then you can use the TCC program.
You need to write a lot of business logic, a judge for themselves whether the transaction in all aspects OK, not OK on the implementation of the compensation / rollback code.
And the best time of your various business performed relatively short. But to tell the truth, so generally try not to engage in their own handwriting rollback logic or compensation logic, too disgusting, business code that is difficult to maintain.
to sum up
This introduction of what is distributed transaction, and also describes the most commonly used three kinds of distributed transaction program
But in addition to the top of the program, there are also two-phase commit scheme (XA program) and local news and other programs table.
But to be honest there are very few companies use these programs, in view of the limited space, will not be covered. If you have the opportunity to follow the articles detailed talk about these two schemes of thinking.