A distributed-based transaction anomaly detection method, device and system

Abstract

Embodiments of the present application provide a distributed transaction exception detection method, device and system, which can be used in the field of artificial intelligence technology. The method comprises the following steps: before executing a business transaction task sent by an upstream transaction node, querying a local main transaction table; and performing transaction exception detection according to rollback conditions in the local main transaction table, so as to prevent transaction suspension in a TCC mode and ensure the consistency of business data.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to the technical field of artificial intelligence, and especially to a transaction exception detection method, device and system based on distribution. BACKGROUND

[0002] Try-Confirm-Cancel (TCC) mode is a common solution in distributed transactions, which principle is to divide the entire distributed transaction into two stages, the first stage is Try operation, and the second stage is Confirm operation or Cancel operation. However, in the TCC mode, if any one sub-transaction only performs one-stage operation without any two-stage processing, it will cause transaction suspension and cause business data inconsistency. There is no method to solve the suspension problem in the related art. SUMMARY

[0003] An object of the present application is to provide a transaction exception detection method based on distribution, which can prevent transaction suspension in TCC mode and ensure the consistency of business data. Another object of the present application is to provide a transaction exception detection device based on distribution. Still another object of the present application is to provide a transaction exception detection system based on distribution. Still another object of the present application is to provide a computer readable medium. Still another object of the present application is to provide a computer device.

[0004] In order to achieve the above objects, one aspect of the present application discloses a transaction exception detection method based on distribution, comprising:

[0005] Before executing the business transaction task sent by the upstream transaction node, querying the local main transaction table;

[0006] According to the rollback situation in the local main transaction table, transaction exception detection is performed.

[0007] Preferably, according to the rollback situation in the local main transaction table, transaction exception detection is performed, comprising:

[0008] If there is a rollback record in the local main transaction table, a transaction exception signal is generated.

[0009] Preferably, it further comprises:

[0010] If there is no rollback record in the local main transaction table, a transaction record corresponding to the business transaction information is added in the local sub-transaction table;

[0011] Querying the local main transaction table;

[0012] If there is no rollback record in the local main transaction table, executing the business transaction task;

[0013] If the rollback record exists in the local master transaction table, a transaction exception signal is generated.

[0014] Preferably, after the business transaction task is executed, the method further comprises:

[0015] determining whether a downstream transaction node exists;

[0016] If the downstream transaction node exists, the business transaction task is sent to the downstream transaction node, so that the downstream transaction node repeatedly executes the step of querying the local master transaction table.

[0017] Preferably, the method further comprises:

[0018] in response to the rollback request sent by the upstream transaction node, adding a rollback record in the local master transaction table;

[0019] determining whether a downstream transaction node exists;

[0020] If the downstream transaction node exists, the rollback request is sent to the downstream transaction node, so that the downstream transaction node repeatedly executes the step of adding the rollback record in the local master transaction table.

[0021] If the downstream transaction node does not exist, a rollback business is executed.

[0022] Preferably, after the rollback business is executed, the method further comprises:

[0023] determining whether an upstream transaction node exists;

[0024] If the upstream transaction node exists, a rollback indication is sent to the upstream transaction node, so that the upstream transaction node executes the rollback business.

[0025] Preferably, the upstream transaction node comprises a unique identification code.

[0026] adding the rollback record in the local master transaction table comprises:

[0027] adding an ignore key to the unique identification code;

[0028] generating the rollback record according to the unique identification code to which the ignore key is added and the rollback request, and adding the rollback record to the local master transaction table.

[0029] The application further discloses a transaction exception detection system based on distribution, comprising: a plurality of transaction nodes, the plurality of transaction nodes comprising an upstream transaction node and a current transaction node.

[0030] The upstream transaction node is configured to send a business transaction task to the current transaction node.

[0031] The current transaction node is configured to query a local master transaction table before executing the business transaction task, and perform transaction exception detection according to a rollback condition in the local master transaction table.

[0032] Preferably, the plurality of transaction nodes further comprises a downstream transaction node;

[0033] The upstream transaction node is further configured to send a rollback request to the current transaction node;

[0034] The current transaction node is further configured to add a rollback record in the local master transaction table in response to the rollback request; determine whether there is a downstream transaction node; if there is, send the rollback request to the downstream transaction node, so that the downstream transaction node repeatedly performs the step of adding the rollback record in the local master transaction table; and if there is not, perform the rollback business.

[0035] The application further discloses a distributed transaction exception detection device, comprising:

[0036] The first query unit is configured to query the local master transaction table in response to the business transaction information sent by the upstream transaction;

[0037] The detection unit is configured to perform transaction exception detection according to the existence of the rollback record in the local master transaction table.

