Order implementation method, system and device based on distributed transaction, equipment and storage medium

Abstract

The embodiment of the invention provides an order implementation method, system and device based on distributed transactions, equipment and a storage medium, and relates to the technical field of computer application. Receiving an order request sent by user equipment, and sending a TRY request to each micro-service in the plurality of micro-services in parallel; after it is determined that the data reservation operation of each micro-service is successful, CONFIRM requests are sent to each micro-service in parallel; and after determining that the data reservation operation of any micro-service fails or receiving a cancel request for any micro-service, respectively sending a CANCEL request to each micro-service, so that each micro-service cancels the data reservation operation of the micro-service after receiving the CANCEL request sent by the order service. According to the invention, the method achieves the control of a plurality of micro-services, improves the business processing efficiency while guaranteeing the consistency and atomicity of distributed transactions, and further improves the business throughput.

Description

Technical Field

[0001] The present invention relates to the field of computer application technology, and in particular to a method, system, device, equipment and storage medium for implementing an order based on distributed transactions. Background Art

[0002] In large-scale e-commerce platforms and complex marketing campaigns, order fulfillment refers to the process of receiving, processing, and delivering online orders. This process often requires the coordination of multiple microservices, such as inventory, logistics, payment, and discount verification. These microservices are responsible for different tasks, and they work together to ensure the smooth completion of orders. However, controlling multiple microservices is a difficult problem in this business scenario. Summary of the Invention

[0003] The purpose of the embodiments of the present invention is to provide a distributed transaction-based order fulfillment method, system, apparatus, device, and storage medium to control multiple microservices. The specific technical solution is as follows:

[0004] In a first aspect, a distributed transaction-based order fulfillment method is provided, which is applied to order services and includes:

[0005] Receive an order request sent by a user device, and send a TRY request to each of the multiple microservices in parallel, so that each microservice, after receiving the TRY request sent by the order service, performs a data reservation operation of the microservice, wherein the data reservation operation indicates checking whether target data required by the order request exists and marking the target data as locked if the target data exists, wherein the multiple microservices jointly complete the order target, and the order target indicates the result to be achieved of the order;

[0006] After determining that the data reservation operations of each microservice are successful, a CONFIRM request is sent to each microservice in parallel, so that each microservice, upon receiving the CONFIRM request sent by the order service, executes the real service operation of the microservice, where the real service operation indicates using the target data marked as locked by the data reservation operation;

[0007] After determining that the data reservation operation of any microservice has failed or receiving a cancellation request for any microservice, a CANCEL request is sent to each microservice respectively, so that each microservice cancels the data reservation operation of the microservice after receiving the CANCEL request sent by the order service.

[0008] Optionally, after sending a TRY request to each of the multiple microservices in parallel, the method further includes:

[0009] Determining whether each microservice has successfully executed the data reservation operation based on the data reservation operation status of each microservice recorded by the transaction coordinator, wherein the transaction coordinator is used to receive the transaction ID sent by the order service and record the data reservation operation status of each microservice, wherein the data reservation operation status indicates the status of executing the data reservation operation of the microservice, wherein the transaction ID is an identifier of a transaction corresponding to the order request generated by the order service after receiving the order request, and the processing operations for one order request are combined into one transaction;

[0010] After determining that the data reservation operations of each microservice are successful, a first notification message is sent to the transaction coordinator; or, after determining that the data reservation operation of any microservice has failed or receiving a cancellation request for any microservice, a second notification message is sent to the transaction coordinator, so that the transaction coordinator performs the following operations: after receiving the first notification message, the transaction status of the transaction ID is updated to a confirmed status, or after receiving the second notification message, the transaction status of the transaction ID is updated to a rollback status. The order service generates a transaction for each order request received, and the transaction status indicates the status of processing the order request.

[0011] Optionally, after sending a TRY request to each of the multiple microservices in parallel, the method further includes:

[0012] After determining that the data reservation operation of any microservice has failed, determine whether the data reservation operation of the current microservice meets the compensation policy requirements, and if the compensation policy requirements are met, send a third notification message to the transaction coordinator, so that after receiving the third notification message, the transaction coordinator marks the data reservation operation status of the target microservice as successful operation. The compensation policy requirements are used to indicate the conditions for meeting the business objectives in the business scenario.

[0013] Optionally, receiving an order request sent by a user device includes:

[0014] Receive TRY requests, CONFIRM requests, and CANCEL requests sent by the order service through the message middleware;

[0015] The sending of a TRY request to each of the multiple microservices in parallel includes:

[0016] After receiving the first get request sent by any microservice, the message middleware sends the TRY request to the microservice;

[0017] The sending of CONFIRM requests to each microservice in parallel includes:

[0018] After receiving the second acquisition request sent by any microservice, the message middleware sends the CONFIRM request to the microservice;

[0019] The sending of a CANCEL request to each microservice includes:

[0020] After receiving the second acquisition request sent by any microservice, the message middleware sends the CANCEL request to the microservice.

[0021] In a second aspect, an order fulfillment system based on distributed transactions is provided, comprising:

[0022] An order service and multiple microservices, wherein the multiple microservices work together to complete an order goal, where the order goal represents the result to be achieved for the order;

[0023] The order service is used to receive an order request sent by a user device and send a TRY request to each of the multiple microservices in parallel;

[0024] Each microservice among the multiple microservices is configured to, after receiving a TRY request sent by the order service, perform a data reservation operation of the microservice, wherein the data reservation operation indicates checking whether target data required by the order request exists and marking the target data as locked if the target data exists;

[0025] The order service is further configured to send a CONFIRM request to each microservice in parallel after determining that the data reservation operation of each microservice is successful;

[0026] Each microservice in the plurality of microservices is further configured to, upon receiving a CONFIRM request sent by the order service, execute a real service operation of the microservice, wherein the real service operation indicates using target data marked as locked by the data reservation operation;

[0027] The order service is further configured to send a CANCEL request to each microservice after determining that a data reservation operation of any microservice has failed or receiving a cancellation request for any microservice;

[0028] Each microservice in the multiple microservices is further configured to cancel the data reservation operation of the microservice after receiving a CANCEL request sent by the order service.

[0029] Optionally, the system further includes: a transaction coordinator;

[0030] The transaction coordinator is configured to receive the transaction ID sent by the order service and record the data reservation operation status of each microservice, where the data reservation operation status indicates the status of executing the data reservation operation of the microservice. The transaction ID is an identifier of a transaction corresponding to the order request generated by the order service after receiving the order request. The processing operations for one order request are combined into one transaction.

[0031] The order service is specifically used to determine whether each microservice has successfully performed the data reservation operation based on the recorded data reservation operation status of each microservice;

[0032] The order service is further configured to send a first notification message to the transaction coordinator after determining that the data reservation operation of each microservice is successful; or send a second notification message to the transaction coordinator after determining that the data reservation operation of any microservice fails or receiving a cancellation request for any microservice;

[0033] The transaction coordinator is further configured to update the transaction status of the transaction ID to a confirmed status after receiving the first notification message, or to update the transaction status of the transaction ID to a rollback status after receiving the second notification message. The order service generates a corresponding transaction each time it receives an order request, and the transaction status indicates the status of processing the order request.

[0034] Optionally, the order service is further configured to, after determining that the data reservation operation of any microservice has failed, determine whether the data reservation operation of the current microservice meets a compensation policy requirement, and send a third notification message to the transaction coordinator if the compensation policy requirement is met, where the compensation policy requirement is used to indicate a condition for meeting a business objective in a business scenario;

