Distributed transaction processing method, apparatus, device, and computer-readable storage medium

Abstract

The application discloses a distributed transaction processing method, device and equipment and a computer readable storage medium. The method comprises the following steps: when alarm information in an alarm Kafka cluster is received, obtaining business system information, routing layer application information and core layer cluster information corresponding to the alarm information; determining a transaction state of a distributed transaction corresponding to the alarm information according to the business system information, the routing layer application information and the core layer cluster information; determining whether the distributed transaction satisfies a preset compensation condition corresponding to a two-stage according to the transaction state; if the preset compensation condition is satisfied, executing a two-stage business corresponding to the distributed transaction. The application triggers the two-stage when the preset compensation condition is satisfied, and performs automatic compensation of the distributed transaction, so as to realize transaction compensation in the distributed transaction, and realize closed-loop processing of automatic compensation of the distributed transaction, the alarm information and the abnormal transaction.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, and particularly relates to a distributed transaction processing method and device, equipment and a computer readable storage medium. BACKGROUND

[0002] With the advent of the cloud era, cloud service applications have been rapidly popularized, and enterprises have become the norm to develop in the cloud. However, with the micro-service of applications, the consistency of transactions has become a higher challenge, especially in the financial field, where the consistency of transactions is required to be higher. With the micro-service of financial systems, the transaction integrity and the recovery timeliness of abnormal transactions have become problems that enterprises urgently need to solve.

[0003] At present, the conventional distributed transaction solutions include two-stage, TCC, local message table, three-stage, MQ message transaction, and maximum effort notification solutions. The existing solutions either implement eventual consistency, which is not high in timeliness and does not meet the timeliness of single transactions in the financial field, or lack a transaction compensation method for transaction processing in the two-stage exception.

[0004] Therefore, how to perform transaction compensation in a distributed transaction is a problem that needs to be solved at present. SUMMARY

[0005] The main purpose of the present application is to provide a distributed transaction processing method, device, equipment and computer readable storage medium, which aims to solve the technical problem of how to perform transaction compensation in a distributed transaction.

[0006] To achieve the above purpose, the present application provides a distributed transaction processing method, which comprises the following steps:

[0007] When receiving alarm information in an alarm Kafka cluster, obtaining business system information, routing layer application information and core layer cluster information corresponding to the alarm information;

[0008] According to the business system information, the routing layer application information and the core layer cluster information, determining the transaction state of the distributed transaction corresponding to the alarm information;

[0009] Based on the transaction state, determining whether the distributed transaction meets a preset compensation condition corresponding to the two-stage;

[0010] If the preset compensation condition is met, performing a two-stage business corresponding to the distributed transaction.

[0011] Further, the step of obtaining the business system information, the routing layer application information and the core layer cluster information corresponding to the alarm information comprises:

[0012] Query business system information, wherein the business system information includes middle office transaction information and set control information;

[0013] Query routing layer application information through transaction monitoring, wherein the routing layer application information includes TCC control information and set information;

[0014] The core layer cluster information is queried through an online transaction back-check method in the business system, wherein the core layer cluster information includes TCC control information and second-stage abnormal image information.

[0015] Furthermore, the step of determining whether the distributed transaction satisfies a preset compensation condition corresponding to the second phase based on the transaction status includes:

[0016] If the transaction status includes a completion status of the distributed transaction and a processing status of the core layer cluster / router, it is determined that the distributed transaction meets a preset compensation condition corresponding to the second phase.

[0017] Furthermore, when the alarm information in the alarm Kafka cluster is received, before the step of obtaining the business system information, routing layer application information, and core layer cluster information corresponding to the alarm information, the distributed transaction processing method further includes:

[0018] Upon receiving the first start signal corresponding to the critical path monitoring, the monitoring Kafka cluster determines whether the first end signal corresponding to the critical path monitoring is received within a preset time interval;

[0019] If the first end signal is not received within a preset time interval, the monitoring Kafka cluster sends an alarm message to the alarm Kafka cluster.

[0020] Furthermore, before the step of monitoring the Kafka cluster to determine whether a first end signal corresponding to the critical path monitoring is received within a preset time interval when the first start signal corresponding to the critical path monitoring is received, the distributed transaction processing method further includes:

[0021] When receiving a try request, the routing layer sends the first start signal corresponding to the critical path monitoring to the monitoring Kafka cluster;