[0038] The application further discloses a computer readable medium, which stores a computer program, and the program is executed by a processor to implement the method.

[0039] The application further discloses a computer device, which comprises a memory and a processor, the memory is used to store information comprising program instructions, and the processor is used to control the execution of the program instructions, and the processor implements the method when executing the program.

[0040] The application queries the local master transaction table before executing the business transaction task sent by the upstream transaction node; and performs transaction exception detection according to the rollback record in the local master transaction table, so that the transaction hanging in the TCC mode can be prevented, and the consistency of the business data can be ensured. BRIEF DESCRIPTION OF DRAWINGS

[0041] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description. Obviously, the drawings in the following description only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0042] Figure 1 A structure diagram of a distributed transaction exception detection system according to an embodiment of the present application is provided.

[0043] Figure 2 A flowchart of a distributed transaction exception detection method according to an embodiment of the present application is provided.

[0044] Figure 3 A flow chart of another distributed-based transaction exception detection method provided for an embodiment of the present application is shown in FIG. 6.

[0045] Figure 4 A structure diagram of a distributed-based transaction exception detection device provided for an embodiment of the present application is shown in FIG. 7.

[0046] Figure 5 A structure diagram of a computer device provided for an embodiment of the present application is shown in FIG. 8. DETAILED DESCRIPTION

[0047] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the present application.

[0048] It should be noted that the distributed-based transaction exception detection method, device and system disclosed in the present application can be used in the field of artificial intelligence technology, and can also be used in any field other than the field of artificial intelligence technology. The application field of the distributed-based transaction exception detection method, device and system disclosed in the present application is not limited.

[0049] In order to facilitate understanding of the technical solutions provided in the present application, the related content of the technical solutions of the present application will be described first. The Try-Confirm-Cancel (TCC) mode is a common solution in distributed transactions, and its principle is to divide the entire distributed transaction into two stages. The first stage is Try operation, and the second stage is Confirm operation or Cancel operation. The function of Try operation is to complete the detection of all businesses and reserve the necessary business resources of the business to ensure that the operation of the second stage executed after the completion of the first stage can be successful. When the Try operation of the first stage is executed successfully, the Confirm operation of the second stage is executed to execute the business logic in the business transaction task. When the Try operation of the first stage fails, the Cancel operation of the second stage is executed to release the resources reserved by the Try operation of the first stage.

[0050] In the same library mode, business data is stored in the business application side, and the initiator application is responsible for transaction coordination, and data high availability follows the application deployment; in the different library mode, business data is stored centrally on the server side, and the transaction platform is responsible for high availability and transaction coordination. The business data in the same library mode is stored in the business application side, which has the advantage of reducing interaction with the distributed transaction platform and reducing dependence on the platform. In the TCC mode, each transaction node has a transaction data table locally, which includes a main transaction table (dtx_tcc_main_x) and a sub-transaction table (dtx_tcc_sub_x). When the main transaction node initiates a business transaction task to the downstream sub-transaction node, a main transaction record is inserted into the local main transaction table of the main transaction node. Subsequent downstream sub-transaction nodes each time initiate a business transaction task to its downstream transaction node will insert a sub-transaction record into the sub-transaction table on the initiator side. For example: A is the main transaction node, B, C and D are sub-transaction nodes. The main transaction node A calls the sub-transaction node B, and the sub-transaction node B calls the sub-transaction nodes C and D. Specifically, the main transaction node A initiates a business transaction task and inserts a business transaction record into the local main transaction table. When the main transaction node A calls the sub-transaction node B, a business transaction record is inserted into the local sub-transaction table first, and then the business transaction task is sent to the sub-transaction node B to call the service of the sub-transaction node B; the sub-transaction node B receives the business transaction task and needs to call the sub-transaction nodes C and D in turn, first inserts a business transaction record for calling the sub-transaction node C into the local sub-transaction table, and then sends the business transaction task to the sub-transaction node C to call the service of the sub-transaction node C; then a business transaction record for calling the sub-transaction node D is inserted into the local sub-transaction table, and then the business transaction task is sent to the sub-transaction node D to call the service of the sub-transaction node D. Taking the second phase execution Confirm operation as an example, the main transaction node A initiates the Confirm operation, queries the record for calling the sub-transaction node B from the local sub-transaction table, and then sends the Confirm operation to the sub-transaction node B; the sub-transaction node B receives the Confirm operation, queries the sub-transaction node C from the local sub-transaction table, and then sends the Confirm operation to the sub-transaction node C, and then queries the sub-transaction node D from the local sub-transaction table, and then sends the Confirm operation to the sub-transaction node D; the sub-transaction node C and the sub-transaction node D execute the Confirm operation, and after execution, send a completion message to the sub-transaction node B; the sub-transaction node B receives the completion messages of the sub-transaction node C and the sub-transaction node D, executes the Confirm operation, and after execution, sends a completion message to the main transaction node A; the main transaction node A receives the completion message of the sub-transaction node B, executes the Confirm operation. If the second phase executes the Cancel operation, the process is the same as the execution of the Confirm operation described above, which will not be described here.

