CN115390997A - Distributed transaction processing method and device and electronic equipment - Google Patents

Abstract

The embodiment of the invention provides a distributed transaction processing method, a distributed transaction processing device and electronic equipment, wherein the method comprises the steps of acquiring thread information corresponding to a first service requesting a second service when monitoring that the first service requests the second service in a service to be processed, setting a thread state corresponding to the first service to be a suspension state, acquiring currently available thread information from a service storage scheduling center, monitoring the thread information corresponding to the first service requesting the second service and the currently available thread information to obtain a monitoring result, synchronizing the monitoring result to a backup server, and respectively processing the second service and the first service according to the monitoring result so as to realize the service to be processed. The condition that the service is always in a locking state is avoided, and the service processing efficiency is improved.

Description

Distributed transaction processing method, device and electronic equipment

technical field

Embodiments of the present invention relate to the technical field of data processing, and in particular, to a distributed transaction processing method, device, and electronic equipment.

Background technique

A distributed transaction means that the participants of the transaction, the server of the supporter, the resource server, and the transaction manager are located on different nodes of different distributed systems, or it can be understood that a large operation is composed of different small operations. These small operations are distributed on different servers and belong to different business applications.

In the prior art, the implementation process of a distributed transaction may mainly include two phases, one is a prepare phase (Prepare Phase), and the other is a commit phase (Commit Phase). Correspondingly, in the preparation phase, the transaction manager sends a Prepare message to each participant, and each database participant executes the transaction locally and writes the local Undo/Redo log. At this time, the transaction is not committed. In the commit phase, if the transaction manager receives a participant's execution failure or timeout message, it will directly send a rollback (Rollback) message to each participant; otherwise, send a commit (Commit) message, and the participant can follow the transaction manager's The instruction executes a commit or rollback operation, and releases lock resources used during transaction processing.

However, for this implementation of the second phase, all participants are in a synchronous blocking state during the transaction submission phase, and if the coordinator fails, the corresponding business will always be locked, which reduces the processing efficiency of the business and affects normal operation of the business.

Contents of the invention

Embodiments of the present invention provide a distributed transaction processing method, device, and electronic equipment to ensure normal implementation of services.

In a first aspect, an embodiment of the present invention provides a distributed transaction processing method, including:

When listening to the first service requesting the second service in the business to be processed, obtaining the thread information corresponding to the first service requesting the second service, and setting the thread state corresponding to the first service to a suspended state;

Obtain currently available thread information from the transaction storage dispatch center, and monitor the corresponding thread information and the currently available thread information when the first service requests the second service, obtain a monitoring result, and store the monitoring result Synchronize to backup server;

The second service and the first service are respectively processed according to the monitoring result, so as to realize the service to be processed.

Optionally, processing the second service and the first service respectively according to the monitoring result, so as to realize the service to be processed, includes:

If the monitoring result is that the currently available thread information is that the second service receives the request of the first service, process the second service, and when the processing of the second service is completed, Setting the thread state corresponding to the currently available thread information to a completed state;

Setting the state of the thread corresponding to the first service as a request state, and processing the first service according to the request state, so as to realize the service to be processed.

Optionally, the method also includes:

If the monitoring result is that the currently available thread information is occupied by services other than the first service and the second service, then setting the state of the second service to a suspended state;

Determining the state of the currently available thread information every preset time period, and assigning the currently available thread information to the second service when the currently available thread information is not occupied by the other services, and The second service is processed.

Optionally, the method also includes:

If the service to be processed is not realized within the preset time length, start the backup server, so that the backup server processes the second service and the first service respectively according to the monitoring result, thereby realizing The business to be processed.

Optionally, before obtaining the currently available thread information from the transaction storage dispatch center, the method further includes:

Determine currently available thread information according to a prestored dynamic routing load rule, wherein the currently available thread information is thread information corresponding to at least one service;

Store the currently available thread information in the transaction storage dispatch center.

Optionally, after obtaining the currently available thread information from the transaction storage dispatch center, further include:

The thread information corresponding to when the first service requests the second service and the currently available thread information are stored in the disk according to the zero-copy rule.

In a second aspect, an embodiment of the present invention provides a distributed transaction processing device, including:

The monitoring module is configured to obtain thread information corresponding to the first service requesting the second service when the first service requesting the second service is detected in the business to be processed, and set the thread state corresponding to the first service to hang starting state;

A processing module, configured to obtain currently available thread information from the transaction storage scheduling center, and monitor the corresponding thread information and the currently available thread information when the first service requests the second service, obtain a monitoring result, and Synchronizing the monitoring result to a backup server;

The processing module is further configured to respectively process the second service and the first service according to the monitoring result, so as to realize the service to be processed.

In a third aspect, an embodiment of the present invention provides an electronic device, including: at least one processor and a memory;

the memory stores computer-executable instructions;

The at least one processor executes the computer-implemented instructions stored in the memory, so that the at least one processor executes the distributed transaction processing method according to any one of the first aspect.

In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium, where computer-executable instructions are stored in the computer-readable storage medium, and when the processor executes the computer-executable instructions, any one of the first aspects can be realized. The described distributed transaction processing method.

In the fifth aspect, an embodiment of the present invention provides a computer program product, including a computer program. When the computer program is executed by a processor, the distributed transaction processing described in the above first aspect and various possible designs of the first aspect is realized. method.

Embodiments of the present invention provide a distributed transaction processing method, device, and electronic equipment. After adopting the above scheme, when the first service request and the second service in the business to be processed are monitored, the first service request and the second service request can be obtained. The thread information corresponding to the time, and set the thread state corresponding to the first service to the suspended state, and then obtain the currently available thread information from the transaction scheduling center, and request the thread information corresponding to the second service for the first service and Monitor the currently available thread information, obtain the monitoring results, and synchronize the monitoring results to the backup server, and then process the second service and the first service respectively according to the monitoring results, and then realize the pending business. The information and the corresponding thread information when the first service requests the second service are monitored, and the method of processing according to the monitoring results reduces the situation that all participants are in a synchronous blocking state, and when the coordinator fails, it can also be passed The backup server is used for processing, which avoids the situation that the business is always locked, and improves the processing efficiency of the business.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings that need to be used in the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only These are some embodiments of the present invention. For those skilled in the art, other drawings can also be obtained according to these drawings without any creative effort.

FIG. 1 is an application schematic diagram of a distributed transaction processing process in the prior art provided by an embodiment of the present invention;

FIG. 2 is a schematic flowchart of a distributed transaction processing method provided by an embodiment of the present invention;

FIG. 3 is a schematic diagram of the principle of a distributed transaction processing method provided by an embodiment of the present invention;

FIG. 4 is a schematic structural diagram of a distributed transaction processing device provided by an embodiment of the present invention;

FIG. 5 is a schematic diagram of a hardware structure of an electronic device provided by an embodiment of the present invention.

Detailed ways

The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only some, not all, embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by persons of ordinary skill in the art without making creative efforts belong to the protection scope of the present invention.

The terms "first", "second", "third", "fourth", etc. (if any) in the description and claims of the present invention and the above drawings are used to distinguish similar objects and not necessarily Describe a specific order or sequence. It should be understood that the terms so used are interchangeable under appropriate circumstances such that the embodiments of the invention described herein are also capable of other sequential instances than those illustrated or described. Furthermore, the terms "comprising" and "having", as well as any variations thereof, are intended to cover a non-exclusive inclusion, for example, a process, method, system, product or device comprising a sequence of steps or elements is not necessarily limited to the expressly listed instead, may include other steps or elements not explicitly listed or inherent to the process, method, product or apparatus.

With the development of Internet technology, most Internet companies will split the system into services, and system service becomes more and more popular. During this period, there will be transaction submission problems between various services. That is, a pending business can be split into multiple services. In the process of realizing the pending business, the problem of submitting between services will be involved. In the existing technology, the implementation process of distributed transactions can mainly be It includes two phases, one is the prepare phase (Prepare phase), the other is the commit phase (commit phase).

