CN115617465B

CN115617465B - Distributed transaction processing method and device

Info

Publication number: CN115617465B
Application number: CN202211630531.XA
Authority: CN
Inventors: 张顺; 徐平; 秦世政; 曾鹤鸣
Original assignee: Alibaba China Co Ltd
Current assignee: Alibaba China Co Ltd
Priority date: 2022-12-19
Filing date: 2022-12-19
Publication date: 2023-03-14
Anticipated expiration: 2042-12-19
Also published as: CN115617465A

Abstract

An embodiment of the present specification provides a distributed transaction processing method and apparatus, where the distributed transaction processing method includes: determining at least two storage nodes for storing metadata and executing the current transaction according to metadata information carried in the current transaction execution request; determining a target storage node from the at least two storage nodes executing the current transaction, and determining a main storage node corresponding to the slave storage node under the condition that the target storage node is determined to be a slave storage node executing the previous transaction execution request and contains the overtime lock information; in the event that it is determined that the master storage node does not contain lock information, executing the last transaction execution request with the slave storage node. The transaction execution state can be determined only according to the lock information of the main storage node, and the transaction recovery can be realized without determining the transaction state through the coordination node, so that the execution of the current transaction can be promoted, and the influence on the whole service capability is avoided.

Description

Distributed transaction processing method and device

Technical Field

The embodiment of the specification relates to the technical field of computers, in particular to a distributed transaction processing method.

Background

In a distributed database, transactions and queries are distributed to multiple nodes for execution, i.e., multiple nodes execute the same transaction. In the process of executing the same transaction by a plurality of nodes, a coordination node is generally required to be independently deployed and used as a centralized node to receive transaction execution information of other nodes through the coordination node throughout the execution period of the whole transaction, so that the state of transaction execution can be known.

However, if an accident occurs in the coordinating node, the state of the transaction execution cannot be known, the transaction cannot be recovered or cancelled, and the transaction can be advanced only after the coordinating node is recovered, which affects the processing of the transaction, and further affects the overall service capability of the distributed database.

Disclosure of Invention

In view of this, the embodiments of the present specification provide a distributed transaction processing method. One or more embodiments of the present specification also relate to a distributed transaction processing apparatus, an object storage device, a computing device, a computer-readable storage medium, and a computer program, so as to solve the technical deficiencies in the prior art.

According to a first aspect of embodiments of the present specification, there is provided a distributed transaction processing method, including:

determining at least two storage nodes for storing metadata and executing the current transaction according to metadata information carried in the current transaction execution request;

determining a target storage node from the at least two storage nodes executing the current transaction, and determining a main storage node corresponding to the slave storage node under the condition that the target storage node is determined to be a slave storage node executing the previous transaction execution request and contains the overtime lock information;

executing the last transaction execution request with the slave storage node if it is determined that the master storage node does not contain lock information.

According to a second aspect of embodiments of the present specification, there is provided a distributed transaction processing apparatus comprising:

the first determining module is configured to determine at least two storage nodes for storing metadata and executing the current transaction according to metadata information carried in the current transaction execution request;

a second determining module configured to determine a target storage node from the at least two storage nodes executing the current transaction, and in a case that the target storage node is determined to be a slave storage node executing the previous transaction execution request and contains the lock information which has timed out, determine a master storage node corresponding to the slave storage node;

an execution module configured to execute the last transaction execution request with the slave storage node if it is determined that the master storage node does not contain lock information.

According to a third aspect of embodiments herein, there is provided an object storage apparatus including:

a memory and a processor;

the memory is configured to store computer-executable instructions and the processor is configured to execute the computer-executable instructions, which when executed by the processor implement the steps of the distributed transaction processing method described above.

According to a fourth aspect of embodiments herein, there is provided a computing device comprising:

a memory and a processor;

According to a fifth aspect of embodiments herein, there is provided a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the distributed transaction processing method described above.

According to a sixth aspect of embodiments herein, there is provided a computer program, wherein the computer program, when executed in a computer, causes the computer to perform the steps of the distributed transaction processing method described above.

One embodiment of the present specification provides a distributed transaction processing method, which determines at least two storage nodes storing metadata for executing a current transaction according to metadata information carried in a current transaction execution request; determining a target storage node from the at least two storage nodes executing the current transaction, and determining a main storage node corresponding to the slave storage node under the condition that the target storage node is determined to be a slave storage node executing the previous transaction execution request and contains the overtime lock information; executing the last transaction execution request with the slave storage node if it is determined that the master storage node does not contain lock information.

The method includes that storage nodes for processing transactions are determined as a main storage node and a slave storage node, lock information is distributed to the main storage node and the slave storage node respectively, when a current transaction execution request is received, if it is determined that a target storage node for executing the transaction execution request is a slave storage node for executing a previous transaction execution request, and the slave storage node contains the overtime lock information, it is indicated that the time for executing the transaction by the slave storage node is overtime but is not submitted, at this time, the main storage node corresponding to the slave storage node can be determined, under the condition that the main storage node does not contain the lock information, it is indicated that the main storage node has executed the previous transaction execution request, and the main storage node is in a normal transaction submission state, at this time, the slave storage node can continue to execute the previous transaction execution request, so that the execution of the previous transaction is completed, and whether an accident occurs to a coordinating node is concerned, recovery of the transaction can be realized, further, execution of the current transaction can be realized, and the influence on the whole service capability is avoided.

Drawings

Fig. 1 is a schematic application scenario diagram of a distributed transaction processing method according to an embodiment of the present specification;

FIG. 2 is a flow diagram of a distributed transaction processing method provided by one embodiment of the present specification;

fig. 3 is a schematic diagram of a transaction in a distributed transaction processing method according to an embodiment of the present specification;

FIG. 4 is a flowchart of a distributed transaction processing method according to an embodiment of the present disclosure;

fig. 5 is a schematic structural diagram of a distributed transaction processing apparatus according to an embodiment of the present specification;

fig. 6 is a block diagram of a computing device according to an embodiment of the present disclosure.

Detailed Description

In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present description. This description may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein, as those skilled in the art will be able to make and use the present disclosure without departing from the spirit and scope of the present disclosure.

The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used in one or more embodiments of the present specification refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, etc. may be used herein in one or more embodiments to describe various information, these information should not be limited by these terms. These terms are only used to distinguish one type of information from another. For example, a first can be termed a second and, similarly, a second can be termed a first without departing from the scope of one or more embodiments of the present description. The word "if" as used herein may be interpreted as "at" \8230; "or" when 8230; \8230; "or" in response to a determination ", depending on the context.