[0035] The transaction coordinator is further configured to mark the data reservation operation status of the target microservice as operation successful after receiving the third notification message.

[0036] Optionally, the system further includes: message middleware;

[0037] The message middleware is used to receive the TRY request, CONFIRM request and CANCEL request sent by the order service; and after receiving the first acquisition request sent by any microservice, send the TRY request to the microservice; or after receiving the second acquisition request sent by any microservice, send the CONFIRM request to the microservice; or after receiving the second acquisition request sent by any microservice, send the CANCEL request to the microservice.

[0038] In a third aspect, an order fulfillment device based on distributed transactions is provided, which is applied to order services and includes:

[0039] A receiving module, configured to receive an order request sent by a user device;

[0040] The sending module is used to send TRY requests to each microservice in multiple microservices in parallel, so that each microservice executes a data reservation operation of the microservice after receiving the TRY request sent by the order service. The data reservation operation indicates checking whether the target data required by the order request exists and marking the target data as locked when the target data exists. The multiple microservices jointly complete the order target, and the order target indicates the result to be achieved for the order. After determining that the data reservation operation of each microservice is successful, the sending module sends CONFIRM requests to each microservice in parallel, so that each microservice executes a real service operation of the microservice after receiving the CONFIRM request sent by the order service. The real service operation indicates using the target data marked as locked by the data reservation operation. After determining that the data reservation operation of any microservice fails or receiving a cancel request for any microservice, the sending module sends CANCEL requests to each microservice respectively, so that each microservice cancels the data reservation operation of the microservice after receiving the CANCEL request sent by the order service.

[0041] In a fourth aspect, an electronic device is provided, comprising a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus;

[0042] Memory for storing computer programs;

[0043] The processor is configured to implement any of the method steps described in the first aspect when executing a program stored in the memory.

[0044] In another aspect of the present invention, a computer-readable storage medium is provided, wherein a computer program is stored in the computer-readable storage medium. When the computer program is executed by a processor, any of the above-mentioned distributed task implementation methods is implemented.

[0045] In yet another aspect of the present invention, a computer program product comprising instructions is provided, which, when executed on a computer, enables the computer to execute any of the above-mentioned distributed task implementation methods.

[0046] In this embodiment of the present invention, an order service receives an order request from a user device and first sends a TRY request to each microservice. Upon determining that any microservice's data reservation operation has failed or receiving a cancel request for any microservice, the order service sends a CANCEL request to each microservice. Upon receiving the CANCEL request from the order service, each microservice cancels the microservice's data reservation operation. Upon determining that all microservices' data reservation operations have succeeded, the order service sends a CONFIRM request to each microservice. Upon receiving the CONFIRM request from the order service, each microservice executes the actual service operation of the microservice. In this manner, through the interaction between the order service and multiple microservices, control over multiple microservices is achieved to ensure the smooth completion of orders.

[0047] At the same time, in an embodiment of the present invention, the order processing process is divided into three stages through TRY requests, CONFIRM requests, and CANCEL requests. The TRY request enables data reservation in the TRY stage. The CONFIRM request enables the execution of actual service operations for each microservice, provided that all data reservation operations for each microservice are successful. If a microservice fails in the TRY stage, the CANCEL request enables the release of previously reserved resources for each microservice in the CANCEL stage. This ensures that all microservices in the order processing process are either successful or canceled, thus guaranteeing the atomicity of the order processing process and the consistency of data across all microservices. Furthermore, the order service sends TRY requests, CANCEL requests, and CONFIRM requests to multiple microservices, respectively, enabling asynchronous calls to microservices and parallel processing of multiple microservices, improving order processing efficiency and further increasing system service throughput. In short, by controlling multiple microservices, service processing efficiency is improved while ensuring the consistency and atomicity of distributed transactions, further increasing service throughput. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for describing the embodiments or the prior art.

[0049] Figure 1 A flowchart of an order fulfillment method based on distributed transactions provided in an embodiment of the present invention;

[0050] Figure 2 A schematic diagram of a flow chart of an order fulfillment method based on distributed transactions according to an embodiment of the present invention;

[0051] Figure 3 Another flow chart of the order fulfillment method based on distributed transactions according to an embodiment of the present invention;

[0052] Figure 4A A schematic diagram of an application scenario of the distributed transaction-based order fulfillment method provided in an embodiment of the present invention;

[0053] Figure 4B A schematic diagram of another application scenario of the distributed transaction-based order fulfillment method provided in an embodiment of the present invention;

[0054] Figure 5 A schematic diagram of the structure of an order fulfillment system based on distributed transactions provided in an embodiment of the present invention;

[0055] Figure 6 A schematic diagram of the structure of an order fulfillment device based on distributed transactions provided by an embodiment of the present invention;

[0056] Figure 7 A schematic structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0057] The technical solutions in the embodiments of the present invention will be described below with reference to the accompanying drawings in the embodiments of the present invention.

[0058] The embodiment of the present invention provides an order fulfillment method based on distributed transactions, which can be applied to order services, and specifically to electronic devices, in which the order service is executed, wherein the electronic device can be a server, etc.

[0059] Reference Figure 1 , an embodiment of the present invention provides an order fulfillment method based on distributed transactions, comprising:

[0060] S11, receiving an order request sent by a user device, and sending a TRY (data reservation) request to each of the multiple microservices in parallel, so that each microservice performs a data reservation operation of the microservice after receiving the TRY request sent by the order service;

[0061] The data reservation operation checks whether the target data required by the order request exists and marks the target data as locked if it exists. Multiple microservices work together to complete the order target, which represents the result of the order to be realized.

[0062] S12, after determining that the data reservation operations of each microservice are successful, send a CONFIRM request to each microservice in parallel, so that each microservice performs the actual service operation of the microservice after receiving the CONFIRM request sent by the order service;

[0063] The real service operation represents the target data marked as locked using the data reservation operation;

[0064] S13, after determining that the data reservation operation of any microservice fails or receiving a cancellation request for any microservice, send a CANCEL request to each microservice respectively, so that each microservice cancels the data reservation operation of the microservice after receiving the CANCEL request sent by the order service.

[0065] In this embodiment of the present invention, an order service receives an order request from a user device and first sends a TRY request to each microservice. Upon determining that any microservice's data reservation operation has failed or receiving a cancel request for any microservice, the order service sends a CANCEL request to each microservice. Upon receiving the CANCEL request from the order service, each microservice cancels the microservice's data reservation operation. Upon determining that all microservices' data reservation operations have succeeded, the order service sends a CONFIRM request to each microservice. Upon receiving the CONFIRM request from the order service, each microservice executes the actual service operation of the microservice. In this manner, through the interaction between the order service and multiple microservices, control over multiple microservices is achieved to ensure the smooth completion of orders.

[0066] Current e-commerce platforms generally adopt a distributed microservices architecture, where microservices communicate via application programming interfaces (APIs). This architecture ensures scalability and high availability in complex marketing scenarios. However, ensuring the consistency and atomicity of distributed transactions remains a key issue with current implementations.

[0067] Distributed transactions are complex, and each microservice runs independently. Maintaining consistency is a difficult problem. Asynchronous operations may lead to data inconsistency. If some operations fail, transaction consistency is difficult to guarantee.

[0068] In an embodiment of the present invention, the order processing process is divided into three stages through TRY request, CONFIRM request and CANCEL request. The TRY request is used to reserve data in the TRY stage. The CONFIRM request is used to execute the real service operation of each microservice on the premise that the data reservation operation of each microservice is successful. If a microservice fails in the TRY stage, the CANCEL request is used to release the resources previously reserved by each microservice in the CANCEL stage, thereby ensuring that all microservices in the order processing process are either successful or canceled, that is, the atomicity of the order processing process is guaranteed, and the consistency of the data of each microservice is guaranteed.