[0022] When a confirm or cancel request is received, the first end signal corresponding to the critical path monitoring is sent to the monitoring Kafka cluster.

[0023] Further, before the step of receiving the alarm information in the alarm Kafka cluster, the distributed transaction processing method further comprises:

[0024] When a second start signal corresponding to the critical path monitoring is received, the monitoring Kafka cluster determines whether a second end signal corresponding to the critical path monitoring is received within a preset time interval;

[0025] If the second end signal is not received within the preset time interval, the monitoring Kafka cluster sends alarm information to the alarm Kafka cluster.

[0026] Further, before the step of receiving the alarm information in the alarm Kafka cluster, the distributed transaction processing method further comprises:

[0027] When a try request is received, the core layer in the core layer cluster sends a second start signal corresponding to the critical path monitoring to the monitoring Kafka cluster;

[0028] When a confirm or cancel request is received, the core layer sends a second end signal corresponding to the critical path monitoring to the monitoring Kafka cluster.

[0029] In addition, in order to achieve the above-mentioned purpose, the present application also provides a distributed transaction processing device, which comprises:

[0030] The acquisition module is configured to, when alarm information in the alarm Kafka cluster is received, acquire business system information, routing layer application information, and core layer cluster information corresponding to the alarm information;

[0031] The first determination module is configured to determine a transaction state of a distributed transaction corresponding to the alarm information according to the business system information, the routing layer application information, and the core layer cluster information;

[0032] The second determination module is configured to determine whether the distributed transaction satisfies a preset compensation condition corresponding to the two-stage based on the transaction state;

[0033] The compensation module is configured to, if the preset compensation condition is satisfied, execute a two-stage business corresponding to the distributed transaction.

[0034] In addition, to achieve the above-mentioned purpose, the present application also provides a distributed transaction processing device, which includes: a memory, a processor, and a distributed transaction processing program stored on the memory and capable of running on the processor. When the distributed transaction processing program is executed by the processor, the steps of the aforementioned distributed transaction processing method are implemented.

[0035] In addition, to achieve the above-mentioned purpose, the present application also provides a computer-readable storage medium, on which a distributed transaction processing program is stored. When the distributed transaction processing program is executed by a processor, the steps of the aforementioned distributed transaction processing method are implemented.

[0036] This application obtains the business system information, routing layer application information and core layer cluster information corresponding to the alarm information when receiving the alarm information in the alarm Kafka cluster; then determines the transaction status of the distributed transaction corresponding to the alarm information based on the business system information, routing layer application information and core layer cluster information; then determines whether the distributed transaction meets the preset compensation conditions corresponding to the second stage based on the transaction status; then executes the second stage business corresponding to the distributed transaction if the preset compensation conditions are met; determines the transaction status of the distributed transaction by obtaining the business system information, routing layer application information and core layer cluster information based on the alarm information, determines whether the preset compensation conditions corresponding to the second stage are met based on the transaction status of the distributed transaction, and triggers the second stage when the preset compensation conditions are met, and performs automatic compensation of the distributed transaction, so as to realize transaction compensation in the distributed transaction and realize closed-loop processing of distributed transactions, alarm information and automatic compensation of abnormal transactions. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0038] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0039] Figure 1 A flowchart of the first embodiment of the distributed transaction processing method of this application is provided;

[0040] Figure 2 This is a schematic diagram of the module structure of the distributed transaction processing device according to an embodiment of the present application;

[0041] Figure 3This is a schematic diagram of the module structure of the distributed transaction processing device according to an embodiment of the present application.

[0042] The realization of the objectives, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0043] It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0044] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0045] The main solution of this application is: when receiving alarm information in the alarm Kafka cluster, obtain the business system information, routing layer application information and core layer cluster information corresponding to the alarm information; determine the transaction status of the distributed transaction corresponding to the alarm information based on the business system information, routing layer application information and core layer cluster information; based on the transaction status, determine whether the distributed transaction meets the preset compensation conditions corresponding to the second stage; if the preset compensation conditions are met, execute the second stage business corresponding to the distributed transaction.

[0046] With the advent of the cloud era, cloud service applications are rapidly gaining popularity, and migrating to the cloud has become a common practice for enterprises. However, the shift to microservices in applications poses a greater challenge to transaction consistency, particularly in the financial sector, where consistency requirements are even higher. With the microservices of financial systems, ensuring transaction integrity and recovery time in the event of anomalies have become urgent challenges for enterprises.

