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

Editor to share with you the TCC transaction segment submission example analysis, I believe that most people do not know much about it, so share this article for your reference, I hope you will learn a lot after reading this article, let's go to know it!

A brief introduction to the case of the scene 1. Description of the scene

Distributed transactions are very common in business systems. The most classic scenario is the transaction business in e-commerce architecture, as shown in the figure:

The client actually triggers multiple service chain requests from the order service by requesting the order service to execute the order operation. The basic steps are as follows:

The client requests to create an order on the order service

Order service invokes account service deduction

The order service invokes the inventory service to perform inventory deduction

The order is transformed into a logistics waybill through logistics services.

This process is the basic business in the e-commerce system, and it is far more complex than that described here in the actual development.

2. Service sequence diagram

In above 1, the business process concept is described. From the system development level, under the architecture mode of micro-service, the usual timing flow is as follows:

In this way, the communication sequence diagram between services is very common in programming. In distributed systems, it is very important to clearly describe the communication flow between services.

The transaction process described in the figure above is that under the most ideal condition, all the services are executed successfully, but the program cannot be 100% guaranteed to be normal all the time. The following situations often occur:

Inter-service communication failed

The service of a single node is down

Service interface execution failed

These are the problems that often occur in actual development, such as successful order creation, successful deduction, but failed inventory deduction and logistics waybill generation, so how to deal with this order? This is the core problem to be solved by distributed transactions.

The distributed transaction mechanism should ensure that a holistic and controllable transaction is formed between different services. unless all the services in the business process are successful, the operation failure of any service will cause the operation on all services to be rolled back and undo the completed action.

2. TCC basic concept 1, Segmentation submission Protocol

XA is a distributed transaction protocol, which is roughly divided into two parts: transaction manager and local resource manager. The local resource manager is basically implemented by the database, and most relational databases implement the XA interface. As the scheduler of the global transaction, the transaction manager is responsible for the commit and rollback of local resources in the whole transaction. The basic principles are as follows:

Phase 1: transaction inquiry

The transaction manager sends an acknowledgement request to all the resource managers participating in the transaction, asking if the transaction commit operation can be performed and waiting for the response of each participant. If the transaction operation is successful, it will feedback to the transaction manager that the transaction can be executed. If the transaction is not executed successfully, the transaction cannot be executed.

Phase 2: transaction commit

According to whether each resource manager is ready to commit successfully in the first stage, XA determines whether to commit the transaction as a whole or to roll back, formally performs the transaction commit operation, and releases the resources occupied by the entire transaction after the commit is completed; the transaction will also fail, causing the process to cancel the rollback

XA transactions have strong consistency and will always hold locks on resources during the whole process of two-phase commit. The disadvantage of poor performance is obvious, especially in the transaction order link, the concurrency is often very high, and XA can not meet this kind of high concurrency scenarios.

2. Brief introduction to the concept of TCC

Try (preprocessing)-Confirm (confirmation)-short for TCC (cancel) mode.

Try stage

Business check (consistency) and resource reservation (isolation), this stage is a preliminary operation, before the transaction is submitted, the check and reservation of business resources are completed; for example, a successful reservation in the ticketing system needs to be paid within 15 minutes.

Confirm stage

Confirm that the business operation is performed and no business check is being performed. Based on the business resources reserved in the Try phase, ideally, as long as the Try is successful, Confirm will also be successful, because the check and locking of the resources have been successful; problems occur in this stage and need to be retried or manually processed; the reservation in the ticketing system is successful and the payment is completed within 15 minutes, and the ticket purchase is successful.

Cancel stage

The Cancel phase is to cancel the branch transaction and release the reserved resources when the business execution error needs to be rolled back to the state; the reservation in the ticketing system is successful but no payment is made within 15 minutes, and the reservation is cancelled.

3. TCC vs. XA

Strong consistency of XA transactions, resulting in locking at the resource layer

TCC pursues ultimate consistency at the business level and will not occupy resources for a long time.

III. Segmented transaction analysis

Now back to the scenario case in module 1, it is good that all the processes are successful in the ideal state, but in fact, there are many emergencies. Analyze the specific business of the above e-commerce based on TCC mode:

1. Resource reservation

In TCC mode, the usual design idea for the status of table fields is: order (in payment. Paid. Cancel the order), account (amount. Frozen amount), inventory (inventory. Freeze inventory), logistics (out of storage. Out of the library, withdrawn), this kind of state management is very common in development.

Therefore, in TCC mode, resource reservation is usually handled as follows:

Assuming that the total amount of the order is 200 and the status is being paid, the resource reservation is as follows:

Tc_account account table: tc_total=1000,tc_ice=200, total amount 1000, freeze 200

Tc_inventory inventory table: tc_total=100,tc_ice=20, total inventory 100 pieces, frozen 20 pieces

Tc_waybill waybill table: tc_state=1, waybill status, out of warehouse

In this way, the relevant resources on the single link have been checked and reserved successfully.

2. Resource submission confirmation

After the resource reservation is successful, the execution resource is submitted for execution:

Tc_account account table: tc_total=800,tc_ice=0, that is, the order is deducted successfully

Tc_inventory inventory table: tc_total=80,tc_ice=0, inventory reduction successful

Tc_waybill waybill table: tc_state=2, waybill status, out of warehouse

In this way, all the relevant resources on the single link have been submitted and processed successfully, which is the most ideal state.

3. Failed rollback

The whole process may fail, or if the user initiates a fallback directly, the data on the entire link will be rolled back:

Tc_account account table: tc_total=1000,tc_ice=0, 200 unfrozen accounts

Tc_inventory inventory table: tc_total=100,tc_ice=0, 20 items unfrozen

Tc_waybill waybill table: tc_state=3, waybill status, withdrawn

In this way, the relevant data on the single link will be backed up and restored based on the order.

4. Compensation mechanism

The whole e-commerce transaction process, whether successful or complete fallback failure, requires that the entire service link and data are absolutely normal under ideal conditions. However, it is difficult to guarantee under the actual distributed architecture, so a lot of operators are reserved in the product design for manual transaction compensation or fallback operations:

In large and complex business systems, direct modification of the database is usually not allowed. In general, the core process will reserve various operation entries to deal with unexpected situations and make up for the integrity of the data. For example, on the transaction link, as long as the deduction is successful, the subsequent data will be made up anyway, and rollback is not allowed. Of course, if the deduction is not successful and the order is valid, the transaction will be concluded.

The above is all the content of the article "sample Analysis of TCC transaction Segment commit". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

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.