Sorted out some Java architecture, interview materials (micro services, clusters, distributed, middleware, etc.), partners in need can pay attention to the public number [programmer internal point], no routine to get
More choice
-
Reeling off nine distributed ID generation methods, the interviewer gets a little confused
-
How about the score sheet? You can play him off like this
-
30,000 words summary, the essence of Mysql optimization
-
The technology department suddenly announced that all JAVA developers would have to know the interface automation testing framework
-
9 kinds of distributed ID generation of the United States (Leaf) combat
Pour out
I still remember that when I first started to write Java, the first project I came into contact with was a business system of State Grid. It is said that 500 million RMB was invested in research and development of this system, and at its peak, the r&d staff once reached 500. The project adopts the most popular SSH (Struts+Spring+Hibernate) framework at that time. The typical three-tier architecture (Controller -> service -> DAO) is simple and crude. All the code written by everyone is put in a big project, and the project file size reaches hundreds of meters. Resolving code conflicts was the biggest workload at the time.
However, on the day of beta delivery, five people went online at the same time, and the project crashed… Ah! You can never imagine the anger of party A, the project team everyone’s ancestors were greeted.
The introduction
Two days ago, a student left a message on his official account, saying that he wanted to talk about distributed affairs, and the interview was hung on this question. Nowadays, with the popularity of microservices architecture, interview questions have gradually begun to upgrade, no longer simple SSH framework knowledge, data structure. High concurrency, high availability, distributed service governance, distributed file system, distributed XXX, anyway and distributed with the edge of the point will ask, the actual use of the project does not matter, the key you have to understand, is there always a sense of learning not to move?
What are distributed transactions?
Let’s take a look at the definition of distributed transaction on Baidu: distributed transaction means that transaction participants, transaction supporting servers, resource servers and transaction managers are located on different nodes of different distributed systems.
"One-stop" work style
At this point all operations are in one transaction and either all commit or all roll back.
However, with the continuous growth of business volume, the “one-stop” system gradually can not carry the huge flow, it is necessary to separate the database and table, the business service separation (SOA), will be separated from the order center, user center, inventory center. As a result, services are isolated from each other. Each service maintains its own database, and data can only be exchanged through RPC calls.
When users place an order again, they need to operate both the order DB and the inventory DB to create an order and reduce the inventory. The two steps must be successful at the same time, otherwise it will cause business chaos. However, at this time, we can only guarantee the data consistency of our own service, but cannot guarantee the success of the operation of calling other services. Therefore, in order to ensure the data consistency of the entire single process, distributed transaction intervention is needed.
Before we talk about distributed transactions, let’s recall the basic concept of a transaction: a transaction is a unit of program execution in which all operations either succeed or fail.
A transaction has four basic properties, commonly known as ACID.
Atomicity: A transaction is an indivisible whole in which all operations either succeed or fail.
Consistency: Data must be consistent from one state to another before and after A transaction is executed (A transfers money to B, and B does not receive the money deducted by A).
Isolation: Multiple concurrent transactions are isolated from each other and cannot interfere with each other.
Durablity: Changes to the database are permanent and cannot be rolled back after the transaction has completed.
These are concepts that are repeated over and over again.
Distributed transaction solutions
When there is a problem, there is always a solution. Nothing is difficult for a smart programmer.
XA protocol is a distributed transaction protocol based on database, which is divided into two parts: transaction manager and local resource manager. As a global scheduler, the transaction manager is responsible for ordering commits or rolls back to all local resource managers. The second order commit protocol (2PC) and third order commit protocol (3PC) are derived from this protocol. Now Oracle, Mysql and other databases have implemented XA interface.
1. Two-paragraph submission (2PC)
Two-stage submission as the name implies, there are two stages of submission: the first stage, the preparation stage (voting stage); The second stage is the commit stage (execution stage).
The above picture originated from the network, if there is infringement contact delete
The following also takes the single deduction inventory as an example to briefly describe the principle of two-section commit (2PC) :
As mentioned earlier, with business servitization (SOA), a single order process uses multiple services, each of which cannot guarantee the success or failure of the other services invoked, and a global role (coordinator) is required to coordinate the services (participants).
An order request comes through the coordinator, sending a Prepare message to each participant, executing the local data script but not committing the transaction.
If the coordinator receives a failure message or timeout message from each participant, send a Rollback message directly to each participant. Otherwise, send a Commit message; Participants perform commit or rollback operations as instructed by the coordinator to release all resources occupied during transaction processing. Obviously, 2PC did all operations either successfully or failed.
Disadvantages of two-paragraph commit (2PC)
Two-phase commit seems to provide atomicity, but it has serious drawbacks
-
Inconsistent data caused by network jitter: In the second phase, after the coordinator sends the commit command to the participants, once network jitter occurs, some participants receive the COMMIT request and execute it, but other participants who do not receive the commit request cannot execute the transaction commit. Then lead to the whole distributed system data inconsistency.
-
Synchronization blocking caused by timeout: All participant nodes in 2PC are transaction blocking. When a participant node times out, other participants passively block and occupy resources.
-
Risk of single point of failure: Due to the heavy reliance on the coordinator, if the coordinator fails while participants are locked resources, the transaction COMMIT cannot be completed. While a failure of the coordinator will result in the election of a new coordinator, the problem of participants being blocked due to the failure of the previous coordinator will not be resolved.
2. Three-paragraph Submission (3PC)
Three-segment commit (3PC) is an upgrade optimization to two-segment commit (2PC), where 3PC inserts a preparation phase between the first and second phases of 2PC. This ensures that the state of the participant nodes is consistent until the final commit phase. At the same time, a timeout mechanism is introduced in both the coordinator and the participant. When the participant does not receive the commit request from the coordinator for various reasons, the local transaction will be committed, which does not block and wait all the time. This solves the single point of failure of 2PC, but 3PC still fails to fundamentally solve the data consistency problem.
The above picture originated from the network, if there is infringement contact delete
The three stages of 3PC are CanCommit, PreCommit, and DoCommit
CanCommit: The coordinator issues the CanCommit command to all participants, asking if the transaction commit operation can be performed. If all responses are YES, the next stage is entered.
PreCommit: The coordinator sends the PreCommit command to all participants, asking whether the transaction can be pre-committed. After receiving the PreCommit request, if the participant successfully executes the transaction, the participant will return Yes and enter the final commit phase. Once one of the participants sends No response to the coordinator, or a timeout is caused by the network, and the coordinator does not receive the response from the participant, the coordinator sends abort request to all participants, and the participant receives abort command to execute the interruption of the transaction.
DoCommit: After all participants respond YES in the first two phases, the coordinator sends the DoCommit command to the participants to formally commit the transaction. If the coordinator does not receive the ACK response from the participants, the coordinator sends the abort request command to all participants to execute the interruption of the transaction.
3. Compensation Transaction (TCC)
Many beginners are confused by TCC, 2PC and 3PC. In fact, TCC, like 2PC and 3PC, is just a solution to implement distributed transactions.
TCC (try-confirm -Cancel) is also known as compensation transaction. TCC and 2PC have similar ideas and transaction processing processes, but 2PC is applied at the DB level, while TCC can be understood as 2PC at the application level, which requires us to write business logic to achieve.
The core idea of TCC is: “For each operation, a corresponding acknowledgement (Try) and compensation (Cancel) are registered.”
Also take down the single deduction inventory to explain its three operations:
Try stage:
Reserve inventory resources are deducted by Try operation when placing an order.
Confirm stage:
Confirm that a service operation is performed and initiate a purchase request based on reserved resources.
Cancel phase:
If one service fails to reserve resources, all service resource reservation requests are cancelled.
The above picture originated from the network, if there is infringement contact delete
Disadvantages of TCC:
-
Application is highly intrusive: TCC is based on the business level, so each operation needs to have three interfaces: try, Confirm, and Cancel.
-
Development difficulty: large amount of code development, to ensure data consistency confirm and Cancel interface must be idempotent.
conclusion
Very simple introduction to 2PC, 3PC, TCC concept, if there is a mistake still hope to gently correct, distributed transaction has been a hot issue in the interview, but also advanced advanced Java engineers essential knowledge points.
Sorted out some Java architecture, interview materials (micro services, clusters, distributed, middleware, etc.), partners in need can pay attention to the public number [programmer internal point], no routine to get