Distributed transaction processing method, device and equipment and computer readable storage medium

Abstract

The invention discloses a distributed transaction processing method, device and equipment and a computer readable storage medium, and the method comprises the steps: obtaining business system information, routing layer application information and core layer cluster information corresponding to alarm information when the alarm information in an alarm Kafka cluster is received; determining a transaction state of a distributed transaction corresponding to the alarm information according to service system information, routing layer application information and core layer cluster information; based on the transaction state, determining whether the distributed transaction meets a preset compensation condition corresponding to two stages; and if the preset compensation condition is met, executing a second-stage service corresponding to the distributed transaction. According to the method, the second stage is triggered when the preset compensation condition is met, and automatic compensation of the distributed transaction is carried out, so that transaction compensation is carried out in the distributed transaction, and closed-loop processing of automatic compensation of the distributed transaction, the alarm information and the abnormal transaction is realized.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a distributed transaction processing method, apparatus, device and computer-readable storage medium. Background Art

[0002] With the advent of the cloud era, cloud service applications have been rapidly popularized, and cloud migration has become the norm for enterprises. However, with the microservices of applications, higher challenges have been raised for transaction consistency, especially in the financial field, where transaction consistency requirements are higher. With the microservices of financial systems, transaction integrity and recovery time under abnormal circumstances have become urgent issues for enterprises.

[0003] At present, conventional distributed transaction solutions include two-phase, TCC, local message table, three-phase, MQ message transaction and best effort notification. The existing solutions either achieve eventual consistency with low timeliness and fail to meet the timeliness requirements of a single transaction in the financial field, or lack transaction compensation methods in the event of abnormal processing in the second phase.

[0004] Therefore, how to perform transaction compensation in distributed transactions is a problem that needs to be solved urgently. Summary of the invention

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

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

[0007] 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;

[0008] Determine the transaction status of the distributed transaction corresponding to the alarm information according to the business system information, the routing layer application information and the core layer cluster information;

[0009] Based on the transaction state, determining whether the distributed transaction satisfies a preset compensation condition corresponding to the second phase;

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

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

[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-checking method in the business system, wherein the core layer cluster information includes TCC control information and second-stage abnormal image information.

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

[0016] 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.

[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] When receiving the first start signal corresponding to the critical path monitoring, monitoring the Kafka cluster to determine 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, when the first start signal corresponding to the critical path monitoring is received, before the step of monitoring the Kafka cluster to determine whether the first end signal corresponding to the critical path monitoring is received within a preset time interval, 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] 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:

[0024] When receiving the second start signal corresponding to the critical path monitoring, monitoring the Kafka cluster to determine whether the 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 a preset time interval, the monitoring Kafka cluster sends an alarm message to the alarm Kafka cluster.

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

[0027] 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;

[0028] 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.

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

[0030] 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;

[0031] A first determination module is used to determine the transaction state of the 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] A second determination module, configured to determine whether the distributed transaction satisfies a preset compensation condition corresponding to a second phase based on the transaction state;

[0033] The compensation module is used to execute the second-phase business corresponding to the distributed transaction if the preset compensation condition is met.

[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 executable on the processor, and the distributed transaction processing program implements the steps of the aforementioned distributed transaction processing method when executed by the processor.

[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, and when the distributed transaction processing program is executed by a processor, the steps of the aforementioned distributed transaction processing method are implemented.

[0036] The present 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 according to the business system information, routing layer application information and core layer cluster information; then determines whether the distributed transaction satisfies 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 according to the alarm information, determines whether the preset compensation conditions corresponding to the second stage are met according to 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 drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0039] Figure 1 A flow chart of the first embodiment of the distributed transaction processing method of the present application;

[0040] Figure 2 This is a schematic diagram of the module structure of a 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 purpose, 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 according to 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] At present, with the advent of the cloud era, cloud service applications have been rapidly popularized, and cloud migration has become the norm for enterprises. However, with the microservices of applications, higher challenges have been raised for transaction consistency, especially in the financial field, where transaction consistency requirements are higher. With the microservices of financial systems, transaction integrity and recovery time under abnormal circumstances have become urgent issues for enterprises.

[0047] At present, conventional distributed transaction solutions include two-phase, TCC, local message table, three-phase, MQ message transaction and best effort notification. The existing solutions either achieve eventual consistency, which is not very timely and does not meet the timeliness of a single transaction in the financial field, or lack transaction compensation methods in the case of abnormal processing in the second phase. Therefore, how to perform transaction compensation in distributed transactions is a problem that needs to be solved urgently.

[0048] The present application obtains business system information, routing layer application information and core layer cluster information according to alarm information, determines the transaction status of distributed transactions, determines whether the preset compensation conditions corresponding to the second stage are met according to the transaction status of the 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 subject of this embodiment may be a distributed transaction processing device, or a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or a distributed transaction processing device capable of realizing the above functions, etc., and this embodiment does not specifically limit this. The following takes the distributed transaction processing device as the execution subject as an example to illustrate this embodiment and the following embodiments.