First, the noun terms to which one or more embodiments of the present specification relate are explained.

Storage space (Bucket): containers for storing objects, all of which must be attached to a certain storage space.

Name/Key (Name/Key): a memory object is uniquely identified in a memory space.

Object (Object): and the basic unit for storing data consists of a name, metadata and data. Metadata is a key-value pair, representing some property of an object.

Hierarchical namespace (Hierarchical namespace): namespaces organized in a tree hierarchy.

Directory tree (Directory-like tree): a same-level namespace.

Transaction (Transaction): a minimum non-separable unit of work usually corresponds to a complete business operation.

Distributed transaction (Distributed transaction): meaning that the participants of the transaction, the servers supporting the transaction, etc. are located on different nodes of different distributed systems, respectively.

Transaction isolation level (Transaction isolation level): the extent to which one transaction must be isolated from resource or data changes made by other transactions.

Read Committed (Read Committed): one transaction can only read data that other transactions have committed.

Two Phase Commit (Two Phase Commit,2 PC): a classical distributed transaction algorithm is divided into two phases, a preparation phase and a commit phase.

Coordinator (Coordinator): the coordinating node, a role in distributed transactions, is responsible for advancing the transaction and maintaining the corresponding state.

Participant (Participant): the storage node, a role in the distributed transaction, acts as a participant in the transaction, interacting with the coordinator.

Global Time Service (TSO): a centralized service can grant globally ordered timestamps.

HDFS: the Hadoop Distributed File System is a Distributed File System.

UUID: the universal Unique Identifier is a universal Unique Identifier.

Distributed database: smaller computer systems are typically used, each of which may be located individually in a single location, each of which may have a complete copy, or a partial copy, of the distributed database, with its own local database, and many computers located in different locations are interconnected via a network to form a complete, globally logically centralized, physically distributed, large database.

In practical applications, in a big data scenario, in order to improve metadata capability, object storage provides a directory tree based modality, such as sinking HDFS capability on a service side or self-building directory tree service. In any case, based on the metadata capability of the single machine, the size and the access capability of the metadata are limited by the processing capability of the single machine; cross-machine based metadata capabilities are typically based on a generic distributed transaction scheme; these distributed transaction schemes typically provide data read and write services at a snapshot isolation level.

However, in the object storage scenario, since the file system does not need the characteristic of repeatable reading, only the submitted level needs to be read, and the data read-write service of the snapshot isolation level does not need to be provided.

In addition, in the existing distributed database, a coordination node is usually required to be used as a centralized node to run through an execution cycle of the whole transaction, and a single-point fault hidden danger exists, that is, if an accident occurs to the coordination node, the state of the whole transaction is unknown, and the transaction needs to be continuously advanced after the coordination node recovers, and meanwhile, when the accident occurs to the coordination node, the execution of the current transaction is stopped, other transactions cannot intervene in the transaction and cannot read and write data locked by the transaction, so that the whole service capability is influenced. And a three-party module is required to pay attention to the information of the coordination node at any time, namely, the coordination node can submit the work information of the coordination node to the three-party module. Moreover, under the condition of providing the data read-write service at the snapshot isolation level, all transactions need to be globally ordered, so that a centralized global time service needs to be introduced, a single-point risk is caused, and extra delay consumption is introduced. Therefore, an effective solution to the above problems is needed.

In this specification, a distributed transaction processing method is provided, and the specification simultaneously relates to a distributed transaction processing apparatus, an object storage device, a computing device, and a computer-readable storage medium, which are described in detail in the following embodiments one by one.

Referring to fig. 1, fig. 1 is a schematic diagram illustrating an application scenario of a distributed transaction processing method according to an embodiment of the present specification.

Fig. 1 includes a client 102 and a server 104, where the server 104 includes a front-end unit 1042 and a back-end unit 1044, where the back-end unit 1044 may be understood as a storage node for storing metadata, and when a user sends a transaction execution request to the server 104 through the client 102, inside the server 104, the front-end unit 1042 receives the transaction execution request, may invoke the metadata stored in the back-end unit 1044, and execute a transaction in the transaction execution request on the metadata, so as to implement a read-write service of the metadata by the user. It is understood that the front end computer 1042 calls the back end computer 1044, which is a call logic inside the server 104 and is not perceivable by the user.

In specific implementation, a user sends a transaction execution request to the server 104 through the client 102, the transaction execution request includes a transaction executed on metadata, after the server 104 receives the transaction execution request, the server invokes at least two backend machines 1044 storing the metadata corresponding to the transaction execution request through the front-end machine 1042, determines a master node and a slave node from the at least two backend machines 1044, allocates lock information to the master node and the slave node when the master node and the slave node write the metadata in advance respectively, and deletes the lock information when the master node and the slave node submit the metadata in advance. Based on this, when the server 104 receives a next transaction execution request, it may be determined that the backend machine 1044 processing the next transaction execution request is a slave node processing a previous transaction execution request and includes lock information that has timed out, which indicates that the backend machine 1044 is still in a previous transaction execution process and may result in that the previous transaction cannot be successfully executed due to an accident, at this time, it may determine a master node corresponding to the slave node, and in a case that the master node does not include the lock information, it may indicate that metadata pre-written when the master node processes the previous transaction is already submitted, which indicates that the previous transaction execution is successfully executed, and at this time, the next transaction execution request may cause the slave node to submit the pre-written metadata to complete execution of the previous transaction, thereby implementing automatic recovery of the transaction.

As shown in fig. 1, a user sends a first transaction execution request "rename a file name abc to a file name 123" to a server 104 through a client 102, a front-end computer 1042 of the server 104 calls a back-end computer 1042 storing the file name abc and a back-end computer 1044 storing the file name 123, the back-end computer 1042 pre-writes the file name abc as a master node and allocates master lock information, and the back-end computer 1044 pre-writes the file name 123 as a slave node and allocates slave lock information. The back-end machine 1042 deletes the master lock information when submitting the pre-written filename abc, and the back-end machine 1044 deletes the slave lock information when submitting the filename 123. The user sends a second transaction execution request "delete the file name 123" to the server 104 through the client 102, the front-end computer 1042 of the server 104 calls the back-end computer 1044 storing the file name 123, at this time, the back-end computer 1044 is a slave node executing the first transaction execution request, when the lock information that has timed out exists in the back-end computer 1044 of the slave node, the back-end computer 1042 of the slave node is determined, and when the back-end computer 1042 does not contain the lock information, the back-end computer 1044 submits the pre-written file name 123, so that the first transaction execution request "renames the file name abc to the file name 123" is completed, recovery of the first transaction is realized, and it is avoided that the first transaction cannot be executed due to an accident, and the execution state of the first transaction cannot be known, thereby ensuring propulsion of the transaction.

