Distributed transaction processing method, apparatus, and electronic device

Abstract

Embodiments of the present application provide a distributed transaction processing method, device and electronic equipment, the method comprises: when listening to the first service request second service in the to-be-processed business, acquiring thread information corresponding to the first service request second service, and setting the thread state corresponding to the first service to a suspended state; acquiring current available thread information from a transaction storage scheduling center; listening to the thread information corresponding to the first service request second service and the current available thread information, obtaining a listening result, and synchronizing the listening result to a backup server; and processing the second service and the first service according to the listening result, thereby realizing the to-be-processed business. The business is prevented from being in a locked state all the time, and the processing efficiency of the business is improved.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a distributed transaction processing method, apparatus and electronic device. Background Technology

[0002] Distributed transactions refer to transactions where the participants, supporter servers, resource servers, and transaction managers are located on different nodes of different distributed systems. Alternatively, it can be understood as a large operation consisting of different smaller operations distributed across different servers and belonging to different business applications.

[0003] In existing technologies, the implementation process of distributed transactions mainly includes two phases: a prepare phase and a commit phase. In the prepare phase, the transaction manager sends a prepare message to each participant. Each database participant executes the transaction locally and writes to its local undo / redo logs; at this stage, the transaction is not committed. In the commit phase, if the transaction manager receives a failure or timeout message from a participant, it directly sends a rollback message to each participant; otherwise, it sends a commit message. Participants can then execute commit or rollback operations according to the transaction manager's instructions and release the lock resources used during the transaction processing.

[0004] However, in this two-phase implementation, all participants are in a synchronous blocking state during the transaction commit phase, and if the coordinator fails, the corresponding business will remain locked, reducing the processing efficiency of the business and thus affecting the normal implementation of the business. Summary of the Invention

[0005] This invention provides a distributed transaction processing method, apparatus, and electronic device to ensure the normal operation of business processes.

[0006] In a first aspect, embodiments of the present invention provide a distributed transaction processing method, comprising:

[0007] When a request is received from the first service to the second service in a pending business process, the thread information corresponding to the request is obtained, and the thread state corresponding to the first service is set to the suspended state.

[0008] Obtain currently available thread information from the transaction storage scheduling center, and monitor the thread information corresponding to the first service requesting the second service and the currently available thread information to obtain the monitoring results, and synchronize the monitoring results to the backup server;

[0009] Based on the monitoring results, the second service and the first service are processed respectively, thereby realizing the pending business.

[0010] Optionally, the step of processing the second service and the first service respectively based on the monitoring results to realize the pending service includes:

[0011] If the monitoring result indicates that the currently available thread information is that the second service receives a request from the first service, the second service is processed, and when the processing of the second service is completed, the thread state corresponding to the currently available thread information is set to the completed state;

[0012] Set the thread state corresponding to the first service to a request state, and process the first service according to the request state to realize the pending business.

[0013] Optionally, the method further includes:

[0014] If the monitoring result indicates that the currently available thread information is occupied by a service other than the first service and the second service, then the state of the second service is set to suspended.

[0015] The status of the currently available thread information is determined at preset intervals, and when the currently available thread information is not occupied by other services, the currently available thread information is allocated to the second service and processed.

[0016] Optionally, the method further includes:

[0017] If the pending service is not completed within the preset time period, the backup server is started so that the backup server processes the second service and the first service respectively according to the monitoring results, thereby completing the pending service.

[0018] Optionally, before obtaining the currently available thread information from the transaction storage scheduling center, the method further includes:

[0019] The currently available thread information is determined based on the pre-stored dynamic routing load rules, wherein the currently available thread information is the thread information corresponding to at least one service;

[0020] The currently available thread information is stored in the transaction storage scheduling center.

[0021] Optionally, after obtaining the currently available thread information from the transaction storage scheduling center, the method further includes:

[0022] According to the zero-copy rule, the thread information corresponding to the first service requesting the second service and the currently available thread information are stored to the disk.

[0023] In a second aspect, embodiments of the present invention provide a distributed transaction processing apparatus, comprising:

[0024] The listening module is used to obtain the thread information corresponding to the first service requesting the second service in the pending business and set the thread state corresponding to the first service to a suspended state.