[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, when receiving alarm information in the alarm Kafka cluster, obtaining 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] When a try request is received, the core layer in the core layer cluster sends a key path monitoring start signal (second start signal) to the monitoring Kafka cluster, and the core layer transaction starts; when a confirm or cancel request is received, the core layer in the core layer cluster sends a key path monitoring end signal (second end signal) to the monitoring Kafka cluster, and the core layer transaction ends. 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 there is an alarm currently based on the received critical path monitoring start signal and the critical path monitoring end signal, and sends the alarm information to the alarm Kafka cluster when there is an alarm.

[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 the TCC control information and the set information; the core layer cluster information includes the TCC control information and the 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 office 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 the alarm information in the alarm Kafka cluster is received, 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. And the routing layer application information is queried through transaction monitoring, wherein the routing layer application information includes TCC control information and set information. For example, the transaction monitoring WMM5 is called to query the TCC control information and the set information. At the same time, the core layer cluster information is queried through the online transaction back-check 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 back-check method (back-check method) of the online transaction in the business system is called to query the TCC control information and the second-stage abnormal image information.

[0062] Step S102, determining the transaction state of the distributed transaction corresponding to the alarm information according to 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, it is determined whether the alarm information is accurate 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 whether the first end signal is received after the preset time interval based on the layer application information and the core layer cluster information. If not, it is determined that the alarm information is accurate. If received, it is determined that the alarm information is 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 whether the second end signal is received after the preset time interval based on the layer application information and the core layer cluster information. If not, it is determined that the alarm information is accurate. If received, it is determined that the alarm information is 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 according to 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 an incomplete (processing) and a completed status (that is, the business system information contains the completion information of the distributed transaction), the processing status of the routing layer includes an incomplete (processing) and a 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 an incomplete (processing) and a completed status (that is, the core layer cluster information contains the completion information of the distributed transaction).

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

[0065] In this embodiment, after obtaining the transaction status, it is determined whether the distributed transaction satisfies the preset compensation conditions corresponding to the second phase. Specifically, according to the processing status of the distributed transaction in the transaction status, the processing status of the core layer, and the processing status of the routing layer, it is determined whether the current distributed transaction satisfies 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 status. If the processing status of the distributed transaction is a completed status, it is determined whether the processing status of the routing layer in the transaction status is a processing status, or whether there is a core layer in the core layer cluster whose processing status is a processing status. If the processing status of the routing layer in the transaction status is a processing status or there is a core layer whose processing status is a processing status, 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 the alarm information is received in the alarm Kafka cluster; then, the transaction status of the distributed transaction corresponding to the alarm information is determined according to the business system information, routing layer application information and core layer cluster information; then, based on the transaction status, it is determined whether the distributed transaction satisfies the preset compensation conditions corresponding to the second stage; then, if the preset compensation conditions are met, the second stage business corresponding to the distributed transaction is executed; the transaction status of the distributed transaction is determined by obtaining the business system information, routing layer application information and core layer cluster information according to the alarm information, and whether the preset compensation conditions corresponding to the second stage are met according to the transaction status of the distributed transaction, and the second stage is triggered when the preset compensation conditions are met, and automatic compensation of the distributed transaction is performed, 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, when receiving the first start signal corresponding to the critical path monitoring, monitoring the Kafka cluster to determine whether the 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, the routing layer sends a first start signal corresponding to the critical path monitoring to the monitoring Kafka cluster. When the first start signal corresponding to the critical path monitoring is received, the monitoring Kafka cluster starts timing to determine 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 the preset time interval, the monitoring Kafka cluster sends an alarm message 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; when receiving the try request, the routing layer sends a critical path monitoring start signal (the 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 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. 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, and the routing layer transaction ends.

[0080] The preset time interval may be reasonably set, 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, and determines the alarm message in the distributed transaction processing process according to the start signal and the end signal of the routing layer, and aggregates the integrity of the transaction according to the monitoring signal through the bypass monitoring data sent during the transaction process, and alarms for transactions that are not completed beyond the configured time range, which 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. 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 the core layer in the core layer cluster receives a try request, each core layer sends a second start signal corresponding to the critical path monitoring to the monitoring Kafka cluster. When the second start signal corresponding to the critical path monitoring is received, the monitoring Kafka cluster starts timing to determine 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 the preset time interval, the monitoring Kafka cluster sends an alarm message 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] Step S304, when 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 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. 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 the database transaction is committed or rolled back, the business layer sends the 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. When receiving a confirm or cancel request, the routing layer sends the critical path monitoring end signal (first end signal) to the monitoring Kafka cluster, and forwards the confirm or cancel request to the core layer cluster, and the routing layer transaction ends. 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.

[0091] The preset time interval may be reasonably set, 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 message 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 within the configured time range, which 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. 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. Figure 2 , the distributed transaction processing device comprises:

[0094] The 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 determination module 20, configured to determine the transaction state of the distributed transaction corresponding to the alarm information according to the business system information, the routing layer application information and the core layer cluster information;

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

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

[0098] The distributed transaction processing device provided in the embodiment of the present application adopts the distributed transaction processing method in the above embodiment, which can solve the technical problem of how to perform transaction compensation in distributed transactions. Compared with the prior art, the beneficial effects of the distributed transaction processing device provided in the embodiment of the present application are the same as the beneficial effects of the distributed transaction processing method provided in the above embodiment, and other technical features in the distributed transaction processing device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0099] The present application provides a distributed transaction processing device, which includes: at least one processor; and a memory that is 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 so that the at least one processor can execute the distributed transaction processing method in the above-mentioned embodiment 1.

