WO2024193138A1 - Transaction processing method and related device - Google Patents

Abstract

The present application relates to the technical field of computers, and provides a transaction processing method and a related device. The transaction processing method comprises: in response to a received operation instruction, creating a distributed transaction for the operation instruction, wherein the distributed transaction comprises a plurality of transaction branches; committing the distributed transaction on the basis of a preset transaction commitment mechanism, and generating a write ahead log of the distributed transaction, wherein the commitment of each transaction branch among the plurality of transaction branches comprises a plurality of process nodes, and the preset transaction commitment mechanism comprises a checkpoint for detecting execution conditions of the plurality of process nodes and a transaction state of each transaction branch; and if it is determined that the distributed transaction comprises an abnormal transaction branch, processing the abnormal transaction branch on the basis of the write ahead log and the checkpoint, wherein the abnormal transaction branch may be caused by an anomaly that occurs in a device where a transaction coordinator or a transaction participant of the distributed transaction is located. The present application can avoid pending transactions.

Description

Transaction processing method and related equipment

This application claims priority to the Chinese patent application filed with the China Patent Office on March 17, 2023, with application number 202310267376.8 and application name “Transaction Processing Methods and Related Equipment”, the entire contents of which are incorporated by reference into this application.

Technical Field

The present application relates to the field of computer technology, and in particular to a transaction processing method and related equipment.

Background Art

When there are multiple transaction participants involved in processing a transaction, this transaction can be called a distributed transaction. At present, in order to ensure the consistency of distributed transaction submission, the mainstream transaction submission protocol is usually a two-phase submission protocol (2PC). Since distributed transactions involve the scheduling and coordination of multiple transaction participants, distributed transaction processing is more complicated than traditional single-machine transactions.

The existing distributed failed transaction retry mechanism generally performs failed transaction retry based on the transaction log records in memory. However, failed transaction retry based on the transaction log records in memory may not guarantee that all failed transactions can be processed correctly. For example, if the transaction coordinator fails, pending failed transactions may be left on the transaction participants.

Summary of the invention

In view of this, it is necessary to provide a transaction processing method to ensure that transactions can be processed correctly and avoid pending transactions.

In a first aspect, an embodiment of the present application discloses a transaction processing method, comprising: in response to a received operation instruction, creating a distributed transaction for the operation instruction, the distributed transaction including multiple transaction branches; committing the distributed transaction based on a preset transaction commit mechanism, and generating a pre-write log of the distributed transaction, the commit of each transaction branch in the multiple transaction branches including multiple process nodes, the preset transaction commit mechanism including a checkpoint for detecting the execution status of the multiple process nodes and the transaction status of each transaction branch; if it is determined that the distributed transaction includes an abnormal transaction branch, processing the abnormal transaction branch based on the pre-write log and the checkpoint, the abnormal transaction branch is caused by an abnormality in the device where the transaction coordinator of the distributed transaction is located, or an abnormality in the device where the transaction participant of the distributed transaction is located.

With the above technical solution, the submission of a distributed transaction may be left in a pending state due to an exception in the device where the transaction coordinator of the distributed transaction is located, or in the device where the transaction participant of the distributed transaction is located (device crash, power outage, network disconnection, restart, etc.). The transaction submission process is recorded by using a pre-write log with persistent storage capability during the transaction submission phase, and checkpoints are set at multiple process nodes in the transaction submission process to check the execution status and transaction status. For transactions with exceptions, after the device exception is recovered, the transaction can be re-promoted from the specified process node based on log playback, providing reliable transaction recovery capabilities for transaction exceptions, ensuring that transactions can be handled correctly, and avoiding pending transactions.

In some embodiments, creating a distributed transaction for an operation instruction includes: if data processed by the operation instruction involves multiple sub-databases or multiple sub-tables, creating a distributed transaction for the operation instruction.

By adopting the above technical solution, when it is determined that the data processed by the operation instruction involves multiple sub-libraries or multiple sub-tables, indicating that there are multiple transaction participants (one sub-library or one sub-table can be a transaction participant), by creating a distributed transaction for the operation instruction, consistency processing of the data located in multiple sub-libraries or multiple sub-tables can be achieved.

In some embodiments, the transaction commit mechanism is preset as a two-phase commit protocol, and a write-ahead log of the distributed transaction is generated, including: before each transaction branch is pre-committed, a first write-ahead log is generated, and the first write-ahead log is used to record transaction-related information of the first phase in the two-phase commit protocol; before each transaction branch is committed, a second write-ahead log is generated, and the second write-ahead log is used to record transaction-related information of the second phase in the two-phase commit protocol. The transaction-related information of the first phase and the transaction-related information of the second phase both include the transaction status information of the distributed transaction, the transaction status information of the transaction branch, the operation data, and the structured query language (SQL) statement for processing the operation data.

By adopting the above technical solution, when a transaction is committed using the two-phase commit protocol, a write-ahead log with persistent storage capability is used in the first and second phases of the transaction to record the transaction status information of the global transaction, the transaction status information of the transaction branch, the operation data, and the SQL statement used to process the operation data, thereby providing a reliable transaction recovery capability for transaction exceptions, ensuring that abnormal transactions can be correctly processed based on log playback, and avoiding pending transactions.

In some embodiments, the transaction processing method further includes: if the generation of the first write-ahead log or the second write-ahead log fails, controlling each transaction branch to roll back.

By adopting the above technical solution, if the generation of the first write-ahead log or the second write-ahead log fails, it indicates that the first stage or the second stage of the transaction cannot be recorded through the write-ahead log, resulting in the inability to continue to advance the abnormal transaction from the first stage or the second stage based on log playback. By controlling each transaction branch to roll back, the problem of being unable to continue to advance the abnormal transaction from the first stage or the second stage based on log playback can be avoided.