Referring to fig. 2, fig. 2 is a flowchart illustrating a distributed transaction processing method according to an embodiment of the present specification, which includes the following steps.

Step 202: and determining at least two storage nodes for storing the metadata and executing the current transaction according to the metadata information carried in the current transaction execution request.

Specifically, the distributed transaction processing method provided in the embodiments of the present specification may be applied to a distributed database, and may also be applied to an object storage device, where the object storage device may be, for example, a storage device for storing a file, and specifically may be a storage device for storing an image file, a storage device for storing an information archive, and the like. Taking an example that a user queries image files in object storage equipment, the image files can be stored in a storage space, each image file has a file name, the file name is metadata, the file name of each image file is stored in a back-end machine of a server of the object storage equipment, and when the user wants to rename a certain image file, the back-end machine storing the file name of the image file can be called through a front-end machine of the server of the object storage equipment, so that the file name can be modified.

Specifically, the distributed transaction processing method may be applied to a server of a distributed database or an object storage device, and is particularly applied to a front-end machine of the server. The user can call the front-end computer through the client, and the front-end computer performs read-write operation on the metadata through accessing the storage node. The front-end machine may be, for example, a coordinating node. The storage node may be, for example, a backend machine, and the reading and writing operations of the metadata performed by the backend machine are not perceived by the user. It is understood that the distributed transaction processing method can be applied to any system requiring a plurality of nodes to process distributed transactions, and the description is not limited herein.

Specifically, the metadata may be processed by using the distributed transaction processing method, for example, when the distributed transaction processing method is used in a distributed database in an enterprise, data stored in the distributed database is an enterprise employee file, the metadata may be a filename of the enterprise employee file, and the metadata is processed, and may be renamed to the filename of the enterprise employee file, or may be created as a new enterprise employee file, and at this time, a new filename needs to be created.

For convenience of understanding, in the embodiments of this specification, detailed description is given by taking an example in which the distributed transaction processing method is applied to a file renaming scenario, but the distributed transaction processing method is not affected when applied to other implementable scenarios.

The current transaction execution request may be understood as a transaction execution request received at a current time, where the transaction execution request may be sent by a user through a client, and after receiving the current transaction execution request, it is required to process a current transaction in the current transaction execution request, and determine at least two storage nodes for executing the current transaction. The transaction execution request may be, for example, a renaming transaction for a file name by changing the file name in the database from abc to xyz. The metadata information may be understood as information of metadata corresponding to a transaction in the transaction execution request, for example, for the aforementioned renamed transaction, where the metadata information carried therein is "change from abc to xyz", then at least two storage nodes executing the current transaction that store the metadata may be understood as at least two storage nodes executing the renamed transaction that store the metadata corresponding to the metadata information, for example, for the aforementioned metadata information, the metadata corresponding to the metadata information determined according to the metadata information is abc and xyz, then at least two storage nodes executing the current transaction that store the metadata are a storage node storing the metadata abc and a storage node storing the metadata xyz.

Based on this, the metadata corresponding to the metadata information can be determined according to the metadata information carried in the transaction execution request received at the current moment, and then at least two storage nodes for executing the current transaction, which store the metadata, are determined according to the metadata. It can be understood that, if the storage node stores metadata corresponding to the metadata information carried in the current transaction execution request, it indicates that the storage node is a storage node that executes the current transaction.

It should be noted that, in a file renaming scenario, metadata stored by a storage node may be a file name of data, and since a large amount of data is stored in the distributed database, if the file names of all data are stored by only one storage node, there is a high requirement on a storage space of the storage node. Therefore, a plurality of storage nodes can be provided, each storage node can be used for storing metadata of a preset character range, for example, storage node 1 stores a file name with an initial letter a, storage node 2 stores a file name with an initial letter b \8230 \ 8230, storage node 6 stores a file name with an initial letter y, and then when data with a certain file name abc is renamed to xyz, the storage node storing the file name abc can be determined to be storage node 1 and the storage node storing the file name xyz is determined to be storage node 6 according to the initial letters. Alternatively, the storage node 1 may store a file name with the first letter (a, b, c, d, e), and the storage node 2 may store a file name with the first letter (f, g, h). Each storage node may store metadata in the storage range according to a preset storage range, where the preset storage range may be a character range or another range, and this is not limited in this embodiment of the specification.

In practical application, before receiving a current transaction execution request, that is, before determining at least two storage nodes storing metadata and executing a current transaction according to metadata information carried in the current transaction execution request, a storage node in a distributed database may execute the previous transaction, and the storage nodes executing the previous transaction and the current transaction may partially overlap, and in order to prevent a transaction conflict, lock information may be allocated to the storage node executing the previous transaction when the previous transaction is executed, where the specific implementation manner is as follows:

determining a main storage node and a slave storage node for executing a previous transaction execution request according to the previous transaction execution request corresponding to the current transaction execution request;

executing the last transaction execution request by using the master storage node and the slave storage node, allocating master lock information to the master storage node, and allocating slave lock information to the slave storage node, wherein the master lock information comprises a starting time of the master storage node executing the last transaction execution request, and the slave lock information comprises a starting time of the slave storage node executing the last transaction execution request and node information of the master storage node;

deleting the master lock information if it is determined that the master storage node submits a transaction completion notification for the last transaction execution request, and deleting the slave lock information if it is determined that the slave storage node submits a transaction completion notification for the last transaction execution request.

The previous transaction execution request may be understood as a previous transaction execution request of the current transaction execution request. If the last transaction execution request is received, the last transaction in the last transaction execution request needs to be executed. The primary lock information may be understood as lock information allocated to the metadata being processed in the primary storage node, which makes it impossible for other transactions to read and write the metadata being processed in the primary storage node. The slave lock information can be understood as lock information allocated to the metadata being processed in the slave storage node, and accordingly, the lock information can also prevent other transactions from reading and writing the metadata being processed in the slave storage node.

In order to distinguish the master storage node from the slave storage node, the storage nodes processing the transaction include the lock information, the master storage node includes the master lock information only including the start time, and the slave storage node includes the slave lock information including the start time and the node information of the master storage node, so that the master storage node can be determined when accessing the slave storage node, and the execution state of the transaction can be determined.