Specifically, FIG. 1 is a schematic diagram of the application of the distributed transaction processing process in the prior art provided by the embodiment of the present invention, as shown in a in FIG. 1 and b in FIG. (Prepare phase), the transaction manager sends a Prepare message to each participant, each database participant executes the transaction locally, and writes the local Undo/Redo log, and the transaction is not committed at this time. (The Undo log is to record the data before modification, which is used for database rollback, and the Redo log is to record the modified data, which is used to write the data file after committing the transaction) In the commit phase (commitphase), if the transaction manager receives the participant When the execution fails or a timeout message, send a rollback (Rollback) message to each participant directly; otherwise, send a commit (Commit) message. Participants perform commit or rollback operations according to the instructions of the transaction manager, and release the lock resources used in the transaction process. Among them, the lock resource must be released in the final stage. As shown in c in Figure 1 and d in Figure 1, it is the case that the distributed transaction fails to commit. There may be problems in the two-phase commit process: all participants are in a synchronous blocking state during the transaction commit phase, which occupies system resources and is easy to lead to performance bottlenecks. If the coordinator is a single point of failure, or fails, the provider will remain locked. In the second stage, if both the coordinator and the participants hang up, it may cause data inconsistency, reduce the processing efficiency of the business, and affect the normal realization of the business.

Based on the above problems, this application monitors the currently available thread information and the corresponding thread information when the first service requests the second service in real time, and processes it according to the monitoring results, so as to reduce the need for all participants to be synchronized In the case of blocked state, and when the coordinator fails, it can also be processed by the backup server, avoiding the situation that the business is always locked, and improving the technical effect of business processing efficiency.

The technical solution of the present invention will be described in detail below with specific embodiments. The following specific embodiments may be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments.

FIG. 2 is a schematic flowchart of a distributed transaction processing method provided by an embodiment of the present invention, and the method of this embodiment may be executed by a master server. As shown in Figure 2, the method of this embodiment may include:

S201: Obtain thread information corresponding to the first service requesting the second service when it is detected that the first service requests the second service in the pending business, and set the thread state corresponding to the first service to a suspended state.

In this embodiment, during implementation of the service to be processed, multiple services may be involved, and the services interact with each other in an orderly manner according to a preset interaction sequence, so that the service to be processed can be realized. In this embodiment, an example is taken in which the service to be processed includes the first service and the second service. Of course, the manner of including other service quantities is also within the protection scope of the present application, and will not be discussed in detail here.

Furthermore, the status of the first service can be monitored in real time, and when the first service requests the second service, the thread information corresponding to the first service requesting the second service can be obtained, wherein the first service requests the second service The corresponding thread information may include a thread ID, a thread name, and a request status. Exemplarily, the request status may include an initiated status, a requesting status and a completed status.

In addition, when listening to the first service requesting the second service, the state of the thread corresponding to the first service can be set to a suspended state first, that is, the first service will not be processed first, and the second service will be processed after the second service is completed. A service for processing.

S202: Obtain the currently available thread information from the transaction storage scheduling center, and monitor the corresponding thread information and the currently available thread information when the first service requests the second service, obtain the monitoring result, and synchronize the monitoring result to the backup server .

In this embodiment, the currently available thread information is stored in the practice storage and dispatch center, and after listening to the request of the first service for the second service, the currently available thread information can be obtained from the practice storage and dispatch center, and then the first service Monitor the corresponding thread information when requesting the second service and the currently available thread information, judge whether the currently available thread information is assigned to the corresponding thread when the first service requests the second service, and obtain the monitoring result.

In addition, after obtaining the monitoring results, in order to avoid data loss caused by failure of the primary server, the monitoring results can be synchronized to the backup server. In addition, other data in the pending business process can also be synchronized to the backup server to ensure data consistency between the backup server and the master server.