[0100] Reference below Figure 3 , which shows a schematic diagram of the structure of a distributed transaction processing device suitable for implementing the 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), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 3 The distributed transaction processing device shown is merely an example and should not bring any limitation to 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 according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the distributed transaction processing device are also stored. The processing device 1001, ROM1002, and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the distributed transaction processing device to communicate with other devices wirelessly or wired to exchange data. Although the distributed transaction processing device with various systems is shown in the figure, it should be understood that it is not required to implement or have all 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 process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a 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 through 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 by the present application adopts the distributed transaction processing method in the above embodiment, which can solve the technical problem of how to perform transaction compensation in distributed transactions. Compared with the prior art, the beneficial effects of the distributed transaction processing device provided by the present application are the same as the beneficial effects of the distributed transaction processing method provided by the above embodiment, and other technical features in the distributed transaction processing device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0104] It should be understood that the various parts disclosed in this application can be implemented by 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 one or more embodiments or examples in a suitable manner.

[0105] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0106] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, wherein the computer-readable program instructions are used to execute the distributed transaction processing method in the above-mentioned embodiment.

[0107] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, 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 suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0108] The computer-readable storage medium may be included in the distributed transaction processing device; or may exist independently without being 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 according to the business system information, routing layer application information and core layer cluster information; based on the transaction status, determines whether the distributed transaction satisfies 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 separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of 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., via the Internet using an Internet service provider).

[0111] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the 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 square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square 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 square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0112] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0113] The readable storage medium provided by the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned distributed transaction processing method, and 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-readable storage medium provided by the present application are the same as the beneficial effects of the distributed transaction processing method provided by the above-mentioned embodiment, and will not be repeated 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 embodiment of this application are the same as the beneficial effects of the distributed transaction processing method provided in the above embodiment, which will not be repeated here.

[0116] The above are only preferred embodiments of the present application, and are not intended to limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, 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 according to the business system information, the routing layer application information and the core layer cluster information; Based on the transaction state, determining whether the distributed transaction satisfies a preset compensation condition corresponding to the second phase; If the preset compensation condition is met, the second-phase business corresponding to the distributed transaction is executed.

2. The distributed transaction processing method according to claim 1, characterized in that: 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-checking method in the business system, wherein the core layer cluster information includes TCC control information and second-stage abnormal image information.

3. The distributed transaction processing method according to claim 1, characterized in that: The step of determining whether the distributed transaction satisfies a preset compensation condition corresponding to the second phase based on the transaction state includes: 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.

4. The distributed transaction processing method according to any one of claims 1 to 3, characterized in that: 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: When receiving the first start signal corresponding to the critical path monitoring, monitoring the Kafka cluster to determine 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.

5. The distributed transaction processing method according to claim 4, characterized in that: Before the step of monitoring the Kafka cluster to determine whether the 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: 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.

6. The distributed transaction processing method according to any one of claims 1 to 3, characterized in that: 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: When receiving the second start signal corresponding to the critical path monitoring, monitoring the Kafka cluster to determine 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.

7. The distributed transaction processing method according to claim 6, characterized in that: 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 when the second start signal corresponding to the critical path monitoring is received, 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.

8. A distributed transaction processing device, characterized in that: The distributed transaction processing device comprises: 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 state of the distributed transaction corresponding to the alarm information according to the business system information, the routing layer application information and the core layer cluster information; A second determination module, configured to determine whether the distributed transaction satisfies a preset compensation condition corresponding to a second phase based on the transaction state; The compensation module is used to execute the second-phase business corresponding to the distributed transaction if the preset compensation condition is met.

9. A distributed transaction processing device, characterized in that: The distributed transaction processing device comprises: 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 as described in any one of claims 1 to 7 are implemented.

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

Images