In my blog, I have written many articles about distribution and transactions. Before I read this article, I hope you can understand the basics of distribution and transactions. Here are some of my previous articles, which are in order and can be read in order:

Introduction to distributed systems

An inquiry into distributed consistency

CAP theory of distributed systems

BASE theory of distributed systems

Transactions in Java — JDBC transactions and JTA transactions

Transactions in Java – global and local transactions

About distributed transactions, two-phase commit protocol, three-stage commit protocol

In-depth understanding of 2PC and 3PC of distributed systems

Here is a brief summary of the previous several articles, as background knowledge for this article. In distributed system, there is CAP theory, and the usability, data consistency and fault tolerance of partition cannot be satisfied at the same time. Therefore, a final consistency theory BASE theory based on CAP is more reliable to solve distributed problems at present.

In distributed systems, data consistency cannot be guaranteed using local transactions. A standard distributed transaction is a global transaction (DTP model). He controls it based on 2PC. However, because 2PC itself has the problem of synchronization blocking, which leads to the global transaction efficiency is very low. Therefore, this kind of global transaction is not suitable to solve the distributed transaction problem of large websites.

Flexible transaction

In the industry, the main solution for distributed transactions is to use flexible transactions. Compared with ACID, a rigid transaction in a database transaction, a flexible transaction guarantees something that is “basically available and ultimately consistent.” This is actually based on the BASE theory to ensure the ultimate consistency of the data.

Although flexible transactions are not as ACID compliant as rigid transactions, they are partially ACID compliant. Let’s take a look at four properties of ACID:

Atomicity: Strictly follow

Consistency: Consistency after transaction completion is strictly followed; Consistency in transactions can be relaxed

Isolation: non-impact between parallel transactions; Mid-transaction result visibility allows for security relaxation

Persistence: Strict adherence

The foundation of flexible transactions

The definition of flexible transactions has been introduced before. At present, there are three main types of flexible transactions in the industry: asynchronous assurance, compensation and maximum effort notification.

These three types of flexible transaction basically have corresponding implementation, different scenarios need to use different types of flexible transaction. These flexible transaction types actually rely on some basic patterns, or basic interfaces, basic functions.

For example, asynchronous assured flexible transactions using the ultimate consistency of reliable messages rely on idempotent and queriable operations. As for the implementation, which we will cover in a later article, this article briefly introduces the basic patterns for implementing flexible transaction dependencies.

Note that the pattern of flexible transactions described below is not a solution for flexible transactions. These are the basics of doing flexible transactions. In other words, if you want to do flexible transactions, your interface and functionality should meet the following requirements. It doesn’t have to be all, because different solutions have different requirements. But it is impossible to do flexible transactions without both.

Queryable operation

Queryable operations are required by almost all distributed solutions.

Take an example of a common distributed scenario, such as order processing:

/** / public void completeOrder() {orderDao.update(); Accountservice.update (); Pointservice.update (); Accountingservice.insert (); / / call accounting services to write original vouchers merchantNotifyService accounting accounting system. The notify (); // Call merchant notification service to send notification of payment result to merchant}Copy the code

In the above example of payment order processing, all operations except that the order service updates the order status locally need to be performed by calling the RPC interface, in which case a simple local transaction cannot guarantee data consistency. You need to introduce distributed transactions. In the process of distributed transaction execution, if one step fails, it is necessary to know the processing status of other operations clearly, which requires other services to provide query interfaces to ensure that the processing status of operations can be determined through query.

To ensure that operations are queriable, each invocation of each service needs to have a globally unique identifier, either a business receipt number (such as an order number) or a system-assigned operation sequence number (such as a payment record sequence number). In addition, the timing of the operation should also be fully recorded.

Idempotent operation

Idempotence is actually a mathematical concept. An idempotent function, or idempotent method, is a function that can be executed repeatedly with the same parameters and achieve the same results, such as:

f(f(x)) = f(x)
Copy the code

The characteristic of an idempotent operation in programming is that any number of executions have the same effect as a single execution. That is, calling the same method multiple times with the same parameters yields the same business result as calling it once.

This requirement is somewhat understandable, because many solutions require a lot of retry operations to ensure final consistency of data. If a method is not idempotent, it will not be retried.

There are many ways to implement idempotent operations, such as caching all requests and processing results in the system, and directly returning the last processing results after detecting repeated operations.

Compensable operation

When it comes to transactions, commit and rollback are possible to ensure atomicity. In distributed transactions, to rollback, compensable operations need to be provided.

For example, in the above example of order processing, after the integral service is called to add points to the integral account, the whole transaction is finally rolled back after the distributed transaction coordination, so it is necessary to provide an operation to deduct points from the integral account by calling the integral service.

Moreover, the compensation operation also needs to satisfy idempotence.

TCC operation

TCC is Try to Confirm to Cancel.

Try: Attempts to execute services

Complete all service checks (Consistency) Reserve required service resources (quasi-isolation)

Confirm: Indicates that the service is executed

Perform services without any service check and only use Confirm resources reserved during the Try phase to ensure idempotency

Cancel: Cancels the service

The Cancel operation to release service resources reserved for the Try phase must be idempotent

This type is similar to compensable operations in that it provides a commit and rollback mechanism. Is a typical two-phase type operation. The two-phase type operation here does not refer to 2PC, which is different from 2PC.

Comparison between TCC and 2PC Protocols TCC is located at the service layer rather than the resource layer. TCC does not have an independent Prepare phase. The Try operation has both resource operation and preparation capabilities

conclusion

This paper mainly introduces the basics of flexible transactions and their implementation. Flexible transaction is the mainstream distributed transaction solution at present. Its basic modes include idempotent operation, compensable operation, queriable operation and TCC operation. Stay tuned for future articles on distributed transaction solutions.

The resources

Distributed transaction processing in large-scale SOA systems