It should be noted that, when a storage node executes a transaction execution request, it may be understood that the storage node executes a transaction in the transaction execution request, and the process may include two phases, a pre-write phase in which the storage node performs pre-write of metadata, but does not access the pre-written metadata when accessing the storage node, and a commit phase in which the storage node accesses the storage node after committing the pre-written metadata. Then the transaction completion notification can be understood as a notification that the storage node committed the pre-written metadata during the commit phase.

Based on this, a master storage node and a slave storage node which execute a last transaction in a last transaction execution request can be determined, and the master storage node and the slave storage node are caused to execute the last transaction, and when the master storage node starts to execute, namely in a pre-writing phase, master lock information is distributed to the master storage node, wherein the master lock information comprises a starting time of the master storage node to execute the last transaction. When the master storage node commits the pre-write metadata of the last transaction, the master lock information is deleted. Accordingly, when the slave storage node starts executing, namely in the pre-writing phase, slave lock information is distributed to the slave storage node, wherein the slave lock information comprises the starting time of the slave storage node executing the last transaction and node information of the master storage node. The slave lock information is deleted when the pre-write metadata of the last transaction is committed from the storage node.

In practical applications, taking an example that a transaction is processed by two storage nodes, referring to fig. 3, fig. 3 shows a schematic diagram of a transaction in a distributed transaction processing method according to an embodiment of the present specification. During the pre-write phase of the transaction execution, the coordinating node distinguishes between the master storage node and the slave storage node for the storage node that processes the transaction. As shown in fig. 3. Taking the executed transaction as a transfer transaction as an example, namely account a transfers 100 elements to account B, the master storage node is the node for managing account a, and the slave storage node is the node for managing account B. The transfer transaction includes: subtracting 100 yuan from account a and adding 100 yuan to account B.

Step 302: the coordination node sends the transaction information to the main storage node and distributes the lock information to the main storage node.

Specifically, the transaction processing process is continued by taking the above transfer transaction as an example, and the coordinating node sends the transaction information of "account a minus 100 yuan" to the main storage node.

Step 304: and the main storage node prewrites the metadata corresponding to the transaction information and sends a prewrite completion notice to the coordination node.

Specifically, the master storage node pre-writes 100 elements from the account a and sends a pre-write completion notification to the coordinating node.

Step 306: the coordinating node sends the transaction information to the slave storage nodes and assigns lock information to the slave storage nodes.

Specifically, the coordinating node sends transaction information of "account B adds 100 elements" to the slave storage node.

Step 308: and pre-writing the metadata corresponding to the transaction information from the storage node, and sending a pre-writing completion notification to the coordination node.

Specifically, 100 yuan is pre-written from the storage node to the account B, and a pre-write completion notification is sent to the coordination node.

Step 310: the coordinating node sends commit information to the primary storage nodes.

Step 312: the master storage node submits the pre-written metadata and clears the lock information, and sends a submission completion notification to the coordinating node.

Specifically, the master storage node deletes the prewritten 100-tuple, clears the lock information, and sends a commit completion notification to the coordinating node.

Step 314: the coordinating node sends commit information to the slave storage nodes.

Step 316: the pre-written metadata is submitted from the storage node and the lock information is cleared, and a submission completion notification is sent to the coordinating node.

Specifically, add the prewritten 100-tuple from the storage node to account B, clear the lock information, and send a commit complete notification to the coordinating node.

Since the lock information allocated to the main storage node includes the starting time of the main storage node starting to execute the transaction, the transaction execution state can be acquired from the lock information of the main storage node, and the coordination node does not maintain the transaction state information.

For example, when the previous transaction execution request is to rename the filename abc to the filename 123, the previous transaction is to "rename the filename abc to the filename 123", and when the transaction is executed, the storage node storing the filename abc needs to complete the operation of deleting the filename abc, and the storage node storing the filename 123 needs to complete the operation of adding the filename 123, then it may be determined that the storage node storing the filename abc is the master storage node, and the storage node storing the filename 123 is the slave storage node. And the main storage node deletes the file name abc determined by the pre-writing node and deletes the main lock information in a submitting stage of submitting. And a commit stage of causing the slave storage node to rewrite the file name 123 in a rewrite stage, and allocating slave lock information including a start time and node information of the master storage node to the slave storage node, and adding the rewritten file name 123 from the storage node, and deleting the slave lock information, to thereby complete the previous transaction of renaming the file name abc to the file name 123.

In summary, in the process of executing the transaction, by distinguishing the master storage node and the slave storage nodes, allocating the lock information including the start time to the master storage node, and allocating the lock information including the start time and the node information of the master storage node to the slave storage nodes, the transaction state executed by the master storage node can be determined only according to the lock information of the master storage node and the start time included in the lock information, and whether the transaction execution is overtime can be determined, so as to determine whether the transaction is abnormal, without determining by the coordination node, thereby avoiding the unknown transaction execution state caused by an accident occurring at the coordination node, and without requiring a global time service mechanism, the transaction execution state can be realized only by depending on the timestamp of the server where the single storage node is located, thereby simplifying the service architecture and the transaction execution flow. And the master storage node executing the transaction can be determined through the node information of the master storage node included in the lock information of the slave storage node, so that the state of the master storage node executing the transaction is determined.

In specific implementation, a master storage node and a slave storage node may be determined for at least two storage nodes executing a transaction, and the specific implementation is as follows:

determining at least two storage nodes for storing metadata and executing the previous transaction according to metadata information carried in the previous transaction execution request corresponding to the current transaction execution request;

and determining a master storage node and a slave storage node from the at least two storage nodes executing the previous transaction according to the length corresponding to the metadata stored in the storage node executing the previous transaction, wherein the slave storage node is a storage node except for the master storage node from the at least two storage nodes executing the previous transaction.

The storage node executing the previous transaction may be understood as a storage node of metadata corresponding to the transaction when the previous transaction in the previous transaction execution request is executed. For example, in the previous transaction execution request, the filename abc is renamed to the filename 123, and the storage node that executes the previous transaction is the storage node that stores the metadata abc and the storage node that stores the metadata 123. The length corresponding to the metadata may be understood as a character length corresponding to the metadata, the character lengths of the metadata stored in each storage node may be arranged in descending order, and the storage node with the largest character length in the arrangement result may be used as a main storage node.