[0047] Currently, conventional distributed transaction solutions include two-phase, TCC, local message tables, three-phase, MQ message transactions, and best-effort notifications. These existing solutions either achieve eventual consistency, resulting in low timeliness and failing to meet the timeliness requirements of individual transactions in the financial sector, or lack transaction compensation methods for exceptions in the second-phase processing. Therefore, implementing transaction compensation in distributed transactions is an urgent issue that needs to be addressed.

[0048] This application obtains business system information, routing layer application information and core layer cluster information based on alarm information to determine the transaction status of distributed transactions, determines whether the preset compensation conditions corresponding to the second stage are met based on the transaction status of distributed transactions, and triggers the second stage when the preset compensation conditions are met to perform automatic compensation of distributed transactions, so as to realize transaction compensation in distributed transactions and realize closed-loop processing of distributed transactions, alarm information and automatic compensation of abnormal transactions.

[0049] It should be noted that the execution entity of this embodiment may be a distributed transaction processing device, or a computing service device with data processing, network communication, and program execution capabilities, such as a tablet computer, personal computer, mobile phone, or a distributed transaction processing device capable of performing the aforementioned functions. This embodiment does not specifically limit this. This embodiment and the following embodiments will be described below using a distributed transaction processing device as the execution entity.

[0050] Based on this, this application proposes a distributed transaction processing method of the first embodiment, please refer to Figure 1 , the distributed transaction processing method includes steps S101 to S104:

[0051] Step S101: upon receiving alarm information from the alarm Kafka cluster, obtain the business system information, routing layer application information, and core layer cluster information corresponding to the alarm information;

[0052] In this embodiment, before the database transaction is committed or rolled back, the business layer sends a high-frequency monitoring start signal to the monitoring Kafka cluster through the online transaction SDK, and sends a try request to the routing layer; after the database transaction is committed or rolled back, the business layer sends a high-frequency monitoring end signal to the monitoring Kafka cluster through the online transaction SDK, and sends a confirm or cancel request to the routing layer.

[0053] When receiving a try request, the routing layer sends a critical path monitoring start signal (the first start signal) to the monitoring Kafka cluster. At the same time, the routing layer transaction starts and forwards the try request to the core layer cluster. When receiving a confirm or cancel request, the routing layer sends a critical path monitoring end signal (the first end signal) to the monitoring Kafka cluster and forwards the confirm or cancel request to the core layer cluster. The routing layer transaction ends.

[0054] Upon receiving a try request, the core layer in the core layer cluster sends a critical path monitoring start signal (the second start signal) to the monitoring Kafka cluster, beginning the core layer transaction. Upon receiving a confirm or cancel request, the core layer in the core layer cluster sends a critical path monitoring end signal (the second end signal) to the monitoring Kafka cluster, ending the core layer transaction. The core layers in the core layer cluster may include Core Layer 1, Core Layer 2, and Core Layer 3.

[0055] The monitoring Kafka cluster determines whether an alarm currently exists based on the received critical path monitoring start signal and the critical path monitoring end signal, and sends an alarm message to the alarm Kafka cluster when an alarm exists.

[0056] In this embodiment, the distributed transaction processing device subscribes to the alarm Kafka cluster information to receive the alarm information in the alarm Kafka cluster. When the alarm information is received, the business system information, routing layer application information and core layer cluster information corresponding to the alarm information are obtained, that is, the business system information, routing layer application information and core layer cluster information of the distributed transaction, wherein the business system information includes the middle-end transaction information and set control information; the routing layer application information includes TCC control information and set information; the core layer cluster information includes TCC control information and second-stage abnormal image information.

[0057] In a feasible implementation, step S101 may include steps S1011 to S1013:

[0058] Step S1011, querying business system information, wherein the business system information includes middle platform transaction information and set control information;

[0059] Step S1012: querying routing layer application information through transaction monitoring, wherein the routing layer application information includes TCC control information and set information;

[0060] Step S1013 , querying the core layer cluster information through the online transaction back-checking method in the business system, wherein the core layer cluster information includes TCC control information and second-stage abnormal image information.

