CN111078451B - Distributed transaction processing method and device, computer equipment and storage medium - Google Patents

Distributed transaction processing method and device, computer equipment and storage medium Download PDF

Info

Publication number
CN111078451B
CN111078451B CN201911268592.4A CN201911268592A CN111078451B CN 111078451 B CN111078451 B CN 111078451B CN 201911268592 A CN201911268592 A CN 201911268592A CN 111078451 B CN111078451 B CN 111078451B
Authority
CN
China
Prior art keywords
transaction
identifier
participant node
storage space
submitted
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201911268592.4A
Other languages
Chinese (zh)
Other versions
CN111078451A (en
Inventor
赵伟
唐颢
赵东志
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN201911268592.4A priority Critical patent/CN111078451B/en
Publication of CN111078451A publication Critical patent/CN111078451A/en
Application granted granted Critical
Publication of CN111078451B publication Critical patent/CN111078451B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0715—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a system implementing multitasking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793—Remedial or corrective actions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1443—Transmit or communication errors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1464—Management of the backup or restore process for networked environments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1469—Backup restoration techniques

Abstract

The application relates to a distributed transaction processing method, a device, computer equipment and a storage medium, wherein the method comprises the following steps: acquiring an identifier of a transaction to be submitted; writing the identification of the transaction and the to-be-submitted state mark corresponding to the identification of the transaction into a preset storage space; when the writing processing aiming at the preset storage space is overtime, reading a to-be-submitted state mark corresponding to the identification of the transaction from the preset storage space; when the state mark to be submitted corresponding to the identification of the transaction is read, sending a third submission request aiming at the transaction to each participant node in the distributed system; the third commit request to instruct the participant node to commit the transaction. According to the scheme, the efficiency of completing the transaction can be improved.

Description

Distributed transaction processing method and device, computer equipment and storage medium
The application is a divisional application with the name of 'distributed transaction exception handling method, device, computer equipment and storage medium' filed by the Chinese patent office on 08/05/2019 with the application number of 201910718775.5, the entire contents of which are incorporated by reference in the application.
Technical Field
The present invention relates to the field of computer technologies, and in particular, to a distributed transaction processing method and apparatus, a computer device, and a storage medium.
Background
With the rapid development of science and technology, various technologies emerge endlessly, and the distributed transaction processing technology is also widely applied in daily life. Two-phase commit is a more common distributed transaction commit method. However, when a distributed transaction is committed in two phases, corresponding processing needs to be performed according to the transaction state. However, it is often the case that the state of a transaction is lost, so that the transaction cannot be committed.
In the traditional method, under the condition that a participant node loses the state of the participant node, the transaction log of the participant node is read, the state of the participant node is judged according to the transaction log, then the participant node actively communicates with a transaction manager to inform that the participant node is in an uncommitted state currently, so that the transaction manager can confirm the state of other participant nodes, and after the confirmation state is finished, a submission request is sent to each participant node again to promote the completion of the whole transaction. In the traditional method, the participant nodes need to communicate with the coordinator according to the self transaction logs, and then the coordinator confirms the state of each participant node, so that the efficiency of completing the transaction is low.
Disclosure of Invention
Therefore, it is necessary to provide a distributed transaction processing method, apparatus, computer device and storage medium for solving the problem of relatively low efficiency of completing transactions in the conventional method.
A method of distributed transaction processing, the method comprising:
acquiring an identifier of a transaction to be submitted;
writing the identification of the transaction and the to-be-submitted state mark corresponding to the identification of the transaction into a preset storage space;
when the writing processing aiming at the preset storage space is overtime, reading a to-be-submitted state mark corresponding to the identification of the transaction from the preset storage space;
when the state mark to be submitted corresponding to the identification of the transaction is read, sending a third submission request aiming at the transaction to each participant node in the distributed system; the third commit request to instruct the participant node to commit the transaction.
In one embodiment, the method further comprises:
when the writing processing is down, the step of reading the status mark to be submitted corresponding to the identification of the transaction from the preset storage space is executed;
when the write processing fails, sending a rollback request to each participant node; the rollback request is used for instructing each participant node to rollback the transaction.
In one embodiment, the identifier of the transaction stored in the preset storage space corresponds to only one state mark; the method further comprises the following steps:
when the state mark to be submitted corresponding to the identification of the transaction is not read, correspondingly writing the identification of the transaction and the suspension state mark into the preset storage space;
reading the state mark corresponding to the transaction identifier from the preset storage space again;
and when the status mark read again is the status mark to be submitted, sending a fourth submission request aiming at the transaction to the participant node in the distributed system.
In one embodiment, the method further comprises:
when the status mark read again is the suspension status mark, a rollback request is sent to each participant node; the rollback request is used for instructing each participant node to rollback the transaction.
In one embodiment, the transaction to be committed is a transaction whose pre-commit processing is successful;
before the obtaining the identification of the transaction to be committed, the method further comprises:
when the pre-commit processing for the transaction is abnormal, then
Sending a rollback request to each of the participant nodes; the rollback request is used for instructing each participant node to rollback the transaction.
In one embodiment, the method further comprises:
when the write-in processing aiming at the preset storage space is normal, sending a first submission request aiming at the transaction to a participant node in the distributed system;
when the first submission request executed by the participant node is abnormal, then
Reading a to-be-submitted state mark corresponding to the identification of the transaction from the preset storage space;
sending a second submission request to the participant node according to the status mark to be submitted; the second commit request is to instruct the participant node to commit the transaction.
In one embodiment, the reading, from the preset storage space, the status flag to be committed corresponding to the identifier of the transaction includes:
reading a to-be-submitted state mark corresponding to the transaction identifier from the preset storage space through the agent nodes respectively arranged aiming at each participant node;
the sending a second commit request to the participant node according to the to-be-committed status flag includes:
and sending a second submission request to the participant node through each agent node according to the state mark to be submitted.
In one embodiment, the method further comprises:
acquiring an identification set of a transaction to be submitted from participant nodes corresponding to the agent nodes at preset time intervals through each agent node;
and when the identifiers of the transaction to be submitted all exist in the identifier sets obtained at least twice, judging that the first submission request executed by the participant node is abnormal.
In one embodiment, the method further comprises:
respectively acquiring an identifier subset of a transaction to be submitted from each participant node to obtain an identifier total set;
acquiring the generation time of each identifier in the total identifier set;
selecting the earliest generation time to obtain a reference time;
and deleting the transaction log corresponding to the identifier with the writing time earlier than the reference time from the preset storage space.
In one embodiment, the method further comprises:
when the identifier of each transaction is generated, generating a timestamp for representing the generation time of the identifier according to the current time;
generating an identifier uniquely identifying the transaction; the timestamp is included in the field of the identifier;
the acquiring the generation time of each identifier in the total identifier set comprises:
and analyzing the fields of all the identifiers in the total identifier set to obtain the time stamps in the identifiers.
In one embodiment, the participant node is a blockchain node.
A distributed transaction processing apparatus, the apparatus comprising:
the state writing module is used for acquiring the identifier of the transaction to be submitted; writing the identification of the transaction and the to-be-submitted state mark corresponding to the identification of the transaction into a preset storage space;
the state reading module is used for reading a to-be-submitted state mark corresponding to the identifier of the transaction from a preset storage space when the writing processing aiming at the preset storage space is overtime;
the submitting module is used for sending a third submitting request aiming at the transaction to each participant node in the distributed system when the to-be-submitted state mark corresponding to the identification of the transaction is read; the third commit request to instruct the participant node to commit the transaction.
A computer device comprising a memory and a processor, the memory having stored therein a computer program that, when executed by the processor, causes the processor to perform the steps of:
acquiring an identifier of a transaction to be submitted;
writing the identification of the transaction and the to-be-submitted state mark corresponding to the identification of the transaction into a preset storage space;
when the writing processing aiming at the preset storage space is overtime, reading a to-be-submitted state mark corresponding to the identification of the transaction from the preset storage space;
when the state mark to be submitted corresponding to the identification of the transaction is read, sending a third submission request aiming at the transaction to each participant node in the distributed system; the third commit request to instruct the participant node to commit the transaction.
A computer-readable storage medium having stored thereon a computer program which, when executed by a processor, causes the processor to perform the steps of:
acquiring an identifier of a transaction to be submitted;
writing the identification of the transaction and the to-be-submitted state mark corresponding to the identification of the transaction into a preset storage space;
when the writing processing aiming at the preset storage space is overtime, reading a to-be-submitted state mark corresponding to the identification of the transaction from the preset storage space;
when the state mark to be submitted corresponding to the identification of the transaction is read, sending a third submission request aiming at the transaction to each participant node in the distributed system; the third commit request to instruct the participant node to commit the transaction.
According to the distributed transaction processing method, the distributed transaction processing device, the computer equipment and the storage medium, aiming at a transaction to be submitted, before a submission request is issued to each participant node, the transaction manager writes an identifier of the transaction and a status mark to be submitted corresponding to the identifier of the transaction into a preset storage space, reads a corresponding status mark to be submitted from the preset storage space when the writing processing is overtime, and can directly trigger the submission request to each participant node according to the status mark to be submitted when the corresponding status mark to be submitted is read. In this way, by writing the to-be-committed status flag into the preset storage space, even when the writing is overtime, each participant node in the distributed system can be instructed to commit the transaction by reading the to-be-committed status flag from the preset storage space, and compared with the conventional method which needs complicated status feedback and status confirmation, the efficiency of completing the transaction is improved.
Drawings
FIG. 1 is a diagram of an application scenario of a distributed transaction exception handling method in one embodiment;
FIG. 2A is a diagram illustrating an exemplary implementation of a distributed transaction exception handling method in accordance with an embodiment;
FIG. 2B is a diagram illustrating an exemplary implementation of a distributed transaction exception handling method in accordance with an embodiment;
FIG. 3 is a flow diagram that illustrates a method for distributed transaction exception handling, according to one embodiment;
FIG. 4 is a schematic diagram illustrating the clearing of distributed transaction logs in one embodiment;
FIG. 5 is a flowchart illustrating a distributed transaction exception handling method according to another embodiment;
FIG. 6 is a simplified timing diagram of a conventional method in one embodiment;
FIG. 7 is a simplified timing diagram of a distributed transaction exception handling method according to the present application, in one embodiment;
FIG. 8 is a block diagram of a distributed transaction exception handling apparatus in one embodiment;
FIG. 9 is a block diagram of a distributed transaction exception handling apparatus in another embodiment;
FIG. 10 is a block diagram of a computer device in one embodiment.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
FIG. 1 is a diagram of an application scenario of the distributed transaction exception handling method in one embodiment. Referring to fig. 1, the application scenario includes a transaction manager 110 and a plurality of participant nodes 120 connected via a network. The participant node 120 is a database. The transaction manager 110 is a device that manages transactions. The transaction manager 110 may be a server. The server may be implemented as a stand-alone server or as a server cluster of multiple physical servers.
The transaction manager 110 may obtain an identification of the transaction to be committed; and correspondingly writing the identification of the transaction and the state mark to be submitted into the preset storage space. The transaction manager 110 may send a first commit request for the transaction to each participant node 120 in the distributed system. When the first commit request executed by the participant node 120 is abnormal, the transaction manager 110 may read a to-be-committed status flag corresponding to the identifier of the transaction from a preset storage space. The transaction manager 110 may send a second commit request to the participant node 120 based on the to-commit status flag; a second commit request instructing the participant node 120 to commit the transaction.
Fig. 2A is an application scenario diagram of a distributed transaction exception handling method in another embodiment. Referring to fig. 2A, the application scenario includes a transaction manager 110, a plurality of participant nodes 120, a storage device 130, and a proxy node 140 respectively disposed corresponding to each participant node 120. The storage device 130 is a device for providing a preset storage space. The proxy node 140, which is a device deployed with each participant node 120, is used to detect and handle transaction exception states.
The transaction manager 110 may obtain an identifier of a transaction to be committed, and write the identifier of the transaction and a to-be-committed status flag corresponding to the identifier of the transaction into a preset storage space provided by the storage device 130. The transaction manager 110 may send a first commit request for the transaction to each participant node 120 in the distributed system. When each agent node 140 detects that the participant node 120 corresponding to itself executes the first commit request and is abnormal, the to-be-committed status flag corresponding to the identifier of the transaction is read from the preset storage space provided by the storage device 130. Each agent node 140 may send a second submission request to the corresponding participant node 140 according to the status flag to be submitted; the second commit request is used to instruct the participant node 140 to commit the transaction.
It is understood that the function of the proxy node may also be completed by the transaction manager itself, a transaction manager may be deployed corresponding to each participant node, and a background thread is started in each transaction manager to perform the same operation as the proxy node.
It is to be appreciated that the participant node 120 in fig. 2A may be a block chain node. Fig. 2B is an application scenario diagram with a blockchain node as a participant node. Referring to fig. 2B, the application scenario includes a transaction manager 110, a plurality of blockchain nodes 150, a storage device 130, and a proxy node 140 respectively corresponding to each blockchain node 150.
FIG. 3 is a flow diagram that illustrates a method for distributed transaction exception handling, according to an embodiment. The distributed transaction exception handling method in this embodiment may be applied to a computer device, and is mainly illustrated by taking the computer device as the transaction manager 110 in fig. 1. Referring to fig. 3, the method specifically includes the following steps:
s302, acquiring the identification of the transaction to be submitted.
The transaction to be committed refers to a transaction that is successful in pre-commit processing but not yet committed. The pre-commit refers to a process of executing the transaction in advance in the local of the participant node before the participant node commits the transaction.
And the identification of the transaction is used for uniquely identifying the transaction. A transaction, refers to a series of operations performed as a single logical unit of work, either performed entirely or not performed at all.
It is understood that the transaction in the embodiments of the present application refers to a distributed transaction. It is understood that distributed transaction means that the participants of the transaction, the servers supporting the transaction, the database and the transaction manager are respectively located on different nodes of different distributed systems.
In particular, the user may determine a participant node to execute the transaction (i.e., a database to execute the transaction) based on the terminal sending a start instruction to execute the transaction to the transaction manager, and inform the transaction manager of the determined participant node. The transaction manager, upon receiving the start instruction, may send a start request to the determined participant nodes to ask whether each participant node can start executing the transaction. Each participant node responds to the start request, starts the transaction locally at each participant node, and returns a response message to the transaction manager that has already started.
The transaction manager, upon receiving the response message, may then enter a pre-commit phase. In particular, the transaction manager may send a pre-commit request to each participant node and wait for replies from all participant nodes. The pre-commit request carries the content that each participant node needs to complete for the transaction. The pre-submission request is used for instructing each participant node to execute the transaction according to the carried content, but not to submit the transaction after execution.
It can be understood that, in the distributed system, since one transaction is completed by the joint participation of a plurality of participant nodes, each participant node completes its corresponding branch transaction locally, thereby completing the whole transaction. It should be noted that the branch transactions corresponding to all participant nodes form a complete transaction.
To facilitate an understanding of the relationship between a branch transaction and a complete transaction, an illustration is now provided. Assume a transfer scenario where 100 elements are transferred from account a to account B. Then the transfer of 100 elements from account a to account B is a complete transaction. Then, the database corresponding to the account a and the database corresponding to the account B are respectively a participant node, i.e. a participant node a and a participant node B. When executing the transaction, the matter to be done by the participant node a is a branch transaction 1 of deducting 100 yuan from the account a, and the matter to be done by the participant node B is a branch transaction 2 of adding 100 yuan to the account B. The branch transaction 1 and the branch transaction 2 completed by the participant node a and the participant node b form a complete transaction. Participant node a and participant node b together complete this complete transaction.
Therefore, in the pre-commit stage, the participant node does not commit the executed branch transaction after the participant node locally executes the branch transaction corresponding to the participant node according to the received pre-commit request. When all participant nodes successfully execute the contents of the transaction that they need to complete (i.e., a branch transaction), a message is returned to the transaction manager that the transaction can be committed. In this case, the transaction is entered into the to-be-committed state and belongs to the to-be-committed transaction. The transaction manager may then obtain an identification of the transaction to be committed.
In one embodiment, the transaction manager may send the start request and the pre-commit request to each participant node through a standard interface provided by each participant node for interfacing with the transaction manager.
In one embodiment, the standard interface may be an interface implemented based on the XA protocol. The XA protocol, first proposed by Tuxedo, is handed over to the X/Open organization as an interface standard for the resource manager (database) and the transaction manager. Currently, many open source databases (e.g., mysql, postgresql, etc.) provide this interface support.
S304, writing the transaction identifier and the to-be-submitted state mark corresponding to the transaction identifier into the preset storage space.
The preset storage space is a preset storage space for writing the transaction state. And the to-be-committed state mark is used for indicating that the transaction is in the to-be-committed state.
In one embodiment, the predetermined storage space may be a dedicated storage device. In another embodiment, the predetermined storage space may also be a storage area partitioned from the transaction manager for storing the transaction status. Here, a specific implementation form of the preset storage space is not limited.
Specifically, the transaction manager may correspondingly write the identifier of the transaction and the to-be-committed status flag into the preset storage space. That is, in the preset storage space, the identifier of the transaction to be committed and the status flag to be committed are stored correspondingly, so as to indicate that the transaction belongs to the status to be committed.
In one embodiment, the transaction manager may correspondingly write the identification of the transaction and the status flag to be committed to the preset storage space in the form of "xid: commit". Wherein xid is the identification of the transaction. Commit, i.e. used to indicate that a transaction is in a pending Commit state, is equivalent to a pending Commit status flag.
In one embodiment, the predetermined storage space is a reliable storage space for implementing persistent storage for the written transaction identifier and the to-be-committed status flag.
S306, a first submission request for the transaction is sent to the participant node in the distributed system.
Wherein, the participant node in the distributed system is the node participating in executing the transaction in the distributed system. It is to be understood that the participant node may be a database.
In one embodiment, the participant node may be a blockchain node.
The Blockchain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism and an encryption algorithm.
It can be understood that the transaction is in a pending commit state, meaning that all participant nodes have completed pre-commit processing for the transaction. Then, after correspondingly writing the identifier of the transaction and the to-be-committed status flag into the preset storage space, the transaction manager may send a first commit request for the transaction to each participant node to instruct each participant node to commit the content executed for the transaction.
In one embodiment, the transaction manager may send a first commit request for the transaction to each participant node through a standard interface provided by each participant node for interfacing with the transaction manager.
Specifically, the transaction manager may send a first commit request for the transaction (i.e., "XA commit", where XA is the interface implemented based on the XA protocol, and "XA commit" is the first commit request sent through the interface implemented based on the XA protocol) to each participant node through the interface implemented based on the XA protocol.
S308, when the first submission request executed by the participant node is abnormal, reading a to-be-submitted state mark corresponding to the transaction identifier from the preset storage space.
In particular, each participant node, upon receiving the first commit request, may then commit content executed for the transaction. The results of the commit may include a normal commit success or a commit exception.
When the execution of the first commit request by any one of the participant nodes is abnormal, that is, when not all the participant nodes successfully execute the first commit request, the to-be-committed state flag corresponding to the identifier of the transaction may be read from the preset storage space to know that the transaction is in the to-be-committed state.
S310, sending a second submission request to the participant node according to the status mark to be submitted; a second commit request to instruct the participant node to commit the transaction.
Specifically, the transaction manager may send a second commit request to the participant node according to the read to-be-committed status flag. The participant node may resubmit the transaction after receiving the second commit request. I.e. to re-commit the content executed for the transaction.
It should be noted that, instead of executing steps S308 to S310 by the transaction manager, steps S308 to S310 may be executed by proxy nodes respectively provided for the participant nodes in the application scenario shown in fig. 2.
According to the distributed transaction exception handling method, before a submission request is issued to each participant node for a transaction to be submitted, the transaction manager writes the identifier of the transaction and the status mark to be submitted into the preset storage space correspondingly, and then issues the submission request to each participant node. Therefore, when the first commit request executed by any participant node is abnormal, the to-be-committed state flag corresponding to the transaction identifier can be read from the preset storage space, that is, the transaction is in the to-be-committed state, so that the condition that the transaction state is lost is avoided. Further, a second commit request may be sent to the participant node according to the to-be-committed status flag; the second commit request is to instruct the participant node to resubmit the transaction. The processing can avoid the condition of losing the transaction state when the transaction is submitted without changing the performance of the participant node, thereby greatly reducing the cost.
In addition, modifying the code of the database itself introduces new problems to a large extent, which in turn may lead to a reduction in the performance of the database. By adopting the distributed transaction exception handling method in the embodiments of the application, the problem can be avoided, and the security and the accuracy of the database are improved.
In one embodiment, the method further comprises: when the write-in processing for the preset storage space is normal, executing step S306 to send a first commit request and subsequent steps for the transaction to the participant node in the distributed system; when the write processing fails, sending a rollback request to each participant node; the rollback request is used for instructing each participant node to rollback the transaction.
The writing process for the preset storage space is a process of correspondingly writing the identifier of the transaction and the state mark to be submitted into the preset storage space.
It will be appreciated that the results of the write process may include a write process normal and a write process failure.
The normal write processing for the preset storage space means that the identifier of the transaction and the to-be-committed status flag are written into the preset storage space correspondingly and normally (within a normal time range). That is, the pending commit status of the transaction is normally recorded in the preset memory space.
And the writing processing failure means that the identification of the transaction and the to-be-committed state mark cannot be written into the preset storage space. That is, an error occurs in recording the to-be-committed state of the transaction in the preset storage space, so that the to-be-committed state of the transaction cannot be recorded. Since the transaction manager can correspondingly write the identifier of the transaction and the to-be-committed status flag into the preset storage space in the form of "xid: commit", it is equivalent to that the write transaction status "xid: commit" makes an error.
It is understood that when the write processing for the preset memory space is normal, the state of the normal write transaction is explained. In this way, even if the subsequent commit transaction fails, the to-be-committed status flag corresponding to the identifier of the transaction may be read from the preset storage space, and thus, step S306 may be performed to send the first commit request and the subsequent steps for the transaction to the participant node in the distributed system with confidence.
However, when the write processing fails, it indicates that the preset storage space does not correspond to the identifier of the storage transaction and the to-be-committed status flag, and then the to-be-committed status flag corresponding to the identifier of the transaction cannot be read from the preset storage space. In this case, when an exception occurs in the subsequent processing, the state of the transaction cannot be known from the preset storage space, so that the transaction state is lost. Therefore, the transaction manager may directly send a rollback request to each participant node to instruct each participant node to rollback the branch transaction local to each participant node, thereby avoiding a subsequent case of a lost transaction state. After receiving the rollback request, each participant node may perform rollback processing on the branch transaction of the transaction locally at the participant node to restore the initial state of the unprocessed transaction.
Specifically, the transaction manager may send a rollback request for the transaction (i.e., "XA rollback", where XA is an interface implemented according to the XA protocol, rollback is rollback, and "XA rollback" is a rollback request sent through an interface implemented according to the XA protocol) to each participant node through an interface implemented according to the XA protocol.
In the above embodiment, the write-in process is normal, which means that the to-be-committed state flag can be read from the preset storage space, and then, the first commit request for the transaction can be sent to the participant node in the distributed system, so that even if an exception occurs subsequently, the transaction state can be known, and the commit of the transaction is promoted. And when the write-in processing fails, sending a rollback request to each participant node, and directly rolling back the transaction, so that unnecessary resources are prevented from being wasted for subsequent processing which cannot be solved due to the occurrence of the abnormity.
In one embodiment, the method further comprises: when the writing processing is overtime or down in the writing processing executing process, reading a to-be-submitted state mark corresponding to the identification of the transaction from the preset storage space; and when the status mark to be submitted corresponding to the identification of the transaction is read, sending a third submission request aiming at the transaction to each participant node.
It will be appreciated that the results of the write process may include a write process timeout and a downtime in performing the write process.
The overtime writing process refers to that the process of writing the transaction identifier and the to-be-committed state flag into the preset storage space is overtime, that is, the transaction identifier and the to-be-committed state flag are correspondingly written into the preset storage space within normal time. Since the transaction manager can correspondingly write the identifier of the transaction and the to-be-committed status flag into the preset storage space in the form of "xid: commit", the write processing timeout is equivalent to the write transaction status "xid: commit" timeout.
It will be appreciated that in this case, the transaction manager does not determine whether the identification of the transaction and the to-be-committed status flag are successfully written into the predetermined storage space. Therefore, the timeout of the write process may include two cases, that is, the identifier of the transaction and the to-be-committed status flag are written into the preset storage space correspondingly, and the identifier of the transaction and the to-be-committed status flag are not written into the preset storage space correspondingly.
And performing the downtime in the writing process refers to that the transaction manager is down in the process of writing the identification of the transaction and the state mark to be submitted into the preset storage space. It is understood that the transaction manager is down corresponding to the write transaction status "xid: commit".
In this case, the transaction manager also does not determine whether the identifier of the transaction and the to-be-committed status flag are written into the preset storage space correspondingly. Therefore, the downtime in the write-in processing process may include two cases that the identifier of the transaction and the state flag to be submitted are written into the preset storage space correspondingly, and the identifier of the transaction and the state flag to be submitted are not written into the preset storage space correspondingly.
Then, when the write processing is overtime or down during the write processing, the transaction manager may read the to-be-committed status flag corresponding to the identifier of the transaction from the preset storage space. The identifier of the transaction and the status flag to be committed may be written in the preset storage space, or may not be written in. Then, the to-be-committed status flag corresponding to the identifier of the transaction may be read during reading, and the to-be-committed status flag corresponding to the identifier of the transaction may not be read.
When the to-be-committed status flag corresponding to the identifier of the transaction is read, the transaction manager knows that the transaction is currently in the to-be-committed status, that is, knows the current status of the transaction, and then the transaction manager may send a third commit request for the transaction to each of the participant nodes. A third commit request to indicate to the participant node to commit the pre-committed branch transaction that is to be completed locally at the participant node. Thus, the completion of the transaction is advanced.
It will be appreciated that in one embodiment, when the to-be-committed status flag corresponding to the identity of the transaction is not read, the transaction manager may then send a rollback request directly to each participant node to instruct each participant node to roll back the transaction uniformly. I.e., a rollback request, for each participant node to rollback executed branch transactions locally at the participant node.
In other embodiments, the condition that the write processing is overtime or down during the write processing may be that, during the reading, the transaction manager temporarily has no time to reach the identifier of the corresponding write transaction and the status flag to be committed in the preset storage space, rather than writing. Therefore, in this case, the transaction can be rolled back directly without standing. The transaction manager may read again whether the state flag corresponding to the identifier of the transaction exists from the preset storage space when the time of the first reading reaches a preset time interval, and if not, send a rollback request to each participant node to instruct each participant node to rollback the transaction in a unified manner. The transaction manager may also attempt to write an abort status flag into the preset storage space corresponding to the identifier of the transaction, and obtain the status flag corresponding to the identifier of the transaction from the preset storage space again, and if the status flag corresponding to the identifier of the transaction is still the abort status flag, roll back the transaction, that is, send a roll back request to the participant node. It can be understood that the identifier of the transaction stored in the preset storage space may correspond to only one status flag, or may correspond to record a plurality of status flags. The last state mark can be used as the final state mark according to the latest written state mark. This is not limitative.
It should be noted that, when the write-in processing is overtime or goes down during the write-in processing, the to-be-submitted state flag corresponding to the identifier of the transaction may also be read from the preset storage space by the proxy node; and when the status mark to be submitted corresponding to the identifier of the transaction is read, each agent node sends a third submission request aiming at the transaction to the corresponding participant node so as to instruct each participant node to submit the transaction. That is, each participant node is instructed to commit the branch transaction executing locally, thereby committing the complete transaction.
It will be appreciated that it may be the proxy node itself that is actively doing the detection of pending transactions that are not committed normally. Generally, the condition that the transaction to be submitted is not normally submitted may include that the writing process is overtime or is down during the process of executing the writing process, so when the processing node actively detects the transaction to be submitted that is not normally submitted, it may be known that the writing process is overtime or is down during the process of executing the writing process. Then, the agent node may perform a step of reading the to-be-committed status flag corresponding to the identification of the transaction from a preset storage space. It should be noted that, the agent node may detect the to-be-committed transaction that is not normally committed, or may detect a case of a commit exception, that is, the transaction manager has already sent the first commit request for the transaction to each participant node, but the participant node executes the first commit request and has an exception, in which case, the agent node may also detect the to-be-committed transaction that is not normally committed.
In other embodiments, when the write processing is overtime or down during the execution of the write processing, the transaction manager may notify the agent node, and when the agent node receives the notification from the transaction manager, the agent node may perform the step of reading the to-be-committed status flag corresponding to the identifier of the transaction from the preset storage space.
In the above embodiment, when the write processing is overtime or down during the execution of the write processing, the to-be-submitted status flag corresponding to the identifier of the transaction may also be read from the preset storage space, and when the to-be-submitted status flag corresponding to the identifier of the transaction is read, a third submit request for the transaction is sent to each participant node to promote the submission of the transaction, so that the efficiency of completing the transaction is improved.
In one embodiment, the identity of the transaction stored in the preset memory space corresponds to only one status flag. The method further comprises the following steps: when the state mark to be submitted corresponding to the identification of the transaction is not read, correspondingly writing the identification of the transaction and the suspension state mark into the preset storage space; reading the state mark corresponding to the transaction identifier from the preset storage space again; and when the status mark read again is the status mark to be submitted, sending a fourth submission request aiming at the transaction to the participant node in the distributed system.
In this embodiment, the identifier of the transaction stored in the preset storage space corresponds to only one state flag. That is, once the identification of the corresponding write transaction and the corresponding state flag in the prediction memory space are written, another state flag cannot be added corresponding to the identification of the transaction. For example, if the abort status flag is successfully added to the identifier of the transaction, the pending commit status flag cannot be subsequently added to the identifier of the transaction.
The abort state mark is used for marking that the transaction is in an abort state and a non-processing state.
Specifically, when the to-be-committed status flag corresponding to the identifier of the transaction is not read, the transaction manager may correspondingly write the identifier of the transaction and the abort status flag into the preset storage space.
It is understood that the writing processing result of writing the identifier of the transaction and the abort status flag into the preset storage space may include the situations of writing success and writing failure. When the process of writing the identifier of the transaction and the status flag to be submitted into the preset storage space is overtime or the transaction manager is down, the transaction manager may try to write the status flag to be submitted into the preset storage space only if the status flag to be submitted is not written in time when the status flag to be submitted corresponding to the identifier of the transaction is not read from the preset storage space for the first time. Therefore, when attempting to write the identification and the suspension status flag of the transaction into the preset storage space, the status flag to be committed, which may not be written before, is already written into the preset storage space corresponding to the identification of the transaction. Since the identifier of the transaction stored in the predetermined storage space only corresponds to one status flag, in this case, an abort status flag cannot be written into the predetermined storage space again corresponding to the identifier of the transaction, and thus, the writing of the abort status flag fails.
Furthermore, when attempting to write the identifier and the suspension status flag of the transaction into the preset storage space correspondingly, the status flag to be committed, which may not be written before, is not written into the preset storage space corresponding to the identifier of the transaction. In this case, the identifier of the transaction does not exist in the preset storage space, and the status flag corresponding to the identifier of the transaction does not exist either, so that the identifier of the transaction and the suspension status flag can be correspondingly written into the preset storage space, that is, the writing is successful. It can be understood that, after the identifier of the transaction and the suspension status flag are successfully written into the preset storage space, since the identifier of the transaction stored in the preset storage space only corresponds to one status flag uniquely, the subsequent transaction manager cannot write the to-be-committed status flag corresponding to the identifier of the transaction.
After the identifier and the suspension status flag of the transaction are written into the preset storage space correspondingly, the transaction manager may read the status flag corresponding to the identifier of the transaction from the preset storage space again. When the read state flag is a to-be-committed state flag, that is, it is known that the current transaction state is the to-be-committed state, a fourth commit request for the transaction may be sent to the participant node in the distributed system. A fourth commit request instructing the respective participant nodes to commit the transaction, i.e. the respective participant nodes commit the branch transaction executed locally.
In an embodiment, the agent node may read the to-be-committed status flag corresponding to the identifier of the transaction from the preset storage space, and when the to-be-committed status flag corresponding to the identifier of the transaction is not read, the agent node may correspondingly write the identifier of the transaction and the suspension status flag into the preset storage space. After correspondingly writing the identifier and the suspension state flag of the transaction into the preset storage space, the proxy node may read the state flag corresponding to the identifier of the transaction from the preset storage space again; when the status flag read again is a pending commit status flag, the broker node may then send a fourth commit request for the transaction to the participant nodes in the distributed system.
In the above embodiment, when the to-be-committed status flag corresponding to the identifier of the transaction is not read, the identifier of the transaction and the suspension status flag are correspondingly written into the preset storage space. Therefore, the situation that the identification of one transaction in the preset storage space corresponds to two states can be avoided. And then, reading the state mark corresponding to the identification of the transaction from the preset storage space again. Therefore, the transaction state uniquely corresponding to the transaction identifier can be read, so that how to process the transaction can be determined according to the transaction state, and the problem of transaction state loss is solved. And when the status mark read again is the status mark to be submitted, sending a fourth submission request aiming at the transaction to the participant node in the distributed system. That is, it is equivalent to being able to give a buffer time for a write timeout or downtime, during which the pending commit status flag may still be written to the preset storage space, and if written, it can be read, so that the commit of the transaction can be advanced.
In one embodiment, the method further comprises: when the status mark read again is the suspension status mark, a rollback request is sent to each participant node; the rollback request is used for instructing each participant node to rollback the transaction.
It can be understood that, if the to-be-committed status flag is temporarily not written in the identifier corresponding to the transaction in the preset storage space when the identifier and the suspension status flag of the transaction are written in the preset storage space correspondingly, the transaction manager may successfully write the identifier and the suspension status flag of the transaction in the preset storage space correspondingly, and subsequently cannot write the to-be-committed status flag corresponding to the identifier of the transaction any more. In this case, the status flag corresponding to the identifier of the transaction read from the preset storage space by the transaction manager is an abort status flag. When the status flag read again is the abort status flag, it indicates that the transaction is to be aborted, and the transaction manager may send a rollback request to each participant node according to the abort status flag. The rollback request is to instruct each participant node to rollback the transaction. Thereby realizing the uniform rollback of each participant node to the transaction.
In one embodiment, when the status flag read again by the proxy node is the suspension status flag, the proxy node may send a rollback request to each participant node; the rollback request is used for instructing each participant node to rollback the transaction.
In the above embodiment, when the status flag read again is the abort status flag, it may be explicitly known that the status of the transaction is the abort status, and at this time, a rollback request may be sent to each participant node; the rollback request is used for instructing each participant node to rollback the transaction. Therefore, the nodes of all participants are rolled back uniformly under the condition of not losing the transaction state, and the uniformity of distributed processing is ensured.
In one embodiment, the transaction to be committed is a transaction whose pre-commit process was successful. Before acquiring the identification of the transaction to be committed in step S202, the method further comprises: when the pre-submission processing of the transaction is abnormal, a rollback request is sent to each participant node; the rollback request is used for instructing each participant node to rollback the transaction.
It is understood that a transaction to be committed is a transaction that is in a to-be-committed state.
It will be appreciated that the pre-commit process is the preparation phase. The transaction manager may send a pre-commit request to each participant node, thereby entering a pre-commit processing phase. Each participant node may pre-commit the transaction.
In one embodiment, the transaction manager may send pre-commit requests to the participant nodes through an interface implemented over the XA protocol. Then the pre-commit processing phase is the xa prepare phase.
When the pre-submission of each participant node to a transaction is successful, the transaction is in a to-be-submitted state and belongs to the to-be-submitted transaction. When the pre-commit processing of the transaction by each participant node is abnormal, the transaction manager may then send a rollback request to the participant node. A rollback request for instructing each of the participant nodes to roll back transactions uniformly at their respective local. It will be appreciated that the pre-commit processing is anomalous, and may include a pre-commit processing timeout or a pre-commit processing error (i.e., failure).
In the above embodiment, when the pre-commit processing of the transaction is abnormal, it indicates that the transaction is not ready, and each participant node may be directly instructed to roll back the transaction, so as to avoid resource waste caused by being in an abnormal state all the time.
In one embodiment, step S308 includes: and when the participant node executes the first submission request and is abnormal, reading the to-be-submitted state mark corresponding to the identifier of the transaction from the preset storage space through the agent nodes respectively arranged aiming at the participant nodes. Step S310 includes: and sending a second submission request to the participant node through each agent node according to the state mark to be submitted.
It should be noted that, for each participant node, a corresponding proxy node is correspondingly deployed. I.e. the participant nodes and the proxy nodes are in one-to-one correspondence. A second commit request to instruct the participant node to commit the transaction.
It can be understood that the agent node itself may actively detect the corresponding participant node to determine whether the corresponding participant node executes the first commit request, and when it is determined that the first commit request is abnormal, the agent node reads the to-be-committed status flag corresponding to the identifier of the transaction from the preset storage space, and sends the second commit request to the corresponding participant node according to the to-be-committed status flag.
In other embodiments, the transaction manager may notify, when it is determined that the participant node executes the first commit request and is abnormal, an agent node corresponding to the abnormal participant node, where the agent node may read, after receiving the notification that the participant node executes the first instruction and is abnormal, a to-be-committed status flag corresponding to the identifier of the transaction from the preset storage space, and send, according to the to-be-committed status flag, the second commit request to the corresponding participant node.
In one embodiment, the method further comprises: acquiring an identification set of a transaction to be submitted from participant nodes corresponding to the agent nodes at preset time intervals through each agent node; and when the identifiers of the transaction to be submitted all exist in the identifier sets obtained at least twice, judging that the first submission request executed by the participant node is abnormal.
The identifier of the transaction to be committed refers to a unique identifier of the transaction to be committed, and is used for uniquely identifying the transaction to be committed. The set of identifications of transactions to commit is a set that includes an identification of at least one transaction to commit. It can be understood that, in the obtained identification set of the transaction to be committed from each participant node, at least one identification of the transaction to be committed by the participant node is successfully pre-committed.
The preset time interval is larger than the normal commit duration of the transaction. The normal commit duration is the duration that is required for a transaction to be committed normally.
Specifically, the proxy node may autonomously acquire, at preset time intervals, an identifier set of a transaction to be submitted from a participant node corresponding to the proxy node. Since the preset time interval is greater than the normal commit duration of the transaction, if the transaction is normally committed, it is unlikely to occur twice in the acquired identification set. Therefore, when the identifier of the to-be-committed transaction exists in the identifier set obtained at least twice, it indicates that the to-be-committed transaction is not committed within the normal commit duration, and it is an exception in the commit stage, so that it can be determined that the participant node has an exception in executing the first commit request. The proxy node may then perform step S308 and subsequent steps.
In the above embodiment, the to-be-committed status flag corresponding to the transaction identifier is autonomously read from the preset storage space by the proxy node, and the second commit request is sent to the participant node by each proxy node according to the to-be-committed status flag. Equivalently, by adding the agent module, the abnormal condition of transaction submission can be realized, and the transaction is resubmitted, so that the completion of the transaction is promoted without the complex operation of changing the code of the database, and the efficiency of transaction completion is improved.
In one embodiment, the method further comprises: respectively acquiring an identifier subset of a transaction to be submitted from each participant node to obtain an identifier total set; acquiring the generation time of each identifier in the total identifier set; selecting the earliest generation time to obtain a reference time; and deleting the transaction log corresponding to the identifier with the writing time earlier than the reference time from the preset storage space.
It will be appreciated that each participant node has stored therein an identified subset of the transactions to be committed. The subset of identifiers of the transactions to be committed stored in each participant node refers to the set of identifiers of the transactions to be committed by that participant node. That is, the identifier subset of the to-be-committed transaction includes an identifier of at least one to-be-stored participant node committed transaction.
The total set of identifiers is a set including subsets of identifiers. For example, there are two participant nodes db1 and db2, where the subset of identifiers for the transaction to be committed by participant node db1 is (xid1, xid2), and the subset of identifiers for the transaction to be committed by participant node db2 is (xid1, xid3), then the total set of identifiers for the transaction to be committed is (xid1, xid2, xid 3).
The identified generation time is the identified time at which the transaction was generated. It is to be appreciated that the time of generation of the indicia can be in a time format (e.g., year, month, day) or in a time stamp format. The expression of the generation time of the flag is not limited here. The reference time is a time for making a reference for comparison. And the writing time is the time for writing the identification of the transaction into the preset storage space.
Specifically, after the transaction manager obtains the identifier subsets from each participant node, the identifier subsets may be summarized to obtain an identifier total set. The transaction manager may obtain the generation time of each identifier in the total set of identifiers, compare the generation times of the identifiers, and select the earliest generation time as the reference time. The transaction manager may search, from the identifiers of the transactions stored in the preset storage space, the identifier of the transaction whose write time is earlier than the reference time, and then delete the transaction log corresponding to the searched identifier of the transaction.
It should be noted that the generation time of the identifier of the transaction may be stored in the preset storage space corresponding to the identifier of the transaction, and is not a component of the identifier of the transaction. Furthermore, the generation time of the identification of the transaction may also be a component of the identification, i.e. belong to a part of the field that constitutes the identification. This is not limitative.
It will be appreciated that the transaction log includes an identification of the transaction and a status flag corresponding to the identification of the transaction. Thus, the write time of the identification of the transaction is the write time of the transaction log. And deleting the transaction log, namely deleting the state marks which are included in the transaction log, namely the identifier of the transaction with the writing time earlier than the reference time and the identifier of the transaction. Then, when the identifier of the transaction and the status flag to be committed are written in the preset storage space, in this case, the status flag included in the transaction log is the status flag to be committed. When the identifier of the transaction and the abort status flag are written in the preset storage space correspondingly, the status flag included in the transaction log is the abort status flag (for example, xid: abort, where xid is the identifier of the transaction, and abort is indicated by abort status).
FIG. 4 is a schematic diagram illustrating the clearing of distributed transaction logs in one embodiment. Referring to fig. 4, agent nodes agent1 through agent3 may obtain identifier subsets S1 through S3 of the transaction to be submitted from corresponding participant nodes db1 through db3, respectively, to obtain an identifier total set S, and then select an identifier with the earliest generation time from the identifier total set S, to obtain a reference tmin. The preset storage space comprises written transaction logs, and the transaction logs 1-logn respectively have corresponding writing time t 1-tn. Comparing t 1-tn with tmin respectively, and deleting the transaction log corresponding to the writing time less than tmin. For example, if t 1-t 3 are all less than tmin, log 1-logn can be deleted from the predetermined storage space.
In one embodiment, if the subset of identifiers is not available from a participant node, the deletion operation may be suspended to avoid the problem of a false deletion. For example, when the participant node db2 is unavailable, the broker nodes of the other participant nodes db may find that a connection cannot be established with the participant node db2, and the other dbs may stop deleting the transaction log. When db2 is available, if there is a transaction xid1 pending on db2, then the proxy node of the other participant node db can protect its transaction log from being deleted until the transaction xid1 commits by getting the timestamp of the transaction xid 1.
It will be appreciated that assuming a base time of tmin, if a participant node db1 started a transaction xid1 before tmin, but did not pre-commit the transaction xid1, then the transaction does not belong to a transaction to be committed for the participant node db 1. Therefore, the transaction manager must not write the transaction log of xid1 yet, that is, the identifier xid1 of the transaction and the status flag to be committed are not written into the preset storage space as the transaction log, and xid1 will not exist in the total set of identifiers of the transaction to be committed currently. Subsequently, if the transaction log of xid1 is written in the preset storage space, the writing time is inevitably greater than the reference time tmin in the total identification set of the transaction to be currently committed (because tmin is the already generated time, the subsequently newly generated writing time is inevitably later than tmin), so that when the transaction log is cleared, the newly written transaction log can be avoided being deleted. And the transaction log with the writing time earlier than the reference time tmin is bound to have been successfully submitted by the corresponding transaction. Therefore, when the transaction log is cleared, the unnecessary transaction log which is successfully submitted can be successfully deleted, and the newly written transaction log which needs to be reserved can be prevented from being deleted.
For ease of understanding, a counter-syndrome method is used for illustration. Assuming that the reference time tmin is the generation time of the identification of transaction A and the write time of the transaction log of transaction B is earlier than the reference time tmin, then the generation time of the identification of transaction B must be earlier than the reference time tmin (since the write time must be later than the generation time for the same transaction, then in the case of a write time earlier than the reference time tmin, then its identification must be generated earlier than the reference time tmin). If the transaction B is not successfully submitted, the identifier of the transaction B is inevitably present in the total identifier set, and since the generation time of the identifier of the transaction B is inevitably earlier than the reference time tmin, the earliest time tmin selected from the generation times of the identifiers of the total identifier set is not the generation time of the identifier of the transaction a, which is contradictory to the former assumption that the reference time tmin is the generation time of the identifier of the transaction a. Thus, assuming this is false, it is certain that transaction B, which has been granted a write time earlier than the base time tmin, will commit successfully. The transaction log retention of transaction B that was committed successfully is not meaningful and can therefore be deleted directly. Therefore, according to the method of the embodiment, when the transaction log is cleared, the unnecessary transaction log which is successfully submitted can be successfully deleted, and the newly written transaction log which needs to be reserved can be prevented from being deleted.
In the above embodiment, the identifier subsets of the to-be-committed transaction in each participant node are collected to obtain the total identifier set of the to-be-committed transaction, and the earliest generation time is selected from the generation times of all the identifiers in the total identifier set as the reference time. The transaction log of the completed submitted transaction can be accurately determined, so that the accuracy of cleaning the transaction log is improved. In addition, the transaction log is cleared, so that the storage resource can be saved, and the system performance is improved.
In one embodiment, the method further comprises: when the identifier of each transaction is generated, generating a timestamp for representing the generation time of the identifier according to the current time; generating an identifier uniquely identifying the transaction; the identified field includes a timestamp. In this embodiment, obtaining the generation time of each identifier in the total identifier set includes: and analyzing the fields of all the identifiers in the identifier total set to obtain the time stamps in the identifiers.
Specifically, the transaction manager, when generating the identifier of each transaction, may generate a timestamp from the current time, where the timestamp is used to characterize the generation time of the identifier. The transaction manager can generate a unique identification for the transaction based on the timestamp. Wherein the timestamp is included in a field of the identification of the transaction.
Then, when the generation time of each identifier in the total set of identifiers is obtained, the transaction manager may parse the field identifying each identifier in the total set of identifiers to extract the timestamp characterizing the generation time of the identifier. The transaction manager may compare all timestamps extracted from the total set of identifiers and select the earliest timestamp as the base time. The transaction manager may filter, from the preset storage space, the identifier of the transaction whose timestamp is earlier than the reference time, and then delete the transaction log corresponding to the identifier of the filtered transaction.
In the embodiment, the timestamp representing the generation time of the identifier of the transaction is used as a field forming the identifier of the transaction, so that the generation time is prevented from being recorded for the identifier of the transaction, and the storage resource is saved. In addition, when the generation time is acquired, the timestamp is directly analyzed from the identification of the transaction, so that the efficiency is improved.
FIG. 5 is a flowchart illustrating a distributed transaction exception handling method according to another embodiment. Referring to fig. 5, the method specifically includes the following steps:
s502, the transaction manager receives a start instruction for the transaction and sends a start request to the participant node which determines to execute the transaction; and receiving response messages returned by the participant nodes to the starting request.
S504, the transaction manager sends a pre-submission request aiming at the transaction to each participant node; and receiving a response message returned by each participant node after the participant node performs local pre-submission processing on the transaction. When the pre-commit process is successful, the transaction enters a to-be-committed state, belonging to the to-be-committed transaction, i.e., step S506 is executed, and when the pre-commit process fails, step S518 is executed.
S506, the transaction manager obtains the identifier of the transaction to be submitted, and writes the identifier of the transaction and the status mark to be submitted corresponding to the identifier of the transaction into the preset storage space. When the write processing for the preset storage space is normal, executing step S508; when the write-in processing is overtime or down in the process of executing the write-in processing, executing step S510; when the writing process fails, step S518 is executed.
S508, the transaction manager sends a first commit request for the transaction to participant nodes in the distributed system. When the first submission request executed by the participant node is abnormal, reading a to-be-submitted state mark corresponding to the transaction identifier from a preset storage space through the agent nodes respectively arranged aiming at each participant node; and sending a second submission request to the participant node through each agent node according to the status mark to be submitted.
In one embodiment, the participant node may be a blockchain node.
And S510, reading the state mark to be submitted corresponding to the transaction identifier from the preset storage space through each proxy node. When the to-be-committed status flag corresponding to the identifier of the transaction is read, step S512 is executed, and when the to-be-committed status flag corresponding to the identifier of the transaction is not read, step S514 is executed.
S512, sending a third submission request aiming at the transaction to each participant node through each proxy node.
S514, correspondingly writing the identification and the suspension state mark of the transaction into the preset storage space through each proxy node; and reading the state mark corresponding to the identification of the transaction from the preset storage space again. When the status flag read again is the status flag to be committed, step S516 is executed. When the status flag read again is the suspension status flag, step S518 is executed.
And S516, sending a fourth submission request aiming at the transaction to the participant nodes of the distributed system through the proxy nodes.
S518, sending a rollback request to each participant node through each proxy node; a rollback request to instruct each participant node to rollback the transaction.
S520, respectively acquiring identifier subsets of the to-be-submitted transaction from each participant node through each agent node to obtain an identifier total set; analyzing the fields of all the identifiers in the identifier total set to obtain the time stamps in the identifiers; selecting the earliest timestamp to obtain the reference time; and deleting the transaction log corresponding to the identifier with the writing time earlier than the reference time from the preset storage space.
It can be understood that, in this embodiment, when generating the identifier of each transaction, the transaction manager generates, according to the current time, a timestamp for characterizing the generation time of the identifier; generating an identifier uniquely identifying the transaction; the identified field includes a timestamp.
According to the distributed transaction exception handling method, before a submission request is issued to each participant node for a transaction to be submitted, the transaction manager writes the identifier of the transaction and the status mark to be submitted into the preset storage space correspondingly, and then issues the submission request to each participant node. Therefore, when the first commit request executed by any participant node is abnormal, the to-be-committed state flag corresponding to the transaction identifier can be read from the preset storage space, that is, the transaction is in the to-be-committed state, so that the condition that the transaction state is lost is avoided. Further, a second commit request may be sent to the participant node according to the to-be-committed status flag; the second commit request is to instruct the participant node to resubmit the transaction. The processing can avoid the condition of losing the transaction state when the transaction is submitted without changing the performance of the participant node, thereby greatly reducing the cost.
In addition, modifying the code of the database itself introduces new problems to a large extent, which in turn may lead to a reduction in the performance of the database. By adopting the distributed transaction exception handling method in the embodiments of the application, the problem can be avoided, and the security and the accuracy of the database are improved
FIG. 6 is a simplified timing diagram of a conventional method in one embodiment. FIG. 7 is a simplified timing diagram of a distributed transaction exception handling method according to the present application, in one embodiment. The differences and benefits of the distributed transaction exception handling method in the embodiments of the present application over the conventional method will now be illustrated with reference to fig. 6 and 7.
Referring to fig. 6 and 7, db1 and db2 belong to two participant nodes. The reliable storage in fig. 6 and 7 is the predetermined storage space. Referring to fig. 6, in the conventional method, a user sends a start instruction (i.e., Begin) for a transaction to a transaction manager through a terminal and determines participant nodes db1 and db2 that execute the transaction. The transaction manager sends a start request (i.e., xa start) to db1 and db2 through the xa interface provided by db1 and db 2. db1 and db2 will send responses to the transaction manager for the begin request. The user may send a commit instruction for the transaction to the transaction manager via the terminal. The transaction manager can send pre-commit requests (i.e., xa prepare xid) to db1 and db2 through the xa interface provided by db1 and db 2. After db1 and db2 complete the pre-commit process for the transaction, the transaction manager can send commit requests (i.e., xa commit xid) to db1 and db 2. After db1 and db2 have successfully committed the transaction, the transaction manager can send a notification of the success of the commit (i.e., "ok" in FIGS. 6 and 7) to the terminal used by the user.
Referring to fig. 7, in the distributed transaction exception handling method in the embodiment of the present application, after db1 and db2 complete pre-commit processing for a transaction and before issuing a commit request to db1 and db2, a transaction manager may write an identifier of the transaction and a corresponding to-be-committed status flag (i.e., xid: commit) corresponding to the identifier of the transaction into a preset storage space in a persistent manner. When the write is successful, the transaction manager can issue commit requests (i.e., xa commit xid) to db1 and db 2. In fig. 7, for each participant node, a corresponding agent node agent is correspondingly set. When the submission is abnormal, each agent node agent can read the to-be-submitted state mark corresponding to the transaction identifier from the preset storage space, and then each agent node agent sends a submission instruction to the corresponding participant node based on the to-be-submitted state mark. It can be understood that when the identifier of the transaction and the status flag to be committed are written into the preset storage space, there may be a case that the writing is over time or the transaction manager is down during the writing process, and in this case, the transaction manager cannot determine whether the identifier of the transaction and the status flag to be committed are successfully written into the preset storage space. Then, the agent node agent may detect the identifier set of the to-be-committed transaction in its corresponding db1 to detect the identifier of the unsuccessfully committed transaction, and then read the to-be-committed status flag corresponding to the identifier of the transaction from the preset storage space. And if so, sending a submitting instruction to the corresponding participant node by each agent node agent based on the to-be-submitted state mark. If not, the agent node may try to correspondingly write the identifier and the suspension status flag of the transaction into the preset storage space, and then read the status flag corresponding to the identifier of the transaction from the preset storage space again. And if the status mark to be submitted can be read when the status mark to be submitted is read again, each agent node agent sends a submission instruction to the corresponding participant node based on the status mark to be submitted. If the abort status flag is read when read again, each agent node agent may send a rollback request (i.e., rollback) to its corresponding participant node.
As shown in fig. 8, in one embodiment, a distributed transaction exception handling apparatus 800 is provided, the apparatus 800 comprising: a status write module 802, a commit module 804, and a status read module 806, wherein:
a status writing module 802, configured to obtain an identifier of a transaction to be submitted; and writing the identification of the transaction and the to-be-submitted state mark corresponding to the identification of the transaction into a preset storage space.
A commit module 804 configured to send a first commit request for the transaction to a participant node in the distributed system.
A status reading module 806, configured to, when the participant node executes the first commit request and an exception occurs, read a to-be-committed status flag corresponding to the identifier of the transaction from the preset storage space;
the submitting module 804 is further configured to send a second submitting request to the participant node according to the status flag to be submitted; the second commit request is to instruct the participant node to commit the transaction.
In one embodiment, when the status writing module 802 performs a normal writing process on the preset storage space, the commit module 804 is notified to perform the step of sending the first commit request for the transaction to the participant node in the distributed system.
In this embodiment, the apparatus 800 further includes:
a rollback module 803, configured to send a rollback request to each of the participant nodes when the status writing module 802 fails to perform the writing process; the rollback request is used for instructing each participant node to rollback the transaction.
In one embodiment, the status reading module 806 is further configured to read the status flag to be submitted corresponding to the identifier of the transaction from the preset storage space when the status writing module 802 times out or goes down during the execution of the writing process.
The commit module 804 is further configured to, when the to-be-committed status flag corresponding to the identifier of the transaction is read, send a third commit request for the transaction to each of the participant nodes.
In one embodiment, the identifier of the transaction stored in the preset storage space corresponds to only one state flag. The commit module 804 is further configured to, when the status reading module 806 does not read the to-be-committed status flag corresponding to the identifier of the transaction, correspondingly write the identifier of the transaction and the abort status flag into the preset storage space; reading the state mark corresponding to the transaction identifier from the preset storage space again; and when the status mark read again is the status mark to be submitted, sending a fourth submission request aiming at the transaction to the participant node in the distributed system.
In one embodiment, the submitting module 804 is further configured to send a rollback request to each participant node when the status flag read again is the suspension status flag; the rollback request is used for instructing each participant node to rollback the transaction.
In one embodiment, the transaction to be committed is a transaction whose pre-commit process was successful. The rollback module 803 is further configured to send a rollback request to each of the participant nodes; the rollback request is used for instructing each participant node to rollback the transaction.
In an embodiment, the status reading module 806 is further configured to read, by the proxy node respectively configured for each participant node, a to-be-committed status flag corresponding to the identifier of the transaction from the preset storage space. The submitting module 804 is further configured to send, by each agent node, a second submitting request to the participant node according to the status flag to be submitted.
In one embodiment, the apparatus further comprises:
an anomaly determination module 805, configured to obtain, by each proxy node, an identifier set of a to-be-submitted transaction from a participant node corresponding to the proxy node at a preset time interval; and when the identifiers of the transaction to be submitted all exist in the identifier sets obtained at least twice, judging that the first submission request executed by the participant node is abnormal.
In one embodiment, the apparatus 800 further comprises:
a transaction log clearing module 808, configured to obtain identifier subsets of the to-be-submitted transaction from each participant node, respectively, to obtain an identifier total set; acquiring the generation time of each identifier in the total identifier set; selecting the earliest generation time to obtain a reference time; and deleting the transaction log corresponding to the identifier with the writing time earlier than the reference time from the preset storage space.
As shown in fig. 9, in one embodiment, the apparatus further comprises: an identifier generation module 801, a rollback module 803, an exception determination module 805, and a transaction log purge module 808, wherein:
an identifier generating module 801, configured to generate, when generating an identifier of each transaction, a timestamp used for characterizing generation time of the identifier according to current time; generating an identifier uniquely identifying the transaction; the timestamp is included in the identified field.
In this embodiment, the transaction log clearing module 808 is further configured to parse fields of each identifier in the total set of identifiers, and obtain a timestamp in the identifier.
In one embodiment, the participant node is a blockchain node.
FIG. 10 is a diagram showing an internal configuration of a computer device according to an embodiment. Referring to FIG. 10, the computer device may be the transaction manager 110 of FIG. 1. The computer device includes a processor, a memory, and a network interface connected by a system bus. Wherein the memory includes a non-volatile storage medium and an internal memory. The non-volatile storage medium of the computer device may store an operating system and a computer program. The computer program, when executed, causes a processor to perform a distributed transaction exception handling method. The processor of the computer device is used for providing calculation and control capability and supporting the operation of the whole computer device. The internal memory may have stored therein a computer program that, when executed by the processor, causes the processor to perform a distributed transaction exception handling method. The network interface of the computer device is used for network communication.
Those skilled in the art will appreciate that the architecture shown in fig. 10 is merely a block diagram of some of the structures associated with the disclosed aspects and is not intended to limit the computing devices to which the disclosed aspects apply, as particular computing devices may include more or less components than those shown, or may combine certain components, or have a different arrangement of components.
In one embodiment, the distributed transaction exception handling apparatus provided in the present application may be implemented in a form of a computer program, the computer program may be executed on a computer device as shown in fig. 10, and a non-volatile storage medium of the computer device may store various program modules constituting the distributed transaction exception handling apparatus, such as a state writing module 802, a committing module 804, and a state reading module 806 shown in fig. 8. The computer program composed of the program modules is used for making the computer device execute the steps in the distributed transaction exception handling method according to the embodiments of the present application described in this specification, for example, the computer device may obtain the identifier of the transaction to be committed through the status writing module 802 in the distributed transaction exception handling apparatus 800 as shown in fig. 8; and writing the identification of the transaction and the to-be-submitted state mark corresponding to the identification of the transaction into a preset storage space. The computer device may send a first commit request for the transaction to a participant node in the distributed system through a commit module 804. When the participant node executes the first commit request and an exception occurs, the computer device may read, by using the status reading module 806, a to-be-committed status flag corresponding to the identifier of the transaction from the preset storage space. The computer device may send a second commit request to the participant node according to the to-be-committed status flag through the commit module 804; the second commit request is to instruct the participant node to commit the transaction.
In one embodiment, a computer device is provided, comprising a memory and a processor, the memory storing a computer program which, when executed by the processor, causes the processor to perform the steps of the distributed transaction exception handling method described above. The steps of the distributed transaction exception handling method herein may be steps in the distributed transaction exception handling method of the various embodiments described above.
In one embodiment, a computer readable storage medium is provided, storing a computer program that, when executed by a processor, causes the processor to perform the steps of the distributed transaction exception handling method described above. The steps of the distributed transaction exception handling method herein may be steps in the distributed transaction exception handling method of the various embodiments described above.
It should be noted that "first", "second", "third", and "fourth" in the embodiments of the present application are used for distinction only, and are not used for limitation in terms of size, order, dependency, and the like.
It should be understood that although the steps in the embodiments of the present application are not necessarily performed in the order indicated by the step numbers. The steps are not performed in the exact order shown and described, and may be performed in other orders, unless explicitly stated otherwise. Moreover, at least some of the steps in various embodiments may include multiple sub-steps or multiple stages, which are not necessarily performed at the same time, but may be performed at different times, and the order of performing the sub-steps or stages is not necessarily sequential, but may be performed alternately or alternately with other steps or at least some of the sub-steps or stages of other steps.
It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by a computer program, which can be stored in a non-volatile computer-readable storage medium, and can include the processes of the embodiments of the methods described above when the program is executed. Any reference to memory, storage, database, or other medium used in the embodiments provided herein may include non-volatile and/or volatile memory, among others. Non-volatile memory can include read-only memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus Direct RAM (RDRAM), direct bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).
The technical features of the embodiments described above may be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the embodiments described above are not described, but should be considered as being within the scope of the present specification as long as there is no contradiction between the combinations of the technical features.
The above-mentioned embodiments only express several embodiments of the present invention, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the inventive concept, which falls within the scope of the present invention. Therefore, the protection scope of the present patent shall be subject to the appended claims.