In some embodiments, the submission of each transaction branch includes submitting a transaction process or rolling back a transaction process, and the submitting transaction process or rolling back a transaction process both include multiple process nodes, and each of the multiple process nodes is provided with a checkpoint.

By adopting the above technical solution, both the transaction submission process and the transaction rollback process can include multiple process nodes. By setting multiple checkpoints in the transaction submission process and the transaction rollback process to check the execution status of each process node, it is possible to re-submit the transaction or roll back the transaction from the specified process node based on log playback after the device abnormality is recovered, thereby providing reliable transaction recovery capabilities for transaction abnormalities, ensuring that transactions can be processed correctly, and avoiding pending transactions.

In some embodiments, after the distributed transaction is committed based on a preset transaction commit mechanism, the method further includes: determining a transaction branch that is not in a preset transaction state as an abnormal transaction branch, where the preset transaction state includes a Rollbacked state or a Committed state.

By adopting the above technical solution, a transaction branch that is not in the Rollbacked state or the Committed state is determined as an abnormal transaction branch. For the abnormal transaction branch, the transaction can be re-committed or rolled back from the specified process node based on log playback until it is in the Committed state or the Rollbacked state, ensuring that the transaction can be processed correctly and avoiding pending transactions.

In some embodiments, an abnormal transaction branch is processed based on a write-ahead log and a checkpoint, including: replaying the write-ahead log corresponding to the abnormal transaction branch, determining a process node for reprocessing the abnormal transaction branch; and processing the abnormal transaction branch with the determined process node as the starting process node.

By adopting the above technical solution, for abnormal transactions, the pre-written log corresponding to the abnormal transaction branch can be replayed after the device abnormality is recovered, thereby improving the log playback efficiency. Based on the log playback, the transaction can be re-promoted from the specified process node, providing reliable transaction recovery capabilities for transaction exceptions, ensuring that the transaction can be processed correctly, and avoiding pending transactions.

In a second aspect, an embodiment of the present application provides a distributed middleware, including: a creation module, used to create a distributed transaction for the operation instruction in response to a received operation instruction, the distributed transaction including multiple transaction branches; a submission module, used to submit the distributed transaction based on a preset transaction submission mechanism, and generate a pre-write log of the distributed transaction, the submission of each transaction branch in the multiple transaction branches includes multiple process nodes, and the preset transaction submission mechanism includes a checkpoint for detecting the execution status of the multiple process nodes and the transaction status of each transaction branch; a processing module, used to process the abnormal transaction branch based on the pre-write log and the checkpoint when it is determined that the distributed transaction contains an abnormal transaction branch, the abnormal transaction branch is caused by an abnormality in the device where the transaction coordinator of the distributed transaction is located, or an abnormality in the device where the transaction participant of the distributed transaction is located.

With the above technical solution, the submission of distributed transactions may be in a pending state due to an abnormality of the device where the transaction coordinator of the distributed transaction is located, or the device where the transaction participant of the distributed transaction is located (device downtime, power outage, network disconnection, restart, etc.). The write-ahead log records the transaction submission process, and checks the execution status and transaction status by setting checkpoints at multiple process nodes in the transaction submission process. For abnormal transactions, after the device abnormality is recovered, the transaction can be re-promoted from the specified process node based on log playback, providing reliable transaction recovery capabilities for transaction exceptions, ensuring that transactions can be handled correctly, and avoiding pending transactions.

In a third aspect, an embodiment of the present application provides a computer-readable storage medium, comprising computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes the transaction processing method as described in the first aspect.

In a fourth aspect, an embodiment of the present application provides a computing device cluster, comprising at least one computing device, each computing device comprising a processor and a memory; the processor of at least one computing device is used to execute instructions stored in the memory of at least one computing device, so that the computing device cluster executes the transaction processing method described in the first aspect.

In a fifth aspect, an embodiment of the present application provides a computer program product. When the computer program product is executed by a computing device cluster, the computing device cluster executes the transaction processing method as described in the first aspect.

In a sixth aspect, a device is provided, wherein the device has the function of implementing the computing device cluster behavior in the method provided in the first aspect. The function can be implemented by hardware, or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions.

It can be understood that the computer-readable storage medium described in the third aspect, the computing device cluster described in the fourth aspect, the computer program product described in the fifth aspect, and the apparatus described in the sixth aspect all correspond to the method of the first aspect. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a schematic diagram of the architecture of a distributed transaction submission system provided by an embodiment of the present application;

FIG2 is a schematic diagram of an application environment of a transaction processing method provided by an embodiment of the present application;

FIG3 is a schematic diagram of the overall execution flow of a distributed transaction provided by an embodiment of the present application;

FIG4 is a schematic diagram of a process of performing two-phase commit of a distributed transaction provided by an embodiment of the present application;

FIG5 is a schematic diagram of the organizational structure of a write-ahead log in a storage device according to an embodiment of the present application;

FIG6 is a schematic diagram of a process of ending a distributed transaction provided by an embodiment of the present application;

FIG7 is a schematic diagram of a process of rolling back a distributed transaction provided by an embodiment of the present application;

FIG8 is a schematic diagram of a process flow of a transaction processing method according to an embodiment of the present application;

FIG9 is a schematic diagram of a module of a distributed database middleware provided in an embodiment of the present application;

FIG10 is a schematic diagram of the structure of a computing device provided by an embodiment of the present application;

FIG. 11 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application.

DETAILED DESCRIPTION

It should be noted that in this application, "at least one" means one or more, and "more than one" means two or more than two. "And/or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and/or B can mean: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The terms "first", "second", "third", "fourth", etc. (if any) in the specification, claims and drawings of this application are used to distinguish similar objects, rather than to describe a specific order or sequence.

In the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

To facilitate understanding of the embodiments of the present application, the application scenarios of the present application are introduced below. The business scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application and do not constitute any As for the limitation of the technical solutions provided in the application embodiments, it is known to those skilled in the art that, with the emergence of new business scenarios, the technical solutions provided in the application embodiments are also applicable to similar technical problems.