[0061] In this embodiment, when an alarm message is received from the alarm Kafka cluster, the business system information is queried, wherein the business system information includes the middle-end transaction information and the set control information. Specifically, for example, WMD2 is called to query the middle-end transaction information and the set control information. Routing layer application information is queried through transaction monitoring, wherein the routing layer application information includes TCC control information and the set information. For example, transaction monitoring WMM5 is called to query TCC control information and the set information. At the same time, the core layer cluster information is queried through the online transaction retrieval method in the business system, wherein the core layer cluster information includes TCC control information and the second-stage abnormal image information. For example, the retrieval method (retrieval method) of the online transaction in the business system is called to query TCC control information and the second-stage abnormal image information.

[0062] Step S102: determining the transaction status of the distributed transaction corresponding to the alarm information based on the business system information, the routing layer application information, and the core layer cluster information;

[0063] In this embodiment, after obtaining the business system information, routing layer application information and core layer cluster information, the transaction status of the distributed transaction corresponding to the alarm information is determined based on the business system information, routing layer application information and core layer cluster information. Specifically, whether the alarm information is accurate is determined based on the routing layer application information and the core layer cluster information. For example, if the alarm information is that the monitoring Kafka cluster does not receive the first end signal within a preset time interval after receiving the first start signal, then it is determined based on the layer application information and the core layer cluster information whether the first end signal is received after the preset time interval. If not, the alarm information is determined to be accurate. If received, the alarm information is determined to be inaccurate. If the alarm information is that the monitoring Kafka cluster does not receive the second end signal within a preset time interval after receiving the second start signal, then it is determined based on the layer application information and the core layer cluster information whether the second end signal is received after the preset time interval. If not, the alarm information is determined to be inaccurate. The information is accurate. If it is received, it is determined that the alarm information is inaccurate. After determining that the alarm information is accurate, the transaction status of the distributed transaction is determined based on the business system information, the routing layer application information and the core layer cluster information. The transaction status includes the processing status of the distributed transaction, the processing status of the core layer, and the processing status of the routing layer. For example, the processing status of the distributed transaction includes incomplete (processing) and completed status (that is, the business system information contains the completion information of the distributed transaction), the processing status of the routing layer includes incomplete (processing) and completed status (that is, the routing layer application information contains the completion information of the distributed transaction), and the processing status of the core layer includes incomplete (processing) and completed status (that is, the core layer cluster information contains the completion information of the distributed transaction).

[0064] Step S103: determining whether the distributed transaction satisfies a preset compensation condition corresponding to the second phase based on the transaction status;

[0065] In this embodiment, after obtaining the transaction status, it is determined whether the distributed transaction meets the preset compensation conditions corresponding to the second phase. Specifically, based on the processing status of the distributed transaction, the processing status of the core layer, and the processing status of the routing layer in the transaction status, it is determined whether the current distributed transaction meets the preset compensation conditions corresponding to the second phase. Specifically, in a feasible implementation, step S103 may include step S1031:

[0066] Step S1031: If the transaction status includes the completion status of the distributed transaction and the processing status of the core layer cluster / router, it is determined that the distributed transaction meets the preset compensation condition corresponding to the second phase.

[0067] In this embodiment, after obtaining the transaction status, it is first determined whether the processing status of the distributed transaction is a completed state. If the processing status of the distributed transaction is a completed state, it is determined whether the processing status of the routing layer in the transaction status is a processing state, or whether there is a core layer in the core layer cluster whose processing status is a processing state. If the processing status of the routing layer in the transaction status is a processing state or there is a core layer with a processing status of a processing state, it is determined that the distributed transaction meets the preset compensation conditions corresponding to the second stage.

[0068] Step S104: If the preset compensation condition is met, the second-phase business corresponding to the distributed transaction is executed.

[0069] In this embodiment, if the distributed transaction meets the disorder compensation condition, the two-phase business corresponding to the distributed transaction is executed to realize transaction compensation in the distributed transaction, and realize closed-loop processing of distributed transactions, alarm information and automatic compensation of abnormal transactions.

[0070] The distributed transaction processing method proposed in this embodiment obtains the business system information, routing layer application information and core layer cluster information corresponding to the alarm information when receiving the alarm information in the alarm Kafka cluster; then determines the transaction status of the distributed transaction corresponding to the alarm information based on the business system information, routing layer application information and core layer cluster information; then determines whether the distributed transaction meets the preset compensation conditions corresponding to the second stage based on the transaction status; then executes the second stage business corresponding to the distributed transaction if the preset compensation conditions are met; determines the transaction status of the distributed transaction by obtaining the business system information, routing layer application information and core layer cluster information based on the alarm information, determines whether the preset compensation conditions corresponding to the second stage are met based on the transaction status of the distributed transaction, and triggers the second stage when the preset compensation conditions are met to perform automatic compensation of the distributed transaction, so as to realize transaction compensation in the distributed transaction and realize closed-loop processing of distributed transactions, alarm information and automatic compensation of abnormal transactions.

