Shulou(Shulou.com)06/03 Report--

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

Distributed theory

1.1. CAP's law

CAP refers to consistency (Consistency), availability (Availability), partition fault tolerance (Partition tolerance).

CAP's law says that in a distributed system, only two of C, An and P can be satisfied at most, but not three at the same time.

In a distributed system, the network is not 100% reliable, and partitioning is an inevitable phenomenon. If we choose CA instead of P, then when partitioning occurs, in order to ensure consistency, the request must be rejected, but A does not allow it, so it is theoretically impossible for distributed systems to choose CA architecture, only CP or AP architecture.

And, obviously, any scale-out strategy depends on data partitioning. Therefore, the designer must choose between consistency and usability.

1.2. BASE theory

It is often impossible to achieve complete consistency in distributed systems, so there is BASE theory, which is a further extension of CAP's law.

BASE refers to:

BASE theory is the result of a tradeoff between consistency and availability in CAP.

The core idea of BASE theory is that we cannot achieve strong consistency, but each application can make the system achieve final consistency in an appropriate way according to its own business characteristics.

BASE theory achieves availability at the expense of strong consistency and allows data to be inconsistent for a period of time, but ultimately achieves a consistent state distributed transaction solution.

2.1. Two-phase commit based on XA protocol

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

Advantages: try to ensure the strong consistency of data, which is suitable for key areas with high requirements for strong consistency of data. (in fact, there is no 100% guarantee of strong consistency.)

Disadvantages: the 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 commit, and the participants will release the resources after committing. There are obvious performance problems with this process.

(PS:XA three-phase commit adds CanCommit phase on the basis of two-phase commit and introduces a timeout mechanism. In this way, the three-stage submission has three stages: CanCommit, PreCommit and DoCommit. )

The two-phase commit scheme takes a long time to lock resources, which has a great impact on performance, and is basically not suitable to solve the problem of micro-service transactions.

2.2. TCC scheme

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

It explicitly divides each branch of the entire business logic into three operations: Try, Confirm and Cancel. The Try part completes the preparation of the business, the confirm part completes the business commit, and the cancel part completes the rollback of the transaction.

Taking the previous example of placing an order, the try of Service An is equivalent to querying whether there are available credits, Confirm is equivalent to deducting points, and Cancel is equivalent to increasing credits.

Pros: 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 in the application layer, so programmers are required to write a lot of compensation code when implementing, and compensation may fail. In some scenarios, some business processes may not be easy to define and handle with TCC.

2.3. Local message table

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

The message producer needs to build an additional message table and record the message delivery status. Message tables and business data are committed in a transaction, that is, they are in a database. The message is then sent to the consumer of the message via MQ. If the message fails to send, it will retry to send.

The message consumer needs to process the message and complete its own business logic. At this point, if the local transaction is successful, it indicates that the processing has been successful, and if the processing fails, the execution will be retried. If it is a failure of the business, 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 message or failed message again. If there is a reliable automatic reconciliation logic, this scheme is still very practical.

The local message table is a good practice, which can effectively prevent duplicate message processing

Take money transfer as an example, the process in this way is as follows:

With the message table, you can prevent repetition, retry, ensure that the message is not lost, and do idempotent verification.

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

Disadvantages: message tables are coupled to the business system, and if there is no encapsulated solution, there will be a lot of chores to deal with.

2.4. MQ (non-transactional message)

If you do not put the local database operation and message delivery in the same transaction, it is difficult to guarantee that the message will be sent successfully after the local transaction is successful.

If you put them in the same transaction, consider the following situations:

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

However, consider the following situation:

The local database operation is successful, the message delivery is successful, the application server is down, and the transaction is rolled back, so the inconsistency occurs, that is, the local database operation is not successful, but the message is sent successfully.

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

The reason is that sending messages is not a database operation, and it is not restricted by ACID, that is, database transactions cannot manage sending messages, because they are not the same transaction in the same database, and of course, another reason is that the messages sent cannot be undone. (PS: transaction messages for RocketMQ that will be introduced later can be undone)

In the above message table, it is the same transaction in the same database, so this problem will not occur.

To sum up, this approach has certain risks, it cannot guarantee the consistency of local database operations and message delivery, and it is not recommended to use

2.5. MQ (transaction message)

Currently, only Aliyun's RocketMQ supports transaction messages. Help users to achieve distributed transaction functions similar to X/Open XA, and the final consistency of distributed transactions can be achieved through MQ transaction messages.

Description:

Wherein, the transaction message is sent corresponding to steps 1, 2, 3 and 4, and the transaction message backcheck corresponds to steps 5, 6 and 7

2.6. GTS

Global transaction Service (Global Transaction Service, referred to as GTS) is a distributed transaction middleware with high performance, high reliability and easy access, which is used to solve the problem of data consistency in distributed environment. GTS can guarantee the ACID characteristics of distributed transactions in distributed systems. It is a product of Aliyun.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.