[0051] In the first stage, when the sub-transaction node B calls the service of the sub-transaction node C, the calling time is too long due to reasons such as network failure, thereby causing the waiting time of the main transaction node A to be too long, and thus the main transaction node A initiates the second stage of the Cancel operation. When the sub-transaction node B receives the Cancel operation, only the record of calling the sub-transaction node C can be queried from the local sub-transaction table, and the record of calling the sub-transaction node D has not been queried, so the sub-transaction node B sends the Cancel operation to the sub-transaction node C only, and does not send the Cancel operation to the sub-transaction node D, so only the sub-transaction node C executes the Cancel operation. If the network is restored when the main transaction node A initiates the second stage of the Cancel operation, the sub-transaction node B will continue to call the service of the sub-transaction node D, and after the service of the sub-transaction node D is called, the sub-transaction node D will not subsequently perform the second stage of the Cancel operation or the Confirm operation due to the subsequent reception of the Cancel operation initiated by the main transaction node A, thereby causing the sub-transaction node D to be suspended. If subsequent business data needs to be queried, the business data inconsistency problem will be caused due to the suspension of the sub-transaction node D. In the inter-library mode, the states of the main transaction node and the sub-transaction node are uniformly managed in the distributed transaction platform, and before each transaction initiated by the sub-transaction node, the distributed transaction platform can determine whether the transaction can be initiated by querying the state of the local main transaction node. However, in the same library mode, the state of the main transaction node is only locally maintained, and the downstream sub-transaction node cannot know the state of the main transaction node when initiating the first stage of the business transaction, and thus the suspension problem cannot be avoided.

[0052] To solve the above technical problems, Figure 1 The structure schematic diagram of the distributed transaction exception detection system provided by the embodiment of the application comprises a plurality of transaction nodes, Figure 1 Taking four transaction nodes as an example, A is an upstream transaction node, B is a current transaction node, and C and D are downstream transaction nodes. The upstream transaction node A is a main transaction node, calls the current transaction node B, and the current transaction node B calls the downstream transaction nodes C and D.

[0053] The plurality of transaction nodes comprise an upstream transaction node and a current transaction node. The upstream transaction node calls the current transaction node, and the current transaction node is a downstream transaction node of the upstream transaction node. As shown in the figure, Figure 1 A is a main transaction node, and the main transaction node A is an upstream transaction node of the current transaction node B. The current transaction node B is a downstream transaction node of the main transaction node A, and is also called a sub-transaction node of the current transaction node A. The current transaction node B is an upstream transaction node of the downstream transaction nodes C and D, and the downstream transaction nodes C and D are also called sub-transaction nodes of the current transaction node B.

[0054] The upstream transaction node is configured to send a business transaction task to the current transaction node. Figure 1 Specifically, the upstream transaction node A is configured to send a business transaction task to the current transaction node B.

[0055] The current transaction node is configured to query a local master transaction table before executing the business transaction task, and perform transaction exception detection according to a rollback in the local master transaction table.

[0056] In the embodiment of the present application, the upstream transaction node is further configured to send a rollback request to the current transaction node. Figure 1 Specifically, the upstream transaction node A is configured to send a rollback request to the current transaction node B.

[0057] The current transaction node is further configured to add a rollback record in the local master transaction table in response to the rollback request, determine whether there is a downstream transaction node, and if there is, send the rollback request to the downstream transaction node, so that the downstream transaction node repeatedly executes the step of adding the rollback record in the local master transaction table, and if there is not, execute a rollback business. Figure 1 Specifically, the current transaction node B adds a rollback record in the local master transaction table after receiving the rollback request sent by the upstream transaction node A, and the current transaction node B further has downstream transaction nodes C and D, and sends the rollback request to the downstream transaction nodes C and D, so that the downstream transaction nodes C and D add the rollback record in the local master transaction table.

[0058] In the technical scheme provided by the embodiment of the present application, the local master transaction table is queried before the business transaction task sent by the upstream transaction node is executed, and transaction exception detection is performed according to the rollback in the local master transaction table, which can prevent transaction hanging in the TCC mode and ensure the consistency of business data.

[0059] It should be noted that Figure 1 The distributed transaction exception detection system based on the distributed transaction exception detection method shown in Figure 2 or Figure 3 is also applicable to the distributed transaction exception detection method, which will not be described here.