S203: Process the second service and the first service respectively according to the monitoring result, so as to realize the service to be processed.

In this embodiment, after the monitoring result is obtained, the second service and the first service may be processed sequentially according to the monitoring result, so as to realize the service to be processed.

Further, the specific process of sequentially processing the second service and the first service according to the monitoring result may be as follows:

If the monitoring result is that the currently available thread information is the second service when the request for the first service is received, the second service is processed, and when the processing of the second service is completed, the currently available The thread state corresponding to the thread information is set to the completed state.

Setting the state of the thread corresponding to the first service as a request state, and processing the first service according to the request state, so as to realize the service to be processed.

In addition, the method may also include:

If the monitoring result is that the currently available thread information is occupied by services other than the first service and the second service, then the state of the second service is set to a suspended state;

Determining the state of the currently available thread information every preset time period, and assigning the currently available thread information to the second service when the currently available thread information is not occupied by the other services, and The second service is processed.

Specifically, the monitoring results may include two types, one is when the currently available thread information is occupied by the thread corresponding to the second service receiving the first service request, that is, the currently available thread information is the second service receiving the first service request. When a service request is requested, the second service can be processed, and when the second service processing is completed, the thread status corresponding to the currently available thread information is set to the completed state, which means that the second service has been processed, and the second service can be processed according to the second service. The information after the service processing is completed continued processing to the first service.

Another monitoring result is that when the currently available thread information is occupied by services other than the first service and the second service, that is, when the currently available thread information is occupied by other pending services, the second service cannot be processed temporarily, and you can The state of the second service is first set to a suspended state. And determine the state of the currently available thread information every preset time length, and when the currently available thread information is not occupied by other services, assign the currently available thread information to the second service, and process the second service, and When the processing of the second service is completed, the thread state corresponding to the currently available thread information is set as the completed state.

After adopting the above solution, when the first service requesting the second service in the pending business is monitored, the thread information corresponding to the first service requesting the second service can be obtained, and the thread state corresponding to the first service can be set to suspend state, and then obtain the currently available thread information from the transaction scheduling center, and monitor the corresponding thread information and the currently available thread information when the first service requests the second service, obtain the monitoring result, and synchronize the monitoring result to the backup The server then processes the second service and the first service respectively according to the monitoring results, and then realizes the business to be processed, and monitors the currently available thread information and the corresponding thread information when the first service requests the second service in real time, and according to The method of processing the monitoring results reduces the situation that all participants are in a synchronous blocking state, and when the coordinator fails, it can also be processed through the backup server, avoiding the situation that the business is always locked and improving the business. Processing efficiency.

Based on the method in FIG. 2 , the embodiment of this specification also provides some specific implementations of the method, which will be described below.

In addition, in another embodiment, the method may also include:

If the service to be processed is not realized within the preset time length, the backup server is started, so that the backup server processes the second service and the first service respectively according to the monitoring result, and then realizes the service to be processed.

In this embodiment, if the business to be processed is still not realized within the preset period of time, it indicates that the main server that realizes the business to be processed may be faulty. In order to avoid affecting the normal realization of the business to be processed, the backup server can be started. The data in the backup server is synchronized with the data in the main server in real time, therefore, the second service and the first service can be processed by the backup server, and then the service to be processed can be realized.

In addition, in another embodiment, before obtaining the currently available thread information from the transaction storage dispatch center, the method may further include:

Determine currently available thread information according to a prestored dynamic routing load rule, where the currently available thread information is thread information corresponding to at least one service.

Store the currently available thread information in the transaction storage dispatch center.

Further, after obtaining the currently available thread information from the transaction storage dispatch center, it may also include:

According to the zero-copy rule, the corresponding thread information when the first service requests the second service and the currently available thread information are stored in the disk.

In this embodiment, FIG. 3 is a schematic diagram of the principle of the distributed transaction processing method provided by the embodiment of the present invention. As shown in FIG. 3 , it may include transaction storage scheduling (Transaction Scheduling), transaction service discovery (TransactionRegistry), transaction control center Service (Transaction Control), transaction monitoring (Transaction Monitor) and service communication (Transaction Remoting) several specific modules.