[0071] In a feasible implementation, before step S101, the distributed transaction processing method may further include steps S201 to S202:

[0072] Step S201: upon receiving a first start signal corresponding to a critical path monitoring, monitoring the Kafka cluster to determine whether a first end signal corresponding to the critical path monitoring is received within a preset time interval;

[0073] Step S202: If the first end signal is not received within a preset time interval, the monitoring Kafka cluster sends an alarm message to the alarm Kafka cluster.

[0074] In this embodiment, during the execution of a distributed transaction, after the routing layer receives a try request, it sends a first start signal corresponding to the critical path monitoring to the monitoring Kafka cluster. Upon receiving the first start signal corresponding to the critical path monitoring, the monitoring Kafka cluster begins timing to determine whether it has received a first end signal corresponding to the critical path monitoring within a preset time interval. If the first end signal is not received within the preset time interval, the monitoring Kafka cluster sends an alarm to the alarm Kafka cluster.

[0075] In a feasible implementation, before step S201, the distributed transaction processing method may further include steps S203 to S204:

[0076] Step S203: upon receiving the try request, the routing layer sends a first start signal corresponding to the critical path monitoring to the monitoring Kafka cluster;

[0077] Step S204: When a confirm or cancel request is received, a first end signal corresponding to the critical path monitoring is sent to the monitoring Kafka cluster.

[0078] In this embodiment, before the database transaction is committed or rolled back, the business layer sends a high-frequency monitoring start signal to the monitoring Kafka cluster through the online transaction SDK, and sends a try request to the routing layer; upon receiving the try request, the routing layer sends a critical path monitoring start signal (first start signal) to the monitoring Kafka cluster, and at the same time the routing layer transaction starts and forwards the try request to the core layer cluster.

[0079] After a database transaction commits or rolls back, the business layer sends a high-frequency monitoring end signal to the monitoring Kafka cluster via the online transaction SDK and sends a confirm or cancel request to the routing layer. Upon receiving a confirm or cancel request, the routing layer sends a critical path monitoring end signal (the first end signal) to the monitoring Kafka cluster and forwards the confirm or cancel request to the core layer cluster, thus ending the routing layer transaction.

[0080] The preset time interval can be set reasonably, for example, the preset time interval is 2 seconds.

[0081] The distributed transaction processing method proposed in this embodiment, when receiving the first start signal corresponding to the critical path monitoring, monitors the Kafka cluster to determine whether the first end signal corresponding to the critical path monitoring is received within a preset time interval; then if the first end signal is not received within the preset time interval, the monitoring Kafka cluster sends an alarm message to the alarm Kafka cluster, determines the alarm message in the distributed transaction processing process according to the start signal and end signal of the routing layer, aggregates the integrity of the transaction according to the monitoring signal through the bypass monitoring data sent during the transaction process, and issues an alarm for transactions that are not completed within the configured time range, has zero impact on the business process and has high stability, the monitoring is unaware of the business system and does not affect the business process, and at the same time, the interval time (preset time interval) of the transactions to be monitored can be adjusted through configuration to improve the timeliness of data monitoring.

[0082] In a feasible implementation, before step S101, the distributed transaction processing method may further include steps S301 to S302:

[0083] Step S301: upon receiving a second start signal corresponding to the critical path monitoring, monitoring the Kafka cluster to determine whether a second end signal corresponding to the critical path monitoring is received within a preset time interval;

[0084] Step S302: If the second end signal is not received within a preset time interval, the monitoring Kafka cluster sends an alarm message to the alarm Kafka cluster.

[0085] In this embodiment, during the execution of a distributed transaction, after a core layer in the core layer cluster receives a try request, each core layer sends a second start signal corresponding to critical path monitoring to the monitoring Kafka cluster. Upon receiving the second start signal corresponding to the critical path monitoring, the monitoring Kafka cluster begins timing to determine whether a second end signal corresponding to the critical path monitoring is received within a preset time interval. If the second end signal is not received within the preset time interval, the monitoring Kafka cluster sends an alarm to the alarm Kafka cluster.