[0025] The processing module is used to obtain the currently available thread information from the transaction storage scheduling center, and to listen to the thread information corresponding to the first service requesting the second service and the currently available thread information, obtain the listening result, and synchronize the listening result to the backup server;

[0026] The processing module is further configured to process the second service and the first service respectively based on the monitoring results, thereby realizing the service to be processed.

[0027] Thirdly, embodiments of the present invention provide an electronic device, comprising: at least one processor and a memory;

[0028] The memory stores computer-executed instructions;

[0029] The at least one processor executes computer execution instructions stored in the memory, causing the at least one processor to perform the distributed transaction processing method as described in any of the first aspects.

[0030] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the distributed transaction processing method as described in any of the first aspects.

[0031] Fifthly, embodiments of the present invention provide a computer program product, including a computer program that, when executed by a processor, implements the distributed transaction processing method described in the first aspect and various possible designs of the first aspect.

[0032] This invention provides a distributed transaction processing method, apparatus, and electronic device. By employing the above scheme, when a first service requests a second service in a pending business transaction, the thread information corresponding to the first service requesting the second service is obtained, and the thread state corresponding to the first service is set to a suspended state. Then, the currently available thread information can be obtained from the transaction scheduling center, and the thread information corresponding to the first service requesting the second service and the currently available thread information are monitored to obtain the monitoring results. These results are then synchronized to a backup server. Based on the monitoring results, the second service and the first service are processed respectively, thereby realizing the pending business transaction. By monitoring the currently available thread information and the thread information corresponding to the first service requesting the second service in real time, and processing based on the monitoring results, the situation where all participants are in a synchronous blocking state is reduced. Furthermore, when the coordinator fails, processing can also be carried out through the backup server, avoiding the situation where the business is in a locked state, thus improving the processing efficiency of the business. Attached Figure Description

[0033] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0034] Figure 1 This is a schematic diagram illustrating the application of distributed transaction processing in the prior art, as provided in the embodiments of the present invention.

[0035] Figure 2 This is a flowchart illustrating the distributed transaction processing method provided in an embodiment of the present invention.

[0036] Figure 3 This is a schematic diagram illustrating the principle of the distributed transaction processing method provided in this embodiment of the invention.

[0037] Figure 4 This is a schematic diagram of the structure of a distributed transaction processing device provided in an embodiment of the present invention;

[0038] Figure 5 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0039] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0040] The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can also include other sequential examples besides those illustrated or described. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0041] With the development of internet technology, most internet companies decompose their systems into services, making service-oriented architecture increasingly popular. This leads to various transaction commit issues between services. Specifically, a pending business task can be broken down into multiple services. During the implementation of these tasks, the issue of committing transactions between these services arises. In existing technologies, the implementation of distributed transactions mainly includes two phases: a prepare phase and a commit phase.

[0042] Specifically, Figure 1 This is a schematic diagram illustrating the application of distributed transaction processing in the prior art provided by the embodiments of the present invention, such as... Figure 1 a and Figure 1As shown in Figure b, this represents the successful commit of a distributed transaction. During the Prepare phase, the transaction manager sends a Prepare message to each participant. Each database participant executes the transaction locally and writes to its local Undo / Redo logs. At this point, the transaction is not committed. (The Undo log records the data before modification, used for database rollback; the Redo log records the data after modification, used for writing to the data file after transaction commit.) During the Commit phase, if the transaction manager receives a participant's execution failure or timeout message, it directly sends a Rollback message to each participant; otherwise, it sends a Commit message. Participants execute the commit or rollback operation according to the transaction manager's instructions and release the lock resources used during transaction processing. It is crucial to release lock resources in the final phase. Figure 1 c and Figure 1 As shown in Figure d, this illustrates a scenario where a distributed transaction commit fails. Potential problems during the two-phase commit process include: all participants being in a synchronous, blocked state during the commit phase, consuming system resources and potentially leading to performance bottlenecks; if the coordinator experiences a single point of failure, or fails, the provider will remain locked. In the two-phase commit, if both the coordinator and participants fail, data inconsistency may occur, reducing processing efficiency and ultimately impacting the normal operation of the business.