In order to facilitate understanding of the technical solutions in the embodiments of the present application, some of the terms involved in the embodiments of the present application are first explained below:

Distributed database: The data in the original centralized database is stored in multiple data storage nodes connected by the network to obtain larger storage capacity and higher concurrency. Specifically, the database and table sharding technology can be used to store massive data shards in each storage node of the distributed database. In general, the database and table sharding technology refers to storing the data shards of a large table in each storage node according to the established partitioning strategy, or dividing a large table into business sub-tables with smaller data volumes, and storing each sub-table in each storage node according to the established partitioning strategy.

Transaction: refers to a group of continuous operations, which are combined into a complete logic. After executing this group of operations, the transaction commit system needs to switch from one consistent state to another consistent state. All operations in the above operation combination are either successfully executed or not successfully executed. If some operations in the operation combination are successfully executed and some operations are not successfully executed, the successful operations need to be rolled back to the state before the unsuccessful execution.

XA protocol: A distributed transaction processing specification proposed by the X/Open organization, which mainly defines the interface between the transaction manager (TM) and the local resource manager (RM). The transaction manager, also known as the transaction coordinator, is responsible for allocating transaction unique identifiers, monitoring the progress of transaction execution, and committing and rolling back transactions. The local resource manager can be a database, file system, etc., which can provide a way to access resources. The application (Application Program) is used to define the transaction boundaries (that is, define the start and end of the transaction) and operate on resources within the transaction boundaries.

Two-phase commit protocol based on XA protocol: The transaction commit process is divided into the prepare phase, which is the first phase in the two-phase commit protocol, and the commit phase, which is the second phase in the two-phase commit protocol. The transaction coordinator can coordinate all transaction participants. If all transaction participants (RM) can commit the transaction in the first phase, the transaction branch on each RM is committed in the second phase. Otherwise, the transaction coordinator rolls back the transaction branch on each RM.

Structured query language (SQL): is a database query and programming language used to access data and query, update, and manage relational database systems.

As shown in FIG1 , a schematic diagram of the architecture of a distributed transaction submission system provided in an embodiment of the present application is exemplarily introduced.

In this embodiment, the distributed transaction submission system may include a transaction coordinator 110 and multiple transaction participants 120. The transaction participants 120 are used to process distributed transactions. The transaction coordinator 110 is used to coordinate and manage multiple transaction participants 120 to process distributed transactions. A distributed transaction may also be called a global transaction. A distributed transaction may correspond to multiple transaction branches, and multiple transaction branches correspond to multiple transaction participants 120 one by one.

In some embodiments, the transaction coordinator 110 may be selected from a plurality of transaction participants 120. For example, the transaction coordinator 110 and one of the plurality of transaction participants 120 may be the same node. For another example, the transaction coordinator 110 and the plurality of transaction participants 120 may also be different nodes, which is not limited in the embodiments of the present application. The specific implementation of a node may be a server or a virtual machine, which is not limited in the embodiments of the present application. For example, a node may refer to a data storage node in a distributed database.

In some embodiments, the transaction coordinator 110 may also be deployed in a middleware used to provide functional extension services for a distributed database. For example, the transaction coordinator 110 may be deployed in a distributed database middleware (DDM) 12 shown in FIG. 2 .

As shown in FIG2 , it is a schematic diagram of an application environment of a transaction processing method provided in an embodiment of the present application.

This embodiment takes the distributed transaction involving the operation of multiple database shards as an example, and includes an application 11, a DDM 12, and a database 13. The application 11 can be a cloud application for tenants, or other types of applications, which are not limited in this application. The database 13 can be a cloud database, or other types of databases, which are not limited in this application. The application does not limit this. DDM 12 can provide database 13 with capabilities such as sub-library and sub-table, read-write separation, and elastic expansion.

The application 11 can be used to receive the user's operation instructions and create a transaction tr1. The data involved in transaction tr1 may be distributed in different database shards on multiple relational database service (RDS) instances. A series of operations on the data table in the same database shard on each RDS instance is equivalent to a transaction branch (local transaction), that is, transaction tr1 can be equivalent to a distributed transaction composed of transaction branches on multiple RDS instances, and these transaction branches are either all executed successfully or all failed to execute successfully. DDM 12 plays the role of transaction coordinator in transaction tr1, and each RDS instance plays the role of transaction participant. In some embodiments, the creation of transaction tr1 can also be executed by DDM 12.

As shown in FIG3 , an overall execution flow chart of a distributed transaction provided in an embodiment of the present application is exemplarily introduced.

In this embodiment, DDM 12 can transparently encapsulate the two-phase commit of transactions. When using transactions, the application side does not need to care whether the underlying layer is a distributed transaction. It can use the ordinary transaction instructions BEGIN/COMMIT to perform distributed transaction operations. DDM 12 can automatically handle the two-phase commit logic of distributed transactions. If the transaction only involves one sub-library or one database, DDM 12 can also automatically downgrade the transaction to a local transaction committed in one phase.

For example, DDM 12 can map distributed transaction semantics with common transaction semantics. DDM 12 can determine whether the transaction is a local transaction or a distributed transaction by identifying whether the data of the transaction operation involves multiple sub-databases or multiple sub-tables. If multiple sub-databases or multiple sub-tables are involved, the transaction is determined to be a distributed transaction and a two-phase commit is performed. If only one sub-database or one sub-table is involved, the transaction is determined to be a local transaction and a one-phase commit is performed.

3 takes a distributed transaction including two transaction branches (hereinafter referred to as a first transaction branch and a second transaction branch) as an example. The first transaction branch corresponds to a first RDS instance RDS1, and the second transaction branch corresponds to a second RDS instance RDS2.