[0086] In a feasible implementation, before step S301, the distributed transaction processing method may further include steps S303 to S304:

[0087] Step S303: upon receiving the try request, the core layer in the core layer cluster sends a second start signal corresponding to the critical path monitoring to the monitoring Kafka cluster;

[0088] In step S304, upon receiving a confirm or cancel request, the core layer sends a second end signal corresponding to the critical path monitoring to the monitoring Kafka cluster.

[0089] In this embodiment, before a database transaction commits or rolls back, the business layer sends a high-frequency monitoring start signal to the monitoring Kafka cluster via the online transaction SDK and sends a try request to the routing layer. Upon receiving the try request, the routing layer sends a critical path monitoring start signal (the first start signal) to the monitoring Kafka cluster, simultaneously starting the routing layer transaction and forwarding the try request to the core layer cluster. Upon receiving the try request, each core layer in the core layer cluster sends a second start signal corresponding to the critical path monitoring to the monitoring Kafka cluster.

[0090] After a database transaction is committed or rolled back, the business layer sends a high-frequency monitoring end signal to the monitoring Kafka cluster via the online transaction SDK and sends a confirm or cancel request to the routing layer. Upon receiving a confirm or cancel request, the routing layer sends a critical path monitoring end signal (the first end signal) to the monitoring Kafka cluster and forwards the confirm or cancel request to the core layer cluster, thus completing the routing layer transaction. Upon receiving a confirm or cancel request, the core layer sends a corresponding second end signal for the critical path monitoring to the monitoring Kafka cluster.

[0091] The preset time interval can be set reasonably, for example, the preset time interval is 2 seconds.

[0092] The distributed transaction processing method proposed in this embodiment, when receiving the second start signal corresponding to the critical path monitoring, monitors the Kafka cluster to determine whether the second end signal corresponding to the critical path monitoring is received within a preset time interval; then if the second end signal is not received within the preset time interval, the monitoring Kafka cluster sends an alarm message to the alarm Kafka cluster; by determining the alarm information in the distributed transaction processing process according to the start signal and end signal of the core layer, through the bypass monitoring data sent during the transaction process, the integrity of the transaction is aggregated according to the monitoring signal, and an alarm is issued for transactions that are not completed beyond the configured time range, which has zero impact on the business process and high stability, and the monitoring is unaware of the business system and does not affect the business process. At the same time, the interval time (preset time interval) of the transactions to be monitored can be adjusted through configuration to improve the timeliness of data monitoring.

[0093] The present application also provides a distributed transaction processing device, please refer to Figure 2 , the distributed transaction processing device includes:

[0094] Acquisition module 10 is used to obtain the business system information, routing layer application information and core layer cluster information corresponding to the alarm information when receiving the alarm information in the alarm Kafka cluster;

[0095] A first determining module 20 is configured to determine the transaction status of the distributed transaction corresponding to the alarm information based on the business system information, the routing layer application information, and the core layer cluster information;

[0096] A second determination module 30 is configured to determine, based on the transaction status, whether the distributed transaction satisfies a preset compensation condition corresponding to the second phase;

[0097] The compensation module 40 is configured to execute the second-phase service corresponding to the distributed transaction if the preset compensation condition is met.

[0098] The distributed transaction processing apparatus provided in the embodiments of this application utilizes the distributed transaction processing method of the aforementioned embodiments to address the technical problem of how to perform transaction compensation within distributed transactions. Compared to the prior art, the distributed transaction processing apparatus provided in the embodiments of this application achieves the same beneficial effects as the distributed transaction processing method provided in the aforementioned embodiments. Other technical features of the distributed transaction processing apparatus are the same as those disclosed in the aforementioned embodiments and are not further detailed here.

[0099] The present application provides a distributed transaction processing device, which includes: at least one processor; and 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, and the instructions are executed by the at least one processor to enable the at least one processor to execute the distributed transaction processing method in the above-mentioned embodiment one.

[0100] Reference below Figure 3 , which shows a schematic diagram of the structure of a distributed transaction processing device suitable for implementing embodiments of the present application. The distributed transaction processing device in the embodiments of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 3 The distributed transaction processing device shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0101] like Figure 3 As shown, the distributed transaction processing device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes based on programs stored in a read-only memory (ROM) 1002 or programs loaded from a storage device 1003 into a random access memory (RAM) 1004. RAM 1004 also stores various programs and data required for the operation of the distributed transaction processing device. Processing device 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems may be connected to I / O interface 1006: input devices 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage device 1003 including, for example, a magnetic tape, hard disk, etc.; and communication devices 1009. The communication device 1009 can allow the distributed transaction processing device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows a distributed transaction processing device with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems can be implemented or have alternatively.