[0043] Based on the above problems, this application achieves the technical effect of reducing the situation where all participants are in a synchronous blocking state, and also preventing the business from being locked in a continuous state when the coordinator fails, by monitoring the currently available thread information and the thread information corresponding to the first service requesting the second service in real time, and processing according to the monitoring results.

[0044] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0045] Figure 2 This is a flowchart illustrating a distributed transaction processing method provided in an embodiment of the present invention. The method in this embodiment can be executed by the master server. Figure 2 As shown, the method in this embodiment may include:

[0046] S201: When the first service in the pending business requests the second service, obtain the thread information corresponding to the first service requesting the second service, and set the thread state corresponding to the first service to the suspended state.

[0047] In this embodiment, the processing of the service to be processed may involve multiple services. These services interact in an orderly manner according to a preset interaction sequence, thereby realizing the service to be processed. In this embodiment, the example of the service to be processed including a first service and a second service is used for illustration. Of course, the inclusion of other numbers of services is also within the scope of protection of this application, and will not be discussed in detail here.

[0048] Furthermore, the status of the first service can be monitored in real time. When a request for the second service is detected from the first service, the thread information corresponding to the request can be obtained. This thread information may include the thread ID, thread name, and request status. For example, the request status may include initiated, pending, and completed status.

[0049] In addition, when a request from the first service to the second service is detected, the state of the thread corresponding to the first service can be set to a suspended state, that is, the first service is not processed first, and the first service is processed after the second service has finished processing.

[0050] S202: Obtain the currently available thread information from the transaction storage scheduling center, and listen to the thread information corresponding to the first service requesting the second service and the currently available thread information, obtain the listening results, and synchronize the listening results to the backup server.

[0051] In this embodiment, the actual storage scheduling center stores currently available thread information. After listening to the first service requesting the second service, the currently available thread information can be obtained from the actual storage scheduling center. Then, the thread information corresponding to the first service requesting the second service and the currently available thread information are listened to, and it is determined whether the currently available thread information is allocated to the thread corresponding to the first service requesting the second service, and the listening result is obtained.

[0052] Furthermore, after receiving the monitoring results, to prevent data loss due to primary server failure, the results can be synchronized to the backup server. Additionally, other data during the processing of pending business operations can also be synchronized to the backup server to ensure data consistency between the backup and primary servers.

[0053] S203: Process the second service and the first service respectively based on the monitoring results, and then realize the pending business.

[0054] In this embodiment, after obtaining the monitoring result, the second service and the first service can be processed sequentially according to the monitoring result, thereby realizing the business to be processed.

[0055] Furthermore, the specific process of processing the second service and the first service sequentially based on the monitoring results can be as follows:

[0056] If the monitoring result indicates that the currently available thread information is that the second service receives a request from the first service, the second service is processed, and upon completion of the second service processing, the thread state corresponding to the currently available thread information is set to the completed state.

[0057] Set the thread state corresponding to the first service to a request state, and process the first service according to the request state to realize the pending business.

[0058] Additionally, the method may also include:

[0059] If the monitoring result indicates that the currently available thread information is occupied by a service other than the first and second services, then the status of the second service will be set to suspended.

[0060] The status of the currently available thread information is determined at preset intervals, and when the currently available thread information is not occupied by other services, the currently available thread information is allocated to the second service and processed.

[0061] Specifically, the monitoring results can include two types. One is when the currently available thread information is occupied by the thread corresponding to the request received by the second service from the first service, that is, when the currently available thread information is that the second service receives the request from the first service, the second service can be processed, and when the second service completes the processing, the thread status corresponding to the currently available thread information is set to the completed state, which indicates that the second service has completed the processing, and the first service can continue to be processed based on the information after the second service has completed the processing.

[0062] Another monitoring result is that if the currently available thread information is occupied by other services besides the first and second services, that is, when the currently available thread information is occupied by other pending business, the second service cannot be processed temporarily, and its status can be set to suspended. Furthermore, the status of the currently available thread information is determined every preset time interval. If the currently available thread information is not occupied by other services, the currently available thread information is allocated to the second service, and the second service is processed. Upon completion of the second service, the thread status corresponding to the currently available thread information is set to completed.