The first phase based on the XA protocol includes: starting an XA transaction (through the XA START instruction), executing business SQL (business SQL may include multiple SQL statements), ending the XA transaction (through the XA END instruction) and pre-committing the XA transaction (through the XA PREPARE instruction), thus completing the preparation operation for the business SQL.

The second phase based on the XA protocol includes: committing an XA transaction or rolling back an XA transaction. Execute the XA COMMIT instruction to commit the XA transaction, and only then will the business SQL be truly committed to the database. Execute the XA ROLLBACK instruction to roll back the XA transaction, complete the rollback of the business SQL, and release the database lock resources.

In the first stage, an XA transaction branch can be started through the XA START instruction, and the XA transaction branch is placed in the ACTIVE state. For the XA transaction branch in the ACTIVE state, the SQL statements that constitute the XA transaction branch are executed, the boundary of the XA transaction branch can be specified, and then the XA END instruction is executed to put the XA transaction branch in the IDLE state, that is, to end the boundary of the XA transaction branch. The SQL statements between the XA START instruction and the XA END instruction constitute a transaction scope of this XA transaction branch. For the XA transaction branch in the IDLE state, the XA transaction branch can be placed in the PREPARED state by executing the XA PREPARE instruction. In the second stage, for the XA transaction branch in the PREPARED state, the XA COMMIT instruction can be executed to commit, or the XA ROLLBACK instruction can be executed to roll back.

For distributed transactions, a globally unique distributed transaction number (XID) can be assigned. XID consists of the transaction sequence number within the node, the node identifier (identity document, ID) and the timestamp. XID can be added with the corresponding sub-database name (also called DBNAME) to form the unique number (XA_ID) of the transaction branch actually opened on the physical database, that is, XA_ID = XID + DBNAME. An XA transaction branch can be opened through the XA START "XID + DBNAME" instruction.

Assume that the XID of the distributed transaction shown in Figure 3 is: 34287.DDM.1.20210421024418, where "34287" is the transaction sequence number in the node, "1" is the node ID, and "20210421024418" is the timestamp. The sub-library name corresponding to the first transaction branch is db_sysbench_0003, and the sub-library name corresponding to the second transaction branch is db_sysbench_0004. That is, the XA_ID of the first transaction branch is: 34287.DDM.1.20210421024418.db_sysbench_0003, and the XA_ID of the second transaction branch is: 34287.DDM.1.20210421024418. db_sysbench_0004.

4 , a flowchart of two-phase commit of a distributed transaction provided by an embodiment of the present application is exemplarily introduced.

In this embodiment, multiple checkpoints are set in the first and second stages (to detect whether each process node in the transaction commit or rollback process is executed successfully or failed), and a write-ahead log (WAL) technology with persistence capability is used to record the transaction commit and rollback, so that after an exception occurs in a transaction, the unfinished distributed transaction can be continued to be promoted through log playback until the transaction is committed or rolled back, thereby avoiding pending transactions. Transaction exceptions are generally caused by an exception in the device where the transaction coordinator is located, or an exception in the device where the transaction participant is located, such as a device crash, power outage, network disconnection, restart, etc. After the device abnormality is recovered, the unfinished distributed transaction is continued to be promoted based on log playback until the transaction is committed or rolled back.

In the first phase, the pre-commit process of a distributed transaction may include:

S4_0, distributed transaction pre-committed.

S4_1, the transaction coordinator writes a pre-log to record the transaction-related information of the first phase.

In some embodiments, the write-ahead log may be persisted, and the transaction-related information of the first phase may include transaction status information, SQL statements, and operation data. Among them, the transaction status information may include the XID of the distributed transaction, the status of the distributed transaction, the XA_ID of each transaction branch, and the status of each transaction branch. The operation data may be one or more items, and the operation data may be distributed in one sub-library or in multiple sub-libraries. The operation data may be identified by the table number and the primary key. The SQL statement is used to indicate what kind of processing is performed on the operation data.

In some embodiments, the write-ahead log is stored in a data structure of a key-value pair. FIG. 5 shows the organizational structure of the write-ahead log in a storage device. As can be seen from the organizational structure shown in FIG. 5, the write-ahead log is stored in a tree diagram organizational structure. The tree diagram includes multiple root blocks and multiple leaf blocks, and each root block corresponds to a leaf block. The leaf block is used to store the write-ahead log, and the execution result of the transaction (distributed transaction or transaction branch) recorded in the write-ahead log, wherein when the execution result is completed, it is used to indicate that the transaction recorded in the write-ahead log is successfully executed, and when the execution result is incomplete, it is used to indicate that the transaction recorded in the write-ahead log is not successfully executed, and log playback is required, so as to facilitate the retry (continue execution or rollback) of the transaction that has not been successfully executed based on the replayed write-ahead log. The root block is used to store the information of the leaf block, for example, the value range of the key of the write-ahead log in the leaf block stored in the root block and the storage address of the corresponding leaf block.

S4_2: If the transaction coordinator fails to write the pre-log, the distributed transaction enters the rollback process.

S4_3, if the transaction coordinator successfully writes the pre-log, the transaction coordinator records each transaction participant as being in the CONN state (also called the connection state), and notifies each transaction participant to set its own state to the PREPARING state (also called the preparing state).

In some embodiments, in the first stage, by setting a checkpoint to determine whether the write-ahead log is successful, each transaction participant performs a pre-commit after the write-ahead log is successful, to avoid the inability to subsequently advance an abnormal transaction branch to a COMMITED state or a ROLLBACKED state based on log playback. An abnormal transaction branch may refer to a transaction branch whose final state is not a COMMITED state or a ROLLBACKED state.

S4_4, each transaction participant executes the "XA END" instruction and the "XA PREPARE" instruction.

S4_5, if the transaction participant executes the "XA END" instruction and the "XA PREPARE" instruction successfully, the transaction participant sets its own status to the PREPARED status (also called the prepared success status).

