A distributed transaction processing method, apparatus and electronic device
By using a business state machine to decouple the transaction coordinator from the business side, and combining an idempotent transaction interface and request queue processing, the problem of strong coupling between the transaction coordinator and the business side in a distributed system is solved, improving processing efficiency and fault tolerance.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING BAIDU NETCOM SCI & TECH CO LTD
- Filing Date
- 2021-10-09
- Publication Date
- 2026-05-05
AI Technical Summary
In a distributed system environment, existing technologies have a strong coupling between the transaction coordinator and the business side, resulting in high operation and maintenance costs, and there is also the problem of improper handling of network anomalies leading to business processing anomalies.
The business state machine's action states are used to call the business operation interface, decoupling the transaction coordinator from the business side. Exception requests are handled through the idempotent transaction interface, and business requests are queued according to type and priority to reduce latency.
It reduces business operation and maintenance costs, improves the timeliness and fault tolerance of distributed transaction processing, and avoids business processing anomalies caused by abnormal requests.
Smart Images

Figure CN113900785B_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of computer technology, and more particularly to the field of database technology. Background Technology
[0002] Currently, when performing transaction processing in a distributed system environment, it is necessary to ensure the atomicity of multiple operation sequences in microservices. Summary of the Invention
[0003] This disclosure provides a distributed transaction processing method, apparatus, device, and storage medium.
[0004] According to one aspect of this disclosure, a distributed transaction processing method is provided, comprising:
[0005] Obtain the current action state of the business state machine as the first action state, wherein the business state machine is a state machine that presents the business processing status;
[0006] The first business operation interface corresponding to the first action state of the business state machine is invoked, so that the business terminal executes the operation corresponding to the first business operation interface.
[0007] According to another aspect of this disclosure, a distributed transaction processing apparatus is provided, comprising:
[0008] The business state machine state acquisition module is used to acquire the current action state of the business state machine as the first action state. The business state machine is a state machine that presents the business processing situation.
[0009] The first interface calling module is used to call the first business operation interface corresponding to the first action state of the business state machine, so that the business end executes the operation corresponding to the first business operation interface.
[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description
[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:
[0012] Figure 1 This is a flowchart illustrating a distributed transaction processing method according to this disclosure;
[0013] Figure 2 This is another flowchart illustrating the distributed transaction processing method according to this disclosure;
[0014] Figure 3This is another flowchart illustrating the distributed transaction processing method according to this disclosure;
[0015] Figure 4 This is another flowchart illustrating the distributed transaction processing method according to this disclosure;
[0016] Figure 5 This is another flowchart illustrating the distributed transaction processing method according to this disclosure;
[0017] Figure 6 This is a schematic diagram of a distributed transaction processing apparatus according to the present disclosure;
[0018] Figure 7 This is a block diagram of an electronic device used to implement the distributed transaction processing method of the embodiments of this disclosure. Detailed Implementation
[0019] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.
[0020] In a distributed system environment, a business processing unit typically needs to combine requests to multiple services. This is especially true in systems with a large number of microservices, where the number of combined service requests can reach dozens. Furthermore, complex, step-by-step business logic is often implemented through a large number of operations. To ensure the normal operation of a distributed system, the consistency of these requests and operations must be guaranteed. The mechanism for ensuring the consistency of these requests and operations is called distributed transactions.
[0021] In related technologies, there are various distributed transaction processing schemes, such as XA (a two-phase commit protocol defined by the X / Open DTP organization) and TCC (Try, Confirm, Cancel), which can process transactions in a distributed manner. However, these technologies introduce a strong coupling problem between the business side and the transaction coordinator during implementation. This causes the transaction coordinator's code to intrude into the business logic, requiring users to perform simultaneous maintenance on the transaction coordinator when operating the business, resulting in high operational costs for the business.
[0022] To address the aforementioned technical problems, embodiments of this disclosure provide a distributed transaction processing method, as follows: Figure 1 As shown, it includes:
[0023] S101, obtain the current action state of the business state machine as the first action state.
[0024] S102, call the first business operation interface corresponding to the first action state of the business state machine, so that the business side executes the operation corresponding to the first business operation interface.
[0025] By using this embodiment, the transaction coordinator can call the business operation interface corresponding to different states based on the first action state of the business state machine, so that each business end can perform the corresponding operation according to the business operation interface. It can be seen that the transaction coordinator of this disclosure only calls the business operation interface according to the state of the business state machine, and each business end only executes the corresponding operation according to the business operation interface. It is not necessary to apply the operation steps corresponding to the business to different businesses. The transaction coordinator interacts with the business through the interface. The transaction coordinator only needs to obtain the state of the business and call the operation interface corresponding to the state for the business. This decouples the transaction coordinator from each business, reduces the intrusion of the transaction coordinator into the business end, and reduces the operation and maintenance cost of the business.
[0026] In S101, the business state machine is a state machine that presents the business processing status. The actions of each node on the business state machine can be predefined according to different business content. For example, taking an online shopping application scenario, there is a user payment order business. Suppose that this business process includes the step of modifying the order status. Then, in the business state machine corresponding to this business, the action corresponding to a node can be defined as modifying the order status, and whether the modification of the order status was successful can be defined as the state corresponding to that node. It can be understood that if the action of modifying the order status in a business operation fails, the current action state (first action state) of the corresponding node in the business state machine for that business is "modification of order status failed."
[0027] In this embodiment, the action state of each node of the business state machine corresponding to the business can be obtained, and the action state of each node can be used as the first action state of the business state machine.
[0028] In S102, after determining the first action state of the business state machine, the corresponding business operation interface can be called based on the first action state of each node. For example, taking the user payment order business in an online shopping application scenario, if the business side fails to execute the step "Modify Order Status," the business state machine displays the corresponding first action state. It is understandable that, because the step "Modify Order Status" failed, to ensure business consistency, all other steps in the user payment order business of this online shopping application scenario should be rolled back to the unstarted state. Therefore, based on the first action state of the business state machine, the transaction coordinator should call the compensation business operation interface corresponding to this first action state to allow the business side to restore to the starting state and re-perform the operation.
[0029] For example, if all steps in the user payment order business in an online shopping application scenario are executed successfully, and the business state machine displays the first action state, then the corresponding business operation interface called by the transaction coordinator for this first action state should be the verification business operation interface, so that the business side can verify each completed step.
[0030] During implementation, the execution steps and states of the business process frequently change. For example, taking the online shopping application scenario mentioned above, if another user buys the same item after one user has purchased it, the business side needs to process the payment order for that user, and the state machine's action state should change accordingly. Based on this, this disclosure also provides a distributed transaction processing method, such as... Figure 2 The above includes:
[0031] S201, Obtain the current action state of the business state machine as the first action state.
[0032] This step is the same as S101 above, and you can refer to the relevant description of S101 above, so it will not be repeated here.
[0033] S202, call the first business operation interface corresponding to the first action state of the business state machine, so that the business side executes the operation corresponding to the first business operation interface.
[0034] This step is the same as S102 above, and you can refer to the relevant description of S102 above, so it will not be repeated here.
[0035] S203, obtain the execution results of each preset execution step of the business on the business side.
[0036] For any given business operation, the execution steps can vary depending on the specific content. Technical personnel can pre-set these execution steps for different business operations. For example, in an online shopping scenario, if another user purchases the same item as a previous user, the business logic needs to process this newly generated payment order. The pre-set execution steps for this payment order might be modifying the order status, deducting inventory, and creating a sales order. The results of these pre-set steps could be whether the order status modification was successful, whether the inventory deduction was correct, and whether the sales order creation was correct, respectively. It's understandable that the business logic will obtain the results after executing each pre-set step; therefore, the business logic can send the execution results corresponding to each pre-set step to the transaction coordinator.
[0037] S204. Based on the execution result of the business, update the current action state of the business state machine to obtain the second action state of the business state machine.
[0038] After obtaining the execution results of each preset execution step of the business process, the transaction coordinator can update the current action state of the business state machine based on the execution results. For example, if the execution results of each preset execution step of the business process are successful modification of order status, correct deduction of inventory, and correct creation of sales delivery order, then the business state machine needs to update the action state of the corresponding node of each step according to the execution results, thereby obtaining the second action state of the business state machine.
[0039] S205, call the second business operation interface corresponding to the second action state of the business state machine, so that the business side executes the operation corresponding to the second business operation interface.
[0040] This step is similar to S102 above, and you can refer to the relevant description of S102 above, so it will not be repeated here.
[0041] By using this embodiment, the action state of the business state machine can be updated in real time according to the processing status of different business operations, and then the business operation interface corresponding to different action states can be called in real time, so that each business can be further processed as soon as possible, thereby improving the timeliness of distributed transaction processing.
[0042] In one possible embodiment, various problems such as network anomalies or server anomalies may occur during the actual implementation of the business, causing issues such as duplicate reporting, out-of-order reporting, and lost reporting of business requests on the business side. Furthermore, this can lead to the transaction coordinator repeatedly, out of order, or missingly calling the business operation interface based on these abnormal business requests, resulting in the business being unable to process normally. Based on this, this application also provides a distributed business processing method, such as... Figure 3 As shown, it includes:
[0043] S301, obtain the current action state of the business state machine as the first action state.
[0044] This step is the same as S101 above, and you can refer to the relevant description of S101 above, so it will not be repeated here.
[0045] S302, call the first business operation interface corresponding to the first action state of the business state machine, so that the business side executes the operation corresponding to the first business operation interface.
[0046] This step is the same as S102 above, and you can refer to the relevant description of S102 above, so it will not be repeated here.
[0047] S303, update the state of the transaction state machine according to the result of the corresponding operation performed by the business end, and obtain the third action state of the transaction state machine.
[0048] A transaction state machine is a state machine that presents the transaction processing status of the business side. The transaction state machine can preset different actions at corresponding nodes based on different business operation interfaces. For example, at a certain node, the preset action for modifying the order status might be compensation or verification, and correspondingly, the action status at that node might be verification successful or verification failed. Therefore, the transaction state machine can update its action status based on the operation results of the corresponding business operation interface executed by the business side.
[0049] For example, taking the user payment order business in the aforementioned online shopping application scenario as an example, if all steps in this business are executed successfully, the business side needs to perform operations according to the verification business operation interface corresponding to the first action state called by the transaction coordinator, verify the execution results of each execution step, and determine whether the verification is successful. Thus, the transaction coordinator can obtain the operation results of the business side's execution of the business operation interface from the business side. If, at this time, only the step of deducting inventory fails verification, while all other execution steps are verified successfully, the transaction state machine can update the action state of each node according to the operation results. That is, update the verification of modifying the order status to verification successful, update the verification of deducting inventory to verification failed, and update the verification of creating a sales delivery order to verification successful, thereby obtaining the third action state of the transaction state machine.
[0050] S304: Receives a business request from the business side and obtains the context corresponding to the business request.
[0051] While the transaction regulator invokes business operation interfaces based on the action state of the business state machine, the business itself also sends business requests to the transaction regulator based on its own business processing status, enabling the transaction regulator to coordinate the next step of the business processing. It can be understood that the business request contains content indicating the business being requested, such as business information indicating whether it's a user order payment or user refund, etc. The business request also contains content indicating the business operation interface it requests; for example, if a step in the business fails and the business requests compensation, the interface information indicating the compensation request will also be included in the business request. The context corresponding to the business request can be relevant information needed to process the business request, or the background when the business sends the business request, such as the processing progress of the business.
[0052] S305, determine whether the business request is an abnormal business request based on the context and the third action status.
[0053] The context of the business request can be obtained, and the third action state of the transaction state machine can determine the operation result of the business side according to the business operation interface. Based on this, the transaction coordinator can determine the processing progress of a business, the operation according to the business operation interface, and the operation result based on the context and the third action state. Based on the business state determined by the transaction coordinator, it can determine whether the received business request is an abnormal business request. For example, if a business request requests a compensation business operation interface, and the transaction coordinator determines from the current action state of the corresponding transaction state machine that the business has already been compensated according to the compensation business operation interface and the compensation was successful, then the business request should be judged as a duplicate request, i.e., an abnormal business request. For example, if a business request requests a validation business operation interface, and the latest node status displayed on the transaction state machine corresponding to that business is "compensation successful," it can be determined from the context of the business request that when the business request was issued, the validation operation had already been requested for the content contained in the business request. If the status of the previous node of the transaction state machine is then checked, it shows that the validation action corresponding to the content contained in the business was successful. It can be understood that the business request has been processed. At this point, the transaction coordinator can determine that the business request is an out-of-order request, i.e., an abnormal business request.
[0054] S306, if so, refuse to perform the operation based on the business request.
[0055] If the transaction coordinator determines that the received business request is an abnormal business request, the transaction coordinator will refuse to call the requested business operation interface for the business, and will not update the action state of the transaction state machine based on the operation result.
[0056] S307, if not, call the business operation interface requested by the business request, so that the business side can perform the corresponding operation according to the business operation interface and update the third action state of the transaction state machine.
[0057] By using this embodiment, the transaction coordinator can avoid calling the business operation interface for abnormal business requests caused by network or server anomalies, filtering duplicate requests, correcting out-of-order requests, and filling in lost reporting issues that could lead to abnormal transaction status and business processing, thereby improving the fault tolerance of distributed transaction processing.
[0058] In one possible embodiment, the business request is sent from the business side to the transaction coordinator through an idempotent transaction interface.
[0059] It is understandable that a transaction interface is the interface through which a business sends a business request to the transaction coordinator, and an idempotent transaction interface can ensure that one or more requests for the same business request yield consistent results.
[0060] By selecting this embodiment, the idempotent nature of the transaction interface can be used to avoid abnormal business requests that could lead to abnormal business processing and transaction status, thereby further improving the fault tolerance of distributed transaction processing.
[0061] In distributed transaction processing, although the business logic is not sensitive to latency, the transaction coordinator needs to ensure timeliness and avoid transaction blocking. Based on this, this disclosure also provides a distributed transaction processing method, such as... Figure 4 As shown, it includes:
[0062] S401, classify multiple business requests into different types of business requests based on business type and transaction type.
[0063] The business type indicates the type of business that generates the business request, and the transaction type indicates the type of transaction requested by the business request. In actual business processing, the transaction coordinator often receives multiple business requests simultaneously. As mentioned earlier, each business request contains the specific content of the business (i.e., the business type) and the business operation interface requested by that business (i.e., the transaction type). Based on this, multiple business requests can be divided into different types of business requests for subsequent processing.
[0064] S402 arranges different types of business requests into the corresponding request queues.
[0065] The request queue is a queue divided according to the type of business request. After the request queue is divided according to the business request, each business request can be placed into the corresponding request queue according to its type.
[0066] S403 delivers multiple service requests to the same data center according to their corresponding request queues, and receives service requests from multiple request queues.
[0067] After queuing business requests into corresponding queues based on their types, the requests in each queue need to be sent to the data center for processing. Specifically, multiple business requests can be sent to the same data center for processing. At the same time, multiple business requests can be sent to the same data center according to their request queues, allowing the transaction coordinator to receive and process business requests in a more refined manner based on the different request queues, i.e., the different types of business requests. Sending multiple business requests to the same data center can also further reduce the processing latency of business requests.
[0068] In one possible implementation, higher-priority business requests can be queued into the same request queue, allowing the transaction coordinator to prioritize higher-priority business requests based on the queue.
[0069] By selecting this embodiment, business requests are finely broken down in terms of business and transaction dimensions, and the business requests are delivered to the same data center. The transaction coordinator then receives the business requests, which improves the efficiency of the transaction coordinator in receiving business requests and reduces the latency of business request processing.
[0070] In one possible embodiment, after determining that the business request is not an abnormal business request, it needs to be processed according to the business request. A single business request often triggers multiple actions. For example, if multiple preset execution steps of a certain business require compensation, then these multiple preset execution steps need to be compensated according to the compensation business operation interface. Therefore, a single business request sent by this business may include requests to multiple compensation business operation interfaces. When the transaction coordinator faces the simultaneous need to call multiple business operation interfaces, it may encounter difficulties in processing them in a timely manner. Based on this, this disclosure also provides a distributed transaction processing method, such as... Figure 5 As shown, it includes:
[0071] S501, obtain the current action state of the business state machine as the first action state.
[0072] This step is the same as S101 above, and you can refer to the relevant description of S101 above, so it will not be repeated here.
[0073] S502, call the first business operation interface corresponding to the first action state, so that the business side executes the corresponding operation by executing the first business operation interface.
[0074] This step is the same as S102 above, and you can refer to the relevant description of S102 above, so it will not be repeated here.
[0075] S503, update the state of the transaction state machine according to the result of the corresponding operation performed by the business end, and obtain the third action state of the transaction state machine.
[0076] This step is the same as S303 above, and you can refer to the relevant description of S303 above, so it will not be repeated here.
[0077] S504 receives business requests from the business side and obtains the context corresponding to the business requests.
[0078] This step is the same as S304 above, and you can refer to the relevant description of S304 above, so it will not be repeated here.
[0079] S505 determines whether a business request is an abnormal business request based on the context and the third action status.
[0080] This step is the same as S305 above, and you can refer to the relevant description of S305 above, so it will not be repeated here.
[0081] S506, if not, divide the business request into multiple first business messages based on the content contained in the business request.
[0082] At this point, it has been determined that the business request is not an abnormal business request. The business request can then be broken down according to its content. Taking the user payment order business in the online shopping application scenario as an example, if the execution of modifying the order status fails, the business side may send a business request, which may include operations such as compensation for modifying the order status, compensation for deducting inventory, and compensation for creating a sales order. In this case, the business request can be divided into the first business message of compensation for modifying the order status, the first business message of compensation for deducting inventory, and the first business message of compensation for creating a sales order according to its content.
[0083] S507 concurrently calls the business operation interfaces corresponding to multiple first business messages.
[0084] After splitting a business request into multiple first business messages, the transaction coordinator can concurrently call the business operation interface in sequence according to the specific content of each first business message to process the business request.
[0085] By using this embodiment, a business request can be split into multiple business messages, and the business operation interface can be called for the business messages in sequence according to their content. This allows multiple first business messages in a business request to be processed concurrently, improving the timeliness of business request processing.
[0086] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.
[0087] According to embodiments of this disclosure, this disclosure also provides a distributed transaction processing apparatus, such as... Figure 6 As shown, it includes:
[0088] The business state machine state acquisition module 601 is used to acquire the current action state of the business state machine as the first action state. The business state machine is a state machine that presents the business processing situation.
[0089] The first interface calling module 602 is used to call the first business operation interface corresponding to the first action state of the business state machine, so that the business end executes the operation corresponding to the first business operation interface.
[0090] In one possible embodiment, the device further includes:
[0091] The execution result acquisition module is used to acquire the execution results of each preset execution step of the business logic.
[0092] The business state machine state update module is used to update the current action state of the business state machine according to the execution result of the business, and obtain the second action state of the business state machine.
[0093] The second interface calling module is used to call the second business operation interface corresponding to the second action state of the business state machine, so that the business end executes the operation corresponding to the second business operation interface.
[0094] In one possible embodiment, the device further includes:
[0095] The transaction state machine state update module is used to update the state of the transaction state machine according to the result of the corresponding operation performed by the business terminal, and obtain the third action state of the transaction state machine. The transaction state machine is a state machine that presents the transaction processing status of the business terminal.
[0096] The business request receiving module is used to receive business requests from the business side and obtain the context corresponding to the business request.
[0097] The business request judgment module is used to determine whether the business request is an abnormal business request based on the context and the third action state; if so, it refuses to perform the operation based on the business request.
[0098] The business request processing module is used to, if not, call the business operation interface requested by the business request, so that the business terminal performs the corresponding operation according to the business operation interface and updates the third action state of the transaction state machine.
[0099] In one possible embodiment, the business request is sent from the business side to the transaction coordinator through an idempotent transaction interface.
[0100] In one possible embodiment, the service request determination module further includes:
[0101] A business request classification unit is used to classify multiple business requests into different types of business requests based on business type and transaction type, wherein the business type is used to indicate the type of business that generates the business request, and the transaction type is used to indicate the type of transaction requested by the business request;
[0102] The request queue partitioning module is used to place the different types of business requests into corresponding request queues, wherein the request queues are partitioned according to the type of the business request;
[0103] The service request delivery module is used to deliver multiple service requests to the same data center according to their corresponding request queues, and to receive service requests from multiple request queues.
[0104] In one possible embodiment, the service request processing module further includes:
[0105] A business message splitting unit is used to divide the business request into multiple first business messages according to the content contained in the business request, if not otherwise.
[0106] The business message processing unit is used to concurrently call multiple business operation interfaces corresponding to the first business message.
[0107] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.
[0108] Figure 7 A schematic block diagram of an example electronic device 700 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.
[0109] like Figure 7 As shown, device 700 includes a computing unit 701, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 702 or a computer program loaded from storage unit 708 into random access memory (RAM) 703. RAM 703 may also store various programs and data required for the operation of device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via bus 704. Input / output (I / O) interface 705 is also connected to bus 704.
[0110] Multiple components in device 700 are connected to I / O interface 705, including: input unit 706, such as keyboard, mouse, etc.; output unit 707, such as various types of monitors, speakers, etc.; storage unit 708, such as disk, optical disk, etc.; and communication unit 709, such as network card, modem, wireless transceiver, etc. Communication unit 709 allows device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.
[0111] The computing unit 701 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above, such as distributed transaction processing methods. For example, in some embodiments, the distributed transaction processing method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program can be loaded and / or installed on device 700 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by the computing unit 701, one or more steps of the distributed transaction processing method described above can be performed. Alternatively, in other embodiments, the computing unit 701 can be configured to perform distributed transaction processing methods by any other suitable means (e.g., by means of firmware).
[0112] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.
[0113] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.
[0114] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.
[0115] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).
[0116] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.
[0117] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.
[0118] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.
[0119] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.
Claims
1. A distributed transaction processing method, comprising: Obtain the current action state of the business state machine as the first action state, wherein the business state machine is a state machine that presents the business processing status; The first business operation interface corresponding to the first action state of the business state machine is invoked, so that the business terminal executes the operation corresponding to the first business operation interface. The transaction state machine is updated based on the result of the corresponding operation performed by the business terminal to obtain the third action state of the transaction state machine. The transaction state machine is a state machine that presents the transaction processing status of the business terminal. Receive a business request from the business side and obtain the context corresponding to the business request; The context of the service request is the processing process of the service requested by the service request; Based on the context and the third action state, it is determined whether the service request is an abnormal service request; the abnormal service request is a service request that has been executed and executed successfully. If so, refuse to operate according to the business request; If not, the business operation interface requested by the business request is invoked, so that the business terminal performs the corresponding operation according to the business operation interface and updates the third action state of the transaction state machine.
2. The method according to claim 1, further comprising: Obtain the execution results of each preset execution step of the business logic; Based on the execution result of the business, update the current action state of the business state machine to obtain the second action state of the business state machine; The second business operation interface corresponding to the second action state of the business state machine is invoked, so that the business terminal executes the operation corresponding to the second business operation interface.
3. The method according to claim 1, wherein, The business request is sent from the business side to the transaction coordinator through an idempotent transaction interface.
4. The method according to claim 1 or 3, wherein, Before determining whether the service request is an abnormal service request based on the context and the third action state, the method further includes: Multiple business requests are categorized into different types of business requests based on business type and transaction type, where the business type indicates the type of business that generates the business request, and the transaction type indicates the type of transaction requested by the business request. Each of the different types of business requests is placed into a corresponding request queue, wherein the request queue is a queue divided according to the type of the business request; Multiple service requests are delivered to the same data center according to their corresponding request queues, and service requests from multiple request queues are received.
5. The method according to any one of claims 1-3, wherein, If not, the business operation interface requested by the business request is invoked, including: If not, the service request will be divided into multiple first service messages based on the content contained in the service request; Concurrently call multiple business operation interfaces corresponding to the first business message.
6. The method according to claim 4, wherein, If not, the business operation interface requested by the business request is invoked, including: If not, the service request will be divided into multiple first service messages based on the content contained in the service request; Concurrently call multiple business operation interfaces corresponding to the first business message.
7. A distributed transaction processing apparatus, comprising: The business state machine state acquisition module is used to acquire the current action state of the business state machine as the first action state. The business state machine is a state machine that presents the business processing situation. The first interface calling module is used to call the first business operation interface corresponding to the first action state of the business state machine, so that the business end can execute the operation corresponding to the first business operation interface. The transaction state machine state update module is used to update the state of the transaction state machine according to the result of the corresponding operation performed by the business terminal, and obtain the third action state of the transaction state machine. The transaction state machine is a state machine that presents the transaction processing status of the business terminal. The business request receiving module is used to receive business requests from the business side and obtain the context corresponding to the business request; the context of the business request is the processing process of the business requested by the business request. The business request judgment module is used to determine whether the business request is an abnormal business request based on the context and the third action state. If so, refuse to operate according to the business request; the abnormal business request is a business request that has already been executed and executed successfully; The business request processing module is used to, if not, call the business operation interface requested by the business request, so that the business terminal performs the corresponding operation according to the business operation interface and updates the third action state of the transaction state machine.
8. The apparatus according to claim 7, further comprising: The execution result acquisition module is used to acquire the execution results of each preset execution step of the business logic. The business state machine state update module is used to update the current action state of the business state machine according to the execution result of the business, and obtain the second action state of the business state machine. The second interface calling module is used to call the second business operation interface corresponding to the second action state of the business state machine, so that the business end executes the operation corresponding to the second business operation interface.
9. The apparatus according to claim 7, wherein, The business request is sent from the business side to the transaction coordinator through an idempotent transaction interface.
10. The apparatus according to claim 7 or 9, wherein, The business request determination module also includes: A business request classification unit is used to classify multiple business requests into different types of business requests based on business type and transaction type, wherein the business type is used to indicate the type of business that generates the business request, and the transaction type is used to indicate the type of transaction requested by the business request; The request queue partitioning module is used to place the different types of business requests into corresponding request queues, wherein the request queues are partitioned according to the type of the business request; The service request delivery module is used to deliver multiple service requests to the same data center according to their corresponding request queues, and to receive service requests from multiple request queues.
11. The apparatus according to any one of claims 7-9, wherein, The business request processing module further includes: A business message splitting unit is used to divide the business request into multiple first business messages according to the content contained in the business request, if not otherwise. The business message processing unit is used to concurrently call multiple business operation interfaces corresponding to the first business message.
12. The apparatus according to claim 10, wherein, The business request processing module further includes: A business message splitting unit is used to divide the business request into multiple first business messages according to the content contained in the business request, if not otherwise. The business message processing unit is used to concurrently call multiple business operation interfaces corresponding to the first business message.
13. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-6.
14. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-6.
15. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-6.
Citation Information
Patent Citations
Message scheduling method and message scheduling device for message queues
CN105306277A
Distributed transaction processing method and device and transaction processor
CN110231980A
Distributed transaction processing method and device, computer equipment and storage medium
CN111857978A