It should be noted that the storage node executing the current transaction and the storage node executing the previous transaction are both storage nodes used for storing metadata in the distributed database, and the storage node executing the current transaction and the storage node executing the previous transaction are partially the same. For example, if the previous transaction is to rename the filename abc to the filename 123, the storage nodes where the previous transaction is performed are the storage node storing the filename abc and the storage node storing the filename 123, and the current transaction is to rename the filename abc to the filename xyz, then the storage nodes where the current transaction is performed are the storage node storing the filename abc and the storage node storing the filename xyz. As can be seen, the storage node executing the current transaction is partially the same as the storage node executing the previous transaction. Accordingly, when the storage node executing the current transaction and the storage node executing the previous transaction are completely different, that is, the metadata corresponding to the previous transaction and the metadata corresponding to the current transaction are completely different, there is no situation that the metadata is locked by the locking information and the current transaction cannot be processed before the previous transaction is completed, but the current transaction is directly processed.

Based on this, the storage node with the longest character length may be used as the master storage node and the rest of the storage nodes may be used as the slave storage nodes according to the character length of the metadata stored in each of the at least two storage nodes executing the previous transaction.

It is understood that, in the case that there are 3 storage nodes executing the previous transaction, the 1 storage node executing the previous transaction, which determines that the character length of the stored metadata is longest, is used as the master storage node from the 3 storage nodes executing the previous transaction, and the remaining 2 storage nodes executing the previous transaction are all slave storage nodes.

In addition, the main storage node may be determined from at least two storage nodes executing the previous transaction according to any method capable of determining the main storage node, for example, the size of the data amount of the metadata stored in the storage node executing the previous transaction may be determined, or one storage node executing the previous transaction may be directly and randomly selected as the main storage node, which is not limited in this embodiment of the present specification.

In conclusion, by determining the main storage node, the state of transaction execution can be judged directly according to the lock information of the main storage node, and a coordination node is not needed, so that the problem of transaction execution stagnation caused by single-point failure of the coordination node is avoided, and a three-party device for maintaining the working information of the coordination node and providing a basis for judging lock overtime is not needed, so that the service architecture is simplified.

Step 204: and determining a target storage node from the at least two storage nodes executing the current transaction, and determining a main storage node corresponding to the auxiliary storage node under the condition that the target storage node is determined to be an auxiliary storage node executing the previous transaction execution request and contains the lock information which is overtime.

Specifically, after determining at least two storage nodes executing the current transaction that process the current transaction execution request, it may be determined whether each storage node executing the current transaction is a storage node executing the previous transaction execution request, so as to avoid a conflict between transactions.

The target storage node may be understood as a storage node in which each of at least two storage nodes executing the current transaction executes the current transaction.

Based on this, it may be determined whether each of at least two storage nodes executing the current transaction, which process the current transaction execution request, is a storage node processing the previous transaction execution request, and in a case where it is determined that any target storage node of the at least two storage nodes executing the current transaction is a slave storage node processing the previous transaction execution request and the slave storage node contains lock information that has timed out, a master storage node corresponding to the slave storage node is determined according to the slave storage node.

Specifically, if the slave storage node includes the lock information that has been timed out, it indicates that the execution time of the last transaction by the slave storage node has exceeded the preset transaction execution time, that is, the execution time of the last transaction by the slave storage node stays in the pre-write stage and is not submitted, at this time, it is necessary to determine the master storage node corresponding to the slave storage node, and determine the execution state of the last transaction according to the lock information included in the master storage node.

In specific implementation, the master storage node corresponding to the slave storage node may be determined according to the slave lock information of the slave storage node, and the specific implementation manner is as follows:

and determining the main storage node corresponding to the slave storage node according to the node information of the main storage node, which is included in the slave lock information.

The node information of the main storage node may be understood as information identifying the main storage node, for example, may be a UUID of a service end where the main storage node is located.

Based on the node information of the master storage node, the node information of the master storage node can be determined according to the slave lock information of the slave storage node, so that the master storage node corresponding to the slave storage node can be determined.

In summary, the master storage node corresponding to the slave storage node is determined through the node information of the master storage node included in the slave lock information, so that the master storage node corresponding to the slave storage node can be quickly determined, the transaction execution state can be quickly determined, and the efficiency is improved.

In practical application, whether the lock information is overtime or not can be determined through the starting time included in the lock information, and further whether the transaction executed by the storage node is overtime or not can be determined, and the specific implementation mode is as follows:

and under the condition that the target storage node is determined to contain the lock information, judging whether the lock information is overtime or not according to the initial time and the preset transaction execution duration included in the lock information.

The preset transaction execution duration may be understood as a reference time for completing the transaction execution.

Based on this, whether the lock information is overtime can be judged according to the starting time contained in the lock information, the preset reference time for completing the transaction execution and the current time.

Specifically, the current transaction execution duration of the target storage node corresponding to the lock information may be determined according to the current time and the start time included in the lock information, and then whether the lock information is overtime may be determined according to the current transaction execution duration and a preset transaction execution duration.

In summary, whether the lock information is overtime can be judged through the starting time and the preset transaction execution duration included in the lock information, so that the transaction execution state can be judged.

Step 206: executing the last transaction execution request with the slave storage node if it is determined that the master storage node does not contain lock information.

Specifically, after the master storage node corresponding to the slave storage node is determined, in a case that the master storage node is determined not to contain the lock information, it indicates that the last transaction executed by the master storage node has been submitted, at this time, it indicates that the execution state of the last transaction is successful, at this time, the slave storage node may continue to execute the last transaction execution request, that is, submit the metadata pre-written by the slave storage node, and delete the lock information of the slave storage node.

Further, in the event that it is determined that the master storage node contains lock information, a rollback operation of the last transaction execution request is performed, and a current transaction execution request is executed.

Wherein performing a rollback operation of a previous transaction execution request may be understood as deleting updates performed by one or more partially completed transactions to restore metadata to a state prior to execution of the previous transaction.

Therefore, when the master storage node is determined to contain the lock information, it is indicated that the last transaction executed by the master storage node is not committed, and it is indicated that the execution of the transaction by the master storage node fails.

Taking renaming of the file name abc to the file name xyz as an example, when it is determined that the main storage node storing the file name abc contains lock information, it indicates that the main storage node only performs pre-writing on the file name abc and does not submit, and at this time, a rollback operation may be performed to cancel the pre-writing on the file name abc.

Specifically, the executing the rollback operation of the previous transaction execution request includes:

and executing the rollback operation of the last transaction execution request by using the slave storage node, and executing the rollback operation of the last transaction execution request by using the master storage node.

Since the lock information included in the slave storage node is also timed out, which indicates that the slave storage node is also in the pre-write phase and is not committed, at this time, the slave storage node may perform the rollback operation first, and then the master storage node may perform the rollback operation.