S4_6: If a transaction participant fails to execute the "XA END" instruction and/or the "XA PREPARE" instruction, the transaction participant rolls back and disconnects from the network connection with the transaction coordinator.

In some embodiments, a checkpoint is set during the process of a transaction participant executing an "XA END" instruction and an "XA PREPARE" instruction, and a transaction participant that fails to execute the instruction is rolled back in advance. The transaction participant rolling back may refer to the transaction participant executing an "XA ROLLBACK" instruction.

In some embodiments, the transaction participant disconnects the network connection with the transaction coordinator, which may mean disconnecting the connection established based on the network or inter-process communication (IPC) mechanism, while the transaction coordinator The SESSION connection between the coordinator and the transaction participant is not disconnected. After the transaction participant disconnects the network connection with the transaction coordinator, the lock resources used by the transaction participant in processing the transaction branch can be released.

S4_7, if the transaction participant rolls back successfully, the transaction participant sets its own state to ROLLBACKED state (also called rollback success state), and the transaction coordinator records the transaction participant disconnected from it as CONN_QUIT state (also called disconnected state).

S4_8, if the transaction participant fails to roll back, the transaction participant sets its own state to ROLLBACK_FAILED state (also called rollback failure state), and the transaction coordinator records the transaction participant disconnected from it as CONN_QUIT state.

In some embodiments, a checkpoint is set during the rollback process after a transaction participant fails to prepare, so that the rollback status of the transaction participant (whether the rollback is successful or failed) can be known in a timely manner.

S4_9 If the transaction coordinator receives feedback from all transaction participants that they are in the PREPARED state, the distributed transaction enters the PREPARED state.

S4_10: If the transaction coordinator does not receive feedback from all transaction participants that the transaction is in the PREPARED state, the distributed transaction enters the rollback process.

In some embodiments, by setting a checkpoint to detect whether the transaction coordinator has received feedback from all transaction participants that the transaction is in a PREPARED state, it is possible to promptly learn whether the transaction participants have successfully pre-committed.

For example, if a transaction participant crashes or loses connection, the transaction coordinator will not be able to receive feedback from the transaction participant that it is in the PREPARED state, that is, the transaction coordinator will not receive feedback from all transaction participants that they are in the PREPARED state.

After the distributed transaction enters the PREPARED state, the transaction coordinator can send a notification to the transaction participants, so that each transaction participant can commit the transaction branch. In the second stage, the submission process of the distributed transaction may include:

S4_11, the distributed transaction is committed.

S4_12, the transaction coordinator writes a pre-log to record the transaction-related information of the second phase.

In some embodiments, the write-ahead log may be persisted, and the transaction-related information of the second phase may also include transaction status information, SQL statements, and operation data.

S4_13: If the transaction coordinator fails to write the pre-log, the distributed transaction enters the rollback process.

S4_14, if the transaction coordinator successfully writes the pre-log, each transaction participant executes the "XA COMMIT" instruction.

In some embodiments, in the second stage, by setting a checkpoint to determine whether the write-ahead log is successful, each transaction participant commits the transaction after the write-ahead log is successful, thereby avoiding the inability to advance the abnormal transaction branch to the COMMITED state or the ROLLBACKED state based on log playback.

S4_15: If the transaction participant executes the "XA COMMIT" instruction successfully, the transaction participant sets its own status to COMMITED status (also called successful commit status).

S4_16: If a transaction participant fails to execute the "XA COMMIT" instruction, the transaction participant sets its own status to COMMIT_FAILED status (also called commit failure status).

In some embodiments, a checkpoint is set during the process of a transaction participant executing an "XA COMMIT" instruction, and the transaction participant for which the instruction execution fails is set to the COMMIT_FAILED state, so that it can be known in a timely manner whether all transaction participants are in the COMMITED state.

S4_17: If the transaction coordinator receives feedback from all transaction participants that they are in the COMMITED state, the distributed transaction enters the COMMITED state.

S4_18: If the transaction coordinator does not receive feedback from all transaction participants that they are in the COMMITED state, the distributed transaction enters the COMMIT_FAILED state.

In some embodiments, by setting a checkpoint to detect whether the transaction coordinator has received feedback from all transaction participants that they are in the COMMITED state, it is possible to promptly learn whether the transaction participants have successfully committed.

S4_19, after the distributed transaction enters the COMMIT_FAILED state, the distributed transaction commit is retried, that is, jumping to step S4_10 to re-execute the distributed transaction commit.

S4_20: If the distributed transaction cannot be committed again, or if the distributed transaction still enters the COMMIT_FAILED state after being committed again, the transaction coordinator performs log replay.

In some embodiments, a checkpoint is set during a distributed transaction commit retry process to determine whether to perform log replay.

In some embodiments, for a distributed transaction that submits an exception, the distributed transaction submission operation is re-executed until the number of failures is equal to a preset threshold, which can be set according to actual needs and is not limited in this application. When the number of failures is equal to the preset threshold, the transaction coordinator performs log playback.

In some embodiments, performing log playback may refer to playing back the write-ahead log of the transaction branch with the exception, determining the cause of failure of the abnormal transaction branch (for example, determining which process node caused the transaction branch to be unable to enter the COMMITED state or the ROLLBACKED state based on the checkpoint set above), and re-starting from the determined process node until the final state of the abnormal transaction branch is the COMMITED state or the ROLLBACKED state.

As shown in FIG6 , the specific execution process of ending an XA transaction includes:

S6_0, each transaction participant executes the "XA END" instruction.

S6_1: If the transaction participant executes the "XA END" instruction successfully, the transaction participant sets its own status to ENDED status (end status).

S6_2: If a transaction participant fails to execute the "XA END" instruction, the transaction participant rolls back and disconnects from the network connection with the transaction coordinator.