[0063] By adopting the above scheme, when the first service in the pending business requests the second service, the thread information corresponding to the first service requesting the second service can be obtained, and the thread status corresponding to the first service can be set to a suspended state. Then, the currently available thread information can be obtained from the transaction scheduling center, and the thread information corresponding to the first service requesting the second service and the currently available thread information can be monitored to obtain the monitoring results. The monitoring results are synchronized to the backup server, and the second service and the first service are processed separately according to the monitoring results, thereby realizing the pending business. By monitoring the currently available thread information and the thread information corresponding to the first service requesting the second service in real time, and processing according to the monitoring results, the situation where all participants are in a synchronous blocking state is reduced. Moreover, when the coordinator fails, it can also be processed through the backup server, avoiding the situation where the business is in a locked state, thus improving the processing efficiency of the business.

[0064] based on Figure 2 In addition to the method described herein, this specification also provides some specific implementation schemes of the method, which will be described below.

[0065] Furthermore, in another embodiment, the method may further include:

[0066] If the pending service is not completed within the preset time period, the backup server is started so that the backup server can process the second service and the first service respectively according to the monitoring results, thereby completing the pending service.

[0067] In this embodiment, if the pending service is not completed within a preset time period, it indicates that the main server that implements the pending service may be faulty. In order to avoid affecting the normal implementation of the pending service, a backup server can be started. Since the data in the backup server is synchronized with the data in the main server in real time, the second service and the first service can be processed through the backup server, thereby realizing the pending service.

[0068] Furthermore, in another embodiment, before obtaining currently available thread information from the transaction storage scheduling center, the method may further include:

[0069] The currently available thread information is determined based on the pre-stored dynamic routing load rules, wherein the currently available thread information is the thread information corresponding to at least one service.

[0070] The currently available thread information is stored in the transaction storage scheduling center.

[0071] Furthermore, after obtaining the currently available thread information from the transaction storage scheduling center, it may also include:

[0072] According to the zero-copy rule, the thread information corresponding to the first service requesting the second service, as well as the currently available thread information, are stored on the disk.

[0073] In this embodiment, Figure 3 This is a schematic diagram illustrating the principle of the distributed transaction processing method provided in this embodiment of the invention, as shown below. Figure 3 As shown, it can include several specific modules such as transaction scheduling, transaction registry, transaction control center, transaction monitor, and transaction remoting.

[0074] Specifically, the transaction storage scheduling module is a component of the transaction control center. It primarily caches and stores the scheduling relationships between services, facilitating faster location of the current call chain. For example, when service A accesses service B, the transaction control center suspends the current thread (CPU context switching) and then persists the current thread to prevent data loss, waiting for service B to confirm and commit before executing the transaction commit for service A. The transaction storage scheduling service allocates a contiguous storage space on disk by default at startup, ensuring data order during persistence by the suspended thread and enabling efficient zero-copy reading. Transaction service discovery can be seen as the registry center of the entire framework, with two main functions: first, configuring the cluster's transaction control center and transaction storage scheduling service routing; second, obtaining real-time configuration information for two services, allowing other modules to access the transaction control center to obtain the latest service status and address. The transaction control center is primarily a controller for managing transaction storage scheduling and transaction monitoring, handling data storage and message reversal to various services after event listening. The transaction control center supports Master or Slave cluster modes. The cluster consists of multiple master-slave nodes and also provides a function to query whether downstream systems have confirmed their commits. The transaction monitoring module, a component of the transaction control center, primarily monitors the initiation of transactions between services. Using custom annotations, when service A calls service B, the service monitor records and tracks the current thread ID and request status, then passes the data to the transaction control center for processing. Specifically, when the service monitor detects that service A is calling service B, it obtains the current thread ID, thread name, request status, etc., and sends them to the transaction control center, which then caches and persists the data. When the downstream service confirms its commit, the monitoring center receives the instruction from the downstream system and sends a request to the service control center to inform it of the transaction commit status. The service communication module primarily uses Netty's underlying communication to implement interactions between all services.