Wherein, the rollback operation is executed by the slave storage node, which can be understood as deleting the metadata pre-written from the storage node and deleting the lock information of the slave storage node; the main storage node is made to execute the rollback operation, which can be understood as deleting the metadata pre-written by the main storage node and deleting the lock information of the main storage node.

And, after the rollback operation is performed, the lock information of the storage node corresponding to the rollback operation may be deleted so that the metadata may be accessed or modified by other transactions. For example, after the rollback operation is executed from the storage node, the lock information of the slave storage node is deleted; and after the main storage node executes the rollback operation, deleting the lock information of the main storage node.

Wherein, executing the current transaction execution request comprises:

determining a master storage node and a slave storage node from the at least two storage nodes executing the current transaction;

executing the current transaction execution request by using the master storage node and the slave storage node, allocating master lock information to the master storage node, and allocating slave lock information to the slave storage node, wherein the master lock information comprises the starting time of the master storage node executing the current transaction execution request, and the slave lock information comprises the starting time of the slave storage node executing the current transaction execution request and the node information of the master storage node;

deleting the master lock information if it is determined that the master storage node submits a transaction completion notification for the current transaction execution request, and deleting the slave lock information if it is determined that the slave storage node submits a transaction completion notification for the current transaction execution request.

It can be understood that the steps for executing the current transaction execution request are the same as those for executing the previous transaction execution request, and are not repeated herein. The storage node executing the current transaction and the storage node executing the last transaction are both storage nodes in the distributed database.

In conclusion, under the condition that the main storage node of the previous transaction is successfully executed, the slave storage node continues to execute the previous transaction and submits the previous transaction, so that the automatic recovery of the transaction under the condition that the coordination node of the distributed transaction has an accident is realized. And under the condition that the execution of the previous transaction fails, the rollback operation is carried out on the previous transaction and the lock information is deleted, so that the current transaction can be normally executed, the efficiency of executing the transaction is ensured, and the service capability of the distributed database is improved.

In practical applications, after determining the target storage node from the at least two storage nodes executing the current transaction, the method further includes:

and under the condition that the target storage node is determined to be the main storage node corresponding to the last transaction execution request and contains the lock information which is overtime, executing the rollback operation of the last transaction execution instruction and executing the current transaction execution request.

Specifically, when the target storage node is determined to be the main storage node executing the previous transaction and includes the lock information that has timed out, it indicates that the transaction is not committed at the main storage node and the transaction execution fails, and at this time, a rollback operation may be performed so that the current transaction can be executed normally.

In specific implementation, the rollback operation of the previous transaction execution instruction is executed, and the rollback operation includes:

under the condition that the slave storage node corresponding to the master storage node is determined to contain the lock information, executing the rollback operation of the last transaction execution instruction by using the slave storage node, and executing the rollback operation of the last transaction execution instruction by using the master storage node; or

And under the condition that the slave storage node corresponding to the master storage node does not contain the lock information, executing the rollback operation of the last transaction execution instruction by using the master storage node.

In summary, by determining whether the slave storage node includes the lock information, the start position of the rollback operation is determined, that is, it is determined whether the rollback operation is performed only on the master storage node or on the slave storage node and the master storage node, the metadata state recovery of the previous transaction is realized, and the incomplete transaction recovery is avoided.

In addition, after determining the target storage node from the at least two storage nodes executing the current transaction, the method further includes:

executing the current transaction execution request if it is determined that the target storage node does not contain lock information; or alternatively

In the event that it is determined that the target storage node contains lock information that has not timed out, not executing the current transaction execution request.

Specifically, when it is determined that the target storage node does not contain the lock information, it indicates that the target storage node is not in a state of executing the transaction, and thus the current transaction may be directly executed. And under the condition that the target storage node is determined to contain the lock information which is not overtime, the target storage node is in the state of executing the previous transaction, and at the moment, in order to avoid transaction conflict, the current transaction is not executed. After a preset time, it may be determined whether the target storage node contains the lock information and whether the lock information is time out, so as to determine whether the current transaction may be executed.

In summary, in the above method, storage nodes that process a transaction are determined as a master storage node and a slave storage node, and lock information is allocated to the master storage node and the slave storage node, respectively, when a current transaction execution request is received, if it is determined that a target storage node that executes the transaction execution request is a slave storage node that executes a previous transaction execution request, and the slave storage node includes lock information that has timed out, it indicates that a time for the slave storage node to execute the transaction has timed out but is not committed, at this time, it may be determined that the master storage node corresponding to the slave storage node, in a case that the master storage node does not include the lock information, it indicates that the master storage node has executed the previous transaction execution request, and it indicates that the master storage node is in a normal transaction commit state, at this time, the slave storage node may continue to execute the previous transaction execution request, thereby completing the execution of the previous transaction, without paying attention to whether a coordination node has an accident, and thus enabling to implement the pushing of the current transaction to avoid affecting the overall service capability.

The following description further describes the distributed transaction processing method by taking an application of the distributed transaction processing method provided in this specification to filename renaming as an example, with reference to fig. 4. Fig. 4 shows a processing procedure flowchart of a distributed transaction processing method provided in an embodiment of the present specification, which specifically includes the following steps.

Step 402: receiving a current transaction execution request, determining at least two storage nodes corresponding to the current transaction execution request, and determining a target storage node from the at least two storage nodes.

Specifically, the current transaction execution request may be a created file name xyz, and a storage node corresponding to the transaction execution request and storing the metadata xyz is determined, where the storage node is a target storage node.

It should be noted that, when the current transaction execution request corresponds to two storage nodes, the lock information of each storage node needs to be determined according to the following steps, so as to determine the transaction execution state of each storage node.

Step 404: judging whether the target storage node has the lock information, if so, executing step 408; if not, go to step 406.

Step 406: and executing the current transaction in the current transaction execution request.

Under the condition that the target storage node does not have the lock information, the target storage node is not in a state of executing the transaction, so that no transaction conflict exists, and the transaction for creating the file name xyz in the current transaction execution request can be directly executed.

Step 408: judging whether the lock information is overtime according to the timestamp in the lock information, if so, executing step 412; if not, go to step 410.

When the target storage node has the lock information, it is indicated that the target storage node is in a state of executing the previous transaction, and whether the lock information is overtime can be determined according to a timestamp in the lock information and a preset transaction execution duration. Wherein the timestamp may be understood as the starting time of the last transaction executed by the target storage node.