In some embodiments, a checkpoint is set during the process of a transaction participant executing an "XA END" instruction, and a rollback can be performed in advance for transaction participants whose execution fails.

S6_3, if the transaction participant rolls back successfully, the transaction participant sets its own state to ROLLBACKED state, and the transaction coordinator records the transaction participant disconnected from it as CONN_QUIT state.

S6_4, if the transaction participant fails to roll back, the transaction participant sets its own state to ROLLBACK_FAILED state, and the transaction coordinator records the transaction participant disconnected from it as CONN_QUIT state.

7 , a flowchart of rolling back a distributed transaction provided by an embodiment of the present application is exemplarily introduced.

S7_0, distributed transaction is rolled back.

S7_1, each transaction participant executes the "XA ROLLBACK" instruction.

S7_2: If the transaction participant executes the "XA ROLLBACK" instruction successfully, the transaction participant sets its own status to ROLLBACKED status.

S7_3: If a transaction participant fails to execute the "XA ROLLBACK" instruction, the transaction participant rolls back and disconnects from the network connection with the transaction coordinator.

In some embodiments, a checkpoint is set during the process of a transaction participant executing an "XA ROLLBACK" instruction, and a transaction participant that fails in the execution can attempt to roll back again.

S7_4: If the transaction participant rolls back successfully, the transaction participant sets its own status to ROLLBACKED, and the transaction coordinator records the disconnected transaction participant as CONN_QUIT.

S7_5: If the transaction participant fails to roll back, the transaction participant sets its own status to ROLLBACK_FAILED, and the transaction coordinator records the disconnected transaction participant as CONN_QUIT.

S7_6: If the transaction coordinator receives feedback from all transaction participants that the transaction is in the ROLLBACKED state, the distributed transaction enters the ROLLBACKED state.

S7_7, if the transaction coordinator does not receive feedback from all transaction participants that the transaction is in the ROLLBACKED state, the distributed transaction is rolled back and retried, that is, the process jumps to step S7_0 and re-executes the distributed transaction rollback.

S7_8: If the distributed transaction cannot be rolled back again, or after the distributed transaction is rolled back again, all transaction participants are still not in the ROLLBACKED state, the transaction coordinator disconnects the SESSION connection (also called session connection) with each transaction participant, and writes the transaction participant information in the ROLLBACK_FAILED state into the log.

S7_9, the transaction coordinator plays back the log.

In some embodiments, the transaction coordinator performs log playback to determine the cause of the failure of the abnormal transaction branch during the rollback process (for example, based on the checkpoints set above, determine which process node in the rollback process caused the rollback failure). If the transaction fails, the rollback is performed again from the determined process node until the final state of the abnormal transaction branch is ROLLBACKED.

Referring to FIG. 8 , a flowchart of the steps of a transaction processing method provided in an embodiment of the present application is shown. According to different requirements, the order of the steps in the flowchart can be changed, and some steps can be omitted. In this embodiment, the transaction processing method may include:

Step S81, in response to the received operation instruction, creating a distributed transaction for the operation instruction, the distributed transaction including multiple transaction branches.

In some embodiments, if the data processed by the operation instruction involves multiple sub-libraries or multiple sub-tables, it indicates that there are multiple transaction participants. A sub-library or a sub-table can serve as a transaction participant. By creating a distributed transaction for the operation instruction, consistency processing of the data located in multiple sub-libraries or multiple sub-tables can be achieved.

Step S82, committing the distributed transaction based on the preset transaction commit mechanism, and generating a pre-written log of the distributed transaction, the commit of each transaction branch in the multiple transaction branches includes multiple process nodes, and the preset transaction commit mechanism includes a checkpoint for detecting the execution status of the multiple process nodes and the transaction status of each transaction branch.

In some embodiments, taking the preset transaction commit mechanism as 2PC as an example, before each transaction branch is pre-committed, a first write-ahead log may be generated, and the transaction-related information of the first phase in the two-phase commit protocol may be recorded through the first write-ahead log; before each transaction branch is committed, a second write-ahead log may be generated, and the transaction-related information of the second phase in the two-phase commit protocol may be recorded through the second write-ahead log, so that when an abnormal transaction branch occurs, the abnormal transaction branch can be continued from the first phase or the second phase based on log playback.

In some embodiments, the transaction-related information of the first phase and the transaction-related information of the second phase may include transaction status information of the distributed transaction, transaction status information of the transaction branch, operation data, and SQL statements for processing the operation data.

In some embodiments, if the generation of the first write-ahead log or the second write-ahead log fails, indicating that the first phase or the second phase of the transaction cannot be recorded through the write-ahead log, each transaction branch can be directly controlled to be rolled back, avoiding the problem that the abnormal transaction branch cannot be continued from the first phase or the second phase based on log playback.

In some embodiments, the submission of each transaction branch includes submitting a transaction process or rolling back a transaction process, and the submitting transaction process or rolling back a transaction process includes multiple process nodes, and each of the multiple process nodes is provided with a checkpoint, so that for an abnormal transaction branch, the transaction can be resubmitted or rolled back from a specified process node based on log playback. An abnormal transaction branch may refer to a transaction branch that is not in a preset transaction state. For example, if a transaction branch is not in a Rollbacked state or a Committed state, the transaction branch may be considered an abnormal transaction branch.

Step S83: If it is determined that the distributed transaction contains an abnormal transaction branch, the abnormal transaction branch is processed based on the write-ahead log and the checkpoint. The abnormal transaction branch is caused by an abnormality in the device where the transaction coordinator is located, or an abnormality in the device where the transaction participant is located.

For example, an abnormality occurs in the device where the transaction coordinator is located at a certain time point, resulting in the inability of each transaction participant to receive the instruction of the transaction coordinator, or some transaction participants have not yet received the instruction of the transaction coordinator in time, resulting in the inability to smoothly execute the transaction submission process or rollback transaction process, which may generate one or more abnormal transaction branches; or, due to an abnormality in the device where a transaction participant is located, the transaction participant cannot receive the instruction of the transaction coordinator, or cannot smoothly execute the transaction submission process or rollback transaction process after receiving the instruction of the transaction coordinator, thereby generating an abnormal transaction branch. After the device abnormality is recovered, the pre-written log corresponding to the abnormal transaction branch is played back to determine the process node for reprocessing the abnormal transaction branch, and the abnormal transaction branch is processed with the determined process node as the starting process node, so as to realize the re-advancement of the transaction for the abnormal transaction branch from the specified process node. For example, a transaction participant of an abnormal transaction branch may send a request to re-advance the transaction to the transaction coordinator, which will replay the write-ahead log corresponding to the abnormal transaction branch, determine the process node for reprocessing the abnormal transaction branch, and notify the transaction participant (transaction participant of the abnormal transaction branch) to re-advance the transaction (commit or roll back the transaction) for the abnormal transaction branch using the determined process node as the starting process node.

As shown in FIG9 , a distributed middleware 30 is provided for an embodiment of the present application. The distributed middleware 30 may include a creation module 301 , a submission module 302 and a processing module 303 .

The creation module 301 is used to create a distributed transaction for the operation instruction in response to the received operation instruction, and the distributed transaction includes multiple transaction branches.

The submission module 302 is used to submit distributed transactions based on a preset transaction submission mechanism and generate a pre-written log of the distributed transaction. The submission of each transaction branch in the multiple transaction branches includes multiple process nodes. The preset transaction submission mechanism includes a checkpoint for detecting the execution status of the multiple process nodes and the transaction status of each transaction branch.

The processing module 303 is used to process the abnormal transaction branch based on the write-ahead log and the checkpoint when it is determined that the distributed transaction contains an abnormal transaction branch. The abnormal transaction branch is caused by an abnormality in the device where the transaction coordinator of the distributed transaction is located, or an abnormality in the device where the transaction participant of the distributed transaction is located.

Among them, the creation module 301, the submission module 302 and the processing module 303 can all be implemented by software, or can be implemented by hardware. Exemplarily, the creation module 301 is taken as an example to introduce the implementation of the creation module 301. Similarly, the implementation of the submission module 302 and the processing module 303 can refer to the implementation of the creation module 301.

As an example of a software functional unit, the creation module 301 may include code running on a computing instance. Among them, the computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the above-mentioned computing instance may be one or more. For example, the creation module 301 may include code running on multiple hosts/virtual machines/containers. It should be noted that the multiple hosts/virtual machines/containers used to run the code can be distributed in the same region (region) or in different regions. Furthermore, the multiple hosts/virtual machines/containers used to run the code can be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple data centers with close geographical locations. Among them, usually a region can include multiple AZs.

Similarly, multiple hosts/virtual machines/containers used to run the code can be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Usually, a VPC is set up in a region. For cross-region communication between two VPCs in the same region and between VPCs in different regions, a communication gateway needs to be set up in each VPC to achieve interconnection between VPCs through the communication gateway.

As an example of a hardware functional unit, the creation module 301 may include at least one computing device, such as a server, etc. Alternatively, the creation module 301 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof.

The multiple computing devices included in the creation module 301 can be distributed in the same region or in different regions. The multiple computing devices included in the creation module 301 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the creation module 301 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

It should be noted that, in other embodiments, the creation module 301 can be used to execute any step in the transaction processing method, the submission module 302 can be used to execute any step in the transaction processing method, and the processing module 303 can be used to execute any step in the transaction processing method. The steps that the creation module 301, the submission module 302 and the processing module 303 are responsible for implementing can be specified as needed. The creation module 301, the submission module 302 and the processing module 303 respectively implement different steps in the transaction processing method to achieve all the functions of the decision-making device 30.

As shown in FIG10 , a computing device 100 is provided in an embodiment of the present application, and the computing device 100 includes: a bus 102, a processor 104, a memory 106, and a communication interface 108. The processor 104, the memory 106, and the communication interface 108 communicate with each other through the bus 102. The computing device 100 may be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in the computing device 100.

The bus 102 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The lines can be divided into address bus, data bus, control bus, etc. For ease of representation, only one line is used in FIG10, but it does not mean that there is only one bus or one type of bus. Bus 104 may include a path for transmitting information between various components of computing device 100 (e.g., memory 106, processor 104, communication interface 108).

The processor 104 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP) or a digital signal processor (DSP).

The memory 106 may include a volatile memory, such as a random access memory (RAM). The processor 104 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

The memory 106 stores executable program codes, and the processor 104 executes the executable program codes to respectively implement the functions of the aforementioned creation module 301, submission module 302, and processing module 303, thereby implementing the transaction processing method. That is, the memory 106 stores instructions for executing the transaction processing method. In FIG. 10 , the processor 104 executes the executable program codes to respectively implement the functions of the aforementioned creation module 301, submission module 302, and processing module 303 as an example.

The communication interface 108 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 100 and other devices or a communication network.

The embodiment of the present application also provides a computing device cluster 10. The computing device cluster 10 includes at least one computing device. The computing device may be a server for data storage, or a local server in a local data center. In some embodiments, the computing device may also be a terminal device such as a desktop computer, a laptop computer, or a smart phone.

As shown in Fig. 11, the computing device cluster 10 includes at least one computing device 100. The memory 106 in one or more computing devices 100 in the computing device cluster 10 may store the same instructions for executing the transaction processing method.

In some possible implementations, the memory 106 of one or more computing devices 100 in the computing device cluster 10 may also store partial instructions for executing the transaction processing method. In other words, the combination of one or more computing devices 100 may jointly execute instructions for executing the transaction processing method.