[0069] Furthermore, the order service receives requests from user devices, interacts with them, and coordinates calls between microservices, eliminating direct interaction between the user device and the microservices, making the overall coordination process more convenient. Furthermore, the asynchronous call mechanism resolves data inconsistencies and prevents performance issues from impacting business expansion, ensuring distributed transactions for order fulfillment in complex marketing ordering scenarios.

[0070] Moreover, the order service sends TRY requests, CANCEL requests, and CONFIRM requests to multiple microservices in parallel, realizing asynchronous calls to microservices and parallel processing of multiple microservices, improving the efficiency of order processing, and further improving the system business throughput. In general, by controlling multiple microservices, it is possible to improve the business processing efficiency while ensuring the consistency and atomicity of distributed transactions, and further improve the business throughput. It can also be understood that the embodiment of the present invention realizes asynchronous orchestration and parallel processing, wherein asynchronous orchestration, that is, through asynchronous message queues and event-driven mechanisms, asynchronousizes the operations of each stage of TCC, reducing the overall locking time and waiting time of the system. Parallel processing, that is, for multiple independent service calls (such as points services and gold coin services), parallel processing can be used to improve the throughput of transaction processing.

[0071] This embodiment of the present invention provides a distributed transaction solution based on the TCC (Try-Confirm-Cancel) model, ensuring the atomicity and consistency of order fulfillment in complex marketing campaigns. This solution interacts with users through the order service, which in turn interacts with multiple microservices. Specifically, the order service applies TCC logic to schedule microservices. This allows for coordination among multiple microservices to ensure smooth order completion. Furthermore, the order service triggers multiple microservices in parallel during the TCC logic scheduling process.

[0072] On the basis of TCC, multiple microservices are scheduled based on TCC logic through the order service. Alternatively, it can be understood that in the order service + microservice scenario, TCC logic is applied, and the order service interacts with the user, and the order service applies TCC logic to schedule microservices; and multiple microservices are triggered in parallel.

[0073] A TRY request, also known as a reservation request, triggers a data reservation operation. This operation checks whether the target data required by the order request exists and, if so, marks the target data as locked. A data reservation operation, also known as a TRY operation, does not actually perform any operations; it simply checks for the existence of the target data required by the order request and marks the target data as locked.

[0074] The target data corresponding to the data reservation operations executed by different microservices is determined according to the specific functions of the microservices. Correspondingly, the lock status marked on the target data by the data reservation operations executed by different microservices can also be determined according to the type of the target data corresponding to the data reservation operations executed by different microservices.

[0075] For example, the inventory service reserves the corresponding inventory and marks the inventory as reserved in the database; the payment service pre-locks user funds and marks the funds as frozen; the points service pre-deducts user points and marks the points as reserved; the gold coin service pre-deducts user gold coins and marks the gold coins as reserved.

[0076] A CONFIRM request, also known as a confirmation request, triggers a real service operation. A real service operation represents the target data marked as locked using a data reservation operation. A microservice's real service operation is the operation that implements the microservice's functionality.

[0077] For example, the inventory service actually deducts the reserved inventory, the payment service actually deducts the user's funds, the voucher service actually writes off the user's vouchers, the points service actually deducts the user's points, and the gold coin service actually deducts the user's gold coins.

[0078] A CANCEL request can also be understood as a cancel request, which is used to trigger the revocation of the data reservation operation. In other words, it releases the resources locked by the data reservation operation, which can also be understood as a rollback operation.

[0079] After receiving the CANCEL request sent by the order service, the microservice cancels the data reservation operation of the microservice, which can also be understood as rolling back the previous data reservation operation. Specifically, the target data marked as locked during the data reservation operation phase can be unlocked.

[0080] For example, the inventory service restores the inventory reserved during the data reservation operation phase, the payment service unlocks the user funds pre-locked during the data reservation operation phase, the voucher service unfreezes the vouchers pre-frozen during the data reservation operation phase, the points service restores the points withheld during the data reservation operation phase, and the gold coin service restores the gold coins withheld during the data reservation operation phase.

[0081] An order goal represents the desired outcome of an order. Simply put, it represents the desired outcome of the order. For example, an order request is a purchase request sent by a user device. The order goal could be to generate a transaction order and send it to the merchant device. Upon receiving the transaction order, the merchant device then ships the purchased goods through logistics.

[0082] In the embodiment of the present invention, order fulfillment can be understood as the entire process of receiving an order request and completing the order goal. In the process of order fulfillment in the embodiment of the present invention, multiple microservices and order services are responsible for different tasks to collaborate to complete the order, that is, order fulfillment is completed based on distributed transactions.

[0083] The user device may specifically be an electronic device used by the user, such as a computer, a mobile phone, etc.

[0084] The target data required for an order request can be obtained by parsing the order request. For example, if the order request is a purchase request and carries the product ID and quantity of the product to be purchased by the user, the product ID and quantity can be understood as the target data required for the order request.

[0085] In an optional embodiment, the plurality of microservices include an inventory service, a payment service, a voucher service, a points service, and a gold coin service.

[0086] After receiving an order request, such as a purchase request, from a user device, the Order Service sends a TRY request to the Inventory Service, Payment Service, Voucher Service, Points Service, and Coin Service in parallel.

[0087] In this embodiment, each microservice is configured to execute a data reservation operation for the microservice upon receiving a TRY request from the order service. Specifically, the target data for the data reservation operation executed by the inventory service is inventory, the target data for the data reservation operation executed by the payment service is funds, the target data for the data reservation operation executed by the voucher service is vouchers, the target data for the data reservation operation executed by the points service is points, and the target data for the data reservation operation executed by the coin service is coins.

[0088] Specifically, after receiving the TRY request sent by the order service, each microservice may perform the following data reservation operations:

[0089] The inventory service receives a request from TRY to perform a data reservation operation, specifically reserving the corresponding inventory; the payment service receives a request from TRY to perform a data reservation operation, specifically pre-locking user funds; the voucher service receives a request from TRY to perform a data reservation operation, specifically freezing user vouchers; the points service receives a request from TRY to perform a data reservation operation, specifically pre-deducting user points; the gold coin service receives a request from TRY to perform a data reservation operation, specifically pre-deducting user gold coins.

[0090] After confirming that the data reservation operations of the inventory service, payment service, voucher service, points service, and gold coin service are successful, the order service sends a CONFIRM request to each microservice in parallel.

[0091] After receiving the CONFIRM request from the Order Service, the Inventory Service, Payment Service, Voucher Service, Points Service, and Coin Service execute the actual service operations of the microservices, which may include:

[0092] The inventory service receives a CONFIRM request and performs a data reservation operation, specifically the actual deduction of the reserved inventory; the payment service receives a CONFIRM request and performs a data reservation operation, specifically the actual deduction of user funds; the voucher service receives a CONFIRM request and performs a data reservation operation, specifically the actual cancellation of user vouchers; the points service receives a CONFIRM request and performs a data reservation operation, specifically the actual deduction of user points; the gold coin service receives a CONFIRM request and performs a data reservation operation, specifically the actual deduction of user gold coins.

