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

This article introduces what the solution of distributed transaction is, the content is very detailed, interested friends can use it for reference, I hope it can be helpful to you.

[distributed, I want strong consistency]

In order to ensure the correctness of distributed transactions, there are several popular solutions in the Internet field, but most of them do not form a standard industrial specification like XA transactions. However, these solutions have been recognized by more and more developers in some specific industries or business scenarios.

Avoid distributed transactions

This scheme advocates avoiding distributed transactions as much as possible, not only because of the difficulty of distributed transactions, but also because more senior talents are needed to implement distributed transactions. If an operation is designed to a transaction operation, and these transaction operations can be solved by using stand-alone transactions, it is recommended that stand-alone transactions are preferred.

Of course, whether distributed transactions can be avoided depends on the specific business. In the current popularity of micro-services, it depends more on the division standard of the domain. If two micro-services can be merged into one micro-service, to a certain extent, within the accepted scope of the domain division standard, you can consider using merging to avoid distributed services.

Take a very simple chestnut: a user basic information service and a user asset service (for example, user experience value). In this business scenario, when the user modifies the data, it involves the operation of two different services, namely, the user data modification and the contribution value. At this time, you can consider merging the two services into one service and replacing the distributed transaction with a stand-alone database transaction.

Where distributed transactions can be avoided, it is preferred to avoid distributed transactions

Two-stage submission

The two-phase (2PC) commit scheme is based on the X/OpenDTP standard specification. The biggest disadvantage is that it needs to lock resources in the first phase, which will greatly reduce the performance of the system. Large-scale Internet applications do not recommend this scheme, and enterprise applications that are not sensitive to performance can try to use it.

In asp.net, Microsoft has provided a type of distributed transaction management: TransactionScope, which relies on DTC (Distributed Transaction Coordinator) services for transaction consistency. When the code it wraps is designed to multiple databases in different physical locations, it will be automatically upgraded to distributed transactions, which is very convenient to use.

Using (TransactionScope ts = new TransactionScope ())

{

Database An operation ()

Database B operation ()

Database C operation ()

Ts.Complete ()

}

TCC

TCC is essentially a programming model that advocates compensation operations, so it generally has a retry mechanism that stipulates that each business party involved in a transaction needs to provide three interfaces, as shown in the previous article. Because of the interface retry feature of TCC, the commit and cancel interfaces provided must be idempotent.

2PC mainly operates on the database, while TCC operates on the business level, which is much higher than 2PC in performance. For example, in a scenario where an order is submitted, inventory needs to be deducted for merchandise service, while the order system needs to create an order. The code is similar to the following. Do not worry about naming and parameters:

Using (TransactionScope ts = new TransactionScope ())

{

Database An operation ()

/ / order service

Public interface IOrderService

{

/ / create an invisible order and return the order number

Task CreateOrder ()

/ / submit the order according to the order number to make the order visible

Task SubmitOrder (string orderNo)

/ / cancel the order according to the order number

Task CancleOrder (string orderNo)

}

/ / goods and services

Public interface IProductService

{

/ / lock the inventory according to the product id, and return the locked id

Task LockProductStock (int productId)

/ / submit the transaction and deduct the inventory according to the locked inventory id

Task SubmitLockStock (int lockId)

/ / cancel the transaction and roll back the goods inventory according to the locked inventory id

Task CancleLockStock (int lockId)

} / / order service

Public interface IOrderService

{

/ / create an invisible order and return the order number

Task CreateOrder ()

/ / submit the order according to the order number to make the order visible

Task SubmitOrder (string orderNo)

/ / cancel the order according to the order number

Task CancleOrder (string orderNo)

}

/ / goods and services

Public interface IProductService

{

/ / lock the inventory according to the product id, and return the locked id

Task LockProductStock (int productId)

/ / submit the transaction and deduct the inventory according to the locked inventory id

Task SubmitLockStock (int lockId)

/ / cancel the transaction and roll back the goods inventory according to the locked inventory id

Task CancleLockStock (int lockId)

} Database B operation ()

Database C operation ()

Ts.Complete ()

}

In fact, there are many details in the process of implementing TCC. For example, what if a node fails to commit due to network reasons or downmachine during the commit transaction phase? At this time, we need to introduce a local message mechanism, or business activity manager, locally, to record every operation of each business participating in a distributed transaction. When a node operation of a process fails, whether it automatically initiates a retry, or manual retry can achieve the consistency of the final data.

Message-based transaction

The distributed transaction based on message realizes the final consistency. It is a solution based on BASE theory, which was first proposed and implemented by eBay. It uses message queue to assist in realizing the transaction control flow. The core idea is to distribute the tasks that need distributed processing to each business to execute asynchronously through MQ. If the task fails, it can initiate the correction process of automatic retry or manual retry.

Or take the above order creation and inventory deduction as chestnuts:

1. First, call the create order API of the order service to create the order. If the order is created successfully, a message that the inventory needs to be deducted (which can also be regarded as a successful order creation message) is sent to MQ.

two。 The merchandise service listens to the deduction inventory message queue, and if the deduction inventory message is received, the deduction operation is performed, and if the operation is successful, the MQ is replied to delete the message. If the operation is not successful, prepare to receive the next delivery of the same message.

This process seems perfect, but in fact there are many loopholes.

-creating an order is the first step, which can be regarded as a simple stand-alone operation. There is no problem with this, but the next step of sending a MQ message needs to ensure the transactionality of creating an order, because it will happen that the order is created successfully and the mq message fails. If the transaction of these two steps cannot be guaranteed by technical means, we can also adopt the scheme of introducing local messages, and use the order database to ensure the success of order creation and the consistency of order message tables when creating orders. Then, after sending the mq successfully, modify the status of the order message table to send successfully, and if the mq message fails, enable another thread or process to retry.

-similar to inventory deduction for goods and services, the operation of deducting inventory and replying to mq messages can also use the local message table to solve the consistency problem. When receiving the inventory deduction message, deducting inventory and adding message successful processing records can make use of database transactions to ensure consistency. If the reply message queue ack fails, even if there are duplicate messages, you can filter the duplicate messages according to the local consumption message table.

Another disadvantage of message-based distributed solutions is that if there are many business participants in a transaction, the sending of messages can be very complex and require very careful design. For example, the Chestnut of the above order has now introduced the coupon service. If the order is successfully created, both inventory and coupons need to be deducted. If the coupon deduction fails, you need to roll back the inventory and cancel the order at the same time. This is only three business participants. What if it's four or five? Of course, this may not be common in business.

The message-based distributed transaction solution, due to the introduction of the retry mechanism, also requires the interface to support idempotency when implemented. However, from a development point of view, this scheme has advantages over tcc and 2pc, minimizing the coupling between each system, and the implementation technology of each business side can be very flexible, whether it is using java or c # alive or golang.

Of course, there are a variety of message-based distributed solutions on the market, but generally speaking, they are the ultimate consistent solutions. If the instability of the message channel MQ is introduced, it is also necessary to introduce a query mechanism in each business to ensure the ack mechanism of the message. Take Chestnut: if the inventory of goods and services has been deducted normally, it will not be able to ack normally due to mq problems. At this time, will the order service take the initiative to inquire whether the goods and services have been deducted from inventory? At this time, the whole architecture may not be what it is now.

On the distributed transaction solution is shared here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.