It should be noted that the memory 106 in different computing devices 100 in the computing device cluster 10 can store different instructions, which are respectively used to execute part of the functions of the data access device. That is, the instructions stored in the memory 106 in different computing devices 100 can implement the functions of one or more modules among the creation module 301, the submission module 302 and the processing module 303.

In some possible implementations, one or more computing devices in the computing device cluster 10 can be connected via a network. The network may be a wide area network or a local area network, etc. FIG. 11 shows a possible implementation. As shown in FIG. 11 , two computing devices 100A and 100B are connected via a network, taking the functions of one or more modules in the creation module 301, the submission module 302, and the processing module 303 as an example. Specifically, the network is connected via a communication interface in each computing device. In this type of possible implementation, the memory 106 in the computing device 100A stores instructions for executing the functions of the creation module 301 and the submission module 302. At the same time, the memory 106 in the computing device 100B stores instructions for executing the functions of the processing module 303.

The connection method between the computing device cluster 10 shown in Figure 11 can be considered to be that the transaction processing method provided in this application requires a large amount of data storage and reading, so it is considered to hand over the functions implemented by the processing module 303 to the computing device 100B for execution.

It should be understood that the functions of the computing device 100A shown in FIG11 may also be completed by multiple computing devices 100. Similarly, the functions of the computing device 100B may also be completed by multiple computing devices 100.

The embodiment of the present application also provides a computer program product including instructions. The computer program product may be software or a program product including instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes a transaction processing method.

The embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk). The computer-readable storage medium includes instructions that instruct the computing device to execute the transaction processing method.

Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are schematic. For example, the division of the modules or units is a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the software product is stored in a storage medium, including a number of instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory, a random access memory, a magnetic disk or an optical disk.

The above description is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application should be included in the protection scope of the present application.

Claims (11)

1. A transaction processing method, characterized in that the method comprises:

   In response to the received operation instruction, create a distributed transaction for the operation instruction, wherein the distributed transaction includes multiple transaction branches;

   Submitting the distributed transaction based on a preset transaction submission mechanism, and generating a write-ahead log of the distributed transaction, wherein the submission of each of the multiple transaction branches includes multiple process nodes, and the preset transaction submission mechanism includes a checkpoint for detecting the execution status of the multiple process nodes and the transaction status of each transaction branch;

   If it is determined that the distributed transaction includes an abnormal transaction branch, the abnormal transaction branch is processed based on the write-ahead log and the checkpoint, and the abnormal transaction branch is caused by an abnormality in a device where a transaction coordinator of the distributed transaction is located, or an abnormality in a device where a transaction participant of the distributed transaction is located.
2. The transaction processing method according to claim 1, wherein creating a distributed transaction for the operation instruction comprises:

   If the data processed by the operation instruction involves multiple sub-databases or multiple sub-tables, a distributed transaction is created for the operation instruction.
3. The transaction processing method according to claim 1 or 2, characterized in that the preset transaction commit mechanism is a two-phase commit protocol, and the generating of the write-ahead log of the distributed transaction comprises:

   Before each transaction branch is pre-committed, a first write-ahead log is generated, where the first write-ahead log is used to record transaction-related information of the first phase in the two-phase commit protocol;

   Before each transaction branch is committed, a second write-ahead log is generated, where the second write-ahead log is used to record transaction-related information of the second phase in the two-phase commit protocol; the transaction-related information of the first phase and the transaction-related information of the second phase both include transaction status information of the distributed transaction, transaction status information of the transaction branch, operation data, and a structured query language SQL statement for processing the operation data.
4. The transaction processing method according to claim 3, characterized in that the method further comprises:

   If the generation of the first write-ahead log or the second write-ahead log fails, each transaction branch is controlled to be rolled back.
5. The transaction processing method according to any one of claims 1 to 4 is characterized in that the submission of each transaction branch includes submitting a transaction process or rolling back a transaction process, and the submitting transaction process or the rolling back transaction process both include multiple process nodes, and each of the multiple process nodes is provided with the checkpoint.
6. The transaction processing method according to claim 5, characterized in that after submitting the distributed transaction based on the preset transaction submission mechanism, it also includes:

   A transaction branch that is not in a preset transaction state is determined as the abnormal transaction branch, where the preset transaction state includes a Rollbacked state or a Committed state.
7. The transaction processing method according to claim 6, wherein the processing of the abnormal transaction branch based on the write-ahead log and the checkpoint comprises:

   Replaying the write-ahead log corresponding to the abnormal transaction branch, and determining a process node for reprocessing the abnormal transaction branch;

   The abnormal transaction branch is processed using the determined process node as the starting process node.
8. A distributed middleware, characterized by comprising:

   A creation module, configured to create a distributed transaction for the operation instruction in response to the received operation instruction, wherein the distributed transaction includes a plurality of transaction branches;

   A commit module, configured to commit the distributed transaction based on a preset transaction commit mechanism, and generate a write-ahead log of the distributed transaction, wherein the commit of each of the multiple transaction branches includes multiple process nodes, and the preset transaction commit mechanism includes a checkpoint for detecting the execution status of the multiple process nodes and the transaction status of each transaction branch;

   a processing module, configured to process the abnormal transaction branch based on the write-ahead log and the checkpoint when determining that the distributed transaction includes an abnormal transaction branch, wherein the abnormal transaction branch is processed by the distributed transaction The device where the transaction coordinator is located has an exception, or the device where the transaction participant of the distributed transaction is located has an exception.
9. A computing device cluster, characterized in that it includes at least one computing device, each computing device includes a processor and a memory;

   The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the transaction processing method according to any one of claims 1 to 7.
10. A computer program product comprising instructions, characterized in that when the instructions are executed by a computing device cluster, the computing device cluster executes the transaction processing method as described in any one of claims 1 to 7.
11. A computer-readable storage medium, characterized in that it includes computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes the transaction processing method as described in any one of claims 1 to claim 7.