[0075] When services communicate with each other, the Transaction Monitor transmits data to the Transaction Control Center. The Transaction Control Center then initiates two steps: first, it writes the current thread ID and request status into memory; second, it uses zero-copy technology to write the data to disk in a specific order, primarily to prevent data loss. Other services send instructions to the transaction service discovery center upon startup, transmitting current service information such as service name and address. The operation of the dynamic routing mechanism largely mimics the configuration of Gateway dynamic routing. By employing zero-copy technology, the CPU is prevented from copying data from one storage location to another. This mainly involves utilizing various zero-copy techniques to avoid the CPU performing extensive data copying tasks, reducing unnecessary copying, or allowing other components to handle these simple data transfer tasks, significantly saving time for disk and I / O interactions.

[0076] Additionally, when service A requests service B, the service listener obtains data such as the current thread ID, thread name, and request status (initiated) and sends it to the transaction control center. The service registration and discovery process determines which stages of the current transaction storage schedule are alive and available, and then dynamically routes the load to the specific transaction storage schedule center. The transaction storage schedule center then maintains and persists the current data. In cluster mode, the data is also synchronized to the slave. When service B receives the request, the service listener also listens for data such as the current request interface's thread ID, thread name, and request status (in progress). Once service B's thread has finished processing, the listener service writes back the current thread's request status as completed and adjusts service A's thread from suspended to normal.

[0077] This application leverages the service architecture features to enable bidirectional communication between services by referencing third-party plugins for current distributed transactions. It employs thread switching technology to achieve thread blocking and sends commands to the database to achieve transaction rollback. This ensures bidirectional communication between services and informs upstream and downstream systems of the transaction rollback status and whether the transaction has been committed. Theoretically, as long as bidirectional communication between services is guaranteed, the eventual consistency and timeliness of transactions can be accurately ensured, and high availability and multi-node deployment can be supported.

[0078] Based on the same idea, this specification also provides an apparatus corresponding to the above method. Figure 4 This is a schematic diagram of the structure of the distributed transaction processing device provided in an embodiment of the present invention, as shown below. Figure 4 As shown, it may include:

[0079] The listening module 401 is used to obtain the thread information corresponding to the first service requesting the second service when it hears the first service requesting the second service in the pending business, and to set the thread state corresponding to the first service to a suspended state.

[0080] The processing module 402 is used to obtain the currently available thread information from the transaction storage scheduling center, and to listen to the thread information corresponding to the first service requesting the second service and the currently available thread information, obtain the listening result, and synchronize the listening result to the backup server.

[0081] The processing module 402 is further configured to process the second service and the first service respectively based on the monitoring results, thereby realizing the service to be processed.

[0082] In this embodiment, the processing module 402 is further configured to:

[0083] If the monitoring result indicates that the currently available thread information is that the second service receives a request from the first service, the second service is processed, and upon completion of processing the second service, the thread state corresponding to the currently available thread information is set to the completed state.

[0084] Set the thread state corresponding to the first service to a request state, and process the first service according to the request state to realize the pending business.

[0085] In this embodiment, the processing module 402 is further configured to:

[0086] If the monitoring result indicates that the currently available thread information is occupied by a service other than the first service and the second service, then the state of the second service is set to suspended.

[0087] The status of the currently available thread information is determined at preset intervals, and when the currently available thread information is not occupied by other services, the currently available thread information is allocated to the second service and processed.

[0088] Furthermore, in another embodiment, the processing module 402 is also used for:

[0089] If the pending service is not completed within the preset time period, the backup server is started so that the backup server processes the second service and the first service respectively according to the monitoring results, thereby completing the pending service.

[0090] Furthermore, in another embodiment, the processing module 402 is also used for:

[0091] The currently available thread information is determined based on the pre-stored dynamic routing load rules, wherein the currently available thread information is the thread information corresponding to at least one service.

[0092] The currently available thread information is stored in the transaction storage scheduling center.

[0093] In this embodiment, the processing module 402 is further configured to:

[0094] According to the zero-copy rule, the thread information corresponding to the first service requesting the second service and the currently available thread information are stored to the disk.

[0095] The apparatus provided in this embodiment of the invention can achieve the above-mentioned... Figure 2 The methods in the embodiments shown are similar in principle and technical effect, and will not be described again here.

