Article list
Distributed transaction is an important test point of MySQL, especially the monolithic architecture becomes the microservice architecture. In the case of high concurrency, a single mysql cannot be supported, and a mysql cluster must be used
[Distributed transaction 001] Seven types of distributed transactions
[Distributed transaction 002] Five evolutions of distributed transaction architecture
[Distributed transaction 004] Distributed transaction based on XA in MySQL
Important interview questions
Interview question 1: Strong consistency, weak consistency, final consistency?
Strong consistency :
Definition : After the update operation is completed, any access by multiple subsequent processes or threads will return the latest updated value.
Advantages : This is the most user-friendly, that is, what the user wrote last time, the next time it is guaranteed to be able to read what.
Disadvantages : According to the CAP theory, this implementation needs to sacrifice availability, such as Mysql Oracle comes with XA transactions.
Weak consistency (weak consistency is only a theory and has no practical value. What has practical value is special weak consistency, eventual consistency) :
Definition : The system does not guarantee that the process or thread access will return to the latest update. Value. It takes a period of time for the user to read that an operation updates the specific data of the system. We call this period of time the "inconsistency window". After the data is successfully written, the system does not promise to read the latest written value immediately, nor does it specifically promise how long it will be able to read it. On the premise that no failure occurs, the time of the inconsistency window is mainly affected by communication delay, system load and the number of replicas.
Final consistency (a special case of weak consistency) :
Definition/specificity : Final consistency is a special kind of weak consistency. So what is special about it? We say, "Weak consistency means that after the data is successfully written, the system does not promise to read the latest written value immediately, nor does it specifically promise how long it will be read". The special feature of final consistency is that the system guarantees In the absence of subsequent updates, the system will eventually return the value of the last update operation. DNS is a typical eventually consistent system.
Pay special attention that there are only two database consistency, strong consistency and weak consistency. Final consistency is a special kind of weak consistency. It is a subset of weak consistency, not the same as strong consistency and weak consistency. The third type of consistency in which sex alone is tied.
The special feature of final consistency is that the system guarantees that the system will eventually return the value of the last update operation without subsequent updates. DNS is a typical eventually consistent system.
Interview question 2: Explain transactions and distributed transactions?
Question: One sentence will clear "transactions and distributed transactions"?
Standard answer :
Definition : Transaction is to ensure the data consistency of a single database, and distributed transaction is to ensure the data consistency of multiple databases.
Implementation method : The
former can be realized by using the built-in transaction Transaction of mysql. It is good to use the built-in transaction transaction to wrap the atomic operation in one layer; the
latter has different implementation methods, and you can use the XA two-stage built-in mainstream database. Implementation of distributed transactions (XA strong consistency, sacrificing certain availability, performance, and scalability), you can write SQL statements yourself, write your own back-end code to achieve (eBay local message table, best-effort notification, TCC programming, final consistency Sex) (non-XA final consistency).
Interview question 3: Summary of seven distributed transactions (interview book: just remember the following three steps)?
The first step
is to offer 7 distributed transactions. MySQL itself provides XA distributed transactions. The underlying principle is a two-stage commit, which
guarantees data consistency among multiple data sources at the database level: eBay’s local message table does not use distributed transaction guarantees. Multi-data source data consistency, but use the message queue MQ as notification, a message table to ensure idempotence,
best-effort notification, but also not use XA, two methods: MQ notification, be notified, put your own inquiry
in the back-end SOA The interface level guarantees the data consistency of multiple data sources: TCC programming mode does not use MySQL's XA distributed transaction, but changes one interface into three interfaces try confirm cancel, and use back-end code to process
semi-message/final consistency. It is the performance optimization of TCC (TCC turns one interface into two interfaces try-confirm or try-cancel), using the core function TCC to achieve, non-core functions are directly called, and the core functions use MQ message queue to notify non-core functionsTherefore, seven types of distributed transactions:
MySql comes with XA distributed transactions: two-stage, three-stage, Mysql distributed transactions based on XA
does not use distributed transactions, operating database mysql level: eBay local message table, best effort Notice
Do not use distributed transactions, call back-end SOA interface level: TCC programming mode, semi-message/eventual consistency for TCC performance optimization
What is XA?
XA definition: XA is a specification for distributed transactions proposed by the X/Open organization (to understand XA, first understand DTP). XA function: The XA specification mainly defines the interface between (global) transaction management and (local) resource manager (RM). The mainstream relational database products all implement the XA interface, such as mysql oracle (this is very important ) .
The second step is to compare the advantages and disadvantages of 5 types of distributed transactions, strong consistency + final consistency, and selection principles.
Advantages of XA distributed transactions : strong consistency of distributed transactions, good.
Disadvantages of XA distributed transactions : distributed transactions Strong consistency comes at the expense of availability, performance, and scalability.
Do not use distributed transactions, operate the database mysql level: eBay local message table, best-effort notification Advantages : the tight coupling between the two database instances is lifted, and its performance and scalability are unmatched by distributed transactions.
Do not use distributed transactions, operate the database mysql level: eBay local message table, best-effort notification Disadvantages : There is no strong consistency guarantee of distributed transactions. When the system fails, the system will be in an inconsistent state for a short time using the above solution. However, based on the message queue and message application state table, the system can eventually be restored to consistency.
Summary : XA distributed transaction, strong consistency; eBay local message table and best-effort notification both use message queues, and both are eventual consistency (special weak consistency.
Selection principle (XA distributed transaction or eBay local message table/ Best effort guarantee) : The
use of distributed transactions can help simplify application development. The use of message queues (ebay local message table/ best effort notification) obviously requires more work.
For systems that are short of time or have low performance requirements, you should Use distributed transactions to speed up development efficiency;
for systems with not very tight time requirements and high performance requirements, you should consider using the message queue scheme (ebay local message table/ best effort notification).
For the original use of distributed transactions, and The system has stabilized, and the performance requirements of the system, you can use the message queue solution (eBay local message table / best effort notification) for reconstruction to optimize performance.
The third step is to sacrifice the database level and the SOA service level.
As for not using distributed transactions, call the back-end SOA interface level : TCC programming mode, semi-message/final consistency is
incomparable to TCC performance optimization . The first two are operations Database table, this is to operate SOA service.
The fourth step is analogous to java multithreading.
Two-phase commit and three-phase commit are similar to the code to be executed wrapped in synchronized and lock, which must be executed atomically.
The rollback operation of TCC relies on the MySQL log system. Java multithreading has no log system and cannot provide support for the rollback mechanism. There is no corresponding.
The best effort notification is similar to the non-blocking synchronization of Java cas, which is atomic operation at the hardware level, and keeps trying until it succeeds.
Note that the third question "Seven Distributed Transactions", this question has not been answered. For each specific implementation of distributed transactions, please read the blog.
For two-stage/three-stage, see "Distributed Transaction 001 "Seven Distributed Transactions"
For the distributed transactions implemented by Mysql based on XA, see a separate blog.
For the best effort guarantee and eBay local message table, they are separate blogs.
For the TCC programming model and eventual consistency, see "Distributed Transaction 001 Seven Distributed Transaction and Distributed Transaction 002 Five Changes in Distributed Transaction