[0093] After the Order Service determines that the data reservation operation of any microservice among the Inventory Service, Payment Service, Voucher Service, Points Service, and Gold Coin Service has failed, or after receiving a cancellation request for any microservice among the Inventory Service, Payment Service, Voucher Service, Points Service, and Gold Coin Service, it sends a CANCEL request to the Inventory Service, Payment Service, Voucher Service, Points Service, and Gold Coin Service respectively.

[0094] After receiving the CANCEL request from the Order Service, the Inventory Service, Payment Service, Voucher Service, Points Service, and Gold Coin Service cancel the data reservation operation of the microservice, including:

[0095] The inventory service receives a CANCEL request to execute a data reservation operation, specifically restoring the inventory reserved during the data reservation operation phase. The payment service receives a CANCEL request to execute a data reservation operation, specifically unlocking the user funds pre-locked during the data reservation operation phase. The voucher service receives a CANCEL request to execute a data reservation operation, specifically unfreezing the vouchers pre-frozen during the data reservation operation phase. The points service receives a CANCEL request to execute a data reservation operation, specifically restoring the points withheld during the data reservation operation phase. The gold coin service receives a CANCEL request to execute a data reservation operation, specifically restoring the gold coins withheld during the data reservation operation phase.

[0096] In one example, each service can be further refined. For example, the order service can be broken down into microservices such as order creation, order modification, and order cancellation. Similarly, the inventory service can be broken down into inventory check, inventory reservation, and inventory update. This allows for fine-grained and modular services. Fine-grained services can be configured modularly, allowing for more flexible combination and reuse. In some scenarios, the processing methods of each sub-module can be dynamically adjusted through configuration files or policies.

[0097] In an optional embodiment, after sending a TRY request to each of the multiple microservices in parallel in S11, the following steps may also be included:

[0098] Based on the data reservation operation status of each microservice recorded by the transaction coordinator, determine whether each microservice has successfully executed the data reservation operation. The transaction coordinator is used to receive the transaction ID sent by the order service and record the data reservation operation status of each microservice. The data reservation operation status indicates the status of the data reservation operation of the microservice. The transaction ID is the identifier of the transaction corresponding to the order request generated by the order service after receiving the order request. The processing operations for one order request are combined into one transaction.

[0099] After determining that the data reservation operations of each microservice are successful, a first notification message is sent to the transaction coordinator; or, after determining that the data reservation operation of any microservice has failed or receiving a cancellation request for any microservice, a second notification message is sent to the transaction coordinator to enable the transaction coordinator to perform the following operations: after receiving the first notification message, the transaction status of the transaction ID is updated to the confirmed status, or after receiving the second notification message, the transaction status of the transaction ID is updated to the rollback status.

[0100] The order service generates a transaction each time it receives an order request, and the transaction status indicates the status of the order request processing.

[0101] In this embodiment, by introducing a transaction coordinator, the processing operations for one order request are combined into one transaction, and the transaction coordinator manages the operations through transactions.

[0102] In the embodiment of the present invention, the transaction coordinator may be a distributed transaction coordinator, such as Seata (an open source distributed transaction solution), TCC-Transaction (transaction), and the like.

[0103] The transaction coordinator is used to manage the status of transactions, where the processing of an order request can be understood as a transaction.

[0104] The transaction coordinator manages the same transaction, that is, the status of the same order request processing process, in a unified manner, and different transaction IDs are used to distinguish different transactions, so that the status of the entire transaction process can be accurately and comprehensively recorded. By managing the transaction status, the entire transaction processing can be better coordinated.

[0105] The TCC model ensures transaction consistency by splitting business operations into three steps: TRY, CONFIRM, and CANCEL. Each microservice first reserves data (TRY). In the CONFIRM phase, all microservices confirm the success of the previous operation. Otherwise, the reserved operation is rolled back in the CANCEL phase.

[0106] Among them, TRY: reserves necessary resources and records the reservation status; CONFIRM: confirms the operation on the premise that all TRY operations are successful; CANCEL: releases the reserved resources if there is a problem or timeout in the TRY operation.

[0107] In the embodiment of the present invention, TCC is used to solve the problem of atomicity of cross-service business operations, such as order reduction and multi-channel combined payment scenarios. By disassembling the business, the application can define the granularity of database operations, which can reduce lock conflicts and improve the business throughput of the system.

[0108] like Figure 2 As shown, processing an order using the distributed transaction-based order fulfillment method according to an embodiment of the present invention may include the following steps:

[0109] 1. Business application starts a transaction. Business applications are apps (Applications) installed on user devices.

[0110] 2. Calling the TRY interface. In this embodiment of the present invention, a business application can send an order request to the order service. After receiving the order request, the order service starts the transaction corresponding to the order request and triggers multiple microservices, such as Service A and Service B, to perform the TRY operation. Specifically, this can be achieved by calling the TRY interface.

[0111] 3. Commit or rollback the transaction.

[0112] 4. Call the CONFIRM interface or the CANCEL interface.

[0113] The data of each microservice can be stored in a database. One microservice can be connected to one database, and the microservice implements its own functions by accessing the data in the database.

[0114] In an optional embodiment, after sending a TRY request to each of the multiple microservices in parallel in S11, the following steps may also be included:

[0115] After determining that the data reservation operation of any microservice has failed, determine whether the data reservation operation of the current microservice meets the compensation strategy requirements, and if the compensation strategy requirements are met, send a third notification message to the transaction coordinator, so that the transaction coordinator marks the data reservation operation status of the target microservice as successful after receiving the third notification message.

[0116] Compensation policy requirements are used to indicate the conditions for meeting business objectives in business scenarios. Specifically, they include requirements that revenue is no less than a preset threshold or that transaction processing time exceeds a preset duration.

[0117] Among them, adaptive compensation strategies are designed according to different business logics and scenarios, and corresponding compensation strategy requirements can be configured accordingly.

[0118] For example, during an order processing, the voucher service receives a TRY request and needs to pre-freeze the user's vouchers. However, the voucher service checks that the user's vouchers do not meet the requirements, and the data reservation operation fails. Normal logic would trigger all microservices to release reserved resources. However, considering that in actual business processing, merchants may not care about the number of vouchers used by users, or even if the vouchers do not meet the requirements, the merchant may benefit from using them. Therefore, the entire process can still proceed smoothly.

[0119] This embodiment can reduce revenue loss caused by transaction failure.

[0120] Based on this, the embodiment of the present invention Figure 1 Based on the processing logic shown, a dynamic compensation mechanism is added. Among them, the embodiment of the present invention introduces a dynamically configurable compensation mechanism by judging whether the data reservation operation of the current microservice meets the compensation policy requirements.

[0121] Specifically, it can be determined whether the benefit after executing the data reservation operation of the current microservice is not less than a preset threshold. If so, it indicates whether the data reservation operation of the current microservice meets the compensation strategy requirements. In this case, a third notification message is sent to the transaction coordinator, so that the transaction coordinator marks the data reservation operation status of the target microservice as a successful operation. In this way, the order service determines whether each microservice has successfully executed the data reservation operation based on the data reservation operation status of each microservice recorded by the transaction coordinator. Although the data reservation operation of any microservice fails, the order service can determine that the data reservation operation of each microservice is successful, and send a CONFIRM request to each microservice, triggering each microservice to execute its own real service operation, so that the order is successfully completed.

[0122] That is, although the data reservation operation of any microservice fails, the embodiment of the present invention enables the transaction coordinator to mark the data reservation operation status of the target microservice as successful, so that when the order service checks the status of each microservice in the transaction coordinator, it will not roll back each microservice to the CANCEL stage due to the failure of the data reservation operation.