Claims (24)

1. A method of distributed transaction processing, the method comprising:
acquiring an identifier of a transaction to be submitted;
writing the identification of the transaction and the to-be-submitted state mark corresponding to the identification of the transaction into a preset storage space;
when the writing processing aiming at the preset storage space is overtime, reading a to-be-submitted state mark corresponding to the identification of the transaction from the preset storage space;
when the state mark to be submitted corresponding to the identification of the transaction is read, sending a third submission request aiming at the transaction to each participant node in the distributed system; the third commit request to instruct the participant node to commit the transaction.
2. The method of claim 1, further comprising:
when the writing processing is down, the step of reading the status mark to be submitted corresponding to the identification of the transaction from the preset storage space is executed;
when the write processing fails, sending a rollback request to each participant node; the rollback request is used for instructing each participant node to rollback the transaction.
3. The method according to claim 1, wherein the identity of the transaction stored in the preset storage space corresponds to only one status flag; the method further comprises the following steps:
when the state mark to be submitted corresponding to the identification of the transaction is not read, correspondingly writing the identification of the transaction and the suspension state mark into the preset storage space;
reading the state mark corresponding to the transaction identifier from the preset storage space again;
and when the status mark read again is the status mark to be submitted, sending a fourth submission request aiming at the transaction to the participant node in the distributed system.
4. The method of claim 3, further comprising:
when the status mark read again is the suspension status mark, a rollback request is sent to each participant node; the rollback request is used for instructing each participant node to rollback the transaction.
5. The method of claim 1, wherein the transaction to be committed is a transaction whose pre-commit process was successful;
before the obtaining the identification of the transaction to be committed, the method further comprises:
when the pre-commit processing for the transaction is abnormal, then
Sending a rollback request to each of the participant nodes; the rollback request is used for instructing each participant node to rollback the transaction.
6. The method of claim 1, further comprising:
when the write-in processing aiming at the preset storage space is normal, sending a first submission request aiming at the transaction to a participant node in the distributed system;
when the first submission request executed by the participant node is abnormal, then
Reading a to-be-submitted state mark corresponding to the identification of the transaction from the preset storage space;
sending a second submission request to the participant node according to the status mark to be submitted; the second commit request is to instruct the participant node to commit the transaction.
7. The method of claim 6, wherein the reading the to-be-committed status flag corresponding to the identity of the transaction from the preset storage space comprises:
reading a to-be-submitted state mark corresponding to the transaction identifier from the preset storage space through the agent nodes respectively arranged aiming at each participant node;
the sending a second commit request to the participant node according to the to-be-committed status flag includes:
and sending a second submission request to the participant node through each agent node according to the state mark to be submitted.
8. The method of claim 7, further comprising:
acquiring an identification set of a transaction to be submitted from participant nodes corresponding to the agent nodes at preset time intervals through each agent node;
and when the identifiers of the transaction to be submitted all exist in the identifier sets obtained at least twice, judging that the first submission request executed by the participant node is abnormal.
9. The method of claim 1, further comprising:
respectively acquiring an identifier subset of a transaction to be submitted from each participant node to obtain an identifier total set;
acquiring the generation time of each identifier in the total identifier set;
selecting the earliest generation time to obtain a reference time;
and deleting the transaction log corresponding to the identifier with the writing time earlier than the reference time from the preset storage space.
10. The method of claim 9, further comprising:
when the identifier of each transaction is generated, generating a timestamp for representing the generation time of the identifier according to the current time;
generating an identifier uniquely identifying the transaction; the timestamp is included in the field of the identifier;
the acquiring the generation time of each identifier in the total identifier set comprises:
and analyzing the fields of all the identifiers in the total identifier set to obtain the time stamps in the identifiers.
11. The method according to any of claims 1 to 10, wherein the participant node is a blockchain node.
12. A distributed transaction processing apparatus, the apparatus comprising:
the state writing module is used for acquiring the identifier of the transaction to be submitted; writing the identification of the transaction and the to-be-submitted state mark corresponding to the identification of the transaction into a preset storage space;
the state reading module is used for reading a to-be-submitted state mark corresponding to the identifier of the transaction from a preset storage space when the writing processing aiming at the preset storage space is overtime;
the submitting module is used for sending a third submitting request aiming at the transaction to each participant node in the distributed system when the to-be-submitted state mark corresponding to the identification of the transaction is read; the third commit request to instruct the participant node to commit the transaction.
13. The apparatus according to claim 12, wherein when the status writing module goes down during the writing process, the status reading module is notified to perform the step of reading the status flag to be submitted corresponding to the identifier of the transaction from the preset storage space;
the device further comprises:
a rollback module, configured to send a rollback request to each of the participant nodes when the status writing module fails to perform the writing process; the rollback request is used for instructing each participant node to rollback the transaction.
14. The apparatus according to claim 12, wherein the identity of the transaction stored in the preset storage space corresponds to only one status flag; the submitting module is further used for correspondingly writing the identifier and the suspension state mark of the transaction into the preset storage space when the state reading module does not read the to-be-submitted state mark corresponding to the identifier of the transaction; reading the state mark corresponding to the transaction identifier from the preset storage space again; when the status mark read again is the status mark to be submitted, sending a fourth submission request aiming at the transaction to the participant node in the distributed system; the fourth commit request is to instruct participant nodes in the distributed system to commit the transaction.
15. The apparatus of claim 14, wherein the commit module is further configured to send a rollback request to each participant node when the status flag read again is an abort status flag; the rollback request is used for instructing each participant node to rollback the transaction.
16. The apparatus of claim 13, wherein the transaction to be committed is a transaction whose pre-commit process was successful; the rollback module is further configured to, before the obtaining of the identifier of the transaction to be committed, send a rollback request to each of the participant nodes when the pre-commit processing of the transaction is abnormal; the rollback request is used for instructing each participant node to rollback the transaction.
17. The apparatus according to claim 12, wherein the commit module is further configured to send a first commit request for the transaction to a participant node in the distributed system when the status write module writes to the preset storage space normally;
the state reading module is further configured to read a to-be-submitted state flag corresponding to the identifier of the transaction from the preset storage space when the participant node executes the first submission request and the first submission request is abnormal;
the submitting module is further used for sending a second submitting request to the participant node according to the status mark to be submitted; the second commit request is to instruct the participant node to commit the transaction.
18. The apparatus according to claim 17, wherein the status reading module is further configured to read, by a proxy node respectively configured for each participant node, a to-be-committed status flag corresponding to the identifier of the transaction from the preset storage space; the submitting module is further configured to send, by each agent node, a second submitting request to the participant node according to the status flag to be submitted.
19. The apparatus of claim 18, further comprising:
an anomaly determination module, configured to obtain, by each agent node, an identifier set of a to-be-submitted transaction from a participant node corresponding to the agent node at a preset time interval; and when the identifiers of the transaction to be submitted all exist in the identifier sets obtained at least twice, judging that the first submission request executed by the participant node is abnormal.
20. The apparatus of claim 12, further comprising:
the transaction log clearing module is used for respectively acquiring the identifier sub-sets of the to-be-submitted transactions from each participant node to obtain an identifier total set; acquiring the generation time of each identifier in the total identifier set; selecting the earliest generation time to obtain a reference time; and deleting the transaction log corresponding to the identifier with the writing time earlier than the reference time from the preset storage space.
21. The apparatus of claim 20, further comprising:
the identification generation module is used for generating a timestamp for representing the generation time of the identification according to the current time when the identification of each transaction is generated; generating an identifier uniquely identifying the transaction; the timestamp is included in the field of the identifier;
the transaction log clearing module is further configured to parse fields identifying each identifier in the total set, and obtain a timestamp in the identifier.
22. The apparatus according to any of claims 12 to 21, wherein the participant node is a blockchain node.
23. A computer arrangement comprising a memory and a processor, the memory having stored therein a computer program which, when executed by the processor, causes the processor to carry out the steps of the method of any one of claims 1 to 11.
24. A computer-readable storage medium, having stored thereon a computer program which, when executed by a processor, causes the processor to carry out the steps of the method according to any one of claims 1 to 11.
CN201911268592.4A 2019-08-05 2019-08-05 Distributed transaction processing method and device, computer equipment and storage medium Active CN111078451B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911268592.4A CN111078451B (en) 2019-08-05 2019-08-05 Distributed transaction processing method and device, computer equipment and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201911268592.4A CN111078451B (en) 2019-08-05 2019-08-05 Distributed transaction processing method and device, computer equipment and storage medium
CN201910718775.5A CN110457157B (en) 2019-08-05 2019-08-05 Distributed transaction exception handling method and device, computer equipment and storage medium

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
CN201910718775.5A Division CN110457157B (en) 2019-08-05 2019-08-05 Distributed transaction exception handling method and device, computer equipment and storage medium

