Distributed transaction (understand in seconds)

• Crazy Maker Circle Classic Book: "Netty Zookeeper Redis High Concurrency Actual Combat" Interview Essential + Interview Essential + Interview Essential [ Blog Garden General Entrance ]

• Crazy Maker Circle Classic Books: "SpringCloud, Nginx High Concurrency Core Programming" Essentials for major manufacturers + Essentials for major manufacturers + Essentials for major manufacturers [ Blog Park General Entrance ]

• Necessary for entering a big factory + salary increase: high concurrency [IM actual combat with 100 million traffic] actual combat series [SpringCloud Nginx spike] actual combat series [ blog garden general entrance ]

---

1 Distributed transaction (the most comprehensive interpretation in history)

1.1 Interview questions

Nowadays, in Java interviews, distributed systems and distributed transactions are almost standard. The distributed system and distributed transaction itself are more complicated, and it is a headache for everyone to learn.

面试题：分布式事务了解吗？你们是如何解决分布式事务问题的？

（标准答案：见末尾）

1.1.1 Introduction to the transaction

Transaction (Transaction) is a program execution unit (unit) that manipulates a certain data item in the database. Transactions should have 4 attributes: atomicity, consistency, isolation, and durability. These four attributes are usually called ACID characteristics.

(1) Atomicity: A transaction is an indivisible unit of work, and all operations included in the transaction are either done or not done.

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.

For example, if you buy something, you must pay and receive the goods together, or you will get a refund if you don’t ship it.

(2) Consistency: The transaction must change the database from one consistency state to another consistency state. When a transaction views data, 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.

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 an error occurs in the transaction, all changes in the system will be automatically rolled back and the system returns to the original state.

(3) Isolation: The execution of a transaction cannot be interfered by other transactions. That is, the internal operations of a transaction and the data used are isolated from other concurrent transactions, and each transaction executed concurrently cannot interfere with each other.

For example: buying things by one person does not affect other people's buying things.

Isolation is divided into four levels: read uncommitted (read uncommitted), read committed (read committed, solve dirty read), repeatable read (repeatable read, solve virtual read), serialization (serializable, solve phantom read ).

(4) Durability: Durability, also known as permanence, means that once a transaction is committed, its changes to the data in the database should be permanent. The following other operations or failures should not have any effect on it. Even if a system crash occurs, after restarting the database system, the database can be restored to the state it was in when the transaction ended successfully.

For example: when a person buys something, it needs to be recorded on the account book, even if the boss forgets that, it is well documented.

1.1.2 MySQL's transaction implementation plan

In most scenarios, our application only needs to operate a single database, the transaction in this case is called a local transaction (Local Transaction). The ACID feature of local transactions is that the database provides direct support.

Most people are familiar with MySQL. Take MySQL's InnoDB (InnoDB is a storage engine of MySQL) as an example to introduce the transaction implementation principle of a single database.

InnoDB is the ACID feature of transactions guaranteed by logs and locks, as follows:

(1) Through the database lock mechanism, the isolation of transactions is guaranteed;

(2) Through Redo Log (redo log) to ensure the durability of the transaction;

(3) Through Undo Log (undo log) to ensure the atomicity of the transaction;

(4) Through Undo Log (undo log) to ensure the consistency of the transaction;

How does Undo Log guarantee the atomicity of transactions?

The specific method is: before operating any data, first back up the data to a place (this place where the data is backed up is called Undo Log), and 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.

How does Redo Log guarantee the durability of transactions?

The specific method is: Redo Log records the backup of new data (the opposite of Undo Log). 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, Redo Log has been persisted. The system can restore all data to the state before the crash based on the content of the Redo Log.

1.1.3 What is a distributed transaction?

For distributed systems, it is necessary to ensure data consistency in the distributed system, to ensure that the data is always consistent in the subsystems, and to avoid business problems. Logarithms in a distributed system either succeed together or fail together, and must be an integral 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 on a distributed system consists of different small operations. These small operations are distributed on different service nodes and belong to different applications. Distributed transactions need to ensure that these small operations are either all successful. Either all fail.

