Distributed Transaction solution-flexible transactions and service models

In a distributed system, local transactions cannot be used to ensure data consistency. A standard distributed transaction is a global transaction (DTP model ). It is controlled based on 2 pcs. However, due to the synchronization blocking problem in two PCs, the global transaction efficiency is very low. Therefore, this global transaction is not suitable for solving the distributed transaction problem of large websites.

Flexible transactions
In the industry, flexible transactions are mainly used to solve distributed transactions. Compared with acid, a rigid transaction in a database transaction, the so-called flexible transactions guarantee "basic availability and eventual consistency ." This is actually based on the base theory to ensure the final consistency of data.

Although flexible transactions do not fully follow acid as rigid transactions do, they also partially follow acid. Let's take a look at the four attributes of acid and the degree of support of flexible transactions:

Atomicity: Strict Compliance

Consistency: The consistency after the transaction is completed is strictly followed; the consistency in the transaction can be relaxed as appropriate

Isolation: Parallel transactions are unaffected. Visibility of intermediate transaction results allows security relaxation.

Persistence: strictly followed

Basics of flexible transactions
We have introduced the definition of flexible transactions. Currently, in the industry, there are three main types of flexible transactions: asynchronous guaranteed, compensatory, and maximum effort notification.

These three types of flexible transactions are basically implemented accordingly, and different types of flexible transactions need to be used in different scenarios. These flexible transaction types depend on some basic modes, or are called Basic interfaces and basic functions.

For example, if you want to use reliable eventually consistent messages for asynchronous and guaranteed flexible transactions, You need to rely on idempotent and queryable operations. For specific implementations, we will introduce them in the following articles. This article briefly introduces these basic modes for implementing flexible transaction dependencies.

Note: The flexible transaction mode described below is not a flexible transaction solution. These are the basis for flexible transactions. That is to say, if you want to perform flexible transactions, your interfaces and functions must meet the following requirements. Different solutions have different requirements. However, if none of them are satisfied, it is impossible to make flexible transactions.

Queryable operations
Query operations are required by almost all distributed solutions.

An example of a common distributed scenario, such as the order processing function

/Payment Order Processing/
Public void completeorder (){
Orderdao. Update (); // The order service updates the order status locally.
Accountservice. Update (); // calls the Fund account service to add money to the fund account
Pointservice. Update (); // call the point service to add points to the point account
Accountingservice. insert (); // call the accounting service to write original accounting creden to the Accounting System
Merchantpolicyservice. Policy (); // call the merchant's notification service to send a notification of the payment result to the merchant
}

In the above example, all operations except the order service to update the order status locally must be performed by calling the RPC interface, in this case, data consistency cannot be guaranteed for local transactions. Distributed transactions need to be introduced. In the distributed transaction execution process, if an error occurs during the execution of a specific step, you need to clearly understand the processing status of several other operations. This requires other services to provide Query Interfaces, make sure that the Operation processing status can be determined through queries.

To ensure that operations can be queried, each call to each service must have a globally unique identifier, which can be the business document number (such as the order number) or the operation serial number allocated by the system (for example, the serial number of the payment record ). In addition, the operation time must be recorded completely.

Idempotent operations
Idempotence is actually a mathematical concept. Idempotent functions, or idempotent methods, are functions that can be executed repeatedly with the same parameters and get the same results, such:

F (f (x) = f (x)

In programming, an idempotent operation is characterized by the impact of any multiple executions being the same as that of a single execution. That is to say, the same method uses the same parameters, and the service results generated by multiple calls are the same as those generated by one call.

This requirement is also easy to understand, because to ensure the final consistency of data, there will be a lot of retry operations for many solutions. If a method does not guarantee idempotence, you cannot try again.

Idempotent operations can be implemented in a variety of ways, such as caching all requests and processing results in the system, and directly returning the previous processing result after detecting repeated operations.

Compensatory operations
When it comes to transactions, in order to ensure atomicity, commit and rollback may occur. In distributed transactions, you need to provide compensatory operations for rollback.

For example, in the above order processing example, after calling the point service to add the point operation to the point account, after the Distributed Transaction coordination, the final decision is to roll back the entire transaction, you need to call the point service to deduct points from the point account.

In addition, the compensation operation also needs to satisfy the idempotence.

TCC operation
TCC is try-confirm-Cancel.

Try: Try to execute the business

Complete all business checks (consistency) Reserve necessary business resources (quasi-isolation)

Confirm: confirm the execution of the business

The actual execution of the business does not perform any business check. Only the business resource confirm operation reserved in the try stage must satisfy the idempotence.

Cancel: cancels the execution of business

Release the business resources reserved in the try phase
The cancel operation must satisfy the idempotence.

This type is similar to a compensatory operation, which provides a mechanism for submission and rollback. Is a typical two-phase operation. The two-phase operations mentioned here do not refer to 2 pcs. They are different from 2 pcs.

Comparison between TCC and 2 PC protocols: TCC is located at the business service layer rather than the resource layer. TCC has no separate preparation (prepare) stage. Can Try operations have both resource operations and preparation capabilities? Try operations allow you to flexibly select the lock granularity of business resources (with specific service granularity). TCC has a high development cost.

Summary
This article briefly introduces the basis for implementing flexible transactions and flexible transactions. Flexible transactions are currently the mainstream distributed transaction solutions. Their basic modes include power-level operations, compensatory operations, queryable operations, and TCC operations. We will introduce the solutions for distributed transactions in subsequent articles.

Distributed Transaction solution-flexible transactions and service models