[0060] The implementation process of the distributed transaction exception detection method based on the distributed transaction exception detection device as an execution subject will be described below. It should be understood that the execution subject of the distributed transaction exception detection method provided by the embodiment of the present application includes but is not limited to the distributed transaction exception detection device.

[0061] Figure 2 The flowchart of the distributed transaction exception detection method provided by the embodiment of the present application is shown in Figure 2 The method comprises the following steps.

[0062] Step 101, before executing the business transaction task sent by the upstream transaction node, querying the local master transaction table.

[0063] Step 102, according to the rollback in the local master transaction table, transaction exception detection is performed.

[0064] In the technical scheme provided by the embodiment of the application, before executing the business transaction task sent by the upstream transaction node, the local master transaction table is queried; according to the rollback in the local master transaction table, transaction exception detection is performed, which can prevent transaction hanging in the TCC mode and ensure the consistency of business data.

[0065] Figure 3 As shown in the flowchart of another distributed transaction exception detection method provided by the embodiment of the application, Figure 3 the method comprises the following steps:

[0066] Step 201, receiving the business transaction task sent by the upstream transaction node.

[0067] In the embodiment of the application, each step is executed by the transaction node.

[0068] In the embodiment of the application, the upstream transaction node can be a master transaction node or a sub-transaction node. The business transaction task is a Try operation in the first stage in the TCC mode, which completes the detection of the business transaction and reserves the necessary business resources of the business to ensure that the operation of the second stage executed after the completion of the first stage can be successful.

[0069] Step 202, querying the local master transaction table, judging whether there is a rollback record in the local master transaction table, if yes, executing step 203; if no, executing step 204.

[0070] In the embodiment of the application, the local master transaction table is the local master transaction table of the transaction node, and the initial state of the local master transaction table is empty, which is only used to record the rollback of the master transaction node. If there is a rollback record in the local master transaction table, it indicates that the master transaction node initiates a rollback request, and the current business transaction is abnormal, and step 203 is executed; if there is no rollback record in the local master transaction table, it indicates that the master transaction node does not initiate a rollback request, and the current business transaction is normal, and step 204 is continued to execute.

[0071] Step 203, generating a transaction exception signal, and the flow ends.

[0072] In the embodiment of the application, if the current business transaction is abnormal, in order to prevent the occurrence of a hanging event, a transaction exception signal is generated, the current business transaction is terminated, and the flow ends.

[0073] In the embodiment of the present application, when the sub-transaction node initiates a business transaction, the state of the main transaction node can be determined in time, and then it is determined whether the current business transaction is abnormal, if abnormal, the current business transaction is directly ended through a transaction exception signal, so that the hanging event can be avoided in time, and the consistency of the business data is ensured.

[0074] In step 204, a transaction record corresponding to the business transaction task is added in the local sub-transaction table.

[0075] In the embodiment of the present application, if the current business transaction is normal, it indicates that the current transaction node can initiate a business transaction, and a transaction record is added in the local sub-transaction table, which includes but is not limited to business data, and the transaction record corresponds to the business transaction task.

[0076] In step 205, the local main transaction table is queried to determine whether there is a rollback record in the local main transaction table, if yes, step 203 is executed, and if no, step 206 is executed.

[0077] In the embodiment of the present application, the transaction node queries the local main transaction table again, if there is a rollback record in the local main transaction table, it indicates that the main transaction node initiates a rollback request when the transaction node adds a transaction record in the local sub-transaction table, the current business transaction is abnormal, and step 203 is continuously executed, if there is no rollback record in the local main transaction table, it indicates that the current business transaction is normal, and step 206 is continuously executed.

[0078] In the embodiment of the present application, before the transaction node sends the business transaction task in the first stage, it is necessary to query whether there is a rollback record in the local main transaction table to determine whether the current business transaction is abnormal, if no abnormal, a transaction record is added in the local sub-transaction table, the query of whether there is a rollback record in the local main transaction table and the addition of the transaction record should be serially executed, if under concurrent execution, the main transaction node initiates a rollback request when the transaction record is added, the hanging event can still occur. Therefore, the present application adopts a post-query mode, that is, the local main transaction table is queried once, and the transaction record is added in the local sub-transaction table under the condition that there is no rollback record, after the transaction record is added, the local main transaction table is queried twice to determine whether the current business transaction is abnormal when the transaction record is added, so that the problem of hanging in the business transaction process is more accurately prevented.

[0079] In step 206, the business transaction task is executed.

[0080] In the embodiment of the present application, the transaction node can execute the business transaction task to complete the detection of the business transaction, and reserve the necessary business resources of the business to ensure that the operation of the second stage executed after the completion of the first stage can be successful.

[0081] Step 207, judging whether the business transaction task is executed normally, if not, executing step 208; if yes, executing step 209.

[0082] In the embodiment of the present application, if the transaction is abnormal during the execution of the business transaction task, it indicates that the first stage fails, and step 208 is executed continuously; if the transaction is normal, it indicates that the first stage succeeds, and step 209 is executed continuously. The transaction node can execute the business transaction task to complete the detection of the business transaction, and reserve the necessary business resources of the business to ensure that the operation of the second stage executed after the completion of the first stage can be successful.

[0083] Step 208, generating a transaction rollback signal, and sending the transaction rollback signal to the upstream transaction node, and executing step 212 continuously.

[0084] In the embodiment of the present application, if the first stage fails, the current transaction node generates a transaction rollback signal, and sends the transaction rollback signal to the upstream transaction node, so that the upstream transaction node transmits the transaction rollback signal to the master node, and step 212 is executed continuously.

[0085] Step 209, judging whether there is a downstream transaction node, if yes, executing step 210; if not, executing step 211.

[0086] In the embodiment of the present application, the downstream transaction node is a sub-transaction node called by the current transaction node, if it is judged that there is a downstream transaction node, it indicates that the business transaction task needs to be transmitted to the downstream continuously, and step 210 is executed continuously; if there is no downstream transaction node, it indicates that the current transaction node does not call other nodes, and the business transaction task does not need to be transmitted to the downstream continuously, if the execution of the business transaction task does not time out, the second stage is entered, and a confirmation (Confirm) request sent by the upstream transaction node is received; if the execution of the business transaction task times out, the second stage is entered, and a rollback (Cancel) request is initiated by the master transaction node and transmitted to the downstream transaction node, and step 211 is executed.

[0087] As an optional solution, if the upstream transaction node does not send a rollback request, the flow ends.

[0088] Step 210, sending the business transaction task to the downstream transaction node, so that the downstream transaction node executes step 202 repeatedly.

[0089] In the embodiment of the present application, the transaction node sends the business transaction task to the downstream transaction node called by it, and the downstream transaction node executes step 202 repeatedly, that is, before executing the business transaction task, the local master transaction table is queried, and it is judged whether there is a rollback record in the local master transaction table, until there is no downstream transaction node called.

[0090] Step 211, receiving the confirmation request sent by the upstream transaction node, and performing the confirmation operation, and the flow ends.

[0091] Specifically, the main transaction node sends a confirmation request to the downstream transaction node, and the confirmation request is sequentially transmitted to each sub-transaction node until there is no downstream transaction node for the current transaction node; the current transaction node performs the confirmation operation, and judges whether there is an upstream transaction node, if yes, sends a confirmation indication to the upstream transaction node, so that the upstream transaction node performs the confirmation operation and repeatedly performs the step of judging whether there is an upstream transaction node; if no, the flow ends.

[0092] Step 212, receiving the rollback (Cancel) request sent by the upstream transaction node.

[0093] In the embodiment of the application, the main transaction node sends a rollback request to the downstream sub-transaction node called by it, so as to transmit the rollback request to each sub-transaction node called, so that each sub-transaction node can receive the rollback request sent by the main transaction node. The upstream transaction node can be the main transaction node or the sub-transaction node.

[0094] In the embodiment of the application, the rollback request includes transaction context information, and the service called by the upstream transaction node can be determined according to the transaction context information. Further, if the service called by the upstream transaction node is the service provided by the current transaction node, step 213 is continued to be performed.

[0095] Step 213, in response to the rollback request sent by the upstream transaction node, adding a rollback record in the local main transaction table.

[0096] In the embodiment of the application, after receiving the rollback request sent by the upstream transaction node, a rollback record is added in the local main transaction table, so as to provide a judgment basis for ensuring that the current business transaction is not abnormal before subsequent business transaction tasks are performed. The upstream transaction node includes a unique identification code, which can uniquely identify an upstream transaction node as a primary key for subsequent addition and query in the database.

[0097] Specifically, the unique identification code is added with an ignore keyword; the rollback record is generated according to the unique identification code added with the ignore keyword and the rollback request, and the rollback record is added to the local main transaction table.

[0098] In the embodiment of the application, by performing idempotent control on the added rollback record, the primary key conflict problem caused by the same service possibly being called multiple times in the same transaction node is prevented.

[0099] Step 214, judging whether there is a downstream transaction node, if yes, executing step 215; if no, executing step 216.

[0100] In the embodiment of the application, the downstream transaction node is a sub-transaction node called by the current transaction node, if there is a downstream transaction node, it indicates that the rollback request needs to be continuously passed down, and step 215 is continuously executed; if there is no downstream transaction node, it indicates that the current transaction node does not call other nodes, and the rollback request does not need to be continuously passed down, and step 216 is executed.

[0101] Step 215, sending the rollback request to the downstream transaction node, so that the downstream transaction node repeatedly executes step 213.

[0102] In the embodiment of the application, the transaction node sends the rollback request to the downstream transaction node called by it, so that the downstream transaction node adds the rollback record in the local master transaction table.

[0103] Step 216, executing the rollback business.

[0104] In the embodiment of the application, if the current transaction node has no sub-transaction node, the rollback business is executed, that is, the rollback business is executed from the bottommost transaction node.

[0105] Step 217, judging whether there is an upstream transaction node, if yes, executing step 218; if no, the process ends.

[0106] In the embodiment of the application, if there is an upstream transaction node, it indicates that the current transaction node is not a master transaction node, and step 218 is executed; if there is no upstream transaction node, it indicates that the current transaction node is a master transaction node, and the process ends.

[0107] Step 218, sending the rollback indication to the upstream transaction node, so that the upstream transaction node repeatedly executes step 216.

[0108] In the embodiment of the application, if the current transaction node is not a master transaction node, the rollback indication is sent to the upstream transaction node, so that the upstream transaction node executes the rollback business until the master transaction node completes the execution of the rollback business.

[0109] In the embodiment of the application, under the distributed architecture, an idea of non-full master transaction state synchronization on the side of the sub-transaction node is proposed, the rollback request of the master transaction node is passed through the service provider filter (Filter) and recorded in the local master transaction table, and the post-query mode is adopted to solve the concurrent problems that may be caused by the non-atomic operation of querying the local master transaction table and inserting the sub-transaction record, which can effectively prevent the problem of transaction suspension under the distributed architecture.

[0110] The technical scheme of the transaction exception detection method based on distribution provided in the embodiment of the application comprises the following steps: before a business transaction task sent by an upstream transaction node is executed, a local main transaction table is queried; and according to a rollback condition in the local main transaction table, transaction exception detection is performed, so that transaction hanging in a TCC mode can be prevented, and the consistency of business data can be ensured.

[0111] Figure 4 A structure diagram of a transaction exception detection device based on distribution provided in the embodiment of the application, which is used for executing the transaction exception detection method based on distribution, as shown in the figure, the device comprises a first query unit 11 and a detection unit 12. Figure 4

[0112] The first query unit 11 is used for querying the local main transaction table in response to business transaction information sent by an upstream transaction.

[0113] The detection unit 12 is used for performing transaction exception detection according to the existence condition of a rollback record in the local main transaction table.

[0114] In the embodiment of the application, the detection unit 12 is specifically used for generating a transaction exception signal if there is a rollback record in the local main transaction table.

[0115] In the embodiment of the application, the device further comprises a first adding unit 13, a second query unit 14, a first execution unit 15 and a first generating unit 16.

[0116] The first adding unit 13 is used for adding a transaction record in a local sub-transaction table if there is no rollback record in the local main transaction table, the transaction record corresponding to the business transaction information.

[0117] The second query unit 14 is used for querying the local main transaction table.

[0118] The first execution unit 15 is used for executing the business transaction task if there is no rollback record in the local main transaction table.

[0119] The first generating unit 16 is used for generating a transaction exception signal if there is a rollback record in the local main transaction table.

[0120] In the embodiment of the application, a first judgment unit 17 and a sending unit 18 are further included.

[0121] The first judgment unit 17 is used for judging whether there is a downstream transaction node.

[0122] If there is, the sending unit 18 is used for sending the business transaction task to the downstream transaction node, so that the downstream transaction node can repeatedly execute the step of querying the local main transaction table.

[0123] ​In the embodiment of the present application, the device further comprises a second adding unit 19, a second judging unit 20 and a second executing unit 21.

[0124] The second adding unit 19 is configured to add a rollback record in the local master transaction table in response to a rollback request sent by an upstream transaction node.

[0125] The second judging unit 20 is configured to determine whether there is a downstream transaction node.

[0126] If there is, the sending unit 18 is configured to send the rollback request to the downstream transaction node, so that the downstream transaction node repeatedly performs the step of adding the rollback record in the local master transaction table.

[0127] If there is not, the second executing unit 21 is configured to perform rollback business.

[0128] In the embodiment of the present application, the device further comprises a third judging unit 22.

[0129] The third judging unit 22 is configured to determine whether there is an upstream transaction node.

[0130] If there is, the sending unit 18 is configured to send a rollback indication to the upstream transaction node, so that the upstream transaction node performs rollback business.

[0131] In the embodiment of the present application, the second adding unit 19 is specifically configured to add an ignore key to the unique identification code; generate a rollback record according to the unique identification code added with the ignore key and the rollback request, and add the rollback record to the local master transaction table.

[0132] In the scheme of the embodiment of the present application, before performing a business transaction task sent by an upstream transaction node, the local master transaction table is queried; according to the rollback situation in the local master transaction table, transaction exception detection is performed, which can prevent transaction hanging in the TCC mode and ensure the consistency of business data.

[0133] The system, device, module or unit illustrated in the above embodiments can be specifically implemented by a computer chip or entity, or by a product with certain functions. A typical implementation device is a computer device, and specifically, the computer device may, for example, be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device or a combination of any of these devices.

[0134] The embodiment of the present application provides a computer device, comprising a memory and a processor, the memory is used for storing information comprising program instructions, the processor is used for controlling execution of the program instructions, when the program instructions are loaded and executed by the processor, each step of the embodiment of the above-mentioned distributed transaction exception detection method is realized, and specific description can be referred to the embodiment of the above-mentioned distributed transaction exception detection method.

[0135] Reference is made below to Figure 5 which shows a structural schematic diagram of the computer device 600 suitable for being used to realize the embodiment of the present application.

[0136] As Figure 5 shown, the computer device 600 comprises a central processing unit (CPU) 601, which can perform various appropriate work and processing according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage portion 608 to a random access memory (RAM) 603. In the RAM 603, various programs and data required for operation of the computer device 600 are also stored. The CPU 601, the ROM 602, and the RAM 603 are connected to each other through a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0137] The following components are connected to the I / O interface 605: an input portion 606 comprising a keyboard, a mouse, and the like; an output portion 607 comprising a display such as a cathode ray tube (CRT), a liquid crystal display (LCD), and the like, and a speaker, and the like; a storage portion 608 comprising a hard disk, and the like; and a communication portion 609 comprising a network interface card such as a LAN card, a modem, and the like. The communication portion 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 606 as necessary. A removable media 611 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, and the like is mounted on the drive 610 as necessary, so that a computer program read therefrom is installed in the storage portion 608 as necessary.

[0138] In particular, according to the embodiment of the present application, the processes described above with reference to the flowcharts can be realized as a computer software program. For example, the embodiment of the present application comprises a computer program product comprising a computer program tangibly embodied on a machine-readable medium, the computer program comprising program code for executing the methods illustrated by the flowcharts. In such an embodiment, the computer program can be downloaded and installed from a network by the communication portion 609, and / or installed from the removable media 611.

[0139] Computer-readable media includes permanent and non-permanent, movable and non-movable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to a computing device. According to the definition herein, computer-readable media does not include transitory media such as modulated data signals and carriers.

[0140] For the convenience of description, the above device is described as various units respectively described in function. Of course, in the implementation of the present application, the functions of each unit can be implemented in the same or more software and / or hardware.

[0141] The present application is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present application. It should be understood that each flow and / or block in the flowchart and / or block diagram, and the combination of flows and / or blocks in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to produce a machine, so that the instructions executed by the computer or other programmable data processing devices produce a device that implements the functions specified in the flowchart and / or block diagram. Figure 1 The functions specified in one or more flows and / or blocks Figure 1 The functions specified in one or more flows and / or blocks

[0142] These computer program instructions can also be stored in a computer-readable memory that can guide the computer or other programmable data processing device to work in a specific way, so that the instructions stored in the computer-readable memory produce a product including instruction devices that implement the functions specified in the flowchart and / or block diagram. Figure 1 The functions specified in one or more flows and / or blocks Figure 1 The functions specified in one or more flows and / or blocks

[0143] These computer program instructions can also be loaded into computer or other programmable data processing devices, so that a series of operational steps are performed on the computer or other programmable data processing devices to generate a computer-implemented process, thus the instructions executed on the computer or other programmable data processing devices provide the function implemented in the flow Figure 1 one or more flows and / or blocks Figure 1 one or more blocks or multiple blocks.

[0144] It should be further noted that the terms "comprise", "comprising", or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element preceded by "comprises a" does not, without more constraints, foreclose the existence of additional identical elements in the process, method, article, or apparatus that comprises the recited element.

[0145] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system or a computer program product. Therefore, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk memory, CD-ROM, optical memory, etc.) containing computer-usable program code.

[0146] The present application can be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The present application can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communication network. In a distributed computing environment, program modules can be located in both local and remote computer storage media including memory storage devices.

[0147] Each of the embodiments in the specification is described in a progressive manner, and the same or similar parts between each of the embodiments can be referred to each other, and each of the embodiments focuses on the difference from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the part of the method embodiment.