[0123] The compensation strategy requirements can be determined based on actual needs. For example, the profit must not be less than a preset threshold, and the preset threshold can be determined based on business needs, etc.

[0124] Based on business needs, you can choose more flexible compensation strategies, such as delay compensation and conditional compensation. Conditional compensation is introduced when conditions determined by business needs are met (such as revenue not less than a preset threshold), while delay compensation is introduced when the transaction processing time exceeds a preset duration.

[0125] In an optional embodiment, receiving the order request sent by the user device in S11 includes: receiving a TRY request, a CONFIRM request, and a CANCEL request sent by the order service through the message middleware;

[0126] S11 sends a TRY request to each of the multiple microservices in parallel, including: after receiving a first get request sent by any microservice through the message middleware, sending a TRY request to the microservice;

[0127] S12 sends a CONFIRM request to each microservice in parallel, including: after receiving the second acquisition request sent by any microservice through the message middleware, sending a CONFIRM request to the microservice;

[0128] In S13 , a CANCEL request is sent to each microservice respectively, including: after receiving the second acquisition request sent by any microservice through the message middleware, a CANCEL request is sent to the microservice.

[0129] Among them, message middleware may include Kafka (a high-throughput distributed publish-subscribe messaging system), RabbitMQ (an open source, message-oriented middleware), etc.

[0130] It can also be understood that the implementation of the order service and microservices through message middleware can reduce the coupling degree of direct service calls, while improving the fault tolerance and scalability of the system.

[0131] Figure 3 A flowchart of an order fulfillment method based on distributed transactions provided by an embodiment of the present invention.

[0132] Including order service, transaction coordinator, inventory service, payment service, voucher service, points service and gold coin service.

[0133] The Order Service coordinates the overall transaction. After receiving a user request, it initiates a TRY operation in each subsystem (Inventory Service, Payment Service, Voucher Service, Points Service, and Coin Service) and aggregates the results. Based on the TRY results, it makes a CONFIRM or CANCEL decision and notifies each subsystem of the transaction status. The transaction coordinator manages the status of the order processing process.

[0134] The distributed transaction-based order fulfillment method provided by the embodiment of the present invention mainly includes the following stages:

[0135] (1) System initialization:

[0136] Microservice startup: In a distributed transaction implementation system, it is critical to ensure that all microservice components (order service, inventory service, payment service, voucher service, points service, and gold coin service) are started and can communicate with each other. These components communicate through a unified messaging middleware (such as Kafka and RabbitMQ) to reduce the coupling of direct service calls and improve the system's fault tolerance and scalability.

[0137] Service registration and discovery: Use a service registration and discovery mechanism, such as Eureka (a Java-based service discovery framework) or Consul (an open-source tool for service discovery and configuration in distributed systems), to ensure that services can locate and communicate with each other. The specific service registration and discovery methods are based on those in related technologies and are not detailed here.

[0138] Logging and monitoring: Use distributed tracing systems such as Jaeger (used for monitoring and troubleshooting microservice architectures in distributed systems) and Zipkin (an open-source distributed real-time data tracing system) and logging systems such as the ELK Stack (a data processing toolchain based on the three open-source software Elasticsearch (collection), Logstash (processing), and Kibana (display)) to monitor the health status of each microservice and track transaction flows.

[0139] (2) TRY phase: The TRY phase is the first phase of the TCC model. This step primarily implements the reservation of service resources, ensuring the feasibility of subsequent operations by reserving resources. The TRY phase must be idempotent, meaning that executing the same operation multiple times will produce the same result as executing it once.

[0140] Order service:

[0141] User Request: A user submits an order request through the Order Service. The Order Service generates a unique transaction ID based on the request and initializes the transaction context.

[0142] Transaction Coordinator: Introduce a distributed transaction coordinator (such as Seata (open source distributed transaction solution), TCC-Transaction (transaction)) to manage the transaction status and the TRY operation of sub-transactions.

[0143] Inventory Services:

[0144] TRY request: The Order Service sends a TRY request to the Inventory Service, which reserves the corresponding inventory. The Inventory Service marks the inventory as reserved in the database and records the transaction ID to ensure idempotence.

[0145] Payment Services:

[0146] TRY Request: The Order Service sends a TRY request to the Payment Service, which pre-locks the user's funds. The Payment Service updates the user's account status to "Frozen" and records the transaction ID.

[0147] Voucher Service:

[0148] TRY request: The order service sends a TRY request to the voucher service. The voucher service pre-freezes the user's voucher and records the transaction ID and status.

[0149] Points service:

[0150] TRY request: The order service sends a TRY request to the points service. The points service deducts the user's points and records the transaction ID and status.

[0151] Gold Coin Service:

[0152] TRY request: The order service sends a TRY request to the coin service. The coin service deducts the user's coins and records the transaction ID and status.

[0153] (3) CONFIRM stage:

[0154] The CONFIRM phase is the second phase of the TCC model. If all service TRY operations are successfully completed, the system enters the CONFIRM phase to actually execute the operations and ensure the eventual consistency of the transaction.

[0155] Confirmation of information by the transaction coordinator: The Order Service aggregates the TRY operation results of each service. If the TRY operation succeeds, the distributed transaction coordinator updates the transaction status to "CONFIRM."

[0156] The inventory service processes the CONFIRM request: After receiving the CONFIRM request, the inventory service actually deducts the reserved inventory and updates the inventory mark status to "deducted".

[0157] The payment service processes the CONFIRM request: After receiving the CONFIRM request, the payment service actually deducts the user's funds, updates the account status to "deducted", and records the transaction.

[0158] The voucher service processes the CONFIRM request: After receiving the CONFIRM request, the voucher service actually cancels the user's voucher and updates the status to "Canceled".

[0159] The points service processes the CONFIRM request: After receiving the CONFIRM request, the points service actually deducts the user's points and updates the status to "deducted".

[0160] The gold coin service processes the CONFIRM request: After receiving the CONFIRM request, the gold coin service actually deducts the user's gold coins and updates the status to "deducted".

[0161] (4) CANCEL stage:

[0162] The CANCEL phase is the third phase of the TCC model. If any service operation in the TRY phase fails or the order service receives a cancellation request, the system enters the CANCEL phase and rolls back the previously reserved operations to ensure data consistency and system reliability.

[0163] Transaction coordinator cancellation information: When the TRY operation fails or times out, the distributed transaction coordinator updates the transaction status to "CANCEL".

[0164] The inventory service processes the CANCEL request: After receiving the CANCEL request, the inventory service restores the reserved inventory and updates the inventory status to "Available".

[0165] The payment service processes the CANCEL request: After receiving the CANCEL request, the payment service unlocks the pre-locked user funds and updates the account status to "Available".

[0166] The voucher service processes the CANCEL request: After receiving the CANCEL request, the voucher service unfreezes the pre-frozen vouchers and updates the status to "available".

[0167] The points service processes the CANCEL request: After receiving the CANCEL request, the points service restores the withheld points and updates the status to "available".

[0168] The gold coin service processes the CANCEL request: After receiving the CANCEL request, the gold coin service restores the withheld gold coins and updates the status to "available".

[0169] Specifically, inventory services, payment services, voucher services, points services, and gold coin services mainly include the following:

[0170] For the inventory service, during the TRY phase, upon receiving a TRY request, the inventory service checks inventory and, if available, reserves the corresponding inventory. The inventory is marked as reserved in the database and the transaction ID is recorded, effectively recording the inventory TRY status. During the CONFIRM phase, the reserved inventory is actually deducted. During the CANCEL phase, upon receiving a CANCEL request, the reserved inventory is restored.