For example, in the case that the previous transaction renames the filename abc to the filename xyz, a storage node storing the filename xyz corresponding to the previous transaction is the same as a storage node storing the filename xyz corresponding to the current transaction, and therefore a conflict exists between the previous transaction and the current transaction.

Step 410: and when the transaction conflict occurs, the current transaction in the current transaction execution request is not executed.

If the lock information is not overtime, it indicates that the target storage node is executing the previous transaction renaming the file name abc to the file name xyz, and a transaction conflict occurs at this time, so that the current transaction creating the file name xyz is not executed, and after a period of time, the lock information of the target storage node is determined, so as to determine whether the target storage node has completed execution of the previous transaction.

Step 412: judging whether the target storage node is the main storage node corresponding to the last transaction execution request, if so, executing step 414; if not, go to step 422.

In the case that the lock information of the target storage node is judged to be overtime, whether the target storage node is a main storage node corresponding to the last transaction or not can be determined.

Step 414: and determining a slave storage node corresponding to the master storage node.

And if so, determining a slave storage node corresponding to the master storage node.

Step 416: judging whether the slave storage node has the lock information, if so, executing step 418; if not, go to step 420.

After determining the slave storage node, it may be determined whether lock information exists for the slave storage node. In the case where it is determined that the lock information exists from the storage node, it is described that the previous transaction was subjected to the pre-write of the metadata from the storage node, but was not committed. In the case where it is determined that the lock information does not exist from the storage node, it is described that the previous transaction is pre-written and committed with metadata from the storage node,

step 418: according to the preset rollback situation 2, the rollback operation is executed on the slave storage node firstly, and then the rollback operation is executed on the master storage node.

The preset rollback condition 2 is that the coordination node has an accident before the main storage node of the previous transaction submits the pre-written metadata, and the previous transaction does not submit at this time and is considered to be in the abort state. When the current transaction accesses, the last transaction is determined to be overtime through the lock information of the main storage node of the last transaction and the timestamp contained in the lock information. At this time, the current transaction can delete the lock information of the storage node and delete the pre-written metadata to realize the rollback of the previous transaction, and at this time, because the slave storage node has the lock information, the lock information of the slave storage node and the pre-written metadata of the slave storage node are deleted, and then the lock information of the master storage node and the pre-written metadata of the master storage node are deleted.

At this time, the rollback of the previous transaction may be executed on the slave storage node, and then the rollback of the previous transaction may be executed on the master storage node, that is, the execution of the previous transaction is cancelled, so that the metadata stored in the storage node is restored to the state before the execution of the previous transaction.

Step 420: according to the preset rollback condition 1, performing rollback operation on the main storage node, and executing the current transaction execution request.

In the preset rollback case 1, before the main storage node of the previous transaction commits the pre-written metadata, the coordination node has an accident, and at this time, the previous transaction is not committed, which is considered to be in the abort state. When the current transaction accesses, the last transaction is determined to be overtime through the lock information of the main storage node of the last transaction and the timestamp contained in the lock information. At this time, the current transaction can delete the lock information of the storage node and delete the pre-written metadata to realize the rollback of the previous transaction, and at this time, because the slave storage node does not have the lock information, only the lock information of the master storage node is deleted and the pre-written metadata of the master storage node is deleted.

A rollback of the last transaction may be performed for the master storage node at this point, restoring the metadata to the state prior to the execution of the last transaction.

Step 422: and determining a master storage node corresponding to the slave storage node.

In the case that the target storage node is not the master storage node corresponding to the previous transaction execution request, it indicates that the target storage node is the slave storage node corresponding to the previous transaction execution request, and at this time, the master storage node corresponding to the slave storage node may be determined according to the node information of the master storage node included in the lock information in the slave storage node.

Step 424: judging whether the main storage node has the lock information, if so, executing step 418; if not, go to step 426.

Step 426: according to the preset submission condition 3, the request is executed and submitted for the last transaction which is continuously executed from the storage node.

In the preset commit situation 3, after the main storage node of the previous transaction commits the pre-written metadata, the coordinating node encounters an accident, and at this time, the previous transaction is already committed and is considered to be in a committed state. When the current transaction is accessed, the last transaction is determined to be successfully executed through the lock information in the main storage node of the last transaction. At this time, the current transaction can delete the lock information of the slave storage node and submit the metadata pre-written from the storage node, and the execution of the last transaction is completed.

Under the condition that the main storage node is determined not to have the lock information, the main storage node is indicated that the previous transaction is subjected to the pre-writing and the submitting of the metadata, and the execution of the transaction is successful, at this time, the previous transaction can be continuously executed and submitted aiming at the slave storage node, and the recovery of the previous transaction is realized.

Corresponding to the foregoing method embodiment, this specification further provides an embodiment of a distributed transaction processing apparatus, and fig. 5 shows a schematic structural diagram of a distributed transaction processing apparatus provided in an embodiment of this specification. As shown in fig. 5, the apparatus includes:

a first determining module 502, configured to determine, according to metadata information carried in a current transaction execution request, at least two storage nodes that store metadata and execute a current transaction;

a second determining module 504, configured to determine a target storage node from the at least two storage nodes executing the current transaction, and in a case that the target storage node is determined to be a slave storage node executing the previous transaction execution request and contains the lock information that has timed out, determine a master storage node corresponding to the slave storage node;

an execution module 506 configured to execute the last transaction execution request with the slave storage node if it is determined that the master storage node does not contain lock information.

In an optional embodiment, the executing module 506 is further configured to:

In an optional embodiment, the second determining module 504 is further configured to:

In an optional embodiment, the executing module 506 is further configured to:

and in the case that the main storage node is determined to contain the lock information, executing the rollback operation of the last transaction execution request and executing the current transaction execution request.

In an optional embodiment, the executing module 506 is further configured to:

under the condition that the slave storage node corresponding to the master storage node is determined to contain the lock information, executing the rollback operation of the last transaction execution instruction by using the slave storage node, and executing the rollback operation of the last transaction execution instruction by using the master storage node; or alternatively

In an optional embodiment, the executing module 506 is further configured to:

In an optional embodiment, the apparatus further comprises a determining module configured to:

and under the condition that the target storage node is determined to contain the lock information, judging whether the lock information is overtime or not according to the starting time and the preset transaction execution duration included in the lock information.

The foregoing is a schematic scheme of a distributed transaction processing apparatus of this embodiment. It should be noted that the technical solution of the distributed transaction processing apparatus and the technical solution of the distributed transaction processing method belong to the same concept, and for details that are not described in detail in the technical solution of the distributed transaction processing apparatus, reference may be made to the description of the technical solution of the distributed transaction processing method.

