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

This article introduces the knowledge of "complete distributed transaction process in seata project". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

A complete distributed transaction is roughly divided into the following steps:

TM (bussiness) applies to TC (seata-server) to open a global transaction, which is successfully created and generates a globally unique XID.

XID propagates in the context of the microservice invocation link.

RM (account,order,storage) registers branch transactions with TC and brings them under the jurisdiction of XID corresponding global transactions.

TM initiates a global commit or rollback resolution against XID to TC.

TC schedules all branch transactions under the jurisdiction of XID to complete commit or rollback requests.

Related concepts

Transaction Coordinator (TC): transaction coordinator, which maintains the running state of global transactions, coordinates and drives the commit or rollback of global transactions

Transaction Manager (TM): a resolution that controls the boundaries of a global transaction, opens a global transaction, and ultimately initiates a global commit or global rollback

Resource Manager (RM): control branch transactions, responsible for branch registration, status reporting, and receive instructions from the transaction coordinator to drive branch (local) transaction commit and rollback

We simulate the process of placing an order for a normal commodity, which involves the following steps:

(1) call Bussiness service to purchase goods

(2) Bussiness calls storage service to check and reduce inventory

(3) Business calls order service to place an order

(4) order service calls account service to account.

The whole process of simulating a customer placing an order is as follows

(note: the global and branch transactions in the figure are automatically registered by the seata agent when the interface is called.)

1. The customer places an order.

two。 After you request to enter the Business service, call the API for placing an order.

The internal implementation of the order-issuing API is shown below:

This API enables a global transaction. After the global transaction is enabled, a global transaction record is created in the global_table (as shown in the following figure). The id initiator name, transaction belonging to the service group, interface name and so on of the global transaction are recorded in detail. The record will be automatically deleted after the transaction ends.

The operation flow of the order issuing interface is to deduct the inventory first, and then create the order after deducting the success.

3. The deduct () interface of the inventory service is called when the inventory is deducted. The detailed implementation of the interface is shown below.

This API is called within the global transaction, so you can get the XID of the global transaction. Through this ID, you can query the details of the global transaction, such as status, in global_table.

This interface also enables transactions, so a branch transaction is created and a branch transaction record is inserted in the branch_ table table. The branch transaction information is as follows

4. After the inventory deduction is successful, the order service is called to place the order.

5 after placing the order successfully, call the account service to deduct the money.

This is the end of the content of "complete distributed transaction process in the seata project". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.