For example: In an e-commerce website, when a user places an order for a product, he needs to create an order data in the order table, and at the same time, he needs to modify the remaining inventory quantity of the current product in the inventory table. The two-step operation is one to add and the other to modify. We must ensure that these two operations must succeed or fail at the same time, otherwise business problems will occur.

When implementing any transaction mechanism, the ACID characteristics of transactions should be considered, including: local transactions and distributed transactions. For distributed transactions, even if they are not well satisfied, the degree of support must be considered.

Typical distributed transaction scenario:

1. Cross-database transactions

Cross-database transaction refers to that a certain function of an application needs to operate multiple libraries, and different business data are stored in different libraries. I have seen a relatively complex business, in which 9 libraries are operated at the same time. The following figure demonstrates the situation where a service operates two libraries at the same time:

2. Sub-library and sub-table

Usually a database has a large amount of data or is expected to have a large amount of data in the future, and it will be split horizontally, that is, sub-database and table. As shown in the figure below, the database B is split into 2 databases:

For the case of sub-database and sub-table, general developers will use some database middleware to reduce the complexity of SQL operations. For example, for sql: insert into user(id,name) values ​​(1,"tianshouzhi"),(2,"wangxiaoxiao"). This sql is the syntax for operating a single database. In the case of a single database, the consistency of the transaction can be guaranteed.

However, since the database and table have been split now, the developer hopes to insert record 1 into database 1, and record 2 into database 2. Therefore, the database middleware should rewrite it into two SQLs and insert them into two different sub-databases. At this time, it is necessary to ensure that the two databases either succeed or fail. Therefore, basically all database middlewares are faced with The problem of distributed transactions.

3. Serving (SOA)

Microservice architecture is currently a relatively popular concept. For example, in the case mentioned by the author above, an application operates 9 libraries at the same time. The business logic of such an application must be very complicated, which is a great challenge for developers. It should be split into different independent services to simplify business logic. . After the split, the independent services use the RPC framework to make remote calls to communicate with each other. The following figure demonstrates an architecture where three services call each other:

Service A needs to directly operate the database to complete a certain function, and also needs to call Service B and Service C. Service B operates 2 databases at the same time, and Service C also operates a library. It is necessary to ensure that these cross-service operations on multiple databases either succeed or fail. In fact, this may be the most typical distributed transaction scenario.

Distributed transaction implementation solutions must consider performance issues. If the performance is severely reduced in order to strictly ensure the ACID characteristics, then it is unacceptable for some businesses that require rapid response.

1.2 Theoretical basis of distributed transactions

The four major characteristics of database transaction ACID cannot meet the actual needs of distributed transactions. At this time, some new big cows put forward some new theories.

1.2.1 CAP theorem

The CAP theorem was proposed by Professor Eric Brewer of the University of California, Berkeley. He pointed out that WEB services cannot satisfy the following three attributes at the same time:

• Consistency: The client knows that a series of operations will happen at the same time (effective)

• Availability (Availability): Every operation must end with a predictable response

• Partition tolerance: Even if a single component is unavailable, the operation can still be completed

Specifically, in a distributed system, a Web application can only support the above two attributes at the same time. Therefore, designers must choose between consistency and usability.

In July 2000, Professor Eric Brewer only proposed a conjecture. Two years later, Seth Gilbert and Nancy Lynch of the Massachusetts Institute of Technology proved the CAP theory theoretically, and a distributed system can only meet the requirements of CAP. 2 items. After that, the CAP theory formally became a recognized theorem in the field of distributed computing.

Therefore, the CAP theorem is applicable to all distributed systems so far!

The consistency, availability, and partition fault tolerance of CAP are as follows:

1. Data Consistency

Data consistency refers to "all nodes see the same data at the same time", that is, after the update operation is successful and returned to the client, the data of all nodes at the same time are completely consistent, and there can be no intermediate state.

For example, for e-commerce system users to place an order, operations such as inventory reduction, user fund account deduction, and point increase must be consistent after the user's order operation is completed. There cannot be a situation similar to the inventory has been reduced, but the user's fund account has not been deducted, and the points have not increased. If this happens, it is considered inconsistent.

Data consistency is divided into strong consistency, weak consistency, and final consistency .