Specifically, the transaction storage scheduling module is a component of the transaction control center, which is mainly used to cache and store the scheduling relationship between services, so as to facilitate faster positioning of the current calling link relationship. For example, when service A accesses service B, the transaction control center will suspend the current thread (CPU switches context), and then persist the current thread to prevent data loss, and wait for service B to confirm whether the submission is completed. Submit the A service transaction commit. The transaction storage scheduling service storage technology will open up a continuous storage space in the disk by default at startup, which can ensure the order of data when the suspended thread persists, and then use zero copy to read efficiently when reading. Transaction service discovery can be regarded as the registration center of the entire framework. It has two main functions. One is the transaction control center of the cluster and the routing configuration of the transaction storage scheduling service. The second is to obtain the real-time configuration information of the two services, and other modules obtain the latest service status and address by accessing the transaction control center. The transaction control center is mainly a controller that manages and controls transaction storage scheduling and transaction monitoring to handle data storage, and process processes such as reversing messages to various services after event monitoring. The transaction control center supports cluster mode Master or Slave. A cluster composed of multiple masters and slaves also provides the function of whether the downstream system confirms and submits the query. The transaction monitoring module is a component of the transaction control center, mainly to monitor the initiation between services, using custom annotations, when A service calls B service, the service monitoring will record and track the current thread ID status and request state, and then pass the data to the transaction control center for processing. Specifically, it can be monitored by the service that when A service calls B service, it will obtain the current thread ID, thread name, request status and other data and send it to the transaction control center, and the transaction control center will cache and persist the data. When the downstream service Confirm confirms the submission, the monitoring center will accept the downstream system instructions and initiate a request to the service control center to inform the online game transaction submission status. The service communication module can mainly realize the interaction between all services based on netty underlying communication.

Among them, when the service communicates with the service, the transaction monitor (Transaction Monitor) will pass the data to the transaction control center. At this time, the transaction control center will initiate two steps. The first step is to write the current Thread ID status and request status. The second step is to use zero-copy technology to write the data to the disk in a certain order, which is mainly to prevent data loss. When other services are started, they will send instructions to transaction service discovery and pass current service information such as service name, service address, etc. The operation of the dynamic routing mechanism can mainly imitate the configuration of Gateway dynamic routing. By adopting zero-copy technology, it is possible to prevent the CPU from copying data from one piece of storage to another piece of storage. Doing this kind of simple data transfer tasks can save a lot of time for the interaction between disk and IO.

In addition, when service A requests service B, the service monitor will obtain the current thread ID, thread name, request status (initiated) and other data and send them to the transaction control center, and the service registration will discover which stages are alive and available according to the current transaction storage scheduling Yes, and then dynamically route the load to the specific transaction storage scheduling center, then the transaction storage scheduling center will maintain and persist the current data, and if it is a cluster mode, it will also synchronize the data to the slave. When the B service receives the request, The service monitoring will also monitor the process ID, thread name, request status (in progress) and other data of the current request interface. After the B service thread is processed, the monitoring service will write back that the current thread request status has been completed, and send the A service thread Suspended state is adjusted to normal state.

This application uses the characteristics of the service architecture to use the current distributed transaction in the form of a third-party plug-in reference to enable the service to perform two-way communication, and uses the thread switching technology to achieve thread blocking and send instructions to the database to achieve the purpose of transaction rollback, both It can ensure two-way communication between services, and can also inform upstream and downstream systems of transaction return status and whether to commit transactions. In theory, as long as two-way communication between services is guaranteed, the final consistency and timeliness of transactions can be accurately guaranteed, and support High availability, multi-node deployment.

Based on the same idea, the embodiment of this specification also provides a device corresponding to the above method. FIG. 4 is a schematic structural diagram of a distributed transaction processing device provided by an embodiment of the present invention. As shown in FIG. 4 , it may include:

The monitoring module 401 is configured to obtain thread information corresponding to the first service requesting the second service when the first service requesting the second service in the pending business is monitored, and set the thread state corresponding to the first service to pending state.

The processing module 402 is configured to obtain currently available thread information from the transaction storage scheduling center, and monitor the corresponding thread information and the currently available thread information when the first service requests the second service, and obtain a monitoring result, And the monitoring result is synchronized to the backup server.

The processing module 402 is further configured to respectively process the second service and the first service according to the monitoring result, so as to realize the service to be processed.

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

If the monitoring result is that the currently available thread information is that the second service receives the request of the first service, process the second service, and when the processing of the second service is completed, Setting the thread state corresponding to the currently available thread information to a completed state.

Setting the state of the thread corresponding to the first service as a request state, and processing the first service according to the request state, so as to realize the service to be processed.

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

If the monitoring result is that the currently available thread information is occupied by services other than the first service and the second service, then setting the state of the second service to a suspended state.

Determining the state of the currently available thread information every preset time period, and assigning the currently available thread information to the second service when the currently available thread information is not occupied by the other services, and The second service is processed.

In addition, in another embodiment, the processing module 402 is further configured to:

If the service to be processed is not realized within the preset time length, start the backup server, so that the backup server processes the second service and the first service respectively according to the monitoring result, thereby realizing The business to be processed.

In addition, in another embodiment, the processing module 402 is further configured to:

Determine currently available thread information according to a prestored dynamic routing load rule, where the currently available thread information is thread information corresponding to at least one service.

Store the currently available thread information in the transaction storage dispatch center.

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

The thread information corresponding to when the first service requests the second service and the currently available thread information are stored in the disk according to the zero-copy rule.

The device provided by the embodiment of the present invention can implement the method of the above embodiment as shown in FIG. 2 , and its implementation principle and technical effect are similar, and will not be repeated here.

FIG. 5 is a schematic diagram of a hardware structure of an electronic device provided by an embodiment of the present invention. As shown in FIG. 5 , a device 500 provided in this embodiment includes: at least one processor 501 and a memory 502 . Wherein, the processor 501 and the memory 502 are connected through a bus 503 .

In a specific implementation process, at least one processor 501 executes the computer-executed instructions stored in the memory 502, so that at least one processor 501 executes the methods in the above method embodiments.

For the specific implementation process of the processor 501, reference may be made to the foregoing method embodiments. The implementation principles and technical effects thereof are similar, and details are not repeated here in this embodiment.

In the above-mentioned embodiment shown in FIG. 5, it should be understood that the processor can be a central processing unit (English: Central Processing Unit, referred to as: CPU), and can also be other general-purpose processors, digital signal processors (English: Digital Signal Processor, referred to as: DSP), application specific integrated circuit (English: Application Specific Integrated Circuit, referred to as: ASIC), etc. A general-purpose processor may be a microprocessor, or the processor may be any conventional processor, or the like. The steps of the method disclosed in conjunction with the invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.

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