[0096] Figure 5 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention. For example... Figure 5 As shown, the device 500 provided in this embodiment includes at least one processor 501 and a memory 502. The processor 501 and the memory 502 are connected via a bus 503.

[0097] In a specific implementation, at least one processor 501 executes computer execution instructions stored in the memory 502, causing at least one processor 501 to execute the method in the above method embodiment.

[0098] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0099] In the above Figure 5 In the illustrated embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0100] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage.

[0101] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0102] This invention also provides a computer-readable storage medium storing computer-executable instructions. When a processor executes the computer-executable instructions, it implements the distributed transaction processing method described in the above method embodiments.

[0103] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the distributed transaction processing method described above.

[0104] The aforementioned computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0105] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0106] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0107] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A distributed transaction processing method, characterized in that, include: When a request is received from the first service to the second service in a pending business process, the thread information corresponding to the request is obtained, and the thread state corresponding to the first service is set to the suspended state. The currently available thread information is determined based on the pre-stored dynamic routing load rules, wherein the currently available thread information is the thread information corresponding to at least one service; Store the currently available thread information in the transaction storage scheduling center; The system obtains currently available thread information from the transaction storage and scheduling center, and listens to the thread information corresponding to the first service requesting the second service and the currently available thread information to obtain the listening results, and synchronizes the listening results to the backup server. Based on the monitoring results, the second service and the first service are processed respectively to realize the pending business; If the pending service is not completed within the preset time period, the backup server is started so that the backup server processes the second service and the first service respectively according to the monitoring results, thereby completing the pending service. The step of processing the second service and the first service respectively based on the monitoring results to realize the pending business includes: If the monitoring result indicates that the currently available thread information is that the second service receives a request from the first service, the second service is processed, and when the processing of the second service is completed, the thread state corresponding to the currently available thread information is set to the completed state; Set the thread state corresponding to the first service to a request state, and process the first service according to the request state to realize the pending business.

2. The method according to claim 1, characterized in that, The method further includes: If the monitoring result indicates that the currently available thread information is occupied by a service other than the first service and the second service, then the state of the second service is set to suspended. The status of the currently available thread information is determined at preset intervals, and when the currently available thread information is not occupied by other services, the currently available thread information is allocated to the second service and processed.

3. The method according to any one of claims 1-2, characterized in that, After obtaining the currently available thread information from the transaction storage scheduling center, the process also includes: According to the zero-copy rule, the thread information corresponding to the first service requesting the second service and the currently available thread information are stored to the disk.

4. A distributed transaction processing device, characterized in that, include: The listening module is used to obtain the thread information corresponding to the first service requesting the second service in the pending business and set the thread state corresponding to the first service to a suspended state. A processing module is used to determine currently available thread information based on pre-stored dynamic routing load rules, wherein the currently available thread information is thread information corresponding to at least one service; store the currently available thread information in a transaction storage and scheduling center; retrieve the currently available thread information from the transaction storage and scheduling center, and listen to the thread information corresponding to the first service requesting the second service and the currently available thread information, obtain the listening result, and synchronize the listening result to a backup server; if the pending business is not implemented within a preset time period, start the backup server so that the backup server processes the second service and the first service respectively according to the listening result, thereby implementing the pending business; wherein, processing the second service and the first service respectively according to the listening result to implement the pending business includes: if the listening result indicates that the currently available thread information is that the second service receives a request from the first service, processing the second service, and setting the thread state corresponding to the currently available thread information to a completed state when the second service is completed; setting the thread state corresponding to the first service to a requested state, and processing the first service according to the requested state, thereby implementing the pending business; The processing module is further configured to process the second service and the first service respectively based on the monitoring results, thereby realizing the service to be processed.

5. An electronic device, characterized in that, include: At least one processor and memory; The memory stores computer-executed instructions; The at least one processor executes the computer execution instructions stored in the memory, causing the at least one processor to perform the distributed transaction processing method as described in any one of claims 1 to 3.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, implement the distributed transaction processing method as described in any one of claims 1 to 3.

7. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the distributed transaction processing method as described in any one of claims 1 to 3.

Images