• If it is possible to ensure that the data seen by the client is consistent at all times as described above, then it is called strong consistency.

• If an intermediate state is allowed and only requires that after a period of time, the data is finally consistent, it is called final consistency.

• In addition, if partial data inconsistency is allowed, it is called weak consistency.

面试题：什么是数据一致性？

现在知道怎么回答了吧！

2. Availability

Availability means that the service provided by the system must always be available, and every operation request from the user can always return a result within a limited time. "Limited time" means that for a user's operation request, the system must be able to return the corresponding processing result within the specified time. If it exceeds this time range, the system is considered unavailable.

Imagine that if an order is placed in order to ensure the consistency of distributed transactions, it takes 10 minutes to process it, then the user is obviously unbearable. "Return result" is another very important indicator of usability. It requires the system to return a normal response result after processing the user request, regardless of whether the result is a success or a failure.

3. Partition fault tolerance

When a distributed system encounters any network partition failure, it still needs to be able to provide external services that meet the consistency and availability, unless the entire network environment fails.

The CAP theory has been proven: a distributed system cannot satisfy the three characteristics of consistency, availability, and partition fault tolerance at the same time, so we need to abandon one.

But partition fault tolerance is the one that cannot be abandoned . Why? For a distributed system, partition fault tolerance is the most basic requirement. Since it is a distributed system, the components in the distributed system must be deployed to different nodes, otherwise there is no such thing as a distributed system. For distributed systems, network problems are an abnormal situation that will inevitably occur. Therefore, partition fault tolerance has become a problem that a distributed system must face and solve.

Since partition fault tolerance cannot be discarded, the only way to find a balance is consistency and availability. Therefore, system architects often need to spend their energy on how to choose between C (consistency) and A (availability) based on business characteristics.

The distributed transaction scheme of the X/Open XA two-phase commit protocol we mentioned earlier emphasizes consistency; due to low availability, there are not many practical applications. The flexible business based on the BASE theory emphasizes usability, which is currently popular, and most Internet companies may prefer to adopt this scheme.

1.2.2 BASE theory

Dan Pritchett, the architect of eBay, originated from a summary of the practice of large-scale distributed systems, and published an article on ACM to propose the BASE theory. Article link: https://queue.acm.org/detail.cfm?id=1394128

BASE theory is an extension of CAP theory. The core idea is that even if strong consistency (Strong Consistency) cannot be achieved, applications can use appropriate methods to achieve eventual consistency (Eventual Consitency).

BASE is the abbreviation of the three phrases Basically Available, Soft state and Eventually consistent.

1. Basically Available

Refers to a distributed system that is allowed to lose part of its availability in the event of unpredictable failures.

2. Soft State

Refers to allowing the data in the system to have an intermediate state, and that the existence of the intermediate state will not affect the overall availability of the system.

3. Eventual Consistency

It is emphasized that all data update operations can finally reach a consistent state after a period of synchronization. Therefore, the essence of final consistency is that the system needs to ensure that the final data can be consistent, but does not need to ensure the strong consistency of system data in real time.

BASE theory is oriented to large-scale, highly available and scalable distributed systems, which is the opposite of the traditional ACID characteristics of things. It is completely different from ACID's strong consistency model, but gains availability by sacrificing strong consistency, and allows data to be inconsistent for a period of time, but eventually reach a consistent state. But at the same time, in actual distributed scenarios, different business units and components have different requirements for data consistency. Therefore, in the specific distributed system architecture design process, ACID features and BASE theory are often combined together.

1.3 The main scheme of distributed transactions

The realization of distributed transaction mainly has the following 5 schemes:

• Two-phase submission plan XA plan

• TCC plan

• Local message table

• Reliable Message Eventual Consistency Scheme

• Best Effort Notification Scheme

Divided into two major categories:

1. The business plan of CAP theory:

• Two-phase submission plan/XA plan

2. BAS flexible business plan:

• TCC (two-stage type, compensation type)

• Local message table

• Eventual consistency of reliable messages (asynchronous guaranteed type)

• Best effort notification (unreliable news, regular proofreading)

1.3.3 XA scheme of two-phase commit mode (2PC)