[0171] For payment services, the TRY phase: Upon receiving a TRY request, the payment service pre-locks the user's funds, updates the user's account status to "frozen," and records the relevant transaction ID, thus recording the TRY status of the funds. The CONFIRM phase: The actual deduction of user funds. The CANCEL phase: Upon receiving a CANCEL request, the pre-locked user funds are unlocked.

[0172] For the voucher service, during the TRY phase, upon receiving a TRY request, the voucher service checks the user's voucher validity. If valid, the voucher is pre-frozen and the status is recorded as TRY. During the CONFIRM phase, the voucher is actually redeemed and the status is updated to CONFIRM, ensuring unique voucher usage. During the CANCEL phase, the pre-frozen voucher is unfrozen and the status is restored, recording the transaction ID and status.

[0173] For the points service, during the TRY phase, the points service queries the user's points balance. If sufficient, it withholds points and records the status as TRY. During the CONFIRM phase, points are actually deducted, the status is updated to CONFIRM, and the points deduction history is recorded. During the CANCEL phase, withheld points are resumed and the status is updated to ensure the accuracy of the points account.

[0174] For the gold coin service, during the TRY phase, the gold coin service queries the user's gold coin balance. If the balance is sufficient, gold coins are withheld and the status is recorded as TRY. During the CONFIRM phase, gold coins are actually deducted and the status is updated to CONFIRM, recording the gold coin consumption history. During the CANCEL phase, the withheld gold coins are resumed and the status is updated to ensure the accuracy of the gold coin account data.

[0175] The embodiments of the present invention introduce the TCC model to ensure the consistency and atomicity of distributed transactions, and guarantee the consistency of asynchronous operations through the processing of asynchronous calls. A detailed reservation, confirmation, and cancellation process and the coordination between each step are also provided. This can ensure the consistency and atomicity of orders in complex marketing activities and distributed systems, improve system reliability and user experience, reduce revenue losses due to transaction failures, and further enhance brand image. The distributed transaction implementation system provided by the embodiments of the present invention has the following main features:

[0176] Asynchronous execution: Asynchronous processing reduces transaction latency and delays caused by synchronous communication, resolving the high latency and network load associated with multiple rounds of communication between nodes in the XA transaction model. Furthermore, the TRY, CONFIRM, and CANCEL functions, used for reservation, confirmation, and rollback, respectively, make operations more flexible and efficient.

[0177] Local transaction processing: Compared with global transaction locking, the TCC mode decomposes transaction processing into local preprocessing, confirmation, and rollback, improving the concurrency of local transactions and reducing the impact of global locking on performance. This solves the problem in related technologies where multiple resources need to remain locked in the XA transaction model, affecting concurrent resource utilization.

[0178] Precise rollback (CANCEL): For failed transactions, the CANCEL mechanism can be used to roll back unconfirmed resources in real time, significantly reducing the impact of failed transactions on the overall system performance.

[0179] Transaction log and state management: Use transaction log and state management mechanisms in the design to record the transaction status of each step, ensuring rapid recovery and state rollback even in the event of a system failure.

[0180] Distributed coordination: Through a decentralized coordination mechanism, the performance bottlenecks and risks of single-point coordinators are reduced. When the number of servers increases, the load on the coordinator will not increase significantly. This solves the problem in related technologies that the XA transaction model coordinator needs to maintain the transaction status of multiple nodes at the same time. When the number of nodes increases, the pressure and bottleneck of the coordinator will increase significantly.

[0181] Among them, the mechanism for processing asynchronous calls in the embodiment of the present invention mainly refers to solving data inconsistency problems through asynchronous communication and event-driven methods during distributed transaction processing, improving system performance, and avoiding performance bottlenecks that affect business expansion.

[0182] 1. Asynchronous communication and event-driven mechanism:

[0183] Message queue: Use message middleware, which can also be understood as a message queue (such as Kafka, RabbitMQ, etc.) to implement asynchronous communication, placing calls between services in the message queue for processing, reducing the waiting time and locked resources caused by synchronous calls.

[0184] Event-driven: Based on the event-driven architecture, each service publishes or subscribes to the corresponding events after completing its own transaction operations (TRY, CONFIRM, CANCEL), achieving decoupling and on-demand processing.

[0185] 2. Combining asynchronous processing with TCC:

[0186] The TCC mode (TRY-CONFIRM-CANCEL) is a transaction processing logic that includes three stages: reserving resources (TRY), confirming execution (CONFIRM), and canceling (CANCEL). The present invention implements and enhances the scalability and efficiency of the traditional TCC mode through an asynchronous call mechanism.

[0187] Asynchronous implementation of TRY, CONFIRM, and CANCEL: TRY, CONFIRM, and CANCEL operations are implemented through asynchronous message queues and event-driven methods, so that these operations are no longer executed synchronously, reducing transaction lock time and avoiding performance bottlenecks.

[0188] Parallel processing: For different services (orders, inventory, payments, etc.), TRY, CONFIRM, and CANCEL can be triggered and executed in parallel, further improving the system's concurrent processing capabilities.

[0189] 3. The asynchronous call mechanism enhances the fault tolerance and consistency of TCC:

[0190] Asynchronous retry mechanism: During the TRY or CONFIRM phase of a transaction, if a failure occurs due to network or system failure, asynchronous retry can be implemented through transaction logs and state management to ensure eventual consistency of the transaction.

[0191] Distributed transaction coordination: A distributed coordinator is used to manage the global transaction status, monitor the completion of steps, and handle failed rollback operations to ensure that operations at each stage can be completed correctly.

[0192] 4. Event-driven and asynchronous context association:

[0193] Event tracing: The event-driven mechanism enables the completion status of each operation to be propagated through events, and other transactions are monitored and processed through events to ensure that there is no loss of connection or omission.

[0194] Operation association: In complex transactions, calls between different services can be contextually associated through asynchronous events to ensure the consistency of all service operations.

[0195] In addition, the distributed transaction-based order fulfillment method provided by the embodiment of the present invention can be used in different application scenarios according to actual needs.

[0196] Generally speaking, the application scenario of the distributed transaction-based order fulfillment method provided by the embodiment of the present invention may include an upstream, an order system, and a downstream.

[0197] In a scenario, such as Figure 4A As shown:

[0198] The upstream generates user demand and generates order requests based on user demand and sends them to the order system. The order system may include: member information, product information, promotion information, inventory information and other information; the corresponding downstream may include: membership system, warehousing system, payment system, risk control system, messaging system, financial system, product system, and promotion system.

[0199] In another scenario, Figure 4B As shown: the upstream includes: membership system, warehousing system, payment system, messaging system, financial system, product system, and promotion system; the order system includes membership information, product information, promotion information, other information, logistics information, and payment information; the downstream includes order lists, order details, and order messages.

[0200] Reference Figure 5 The embodiment of the present invention further provides an order fulfillment system based on distributed transactions, including:

[0201] An order service 51 and multiple microservices 52, where the multiple microservices 52 work together to complete an order goal, where the order goal represents the result to be achieved for the order;

[0202] The order service 51 is configured to receive an order request sent by a user device and send a TRY request to each of the multiple microservices 52 in parallel;

[0203] Each microservice 52 in the plurality of microservices 52 is configured to execute a data reservation operation of the microservice 52 after receiving a TRY request sent by the order service 51. The data reservation operation is configured to check whether target data required by the order request exists and mark the target data as locked if the target data exists.

[0204] The order service 51 is further configured to send a CONFIRM request to each microservice 52 in parallel after determining that the data reservation operation of each microservice 52 is successful;

[0205] Each microservice 52 in the plurality of microservices 52 is further configured to execute a real service operation of the microservice 52 upon receiving a CONFIRM request sent by the order service 51, where the real service operation indicates using target data marked as locked by the data reservation operation;

[0206] The order service 51 is further configured to send a CANCEL request to each microservice 52 upon determining that the data reservation operation of any microservice 52 has failed or receiving a cancellation request for any microservice 52;

[0207] Each microservice 52 in the multiple microservices 52 is further configured to cancel the data reservation operation of the microservice 52 after receiving a CANCEL request sent by the order service 51 .

[0208] Optionally, the system further includes: a transaction coordinator;

[0209] The transaction coordinator is used to receive the transaction ID sent by the order service 51 and record the data reservation operation status of each microservice 52. The data reservation operation status indicates the status of the data reservation operation executed by the microservice 52. The transaction ID is the identifier of the transaction corresponding to the order request generated by the order service 51 after receiving the order request. The processing operations for one order request are combined into one transaction.

[0210] The order service 51 is specifically used to determine whether each microservice 52 has successfully performed the data reservation operation based on the recorded data reservation operation status of each microservice 52;

[0211] The order service 51 is further configured to send a first notification message to the transaction coordinator after determining that the data reservation operation of each microservice 52 is successful; or send a second notification message to the transaction coordinator after determining that the data reservation operation of any microservice 52 fails or receiving a cancellation request for any microservice 52;

[0212] The transaction coordinator is also used to update the transaction status of the transaction ID to a confirmed status after receiving a first notification message, or to update the transaction status of the transaction ID to a rollback status after receiving a second notification message. The order service 51 generates a transaction each time it receives an order request, and the transaction status indicates the status of processing the order request.

[0213] Optionally, the order service 51 is further configured to, after determining that the data reservation operation of any microservice 52 has failed, determine whether the data reservation operation of the current microservice 52 satisfies the compensation policy requirements, and send a third notification message to the transaction coordinator if the compensation policy requirements are met. The compensation policy requirements are used to indicate the conditions for satisfying the business objectives in the business scenario.

[0214] The transaction coordinator is further configured to mark the data reservation operation status of the target microservice 52 as operation successful after receiving the third notification message.

[0215] Optionally, the system further includes: message middleware;

[0216] The message middleware is used to receive the TRY request, CONFIRM request and CANCEL request sent by the order service 51; and after receiving the first acquisition request sent by any microservice 52, send a TRY request to the microservice 52; or after receiving the second acquisition request sent by any microservice 52, send a CONFIRM request to the microservice 52; or after receiving the second acquisition request sent by any microservice 52, send a CANCEL request to the microservice 52.

[0217] The embodiment of the present invention provides an order fulfillment device based on distributed transactions, which is applied to order services, such as Figure 6 Shown, including:

[0218] Receiving module 601, configured to receive an order request sent by a user device;

[0219] The sending module 602 is used to send TRY requests to each microservice in the multiple microservices in parallel, so that each microservice executes the data reservation operation of the microservice after receiving the TRY request sent by the order service. The data reservation operation means checking whether the target data required by the order request exists, and marking the target data as locked when the target data exists. The multiple microservices work together to complete the order target, and the order target represents the result of the order to be realized; after determining that the data reservation operation of each microservice is successful, sending CONFIRM requests to each microservice in parallel, so that each microservice executes the real service operation of the microservice after receiving the CONFIRM request sent by the order service, and the real service operation means using the target data marked as locked by the data reservation operation; after determining that the data reservation operation of any microservice fails or receiving a cancel request for any microservice, sending CANCEL requests to each microservice respectively, so that each microservice cancels the data reservation operation of the microservice after receiving the CANCEL request sent by the order service.

[0220] Optionally, the device further comprises:

[0221] The status update module is configured to, after sending a TRY request to each of the multiple microservices in parallel, determine whether each microservice has successfully executed the data reservation operation based on the data reservation operation status of each microservice recorded by the transaction coordinator. The transaction coordinator is configured to receive a transaction ID sent by the order service and record the data reservation operation status of each microservice. The data reservation operation status indicates the status of executing the data reservation operation of the microservice. The transaction ID is an identifier of a transaction corresponding to the order request generated by the order service after receiving the order request. The processing operations for one order request are combined into one transaction. After determining that the data reservation operations of each microservice are successful, the module sends a first notification message to the transaction coordinator. Alternatively, after determining that the data reservation operation of any microservice has failed or receiving a cancel request for any microservice, the module sends a second notification message to the transaction coordinator, causing the transaction coordinator to perform the following operations: after receiving the first notification message, updating the transaction status of the transaction ID to a confirmed state, or after receiving the second notification message, updating the transaction status of the transaction ID to a rollback state. The order service generates a transaction for each order request received, and the transaction status indicates the status of processing the order request.

[0222] Optionally, the device further comprises:

[0223] The compensation module is used to, after sending TRY requests to each microservice in multiple microservices in parallel, determine whether the data reservation operation of the current microservice meets the compensation strategy requirements after determining that the data reservation operation of any microservice has failed, and send a third notification message to the transaction coordinator when the compensation strategy requirements are met, so that the transaction coordinator marks the data reservation operation status of the target microservice as successful after receiving the third notification message. The compensation strategy requirements are used to indicate the conditions for meeting business goals in business scenarios.

[0224] Optionally, the receiving module 601 is specifically configured to receive a TRY request, a CONFIRM request, and a CANCEL request sent by the order service through the message middleware;

[0225] The sending module 602 is specifically used to send a TRY request to the microservice through the message middleware after receiving the first acquisition request sent by any microservice; send a CONFIRM request to the microservice through the message middleware after receiving the second acquisition request sent by any microservice; and send a CANCEL request to the microservice through the message middleware after receiving the second acquisition request sent by any microservice.

[0226] The embodiment of the present invention further provides an electronic device, such as Figure 7As shown, it includes a processor 701, a communication interface 702, a memory 703 and a communication bus 704, wherein the processor 701, the communication interface 702, and the memory 703 communicate with each other through the communication bus 704;

[0227] Memory 703, for storing computer programs;

[0228] The processor 701 is configured to implement the steps of the above-mentioned distributed transaction implementation method when executing the program stored in the memory 703 .

[0229] The communication bus mentioned in the terminal can be a Peripheral Component Interconnect (PCI) bus or an Extended Industrial Standard Architecture (EISA) bus. This communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is used in the figure, but this does not mean that there is only one bus or only one type of bus.

[0230] The communication interface is used for communication between the above terminal and other devices.

[0231] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage. Alternatively, the memory may be at least one storage device located away from the processor.

[0232] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components.

[0233] In another embodiment of the present invention, a computer-readable storage medium is provided, in which a computer program is stored. When the computer program is executed by a processor, the distributed transaction implementation method described in any one of the above embodiments is implemented.

[0234] In another embodiment of the present invention, a computer program product including instructions is provided. When the computer program product is executed on a computer, the computer executes the distributed transaction implementation method described in any one of the above embodiments.

[0235] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

[0236] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply the existence of any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.

[0237] Each embodiment in this specification is described in a related manner. Similar portions between the various embodiments can be referenced to each other. Each embodiment focuses on the differences between the other embodiments. In particular, the system, device, electronic device, computer-readable storage, and computer program product embodiments are generally similar to the method embodiments, so their descriptions are relatively simplified. For related portions, reference can be made to the descriptions of the method embodiments.