The bus may be an Industry Standard Architecture (Industry Standard Architecture, ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (Extended Industry Standard Architecture, EISA) bus, etc. The bus can be divided into address bus, data bus, control bus and so on. For ease of representation, the buses in the drawings of the present application are not limited to only one bus or one type of bus.

The embodiment of the present invention also provides a computer-readable storage medium, the computer-readable storage medium stores computer-executable instructions, and when the processor executes the computer-executable instructions, the distributed transaction processing method of the above-mentioned method embodiment is implemented method.

An embodiment of the present invention also provides a computer program product, including a computer program. When the computer program is executed by a processor, the above-mentioned distributed transaction processing method is realized.

The above-mentioned computer-readable storage medium, the above-mentioned readable storage medium can be realized by any type of volatile or non-volatile storage device or their combination, 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 Memory, Flash Memory, Magnetic or Optical Disk. Readable storage media can be any available media that can be accessed by a general purpose or special purpose computer.

An exemplary readable storage medium is coupled to the processor such the processor can 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 may be located in application specific integrated circuits (Application Specific Integrated Circuits, ASIC for short). Of course, the processor and the readable storage medium can also exist in the device as discrete components.

Those of ordinary skill in the art can understand that all or part of the steps for implementing the above method embodiments can be completed by program instructions and related hardware. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps including the above-mentioned method embodiments; and the aforementioned storage medium includes: ROM, RAM, magnetic disk or optical disk and other various media that can store program codes.

Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present invention, rather than limiting them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: It is still possible to modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the technical solutions of the various embodiments of the present invention. scope.

Claims (10)

1. A distributed transaction processing method, characterized in that, comprising: When listening to the first service requesting the second service in the business to be processed, obtaining the thread information corresponding to the first service requesting the second service, and setting the thread state corresponding to the first service to a suspended state; Obtain currently available thread information from the transaction storage dispatch center, and monitor the corresponding thread information and the currently available thread information when the first service requests the second service, obtain a monitoring result, and store the monitoring result Synchronize to backup server; The second service and the first service are respectively processed according to the monitoring result, so as to realize the service to be processed. 2. The method according to claim 1, wherein the processing of the second service and the first service respectively according to the monitoring result, so as to realize the service to be processed, comprises: If the monitoring result is that the currently available thread information is that the second service receives the request of the first service, process the second service, and when the processing of the second service is completed, Setting the thread state corresponding to the currently available thread information to a completed state; Setting the state of the thread corresponding to the first service as a request state, and processing the first service according to the request state, so as to realize the service to be processed. 3. The method according to claim 2, wherein the method further comprises: If the monitoring result is that the currently available thread information is occupied by services other than the first service and the second service, then setting the state of the second service to a suspended state; Determining the state of the currently available thread information every preset time period, and assigning the currently available thread information to the second service when the currently available thread information is not occupied by the other services, and The second service is processed. 4. The method according to any one of claims 1-3, wherein the method further comprises: If the service to be processed is not realized within the preset time length, start the backup server, so that the backup server processes the second service and the first service respectively according to the monitoring result, thereby realizing The business to be processed. 5. The method according to any one of claims 1-3, wherein, before obtaining the currently available thread information from the transaction storage dispatch center, the method further comprises: Determine currently available thread information according to a prestored dynamic routing load rule, wherein the currently available thread information is thread information corresponding to at least one service; Store the currently available thread information in the transaction storage dispatch center. 6. The method according to any one of claims 1-3, characterized in that, after obtaining the currently available thread information from the transaction storage dispatch center, further comprising: The thread information corresponding to when the first service requests the second service and the currently available thread information are stored in the disk according to the zero-copy rule. 7. A distributed transaction processing device, characterized in that, comprising: The monitoring module is configured to obtain thread information corresponding to the first service requesting the second service when the first service requesting the second service is detected in the business to be processed, and set the thread state corresponding to the first service to hang starting state; A processing module, configured to obtain currently available thread information from the transaction storage scheduling center, and monitor the corresponding thread information and the currently available thread information when the first service requests the second service, obtain a monitoring result, and Synchronizing the monitoring result to a backup server; The processing module is further configured to respectively process the second service and the first service according to the monitoring result, so as to realize the service to be processed. 8. An electronic device, comprising: at least one processor and a memory; the memory stores computer-executable instructions; The at least one processor executes the computer-executed instructions stored in the memory, so that the at least one processor executes the distributed transaction processing method according to any one of claims 1 to 6. 9. A computer-readable storage medium, wherein computer-readable instructions are stored in the computer-readable storage medium, and when the processor executes the computer-executable instructions, the computer-readable storage medium according to any one of claims 1 to 6 can be implemented. The distributed transaction processing method described above. 10. A computer program product, comprising a computer program, characterized in that, when the computer program is executed by a processor, the distributed transaction processing method according to any one of claims 1 to 6 is implemented.

Images