2PC (2 phase commit) is an abbreviation for two-phase transaction commit in a distributed transaction. JTA/XA of JavaEE is an implementation of 2PC. 2PC is suitable for multiple data sources to complete operations in accordance with the ACID principle. For example, an operation involves three tables abc in three databases. How to ensure that the data of these three tables are completed at the same time to ensure consistency under the same logic. This is where 2PC is concerned. If there is no 2PC, it is possible that the modification of table a is successful, and the modification of table b and table c is not successful, then inconsistency occurs.

Students who have an understanding of database distributed transactions must know the two-phase commit (2PC) supported by the database, also known as XA Transactions. MySQL has been supported since version 5.5, SQL Server 2005 has been supported, and Oracle 7 has been supported.

Among them, XA is a two-phase submission protocol, which is divided into the following two phases:

The first stage: The transaction coordinator requires each database involved in the transaction to pre-commit (precommit) this operation, and reflect whether it can be submitted.

The second stage: The transaction coordinator requires each database to submit data.

Among them, if any database vetoed the commit, then all databases will be required to roll back their part of the information in this transaction. What are the disadvantages of this? At first glance, we can achieve consistency between database partitions.

XA's failure handling:

In the XA solution, there is a role of a transaction manager responsible for coordinating the transactions of multiple databases (resource managers). The transaction manager first asks each database, are you ready? If each database responds ok, then the transaction is officially submitted and operations are performed on each database; if any one of the databases responds not ok, then the transaction is rolled back.

The XA scheme is more suitable for distributed transactions across multiple libraries in a single application, and because it relies heavily on the database level to handle complex transactions, the efficiency is very low, and it is definitely not suitable for high concurrency scenarios. If you want to play, then it can be done based on spring + JTA, just search for a demo by yourself and see.

The XA scheme is actually rarely used. Generally speaking, if such an operation across multiple libraries occurs in a certain system, it is not compliant. I can introduce to you, now microservices, a large system is divided into hundreds of services and dozens of services. Generally speaking, our regulations and specifications require that each service can only operate on its own corresponding database.

If you want to operate the libraries corresponding to other services, and you are not allowed to directly connect to the libraries of other services, it violates the specifications of the microservice architecture, and you randomly access them randomly. If there are hundreds of services, all of them will be messy. Such a set of services is not If there is no way to manage, there may be situations where data is corrected by others, and your own library is written by others.

If you want to operate the library of other people's services, you must do so by calling the interfaces of other services, and cross-access to other people's databases is absolutely not allowed.

1.3.4 TCC scheme

The full name of the TCC program is: Try, Confirm, Cancel.

l Try phase: Check the resources of each service and lock or reserve the resources.

l Confirm phase: Perform actual operations in each service.

l Cancel phase: If the business method of any service is executed incorrectly, then compensation actions are required here. Specifically, the compensation action is the rollback operation of the successfully executed business logic.

The TCC solution relies heavily on rollback and compensation code, and the final result is that the logic of the rollback code is complex, and the business code is difficult to maintain. Therefore, the TCC scheme has fewer usage scenarios, but there are also usage scenarios.

For example, when dealing with money, payment and transaction-related scenarios, everyone will use the TCC scheme to strictly ensure that distributed transactions are either all successful or all automatically rolled back, strictly ensuring the correctness of funds, and ensuring that there will be no problems with funds .

The more detailed process is as follows:

1.3.5 Local Message Table

The local news list is actually a set of ideas developed by foreign eBay.

This roughly means this:

(1) System A inserts a piece of data into the message table while operating in a local transaction;

(2) Then A system sends this message to MQ;

(3) After the B system receives the message, in a transaction, it inserts a piece of data into its local message table and performs other business operations at the same time. If the message has been processed, then the transaction will be rolled back at this time. This ensures that the message will not be processed repeatedly;

(4) After the B system is executed successfully, it will update the status of its own local message table and the status of the A system message table;

(5) If the B system fails to process, then the message table status will not be updated, then the A system will scan its own message table regularly. If there are unprocessed messages, they will be sent to MQ again, and B will be sent again deal with;

(6) This scheme guarantees final consistency, even if B's ​​transaction fails, A will continue to resend messages until B succeeds.

To be honest, the biggest problem with this solution is that it relies heavily on the message table of the database to manage transactions. What if it is a high-concurrency scenario? How to expand? So it's really rarely used.

A similar process is as follows:

A similar process is as follows:

1.3.6 Eventual consistency scheme of reliable messages

The meaning of this is to simply do not use the local message table, and directly implement transactions based on MQ. For example, Ali's RocketMQ supports message transactions.

The approximate meaning is:

(1) System A sends a prepared message to mq first, if the prepared message fails to be sent, it will cancel the operation directly and don't execute it;

(2) If the message is sent successfully, then execute the local transaction, if it succeeds, tell mq to send a confirmation message, if it fails, tell mq to roll back the message;

(3) If a confirmation message is sent, then the B system will receive the confirmation message at this time, and then execute the local transaction;

(4) mq will automatically poll all prepared messages to call back to your interface at regular intervals, and ask you whether this message has failed in local transaction processing, and all messages that have not sent confirmation, should you continue to retry or roll back? Generally speaking, you can check the database to see whether the local transaction was executed before. If it is rolled back, then roll back here too. This is to avoid the possibility that the local transaction was executed successfully, but the confirmation message failed to be sent.

(5) In this scheme, what if the transaction of system B fails? Try again, automatically keep retrying until it succeeds. If it does not work, either it is a rollback for important financial services. For example, after system B rolls back locally, find a way to notify system A to roll back; or send an alarm. Manually roll back and compensate manually.

This is quite appropriate. At present, most of the domestic Internet companies are playing this way, or you can use RocketMQ support, or you can base yourself on something similar to ActiveMQ? RabbitMQ? Encapsulate a set of similar logic by yourself. In short, the idea is like this.

1.3.7 Best Effort Notification Scheme

The general meaning of this program is:

(1) System A sends a message to MQ after the local transaction is executed;

(2) There will be a best-effort notification service dedicated to consuming MQ. This service will consume MQ and then write it into the database and record it, or put it in a memory queue, and then call the interface of system B;

(3) If the execution of system B succeeds, it is ok; if the execution of system B fails, the best-effort notification service will try to call system B again regularly, repeat N times, and finally give up if it fails.

1.4 How to respond during the interview?

TCC and reliable message eventual consistency schemes are the most commonly used in production.

One requirement is strong agreement, and the other requirement is final agreement.

TCC is used for strong consistency and is mainly used for core modules, such as transactions/orders. The final consistency scheme is generally used for edge modules such as inventory, and is notified by mq to ensure final consistency, and it can also decouple business.

If you are really asked during the interview, you can answer in different scenarios:

(1) For those particularly strict scenarios, TCC is used to ensure strong consistency;

Prepare an example: You find a scenario that strictly requires that the data must not be wrong (such as funds in an e-commerce transaction), and you can answer the use of mature middleware such as Ali distributed transaction seata components.

 阿里开源了分布式事务框架，fescar，seata。seata类似TCC事务，
 经历过阿里生产环境大量考验的框架。
 seata支持Dubbo，Spring Cloud。

(2) For scenarios where data consistency requirements are not particularly strict, you can answer the use of a reliable message final consistency solution. If you implement a distributed transaction framework based on RocketMQ, you can also
develop a reliable message based on ActiveMQ, RabbitMQ, RocketMQ, etc. Service, after receiving the message, try to deliver it to MQ, if the delivery fails, retry the delivery.

Prepare an example: You find a scenario where strict data consistency requirements are not so strict. For example, after an e-commerce order is inserted, you need to call the inventory service to update the inventory. The inventory data is not so strict. For example, a little less is fine. You only need to ensure the final consistency. Sex is enough.

现在大量用RocketMQ，作为MQ中间件，
RocketMQ提供了分布式事务支持，已经把可靠消息服务需要实现的功能逻辑已经做好了。

References:
1 http://www.tianshouzhi.com/api/tutorials/distributed_transaction
2 https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html
3 https://zhuanlan. zhihu.com/p/25933039
4 https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html

---

Back to ◀ Crazy Maker Circle ▶

Crazy Maker Circle-Java high-concurrency research community, open the door to big factories for everyone