Distributed transaction

In essence, distributed transaction is to ensure the data consistency of different databases.

1. Distributed theory

1.1. Cap law

Cap refers to consistency, availability and partition tolerance.

Cap law says that in a distributed system, only two of C, a and P can be met at most, and it is impossible to meet three at the same time.

In the distributed system, the network cannot be 100% reliable, and zoning is actually an inevitable phenomenon. If we choose Ca and abandon P, in order to ensure consistency, we must reject the request at this time, but a does not allow it. Therefore, it is theoretically impossible for the distributed system to choose CA architecture, but CP or AP architecture.

And, obviously, any scale out strategy depends on data partitioning. Therefore, designers must choose between consistency and availability.

For more information, please refer to https://queue.acm.org/detail.cfm?id=1394128

1.2. Base theory

It is often impossible to achieve complete consistency in distributed systems, so base theory is a further extension of cap law

Base means:

Base theory is the result of a trade-off between consistency and availability in cap

The core idea of base theory is that we cannot achieve strong consistency, but each application can adopt appropriate methods to achieve the final consistency of the system according to its own business characteristics

Base theory obtains availability by sacrificing strong consistency, and allows data to be inconsistent for a period of time, but finally reach a consistent state

2. Distributed transaction solution

2.1. Two phase commit based on XA protocol

Xa protocol consists of two parts: transaction manager and local resource manager. The local resource manager is often implemented by the database. At present, the mainstream relational databases implement the XA interface, and the transaction manager, as the global scheduler, is responsible for the submission and rollback of each local resource.

Advantages: strong consistency of data is ensured as far as possible, which is suitable for key fields with high requirements for strong consistency of data. (in fact, there is no 100% guarantee of strong consistency)

Disadvantages: XA protocol follows strong consistency. In the process of transaction execution, each node occupies database resources. Only when all nodes are ready, the transaction coordinator will notify the submission, and the participants will release the resources after submission. Such a process has very obvious performance problems.

(PS: XA three-phase submission adds the cancommit phase to the two-phase submission and introduces the timeout mechanism. In this way, the three-phase submission has three phases: cancommit, precommit and docommit.)

The two-phase commit scheme takes a long time to lock resources and has a great impact on performance. It is basically not suitable for solving the problem of microservice transactions.

2.2. TCC scheme

TCC is actually a compensation mechanism adopted. Its core idea is to register a corresponding confirmation and compensation (revocation) operation for each operation.

It explicitly divides each branch of the whole business logic into three operations: try, confirm and cancel. The try part completes the business preparation, the confirm part completes the business submission, and the cancel part completes the transaction rollback.

Take the previous example of placing an order. Try of service a is equivalent to querying whether there are available points, confirm is equivalent to deducting points, and cancel is equivalent to increasing points.

Advantages: compared with 2pc, the implementation and process are relatively simple, but the data consistency is also worse than 2pc

Disadvantages: TCC is a compensation method of the application layer, so programmers need to write a lot of compensation code during implementation, and the compensation may fail. In some scenarios, some business processes may not be well defined and processed with TCC.

2.3. Local message table

Its basic design idea is to split the remote distributed transaction into a series of local transactions.

The message producer needs to create an additional message table and record the message sending status. Message tables and business data should be submitted in a transaction, that is, they should be in a database. The message is then sent through MQ to the consumer of the message. If the message fails to be sent, it will be sent again.

The message consumer needs to process the message and complete its own business logic. At this time, if the local transaction processing is successful, it indicates that the processing has been successful. If the processing fails, the execution will be retried. If it is a business failure, you can send a business compensation message to the manufacturer to notify the manufacturer to roll back and other operations.

The producer and consumer scan the local message table regularly and send the unfinished messages or failed messages again. If there is reliable automatic reconciliation and account supplement logic, this scheme is still very practical.

Local message table is a good practice, which can effectively prevent repeated message processing

Taking transfer as an example, the process of this method is as follows:

After having a message table, you can prevent duplication, Retry, ensure that messages are not lost, and do idempotent verification

Advantages: a very classic implementation avoids distributed transactions and achieves final consistency.

Disadvantages: the message table will be coupled to the business system. If there is no encapsulated solution, there will be a lot of chores to deal with.

2.4. MQ (non transactional messages)

If the local database operation and message delivery are not placed in the same transaction, it is difficult to ensure that the message will be sent successfully after the local transaction is successful

If they are placed in the same transaction, consider the following situations:

The above three situations are normal and there will be no problem

However, consider the following:

The local database operation is successful, the message delivery is successful, the application server hangs, and the transaction is rolled back. Therefore, inconsistencies occur, that is, the local database operation is unsuccessful, but the message is sent successfully

If this is a transfer, the other party will make an extra sum of money for no reason

The reason is that sending messages is not a database operation, and it is not limited by acid, that is, database transactions cannot manage sending messages, because they are not the same transaction of the same database. Of course, another reason is that the sent messages cannot be revoked. (PS: the transaction messages of rocketmq to be described later can be revoked)

The above message table is the same transaction of the same database, so this problem will not occur

To sum up, this method has certain risks. It cannot ensure the consistency between local database operation and message delivery, so it is not recommended

2.5. MQ (transaction message)

Currently, only Alibaba cloud rocketmq supports transaction messages. Help users realize the distributed transaction function similar to X / open Xa, and achieve the final consistency of distributed transactions through MQ transaction messages.

@H_ 745_ 301@

explain:

Among them, the transaction message sending corresponds to steps 1, 2, 3 and 4, and the transaction message back checking corresponds to steps 5, 6 and 7

See for more information https://help.aliyun.com/document_detail/43348.html?spm=a2c4g.11186623.6.551.2ddc47b1P5PHi2

2.6. GTS

Global transaction service (GTS) is a distributed transaction middleware with high performance, high reliability and simple access. It is used to solve the problem of data consistency in distributed environment. GTS can ensure the acid characteristics of distributed transactions in distributed systems. It is a product of Alibaba cloud.

See for more information https://help.aliyun.com/document_detail/48726.html?spm=a2c4g.11186623.6.542.53ff681awWVYxc

3. Reference

https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html

https://www.cnblogs.com/jiangyu666/p/8522547.html

https://www.jianshu.com/p/16b1baf015e8