[0148] The above merely provides an example of the present application, and is not intended to limit the present application. Any modification, equivalent replacement, improvement, etc. within the spirit and principle of the present application should be included in the scope of claims of the present application.

Claims

1. A distributed transaction anomaly detection method, characterized in that, The method includes: Before executing the business transaction task sent by the upstream transaction node, the local main transaction table is queried. The upstream transaction node includes a unique identifier. In response to the rollback request sent by the upstream transaction node, an ignore keyword is added to the unique identifier. Based on the unique identifier with the ignore keyword and the rollback request, a rollback record is generated and added to the local main transaction table. Before executing the business transaction task sent by the upstream transaction node, the local main transaction table is queried, including: performing a query on the local main transaction table; if no rollback record is found, adding a transaction record to the local sub-transaction table; the transaction record corresponds to the business transaction task; after adding the transaction record, a second query is performed on the local main transaction table; based on the rollback status in the local main transaction table, transaction anomaly detection is performed; if no rollback record is found in the local main transaction table, the business transaction task is executed. The step of performing transaction anomaly detection based on the rollback status in the local master transaction table includes: If a rollback record exists in the local master transaction table, a transaction exception signal is generated.

2. The distributed transaction anomaly detection method according to claim 1, characterized in that, After executing the business transaction task, the following is also included: Determine if a downstream transaction node exists; If it exists, the business transaction task is sent to the downstream transaction node so that the downstream transaction node can repeat the step of querying the local main transaction table.

3. The distributed transaction anomaly detection method according to claim 1, characterized in that, The method further includes: Determine if a downstream transaction node exists; If it exists, the rollback request is sent to the downstream transaction node so that the downstream transaction node can repeat the step of adding the rollback record in the local master transaction table. If it does not exist, perform a rollback.

4. The distributed transaction anomaly detection method according to claim 3, characterized in that, After performing the rollback operation, the following is also included: Determine if an upstream transaction node exists; If present, a rollback instruction is sent to the upstream transaction node so that the upstream transaction node can perform the rollback operation.

5. A distributed transaction anomaly detection system, characterized in that, The system includes: multiple transaction nodes, which include upstream transaction nodes and current transaction nodes; The upstream transaction node is used to send business transaction tasks to the current transaction node; The current transaction node is used to query the local main transaction table before executing the business transaction task, and to perform transaction anomaly detection based on the rollback status in the local main transaction table; The upstream transaction node includes a unique identifier. In response to a rollback request sent by the upstream transaction node, an ignore keyword is added to the unique identifier. A rollback record is generated based on the unique identifier with the added ignore keyword and the rollback request, and the rollback record is added to the local master transaction table. Before executing the business transaction task, querying the local master transaction table includes: performing a query on the local master transaction table; if no rollback record is found, adding a transaction record to the local sub-transaction table; the transaction record corresponds to the business transaction task; after adding the transaction record, performing a second query on the local master transaction table; if no rollback record is found in the local master transaction table, executing the business transaction task. The step of performing transaction anomaly detection based on the rollback status in the local master transaction table includes: If a rollback record exists in the local master transaction table, a transaction exception signal is generated.

6. The distributed transaction anomaly detection system according to claim 5, characterized in that, The plurality of transaction nodes also includes downstream transaction nodes; The upstream transaction node is also used to send a rollback request to the current transaction node; The current transaction node is also used to determine whether there is a downstream transaction node; If it exists, the rollback request is sent to the downstream transaction node so that the downstream transaction node can repeat the step of adding the rollback record in the local master transaction table. If it does not exist, perform a rollback.

7. A distributed transaction anomaly detection device, characterized in that, The device includes: The first query unit is used to query the local main transaction table before executing the business transaction task sent by the upstream transaction node. The upstream transaction node includes a unique identifier. In response to the rollback request sent by the upstream transaction node, an ignore keyword is added to the unique identifier. Based on the unique identifier with the ignore keyword and the rollback request, a rollback record is generated and added to the local main transaction table. The detection unit is used to detect transaction anomalies based on the rollback status in the local master transaction table. The first query unit is further configured to perform a query on the local master transaction table, and add a transaction record to the local sub-transaction table if there is no rollback record; the transaction record corresponds to the business transaction task; after adding the transaction record, perform a second query on the local master transaction table; if there is no rollback record in the local master transaction table, execute the business transaction task; The detection unit is also used to generate a transaction exception signal if a rollback record exists in the local master transaction table.

8. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the distributed transaction anomaly detection method as described in any one of claims 1 to 4.

9. A computer device comprising a memory and a processor, the memory for storing information including program instructions, and the processor for controlling the execution of the program instructions, characterized in that, When the program instructions are loaded and executed by the processor, they implement the distributed transaction anomaly detection method according to any one of claims 1 to 4.

Images