Embodiments of the present specification also provide an object storage device, including a memory for storing computer-executable instructions and a processor for executing the computer-executable instructions, which when executed by the processor implement the steps of the distributed transaction processing method.

FIG. 6 illustrates a block diagram of a computing device 600 provided in accordance with one embodiment of the present specification. The components of the computing device 600 include, but are not limited to, a memory 610 and a processor 620. The processor 620 is coupled to the memory 610 via a bus 630 and a database 650 is used to store data.

Computing device 600 also includes access device 640, access device 640 enabling computing device 600 to communicate via one or more networks 660. Examples of such networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the internet. The Access device 640 may include one or more of any type of Network interface (e.g., a Network interface controller) that may be wired or Wireless, such as an IEEE802.11 Wireless Local Area Network (WLAN) Wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an ethernet interface, a Universal Serial Bus (USB) interface, a cellular Network interface, a bluetooth interface, a Near Field Communication (NFC) interface, and so forth.

In one embodiment of the present application, the above-described components of computing device 600, as well as other components not shown in FIG. 6, may also be connected to each other, such as by a bus. It should be understood that the block diagram of the computing device structure shown in FIG. 6 is for illustration purposes only and is not intended to limit the scope of the present application. Those skilled in the art may add or replace other components as desired.

Computing device 600 may be any type of stationary or mobile computing device, including a mobile Computer or mobile computing device (e.g., tablet, personal digital assistant, laptop, notebook, netbook, etc.), a mobile phone (e.g., smartphone), a wearable computing device (e.g., smartwatch, smartglasses, etc.), or other type of mobile device, or a stationary computing device such as a desktop Computer or Personal Computer (PC). Computing device 600 may also be a mobile or stationary server.

Wherein the processor 620 is configured to execute computer-executable instructions that, when executed by the processor, implement the steps of the distributed transaction processing method described above.

The above is an illustrative scheme of a computing device of the present embodiment. It should be noted that the technical solution of the computing device belongs to the same concept as the technical solution of the distributed transaction processing method described above, and for details that are not described in detail in the technical solution of the computing device, reference may be made to the description of the technical solution of the distributed transaction processing method described above.

An embodiment of the present specification also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the distributed transaction processing method described above.

The above is an illustrative scheme of a computer-readable storage medium of the present embodiment. It should be noted that the technical solution of the storage medium belongs to the same concept as the technical solution of the distributed transaction processing method described above, and details that are not described in detail in the technical solution of the storage medium can be referred to the description of the technical solution of the distributed transaction processing method described above.

An embodiment of the present specification further provides a computer program, wherein when the computer program is executed in a computer, the computer program is used to make the computer execute the steps of the distributed transaction processing method.

The above is an illustrative scheme of a computer program of the present embodiment. It should be noted that the technical solution of the computer program and the technical solution of the distributed transaction processing method belong to the same concept, and details that are not described in detail in the technical solution of the computer program can be referred to the description of the technical solution of the distributed transaction processing method.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The computer instructions comprise computer program code which may be in the form of source code, object code, an executable file or some intermediate form, or the like. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, usb disk, removable hard disk, magnetic disk, optical disk, computer Memory, read-Only Memory (ROM), random Access Memory (RAM), electrical carrier wave signals, telecommunications signals, software distribution medium, and the like. It should be noted that the computer readable medium may contain content that is subject to appropriate increase or decrease as required by legislation and patent practice in jurisdictions, for example, in some jurisdictions, computer readable media does not include electrical carrier signals and telecommunications signals as is required by legislation and patent practice.

It should be noted that, for the sake of simplicity, the foregoing method embodiments are described as a series of acts, but those skilled in the art should understand that the present embodiment is not limited by the described acts, because some steps may be performed in other sequences or simultaneously according to the present embodiment. Further, those skilled in the art should also appreciate that the embodiments described in this specification are preferred embodiments and that acts and modules referred to are not necessarily required for an embodiment of the specification.

In the foregoing embodiments, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to the related descriptions of other embodiments.

The preferred embodiments of the present specification disclosed above are intended only to aid in the description of the specification. Alternative embodiments are not exhaustive and do not limit the invention to the precise embodiments described. Obviously, many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the embodiments and the practical application, and to thereby enable others skilled in the art to best understand the specification and utilize the specification. The specification is limited only by the claims and their full scope and equivalents.

Claims

1. A distributed transaction processing method, comprising:

determining a target storage node from the at least two storage nodes executing the current transaction, and determining a master storage node corresponding to the slave storage node under the condition that the target storage node is determined to be a slave storage node executing the last transaction execution request and contains overtime lock information;

2. The method according to claim 1, wherein before determining at least two storage nodes storing metadata for executing the current transaction according to metadata information carried in the current transaction execution request, the method further comprises:

3. The method of claim 2, wherein determining a master storage node and a slave storage node for executing a previous transaction execution request according to the previous transaction execution request corresponding to a current transaction execution request comprises:

determining at least two storage nodes for storing metadata to execute the previous transaction according to metadata information carried in the previous transaction execution request corresponding to the current transaction execution request;

4. The method of claim 2, the determining a master storage node to which the slave storage node corresponds, comprising:

5. The method of claim 2, after determining the master storage node corresponding to the slave storage node, further comprising:

6. The method of claim 5, the performing the rollback operation of the last transaction execution request comprising:

7. The method of claim 5, the executing the current transaction execution request comprising:

8. The method of claim 2, after determining a target storage node from the at least two storage nodes executing the current transaction, further comprising:

9. The method of claim 8, the performing a rollback operation of the last transaction execution instruction, comprising:

under the condition that the slave storage node corresponding to the master storage node is determined to contain lock information, executing the rollback operation of the last transaction execution instruction by using the slave storage node, and executing the rollback operation of the last transaction execution instruction by using the master storage node; or alternatively

10. The method of claim 2, after determining a target storage node from the at least two storage nodes executing the current transaction, further comprising:

executing the current transaction execution request if it is determined that the target storage node does not contain lock information; or

11. The method of claim 2, after determining a target storage node from the at least two storage nodes executing the current transaction, further comprising:

12. A computing device, comprising:

a memory and a processor;

the memory is for storing computer-executable instructions, and the processor is for executing the computer-executable instructions, which when executed by the processor, implement the steps of the method of any one of claims 1 to 11.

13. A computer-readable storage medium storing computer-executable instructions which, when executed by a processor, implement the steps of the method of any one of claims 1 to 11.