Publications (2)

Publication Number Publication Date
CN111078451A CN111078451A (en) 2020-04-28
CN111078451B true CN111078451B (en) 2021-05-11

Family

ID=68483037

Family Applications (2)

Application Number Title Priority Date Filing Date
CN201910718775.5A Active CN110457157B (en) 2019-08-05 2019-08-05 Distributed transaction exception handling method and device, computer equipment and storage medium
CN201911268592.4A Active CN111078451B (en) 2019-08-05 2019-08-05 Distributed transaction processing method and device, computer equipment and storage medium

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN201910718775.5A Active CN110457157B (en) 2019-08-05 2019-08-05 Distributed transaction exception handling method and device, computer equipment and storage medium

Country Status (1)

Country Link
CN (2) CN110457157B (en)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111143040A (en) * 2019-12-30 2020-05-12 北京三快在线科技有限公司 Transaction processing method, device, system and storage medium
CN111651243B (en) * 2020-05-29 2021-08-10 北京东方通科技股份有限公司 Distributed transaction guarantee method oriented to memory data grid
CN113297320A (en) * 2020-07-24 2021-08-24 阿里巴巴集团控股有限公司 Distributed database system and data processing method
CN111930847B (en) * 2020-09-16 2021-01-08 深圳壹账通智能科技有限公司 Data processing method and device based on block chain and storage medium

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108459919A (en) * 2018-03-29 2018-08-28 中信百信银行股份有限公司 A kind of distributed transaction processing method and device

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7149920B2 (en) * 2003-09-30 2006-12-12 International Business Machines Corporation Deterministic error recovery protocol
CN100561920C (en) * 2004-12-27 2009-11-18 北京航空航天大学 Web service transacter and processing method
CN101706811B (en) * 2009-11-24 2012-01-25 中国科学院软件研究所 Transaction commit method of distributed database system
CN102073540B (en) * 2010-12-15 2013-05-08 北京新媒传信科技有限公司 Distributed affair submitting method and device thereof
US20150172412A1 (en) * 2012-07-06 2015-06-18 Cornell University Managing dependencies between operations in a distributed system
US9152501B2 (en) * 2012-12-19 2015-10-06 International Business Machines Corporation Write performance in fault-tolerant clustered storage systems
US9456035B2 (en) * 2013-05-03 2016-09-27 International Business Machines Corporation Storing related data in a dispersed storage network
US20160092310A1 (en) * 2014-09-30 2016-03-31 Vivint, Inc. Systems and methods for managing globally distributed remote storage devices
CN105786592A (en) * 2014-12-15 2016-07-20 北大方正集团有限公司 Method and device for processing distributed transactions
CN105893395B (en) * 2015-01-26 2019-04-02 阿里巴巴集团控股有限公司 The message of distributed transaction returns checking method and its system
CN105989133B (en) * 2015-02-25 2019-10-01 阿里巴巴集团控股有限公司 Transaction methods and device
CN106325978B (en) * 2015-06-19 2020-06-30 阿里巴巴集团控股有限公司 Distributed transaction processing method and device
US10061790B2 (en) * 2015-07-07 2018-08-28 SwiftStack, Inc. Reconciler for a distributed storage system
US10318366B2 (en) * 2015-09-04 2019-06-11 International Business Machines Corporation System and method for relationship based root cause recommendation
US20180052759A1 (en) * 2016-08-19 2018-02-22 Ca, Inc. Performance metric contextualization in a distributed computing environment
CN106775959B (en) * 2016-12-06 2017-12-22 上海壹账通金融科技有限公司 distributed transaction processing method and system
CN106874076B (en) * 2017-01-21 2019-08-30 浙江沛宏网络科技有限公司 Distributed transaction processing method
US10936578B2 (en) * 2017-06-01 2021-03-02 Sap Se Client-driven commit of distributed write transactions in a database environment
CN108924184B (en) * 2018-05-31 2022-02-25 创新先进技术有限公司 Data processing method and server
CN109542639B (en) * 2018-11-06 2021-05-11 用友网络科技股份有限公司 Processing method and processing device for guaranteeing consistency of microservice calling data
CN109451078B (en) * 2019-01-10 2022-05-03 网易（杭州）网络有限公司 Transaction processing method and device under distributed architecture
CN109977171B (en) * 2019-02-02 2023-04-28 中国人民大学 Distributed system and method for ensuring transaction consistency and linear consistency
CN110083439B (en) * 2019-05-23 2021-10-01 北京奥鹏远程教育中心有限公司 Distributed transaction system

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108459919A (en) * 2018-03-29 2018-08-28 中信百信银行股份有限公司 A kind of distributed transaction processing method and device