[0102] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0103] The distributed transaction processing device provided in this application utilizes the distributed transaction processing method of the aforementioned embodiment to solve the technical problem of how to perform transaction compensation within distributed transactions. Compared to the prior art, the distributed transaction processing device provided in this application achieves the same beneficial effects as the distributed transaction processing method of the aforementioned embodiment. Other technical features of this distributed transaction processing device are the same as those disclosed in the aforementioned embodiment and are not further elaborated here.

[0104] It should be understood that various aspects of the disclosure can be implemented in hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any appropriate manner in any one or more embodiments or examples.

[0105] The above description is merely illustrative of the application and is not intended to limit the scope of the application. Any variations and modifications that can be made by any person skilled in the art within the spirit and scope of the application are intended to be encompassed by the application. The scope of the application is defined by the appended claims.

[0106] The application provides a computer readable storage medium having stored thereon computer readable program instructions (i.e., a computer program) for performing the distributed transaction processing method in the above embodiments.

[0107] The computer readable storage medium provided by the application may, for example, be a U disk, but is not limited to an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, system, or device, or any combination thereof. More specific examples of the computer readable storage medium can include, but are not limited to, an electrical connection having one or more conductive wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any appropriate combination of the above. In the present embodiment, the computer readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer readable storage medium can be transmitted in any appropriate medium, including but not limited to electrical wire, optical cable, RF (Radio Frequency), etc., or any appropriate combination thereof.

[0108] The above computer readable storage medium can be included in the distributed transaction processing device; or can exist separately and not be assembled into the distributed transaction processing device.

[0109] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by a distributed transaction processing device, the distributed transaction processing device: when receiving the alarm information in the alarm Kafka cluster, obtains the business system information, routing layer application information and core layer cluster information corresponding to the alarm information; determines the transaction status of the distributed transaction corresponding to the alarm information based on the business system information, routing layer application information and core layer cluster information; based on the transaction status, determines whether the distributed transaction meets the preset compensation conditions corresponding to the second stage; if the preset compensation conditions are met, executes the second stage business corresponding to the distributed transaction.

[0110] Computer program code for performing the operations of the present application may be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0111] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0112] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0113] The computer-readable storage medium provided in this application stores computer-readable program instructions (i.e., a computer program) for executing the above-described distributed transaction processing method, thereby resolving the technical problem of how to perform transaction compensation in distributed transactions. Compared to the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the distributed transaction processing method provided in the above-described embodiments, and are not further elaborated here.

[0114] An embodiment of the present application provides a computer program product, including a computer program, which implements the steps of the above-mentioned distributed transaction processing method when executed by a processor.

[0115] The computer program product provided in this application can solve the technical problem of how to perform transaction compensation in distributed transactions. Compared with the prior art, the beneficial effects of the computer program product provided in the embodiments of this application are the same as the beneficial effects of the distributed transaction processing method provided in the above embodiments, and will not be repeated here.

[0116] The above are only preferred embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the description and drawings of this application, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A distributed transaction processing method, characterized in that: The distributed transaction processing method comprises the following steps: When receiving the alarm information in the alarm Kafka cluster, obtain the business system information, routing layer application information and core layer cluster information corresponding to the alarm information; Determine the transaction status of the distributed transaction corresponding to the alarm information based on the business system information, routing layer application information, and core layer cluster information; Based on the transaction status, determining whether the distributed transaction satisfies a preset compensation condition corresponding to the second phase, wherein, after obtaining the transaction status, determining whether the processing status of the distributed transaction is a completed state; if the processing status of the distributed transaction is a completed state, determining whether the processing status of the routing layer in the transaction status is a processing state, or whether there is a core layer in the core layer cluster with a processing state in the processing state; if the processing status of the routing layer in the transaction status is a processing state or there is a core layer with a processing state in the processing state, determining that the distributed transaction satisfies the preset compensation condition corresponding to the second phase; If the preset compensation condition is met, executing the second phase business corresponding to the distributed transaction; The step of obtaining the business system information, routing layer application information, and core layer cluster information corresponding to the alarm information includes: Query business system information, wherein the business system information includes middle office transaction information and set control information; Query routing layer application information through transaction monitoring, wherein the routing layer application information includes TCC control information and set information; The core layer cluster information is queried through an online transaction back-check method in the business system, wherein the core layer cluster information includes TCC control information and second-stage abnormal image information.

2. The distributed transaction processing method according to claim 1, wherein: When the alarm information in the alarm Kafka cluster is received, before the step of obtaining the business system information, routing layer application information, and core layer cluster information corresponding to the alarm information, the distributed transaction processing method further includes: Upon receiving the first start signal corresponding to the critical path monitoring, the monitoring Kafka cluster determines whether the first end signal corresponding to the critical path monitoring is received within a preset time interval; If the first end signal is not received within a preset time interval, the monitoring Kafka cluster sends an alarm message to the alarm Kafka cluster.

3. The distributed transaction processing method according to claim 2, wherein: Before the step of monitoring the Kafka cluster to determine whether a first end signal corresponding to the critical path monitoring is received within a preset time interval upon receiving the first start signal corresponding to the critical path monitoring, the distributed transaction processing method further includes: When receiving a try request, the routing layer sends the first start signal corresponding to the critical path monitoring to the monitoring Kafka cluster; When a confirm or cancel request is received, the first end signal corresponding to the critical path monitoring is sent to the monitoring Kafka cluster.

4. The distributed transaction processing method according to any one of claims 1 to 3, wherein: When the alarm information in the alarm Kafka cluster is received, before the step of obtaining the business system information, routing layer application information, and core layer cluster information corresponding to the alarm information, the distributed transaction processing method further includes: Upon receiving the second start signal corresponding to the critical path monitoring, the monitoring Kafka cluster determines whether the second end signal corresponding to the critical path monitoring is received within a preset time interval; If the second end signal is not received within a preset time interval, the monitoring Kafka cluster sends an alarm message to the alarm Kafka cluster.

5. The distributed transaction processing method according to claim 4, wherein: Before the step of monitoring the Kafka cluster to determine whether a second end signal corresponding to the critical path monitoring is received within a preset time interval upon receiving the second start signal corresponding to the critical path monitoring, the distributed transaction processing method further includes: Upon receiving the try request, the core layer in the core layer cluster sends the second start signal corresponding to the critical path monitoring to the monitoring Kafka cluster; When receiving a confirm or cancel request, the core layer sends the second end signal corresponding to the critical path monitoring to the monitoring Kafka cluster.

6. A distributed transaction processing device, characterized in that: The distributed transaction processing device includes: An acquisition module is used to obtain the business system information, routing layer application information, and core layer cluster information corresponding to the alarm information when receiving the alarm information in the alarm Kafka cluster; A first determination module is used to determine the transaction status of the distributed transaction corresponding to the alarm information based on the business system information, the routing layer application information and the core layer cluster information; a second determination module, configured to determine, based on the transaction status, whether the distributed transaction satisfies a preset compensation condition corresponding to the second phase, wherein, after obtaining the transaction status, determining whether the processing status of the distributed transaction is a completed state; if the processing status of the distributed transaction is a completed state, determining whether the processing status of the routing layer in the transaction status is a processing state, or whether there is a core layer in the core layer cluster with a processing state in the processing state; if the processing status of the routing layer in the transaction status is a processing state or there is a core layer with a processing state in the processing state, determining that the distributed transaction satisfies the preset compensation condition corresponding to the second phase; A compensation module, configured to execute the second-phase business corresponding to the distributed transaction if the preset compensation condition is met; The acquisition module is specifically used to: Query business system information, wherein the business system information includes middle office transaction information and set control information; Query routing layer application information through transaction monitoring, wherein the routing layer application information includes TCC control information and set information; The core layer cluster information is queried through an online transaction back-check method in the business system, wherein the core layer cluster information includes TCC control information and second-stage abnormal image information.

7. A distributed transaction processing device, characterized in that: The distributed transaction processing device includes: a memory, a processor, and a distributed transaction processing program stored in the memory and executable on the processor. When the distributed transaction processing program is executed by the processor, the steps of the distributed transaction processing method according to any one of claims 1 to 5 are implemented.

8. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a distributed transaction processing program, which, when executed by a processor, implements the steps of the distributed transaction processing method according to any one of claims 1 to 5.

Images