[0238] The above description is only a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention are included in the scope of protection of the present invention.

Claims

1. An order fulfillment method based on distributed transactions, characterized in that: Applied to order services, including: Receive an order request sent by a user device, and send a TRY request to each of the multiple microservices in parallel, so that each microservice, after receiving the TRY request sent by the order service, performs a data reservation operation of the microservice, wherein the data reservation operation indicates checking whether target data required by the order request exists and marking the target data as locked if the target data exists, wherein the multiple microservices jointly complete the order target, and the order target indicates the result to be achieved of the order; After determining that the data reservation operations of each microservice are successful, a CONFIRM request is sent to each microservice in parallel, so that each microservice, upon receiving the CONFIRM request sent by the order service, executes the real service operation of the microservice, where the real service operation indicates using the target data marked as locked by the data reservation operation; After determining that the data reservation operation of any microservice has failed or receiving a cancellation request for any microservice, a CANCEL request is sent to each microservice respectively, so that each microservice cancels the data reservation operation of the microservice after receiving the CANCEL request sent by the order service.

2. The method according to claim 1, characterized in that After sending the TRY request to each of the multiple microservices in parallel, the method further includes: Determining whether each microservice has successfully executed the data reservation operation based on the data reservation operation status of each microservice recorded by the transaction coordinator, wherein the transaction coordinator is used to receive the transaction ID sent by the order service and record the data reservation operation status of each microservice, wherein the data reservation operation status indicates the status of executing the data reservation operation of the microservice, wherein the transaction ID is an identifier of a transaction corresponding to the order request generated by the order service after receiving the order request, and the processing operations for one order request are combined into one transaction; After determining that the data reservation operations of each microservice are successful, a first notification message is sent to the transaction coordinator; or, after determining that the data reservation operation of any microservice has failed or receiving a cancellation request for any microservice, a second notification message is sent to the transaction coordinator, so that the transaction coordinator performs the following operations: after receiving the first notification message, the transaction status of the transaction ID is updated to a confirmed status, or after receiving the second notification message, the transaction status of the transaction ID is updated to a rollback status. The order service generates a transaction for each order request received, and the transaction status indicates the status of processing the order request.

3. The method according to claim 2, characterized in that After sending the TRY request to each of the multiple microservices in parallel, the method further includes: After determining that the data reservation operation of any microservice has failed, determine whether the data reservation operation of the current microservice meets the compensation policy requirements, and if the compensation policy requirements are met, send a third notification message to the transaction coordinator, so that after receiving the third notification message, the transaction coordinator marks the data reservation operation status of the target microservice as successful operation. The compensation policy requirements are used to indicate the conditions for meeting the business objectives in the business scenario.

4. The method according to any one of claims 1 to 3, characterized in that The receiving the order request sent by the user equipment includes: Receive TRY requests, CONFIRM requests, and CANCEL requests sent by the order service through the message middleware; The sending of a TRY request to each of the multiple microservices in parallel includes: After receiving the first get request sent by any microservice, the message middleware sends the TRY request to the microservice; The sending of CONFIRM requests to each microservice in parallel includes: After receiving the second acquisition request sent by any microservice, the message middleware sends the CONFIRM request to the microservice; The sending of a CANCEL request to each microservice includes: After receiving the second acquisition request sent by any microservice, the message middleware sends the CANCEL request to the microservice.

5. An order fulfillment system based on distributed transactions, characterized in that: include: An order service and multiple microservices, wherein the multiple microservices work together to complete an order goal, where the order goal represents the result to be achieved for the order; The order service is used to receive an order request sent by a user device and send a TRY request to each of the multiple microservices in parallel; Each microservice among the multiple microservices is configured to, after receiving a TRY request sent by the order service, perform a data reservation operation of the microservice, wherein the data reservation operation indicates checking whether target data required by the order request exists and marking the target data as locked if the target data exists; The order service is further configured to send a CONFIRM request to each microservice in parallel after determining that the data reservation operation of each microservice is successful; Each microservice in the plurality of microservices is further configured to, upon receiving a CONFIRM request sent by the order service, execute a real service operation of the microservice, wherein the real service operation indicates using target data marked as locked by the data reservation operation; The order service is further configured to send a CANCEL request to each microservice after determining that a data reservation operation of any microservice has failed or receiving a cancellation request for any microservice; Each microservice in the multiple microservices is further configured to cancel the data reservation operation of the microservice after receiving a CANCEL request sent by the order service.

6. The system according to claim 5, characterized in that The system further includes: a transaction coordinator; The transaction coordinator is configured to receive the transaction ID sent by the order service and record the data reservation operation status of each microservice, where the data reservation operation status indicates the status of executing the data reservation operation of the microservice. The transaction ID is an identifier of a transaction corresponding to the order request generated by the order service after receiving the order request. The processing operations for one order request are combined into one transaction. The order service is specifically used to determine whether each microservice has successfully performed the data reservation operation based on the recorded data reservation operation status of each microservice; The order service is further configured to send a first notification message to the transaction coordinator after determining that the data reservation operation of each microservice is successful; or send a second notification message to the transaction coordinator after determining that the data reservation operation of any microservice fails or receiving a cancellation request for any microservice; The transaction coordinator is further configured to update the transaction status of the transaction ID to a confirmed status after receiving the first notification message, or to update the transaction status of the transaction ID to a rollback status after receiving the second notification message. The order service generates a corresponding transaction each time it receives an order request, and the transaction status indicates the status of processing the order request.

7. The system according to claim 5, characterized in that The order service is further configured to, after determining that the data reservation operation of any microservice has failed, determine whether the data reservation operation of the current microservice meets the compensation policy requirements, and send a third notification message to the transaction coordinator if the compensation policy requirements are met, where the compensation policy requirements are used to indicate the conditions for meeting the business objectives in the business scenario; The transaction coordinator is further configured to mark the data reservation operation status of the target microservice as operation successful after receiving the third notification message.

8. The system according to any one of claims 5 to 7, characterized in that The system further includes: a message middleware; The message middleware is used to receive the TRY request, CONFIRM request and CANCEL request sent by the order service; and after receiving the first acquisition request sent by any microservice, send the TRY request to the microservice; or after receiving the second acquisition request sent by any microservice, send the CONFIRM request to the microservice; or after receiving the second acquisition request sent by any microservice, send the CANCEL request to the microservice.

9. An order fulfillment device based on distributed transactions, characterized in that: Applied to order services, including: A receiving module, configured to receive an order request sent by a user device; The sending module is used to send TRY requests to each microservice in multiple microservices in parallel, so that each microservice executes a data reservation operation of the microservice after receiving the TRY request sent by the order service. The data reservation operation indicates checking whether the target data required by the order request exists and marking the target data as locked when the target data exists. The multiple microservices jointly complete the order target, and the order target indicates the result to be achieved for the order. After determining that the data reservation operation of each microservice is successful, the sending module sends CONFIRM requests to each microservice in parallel, so that each microservice executes a real service operation of the microservice after receiving the CONFIRM request sent by the order service. The real service operation indicates using the target data marked as locked by the data reservation operation. After determining that the data reservation operation of any microservice fails or receiving a cancel request for any microservice, the sending module sends CANCEL requests to each microservice respectively, so that each microservice cancels the data reservation operation of the microservice after receiving the CANCEL request sent by the order service.

10. An electronic device, characterized in that: It includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus; Memory for storing computer programs; A processor, configured to implement the method steps described in any one of claims 1 to 4 when executing a program stored in a memory.

11. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method steps according to any one of claims 1 to 4 are implemented.

Images