Also Published As

Publication number Publication date
CN110457157B (en) 2021-05-11
CN111078451A (en) 2020-04-28
CN110457157A (en) 2019-11-15

Similar Documents

Publication Publication Date Title
CN111078451B (en) Distributed transaction processing method and device, computer equipment and storage medium
CN109189608B (en) A kind of method guaranteeing duplication transaction consistency and corresponding reproducing unit
US6662196B2 (en) Collision avoidance in bidirectional database replication
CN110473100B (en) Transaction processing method and device based on blockchain system
CN108446172B (en) Data calling method and device, computer equipment and storage medium
CN104094228A (en) Systems and methods for supporting transaction recovery based on a strict ordering of two-phase commit calls
CN110727724B (en) Data extraction method and device, computer equipment and storage medium
CN112613993B (en) Transaction data processing method and device, computer equipment and storage medium
US20220253363A1 (en) Distributed database remote backup
CN111210350A (en) Block chain transaction method and device, computer equipment and storage medium
CN111291062B (en) Data synchronous writing method and device, computer equipment and storage medium
CN112988777B (en) Object processing method and device, computer equipment and storage medium
CN110619022A (en) Node detection method, device, equipment and storage medium based on block chain network
CN111291063B (en) Master and backup copy election method, system, computer equipment and storage medium
CN112114750A (en) Metadata volume bitmap data conflict processing method and related components
CN115098889B (en) Authority management method, device, equipment and storage medium
CN114297216B (en) Data synchronization method and device, computer storage medium and electronic equipment
CN111984473B (en) Memory snapshot data acquisition method and related device
CN112765126A (en) Database transaction management method and device, computer equipment and storage medium
CN109947592A (en) A kind of method of data synchronization, device and relevant device
CN112818021A (en) Data request processing method and device, computer equipment and storage medium
CN112527561A (en) Data backup method and device based on Internet of things cloud storage
CN114584572B (en) Data synchronization method, device, equipment and medium in distributed object storage
CN110162507B (en) Snapshot overwriting method, device, computer equipment and storage medium
CN117453454A (en) Data backup method, device, computer equipment, medium and product

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 40021092

Country of ref document: HK

SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant