Transaction processing method, apparatus, node, and computer readable storage medium

Abstract

The application discloses a transaction processing method and device, a node and a storage medium, and belongs to the technical field of data access. In the embodiment of the application, a first node reads a write object from a second node and reads a read object from a third node, sends a write lock message to the second node and a read lock message to the third node after modifying a data item of the write object. In this way, the second node and the third node can perform object locking and version value verification without any sequence. Compared with performing read object version value verification after write object locking is successful and version value verification is passed, the transaction processing time is shortened. Moreover, even if the third node successfully verifies the version value of the read object before the second node successfully locks the write object, since the read lock of the read object is successfully added when the version value verification of the read object is passed, the read object will not be tampered with by other transactions before the second node successfully locks the write object, thereby ensuring the correctness of the submitted data.

Description

Technical Field

[0001] This application relates to the field of data access technology, and in particular to a transaction processing method, apparatus, node, and computer-readable storage medium. Background Technology

[0002] Application access to stored objects in a database can be achieved through multiple transactions. A transaction includes information about at least one stored object to be accessed and information about at least one access operation to be performed on that stored object. This at least one access operation includes read and / or write operations. The stored object targeted by a read operation is called a read object, and the stored object targeted by a write operation is called a write object. Currently, in distributed scenarios such as data centers, stored objects in the database are distributed across multiple physical nodes. Furthermore, to ensure data reliability, after storing a stored object on its corresponding physical node, it can be backed up to other physical nodes. The physical node corresponding to the stored object is the primary node where the stored object resides, and the other physical nodes used for backup are the backup nodes. Thus, when a transaction accesses multiple stored objects, the primary and backup nodes for these multiple stored objects may be different. In this case, the transaction initiating node can handle transactions based on the optimistic concurrency control (OCC) protocol to achieve transaction concurrency control.

[0003] Currently, in the OCC protocol, the transaction initiating node first reads the storage object, including its version value, from the master node of the storage object to be accessed, based on the transaction to be processed. If multiple storage objects are read, including both read and write objects, the transaction initiating node first modifies the data items of the write objects. After modifying the write object's data items, the transaction initiating node interacts with the master node of the write object to lock the write object and verify its version value. After successfully locking the write object and verifying the version value, the transaction initiating node then interacts with the master node of the read object to verify its version value. After successfully verifying the read object's version value, the transaction initiating node commits the updated data items of the write object to the master and backup nodes of the write object. After successful commit, the transaction initiating node can generate a transaction completion notification to inform the upper-layer application that the transaction processing is complete.

[0004] As can be seen, in the above transaction processing, after modifying the data items of the write object, the transaction initiating node must interact multiple times with the primary node where the write object is located, the primary node where the read object is located, and the backup node of the write object in sequence to complete the commit of the updated data items, thereby notifying the upper-layer application that the transaction processing is complete, which takes a long time. Summary of the Invention

[0005] This application provides a transaction processing method, apparatus, node, and computer-readable storage medium, which can shorten transaction processing latency and improve transaction processing efficiency.

[0006] In a first aspect, this application provides a transaction processing method applied to a first node. The method includes: reading a write object from a second node and a read object from a third node based on information about a write object and a read object included in a first transaction; the write object includes a first data item; the second node is the master node where the write object resides; and the third node is the master node where the read object resides; modifying the first data item to obtain an updated first data item; sending a write lock message to the second node and a read lock message to the third node; the read lock message is used to acquire a read lock on the read object and detect whether the read object read by the first node is correct; and, upon receiving a write lock success response from the second node and a read lock success response from the third node, submitting the updated first data item to the second node and the fourth node; the write lock success response indicates that the write lock on the write object was successfully acquired and the read object is correct, and the read lock success response indicates that the read lock on the read object was successfully acquired and the read object is correct, wherein the fourth node is a backup node for the write object.

[0007] In this embodiment, the first node reads the write object from the second node and the read object from the third node. After modifying the data items of the write object, it can send a write lock message to the second node and a read lock message to the third node. This allows the second and third nodes to lock and verify the object's version value in parallel; that is, the first node can initiate locking and version value verification of the write object and verifying the version value of the read object in parallel. This shortens the transaction processing time compared to verifying the read object's version value only after successfully locking and verifying the write object's version value. Furthermore, in this embodiment, even if the third node returns a read lock response before the second node returns a write lock response—meaning the third node successfully verifies the read object's version value before the second node successfully locks the write object—the read object will not be modified by other transactions before the second node successfully acquires a write lock, ensuring the correctness of the submitted data. Therefore, this embodiment shortens the transaction processing time while ensuring the correctness of the submitted data.

[0008] Optionally, the process of sending a write lock message to the second node and a read lock message to the third node can be as follows: sending the write lock message to the second node and simultaneously sending the read lock message to the third node; or, sending the write lock message to the second node; and after sending the write lock message but before receiving a write lock success response, sending the read lock message to the third node; or, sending the read lock message to the third node; and after sending the read lock message but before receiving a read lock success response, sending the write lock message to the second node.

[0009] In this embodiment, since the read lock message instructs the third node not only to verify the version of the read object but also to lock the read object, even if the third node successfully verifies the version value of the read object before the second node successfully locks the write object, the read object will not be tampered with by other transactions before the write object successfully acquires a write lock. Therefore, the first node does not need to send the read lock message only after receiving the write lock success response from the second node. In other words, the verification of the read object does not depend on the locking and verification of the write object, yet data correctness is still guaranteed. Furthermore, since the read object verification does not need to be performed only after the write object is successfully locked, the two can be executed in parallel or with a very short time difference, thus shortening transaction processing latency and improving transaction processing efficiency.

[0010] Optionally, when submitting the updated first data item to the second node and the fourth node, the first node may also send a read lock release message to the third node, the read lock release message being used to instruct the third node to release the read lock of the read object.

[0011] In this process, the first node can send a read lock release message to the third node while committing the updated first data item. This allows the first node to execute the update step in parallel with the first data item update step, thus shortening the transaction processing latency.

[0012] Alternatively, the first node can send a read lock release message to the third node after the updated first data item has been successfully committed. This way, other transactions cannot modify the read object during the commit process.

[0013] Optionally, upon receiving a write lock failure response from the second node and / or a read lock failure response from the third node, a process abort message is sent to the second node and the third node. The write lock failure response indicates that acquiring a write lock on the write object failed and / or the write object read by the first node is incorrect. The read lock failure response indicates that acquiring a read lock on the read object failed and / or the read object read by the first node is incorrect. The process abort message is used to indicate the abort of the processing of the first transaction, and the process abort message is also used to instruct the second node and the third node to unlock the object that was successfully locked.

[0014] In this embodiment of the application, if any operation of verifying and locking the read object or verifying and locking the write object fails, the first node may suspend the processing of the first transaction and instruct the second and third nodes to release the locks applied to the corresponding objects based on the first transaction.

[0015] Optionally, both the write object and the read object read by the first node include a version value, the write lock message includes the version value of the write object read by the first node, the read lock message includes the version value of the read object read by the first node, and the correctness of the write object or the read object read by the first node means that the version value of the corresponding object read by the first node meets the verification condition.

[0016] Optionally, the verification condition refers to the fact that the version value of the corresponding object read by the first node is an intermediate version value and the version value of the corresponding object in the corresponding master node is a stable version value corresponding to the version value of the corresponding object read by the first node; or, the verification condition refers to the fact that the version value of the corresponding object read by the first node is a stable version value and the version value of the corresponding object in the corresponding master node is the same as the version value of the corresponding object read by the first node. The intermediate version value is used to indicate that the updated data item of the corresponding object has not been successfully submitted, and the stable version value is used to indicate that the updated data item of the corresponding object has been successfully submitted.

[0017] Optionally, the write lock message further includes the updated first data item; when the version value of the object includes both the intermediate version value and the stable version value mentioned above, the process of submitting the updated first data item to the second node and the fourth node may include: sending a main commit message to the second node and a backup commit message to the fourth node, the backup commit message including the updated first data item; upon receiving a main commit success response from the second node and a backup commit success response from the fourth node, determining that the updated first data item has been successfully submitted, the main commit success response being sent by the second node after updating the stored data item and the first version value of the write object based on the main commit message and the updated first data item, the updated write object including a second version value, the second version value being the next intermediate version value of the first version value, and the backup commit success response being sent by the fourth node after receiving the backup commit message.

[0018] In this embodiment, the version value of any object may include a stable version value and an intermediate version value. The intermediate version value indicates that the updated data item of the corresponding object has not been successfully committed, while the stable version value indicates that the updated data item of the corresponding object has been successfully committed. Based on this, the state of the write object can be identified by switching between these two version values. Therefore, even if the first node sends a main commit message before receiving the backup commit success response, the second node can still indicate that the write object is under modification by switching its version value to an intermediate version value. This allows other transactions that need to modify the write object to perform version verification based on the intermediate version value, thereby ensuring data correctness. Thus, by switching between the two version values, write conflicts to the corresponding object by transactions are avoided, ensuring the correctness of the data read by the transaction. Furthermore, the sending of the main commit message does not depend on the receipt of the backup commit success response. This allows the sending of the main commit message and the sending of the backup commit message to be executed at very short intervals or even in parallel, shortening the time required from the start of processing the first transaction to notifying the upper-layer application of the transaction completion.

[0019] Optionally, the process of sending the main commit message to the second node and the backup commit message to the fourth node can be as follows: sending the main commit message to the second node and simultaneously sending the backup commit message to the fourth node; or, sending the backup commit message to the fourth node, and then sending the main commit message to the second node after sending the backup commit message and before receiving a successful backup commit response; or, sending the main commit message to the second node, and then sending the backup commit message to the fourth node after sending the main commit message and before receiving a successful main commit response.

[0020] Optionally, if no primary commit success response is received from the second node and / or a backup commit success response is received from the fourth node, the first node may send a process abort message to the second node, the third node, and the fourth node. The process abort message is used to indicate the abort of the processing of the first transaction, and the process abort message is also used to instruct the second node and the third node to unlock the successfully locked object.

[0021] Optionally, if any object includes an intermediate version value and a stable version value, after the first data item is successfully committed after the update, the first node may also send a write lock release message to the second node. The write lock release message is used to instruct the second node to update the second version value to a third version value and release the write lock of the updated write object. The third version value is the stable version value corresponding to the second version value.

[0022] In this embodiment of the application, after the first data item is successfully submitted after being updated, the first node can instruct the second node to update the version value of the write object to the stable state version value to indicate that the write object has entered a stable state, and at the same time unlock the write object so that other subsequent transactions can access the write object.

[0023] Optionally, after the updated first data item is successfully committed, the first node may send a first deletion message to the second node, which instructs the second node to delete the write lock message and the main commit message; and send a second deletion message to the fourth node, which instructs the fourth node to update the stored data item and first version value of the write object based on the backup commit message and delete the backup commit message.

[0024] Optionally, after the first updated data item is successfully committed, the first node can also notify the upper-layer application that the transaction processing is complete.

[0025] Secondly, a transaction processing method is provided, applied in a first node. This method includes: reading the write object from a second node and the read object from a third node based on information about the write object and read object included in the first transaction. Both the write object and the read object include version values, and the write object includes a first data item. The second node is the master node where the write object resides, and the third node is the master node where the read object resides. The first data item is modified to obtain an updated first data item. If a write lock is successfully acquired on the write object in the second node and both the write object and the read object read by the first node are correct, a main commit message is sent to the second node to commit the updated first data item, and a backup commit message is sent to a fourth node to commit the updated first data item. The correctness of the write object or read object read by the first node means that the version value of the corresponding object read by the first node is an intermediate version value, and the version value of the corresponding object in the corresponding master node is the first version value. The stable version value corresponding to the version value of the corresponding object read by the first node, or the stable version value of the corresponding object read by the first node and the version value of the corresponding object in the corresponding master node is the same as the version value of the corresponding object read by the first node. The intermediate version value is used to indicate that the updated data item of the corresponding object has not been successfully committed, and the stable version value is used to indicate that the updated data item of the corresponding object has been successfully committed. The fourth node is the backup node of the write object. Upon receiving the master commit success response from the second node and the backup commit success response from the fourth node, a transaction completion notification is generated. The master commit success response is sent by the second node after updating the stored data item and the first version value of the write object based on the master commit message and the updated first data item. The updated write object includes a second version value, which is the next intermediate version value of the first version value. The backup commit success response is sent by the fourth node after receiving the backup commit message.

[0026] In this embodiment, the version value of any object may include a stable version value and an intermediate version value. The intermediate version value indicates that the updated data item of the corresponding object has not been successfully committed, while the stable version value indicates that the updated data item of the corresponding object has been successfully committed. Based on this, the state of the write object can be identified by switching between these two version values. Therefore, even if the first node sends a main commit message before receiving the backup commit success response, the second node can still indicate that the write object is under modification by switching its version value to an intermediate version value. This allows other transactions that need to modify the write object to perform version verification based on the intermediate version value, thereby ensuring data correctness. Thus, by switching between the two version values, write conflicts to storage objects are avoided, ensuring the correctness of the data read by the transaction. Furthermore, the sending of the main commit message does not depend on the receipt of the backup commit success response. This allows the sending of the main commit message and the sending of the backup commit message to be executed at very short intervals or even in parallel, shortening the time required from the start of processing the first transaction to notifying the upper-layer application of the transaction completion.

[0027] Optionally, the process of sending a main commit message to the second node to commit the updated first data item and a backup commit message to the fourth node to commit the updated first data item can be as follows: sending the main commit message to the second node and simultaneously sending the backup commit message to the fourth node; or, sending the backup commit message to the fourth node, and then sending the main commit message to the second node after sending the backup commit message and before receiving a successful backup commit response; or, sending the main commit message to the second node, and then sending the backup commit message to the fourth node after sending the main commit message and before receiving a successful main commit response.

[0028] Optionally, after generating the transaction completion notification, the first node may also send a write lock release message to the second node. The write lock release message is used to instruct the second node to update the second version value to the third version value and release the write lock of the updated write object. The third version value is the stable version value corresponding to the second version value.

[0029] Optionally, after modifying the data item of the write object to obtain the updated first data item, the first node may send a write lock message to the second node. The write lock message instructs the second node to acquire a write lock on the write object and verify whether the write object is correct. Upon receiving a write lock success response from the second node, the first node sends a verification message to the third node. The verification message instructs the third node to verify whether the read object read by the first node is correct. Upon receiving a verification success response from the third node, it is determined that the write lock on the write object in the second node was successfully acquired and that the write object and read object read by the first node are correct.

[0030] Optionally, after modifying the data item of the write object to obtain the updated first data item, the first node can send a write lock message to the second node and a read lock message to the third node. The write lock message instructs the second node to acquire a write lock on the write object and check whether the write object read by the first node is correct. The read lock message instructs the third node to acquire a read lock on the read object and check whether the read object read by the first node is correct. Upon receiving a write lock success response from the second node and a read lock success response from the third node, it is determined that the write lock on the write object in the second node was successfully acquired and that both the write object and the read object read by the first node are correct.

[0031] Optionally, if the first node sends a read lock message to the third node, then during the process of sending a main commit message to the second node and a backup commit message to the fourth node, or when receiving a main commit success response and a backup commit success response, the first node may also send a read lock release message to the third node to instruct the third node to release the read lock that was added to the read object based on the first transaction.

[0032] Thirdly, a transaction processing apparatus is provided, deployed on a first node, the transaction processing apparatus including at least one module for implementing the transaction processing method described in the first aspect. Exemplarily, the at least one module includes a read module, a modify module, a send module, and a commit module.

[0033] The system includes a read module for reading a write object from a second node and a read object from a third node based on information about the write object and read object included in the first transaction. The write object includes a first data item. The second node is the master node where the write object is located, and the third node is the master node where the read object is located. A modify module is used to modify the first data item to obtain an updated first data item. A send module is used to send a write lock message to the second node and a read lock message to the third node. The read lock message is used to acquire a read lock on the read object and check whether the read object read by the first node is correct. A commit module is used to commit the updated first data item to the second node and the fourth node when a write lock success response is received from the second node and a read lock success response from the third node. The write lock success response indicates that the write lock on the write object was successfully acquired and the read object is correct. The read lock success response indicates that the read lock on the read object was successfully acquired and the read object is correct. The fourth node is a backup node for the write object.

[0034] Optionally, the sending module is mainly used to: send the write lock message to the second node and simultaneously send the read lock message to the third node; or, send the write lock message to the second node; after sending the write lock message but before receiving the write lock success response, send the read lock message to the third node; or, send the read lock message to the third node; after sending the read lock message but before receiving the read lock success response, send the write lock message to the second node.

[0035] Optionally, the sending module is further configured to: when the submission module submits the updated first data item to the second node and the fourth node, send a read lock release message to the third node, the read lock release message being used to instruct the third node to release the read lock of the read object.

[0036] Optionally, the sending module is further configured to: upon receiving a write lock failure response from the second node and / or a read lock failure response from the third node, send a process abort message to the second node and the third node, wherein the write lock failure response indicates that the write lock on the write object failed and / or the write object read by the first node is incorrect, the read lock failure response indicates that the read lock on the read object failed and / or the read object read by the first node is incorrect, the process abort message is used to indicate the abort of the processing of the first transaction, and the process abort message is also used to instruct the second node and the third node to unlock the object that was successfully locked.

[0037] Optionally, both the write object and the read object read by the first node include a version value, the write lock message includes the version value of the write object read by the first node, the read lock message includes the version value of the read object read by the first node, and the correctness of the write object or the read object read by the first node means that the version value of the corresponding object read by the first node meets the verification condition.

[0038] Optionally, the verification condition refers to the fact that the version value of the corresponding object read by the first node is an intermediate version value and the version value of the corresponding object in the corresponding master node is a stable version value corresponding to the version value of the corresponding object read by the first node; or, the verification condition refers to the fact that the version value of the corresponding object read by the first node is a stable version value and the version value of the corresponding object in the corresponding master node is the same as the version value of the corresponding object read by the first node. The intermediate version value is used to indicate that the updated data item of the corresponding object has not been successfully submitted, and the stable version value is used to indicate that the updated data item of the corresponding object has been successfully submitted.

[0039] Optionally, the write lock message further includes the updated first data item; the commit module is mainly used to: send a main commit message to the second node and a backup commit message to the fourth node, the backup commit message including the updated first data item; upon receiving a main commit success response from the second node and a backup commit success response from the fourth node, determine that the updated first data item has been successfully committed, the main commit success response being sent by the second node after updating the stored data item and first version value of the write object based on the main commit message and the updated first data item, the updated write object including a second version value, the second version value being the next intermediate version value of the first version value, and the backup commit success response being sent by the fourth node after receiving the backup commit message.

[0040] Optionally, the submission module is mainly used to: send the main submission message to the second node and simultaneously send the backup submission message to the fourth node; or, send the backup submission message to the fourth node, and after sending the backup submission message but before receiving a successful backup submission response, send the main submission message to the second node; or, send the main submission message to the second node, and after sending the main submission message but before receiving a successful main submission response, send the backup submission message to the fourth node.

[0041] Optionally, the sending module is further configured to: send a process abort message to the second node, the third node, and the fourth node if no primary commit success response is received from the second node and / or a backup commit success response is received from the fourth node, wherein the process abort message is used to indicate the abort of the processing of the first transaction, and the process abort message is also used to instruct the second node and the third node to unlock the object that was successfully locked.

[0042] Optionally, the sending module is further configured to: send a write lock release message to the second node, the write lock release message being used to instruct the second node to update the second version value to the third version value and release the write lock of the updated write object, the third version value being the stable version value corresponding to the second version value.

[0043] Optionally, the sending module is further configured to: send a first deletion message to the second node, the first deletion message being used to instruct the second node to delete the write lock message and the main commit message; and send a second deletion message to the fourth node, the second deletion message being used to instruct the fourth node to update the data items and the first version value of the stored write object based on the backup commit message and delete the backup commit message.

[0044] Fourthly, a transaction processing apparatus is provided, deployed on a first node, the apparatus comprising at least one module for implementing the transaction processing method described in the second aspect. Exemplarily, the at least one module includes a read module, a modify module, a commit module, and a generate module.

[0045] The system includes a reading module, used to read the write object from a second node and the read object from a third node based on the information of the write object and read object included in the first transaction. Both the write object and the read object include version values, and the write object includes a first data item. The second node is the master node where the write object resides, and the third node is the master node where the read object resides. A modification module is used to modify the first data item to obtain an updated first data item. A commit module is used to send a main commit message to the second node to commit the updated first data item and a backup commit message to the fourth node to commit the updated first data item, provided that a write lock is successfully acquired on the write object in the second node and both the write object and the read object read by the first node are correct. The correctness of the write object or read object read by the first node means that the version value of the corresponding object read by the first node is an intermediate version value, and the version value of the corresponding object in the corresponding master node is the version value read by the first node. The stable version value corresponding to the version value of the object, or, the version value of the corresponding object read by the first node is the stable version value and the version value of the corresponding object in the corresponding master node is the same as the version value of the corresponding object read by the first node. The intermediate version value is used to indicate that the updated data item of the corresponding object has not been successfully committed, and the stable version value is used to indicate that the updated data item of the corresponding object has been successfully committed. The fourth node is the backup node of the write object. The generation module is used to generate a transaction completion notification when receiving the master commit success response from the second node and the backup commit success response from the fourth node. The master commit success response is sent by the second node after updating the stored data item and the first version value of the write object based on the master commit message and the updated first data item. The updated write object includes a second version value, which is the next intermediate version value of the first version value. The backup commit success response is sent by the fourth node after receiving the backup commit message.

[0046] Optionally, the submission module is mainly used to: send the main submission message to the second node and simultaneously send the backup submission message to the fourth node; or, send the backup submission message to the fourth node, and after sending the backup submission message but before receiving a successful backup submission response, send the main submission message to the second node; or, send the main submission message to the second node, and after sending the main submission message but before receiving a successful main submission response, send the backup submission message to the fourth node.

[0047] Optionally, the device further includes: a sending module, configured to send a write lock release message to the second node, the write lock release message being configured to instruct the second node to update the second version value to a third version value and release the write lock of the updated write object, the third version value being the stable version value corresponding to the second version value.

[0048] Optionally, the sending module is further configured to, after modifying the data item of the write object and obtaining the updated first data item, send a write lock message to the second node. The write lock message instructs the second node to acquire a write lock on the write object and verify whether the write object read by the first node is correct. Upon receiving a write lock success response from the second node, a verification message is sent to the third node. The verification message instructs the third node to verify whether the read object read by the first node is correct. Upon receiving a verification success response from the third node, it is determined that the write lock on the write object in the second node was successfully acquired and that both the write object and the read object read by the first node are correct.

[0049] Optionally, the sending module is further configured to send a write lock message to the second node and a read lock message to the third node, wherein the write lock message instructs the second node to acquire a write lock on the write object and detect whether the write object read by the first node is correct, and the read lock message instructs the third node to acquire a read lock on the read object and detect whether the read object read by the first node is correct; upon receiving a write lock success response from the second node and a read lock success response from the third node, it is determined that the write lock on the write object in the second node was successfully acquired and that both the write object and the read object read by the first node are correct.

[0050] Optionally, if the first node sends a read lock message to the third node, then during the process of sending a main commit message to the second node and a backup commit message to the fourth node, or when receiving a main commit success response and a backup commit success response, the sending module is also used to send a read lock release message to the third node to instruct the third node to release the read lock added to the read object based on the first transaction.

[0051] Fifthly, a node is provided, the node including a processor and a memory, the memory being used to store at least one program instruction or code supporting the node in executing the transaction processing method provided in the first or second aspect, and to store data involved in implementing the transaction processing method provided in the first or second aspect. The processor is used to execute the program instruction or code stored in the memory.

[0052] In a sixth aspect, a computer-readable storage medium is provided, wherein instructions are stored therein, which, when executed on a computer, cause the computer to perform the transaction processing method described in the first or second aspect above.

[0053] In a seventh aspect, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to perform the transaction processing method described in the first or second aspect above.

[0054] The technical solutions provided in this application have at least the following beneficial effects:

[0055] In this embodiment, the first node reads the write object from the second node and the read object from the third node. After modifying the data items of the write object, a write lock message can be sent to the second node where the write object resides, and a read lock message can be sent to the third node where the read object resides. In this way, the second and third nodes can lock and verify the version value of the object in any order; that is, the first node can initiate locking and version value verification of the write object and version value verification of the read object in parallel. This shortens the transaction processing time compared to performing version value verification of the read object only after the write object has been successfully locked and its version value verified. Furthermore, in this embodiment, even if the third node returns a read lock response first, and the second node returns a write lock response later—that is, even if the third node successfully verifies the version value of the read object before the second node successfully locks the write object—because the third node successfully acquires a read lock on the read object at the same time as verifying its version value, the read object will not be tampered with by other transactions before the second node successfully acquires a write lock on the write object, ensuring the correctness of the committed data. Therefore, the embodiments of this application can shorten the transaction processing time while ensuring the correctness of the submitted data. Attached Figure Description

[0056] Figure 1 This is a system architecture diagram involving the transaction processing method provided in the embodiments of this application;

[0057] Figure 2 This is another system architecture diagram involved in the transaction processing method provided in the embodiments of this application;

[0058] Figure 3 This is a schematic diagram of the interaction timing between various nodes in a transaction processing flow, provided by related technologies;

[0059] Figure 4 This is a flowchart of a transaction processing method provided in an embodiment of this application;

[0060] Figure 5 This is a schematic diagram of a data structure for a storage object provided in an embodiment of this application;

[0061] Figure 6 This is a flowchart of another transaction processing method provided in the embodiments of this application;

[0062] Figure 7 This is a flowchart of the first type of node interaction for transaction processing provided in the embodiments of this application;

[0063] Figure 8 This is a schematic diagram of the interaction timing between various nodes in the first transaction processing flow provided in the embodiments of this application;

[0064] Figure 9 This is a flowchart illustrating the second type of node interaction for transaction processing provided in this application embodiment;

[0065] Figure 10 This is a schematic diagram of the interaction timing between various nodes in the second transaction processing flow provided in the embodiments of this application;

[0066] Figure 11 This is a flowchart of the third type of node interaction for transaction processing provided in the embodiments of this application;

[0067] Figure 12 This is a schematic diagram of the interaction timing between various nodes in the third transaction processing flow provided in the embodiments of this application;

[0068] Figure 13 This is a schematic diagram of the structure of a transaction processing device provided in an embodiment of this application;

[0069] Figure 14 This is a schematic diagram of another transaction processing device provided in the embodiments of this application. Detailed Implementation

[0070] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0071] Before providing a detailed explanation of the embodiments of this application, the system architecture involved in the embodiments of this application will be introduced first.

[0072] The transaction processing method provided in this application can be used to process distributed transactions in distributed scenarios such as data centers. A distributed transaction refers to a transaction where the storage objects to be accessed are distributed across different nodes.

[0073] Based on this Figure 1 This is a system architecture diagram involving a transaction processing method provided in an embodiment of this application. For example... Figure 1As shown, the system includes a compute node cluster and a storage node cluster. The compute node cluster includes one or more compute nodes 10 ( Figure 1 The diagram shows two computing nodes 10 (but is not limited to two computing nodes 10), and the computing nodes 10 can communicate with each other. A computing node 10 is a computing device, such as a server or desktop computer.

[0074] At the hardware level, such as Figure 1 As shown, the computing node 10 includes at least a processor 101, memory 102, and a network interface card 103.

[0075] The processor 101 is a central processing unit (CPU) used to process data access requests from outside the compute node 10 or requests generated internally within the compute node 10. These data access requests include read requests and write requests.

[0076] Memory 102 refers to the internal memory that directly exchanges data with the processor 101. It can read and write data at any time and at high speed, serving as temporary data storage for the operating system or other running programs. Memory 102 includes at least two types of memory, such as random access memory (RAM) or read-only memory (ROM). For example, the RAM may be dynamic random access memory (DRAM) or storage class memory (SCM). However, DRAM and SCM are merely illustrative examples in this embodiment, and memory 102 may also include other RAMs, such as static random access memory (SRAM). For read-only memory, examples include programmable read-only memory (PROM) and erasable programmable read-only memory (EPROM). Additionally, memory 102 can also be a dual in-line memory module (DIMM), i.e., a module composed of dynamic random access memory (DRAM), or a solid state disk (SSD). In practical applications, multiple memory modules 102, and different types of memory modules 102, can be configured in computing node 10. This embodiment does not limit the number or type of memory modules 102. Furthermore, memory modules 102 can be configured to have a power-saving function. The power-saving function means that when the system experiences a power outage and then power is restored, the data stored in memory modules 102 will not be lost. Memory with a power-saving function is called non-volatile memory.

[0077] Network interface card 103 is used to communicate with storage node 11. For example, when the total amount of data in memory 102 reaches a certain threshold, computing node 10 can send a request to storage node 11 via network interface card 103 to persistently store the data. Network interface card 103 can be a remote direct memory access (RDMA) network interface card. In this case, network interface card 103 can bypass processor 101 and directly read and write to the memory of storage node 11.

[0078] Additionally, compute node 10 may include a bus for communication between components within compute node 10. Functionally, because Figure 1The primary function of compute node 10 is computing operations. When storing data, it can utilize remote storage for persistent storage, thus requiring less local storage than a conventional server, resulting in cost and space savings. However, this does not mean that compute node 10 cannot have local storage. In practice, compute node 10 can also have a small amount of internal hard disk or external hard disk.

[0079] At the software level, such as Figure 1 As shown, an application 104 (hereinafter referred to as an application) can run on compute node 10. Application 104 is a collective term for various applications presented to the user. Client 105 is used to receive data access requests triggered by application 104 and interact with storage node 11, sending the data access requests to storage node 11. Client 105 is also used to receive data from storage node 11 and forward the data to application 104. It is understood that when client 105 is a software program, the functionality of client 105 is implemented by the processor 101 included in compute node 10 running the program in memory 102. Client 105 can also be implemented by hardware components located inside compute node 10. Any client 105 in the compute node cluster can access any storage node 11 in the storage node cluster.

[0080] For example, in this embodiment of the application, application 104 can trigger a transaction processing request, and client 105 can be a coordinator client in a distributed transaction processing system. The coordinator client receives the transaction processing request from application 104, initiates the processing of the transaction, interacts with storage node 11 to coordinate the execution of the transaction, determine the steps of the transaction execution, and determine whether the transaction should ultimately be committed or terminated. Accordingly, the computing node on which the coordinator client is deployed can be called the transaction initiating node.

[0081] Any compute node 10 can access any storage node 11 in the storage node cluster via the network. The storage node cluster includes multiple storage nodes 11 ( Figure 1 The diagram shows three storage nodes 11, but is not limited to three storage nodes 11. Some of the storage nodes 11 serve as master nodes for certain stored objects, while others serve as backup nodes for other stored objects. That is, in this embodiment, a master-replica mechanism is used to store objects in the storage node cluster. Each stored object has a corresponding master node and a backup node. The master node of a given stored object is the node that stores the master copy of that stored object, while the backup node is the node that stores the backup copy of that stored object.

[0082] For example, a storage node 11 includes one or more controllers 111, a network interface card (NIC) 112, and multiple hard disks 113. The NIC 112 is used to communicate with the compute node 10. The NIC 112 can be an RDMA NIC. The hard disks 113 are used to store data and can be disks or other types of storage media, such as solid-state drives (SSDs) or shingled magnetic recording hard disks (SMARDs). The controllers 111 are used to write data to or read data from the hard disks 113 according to read / write data requests sent by the compute node 10. During the read / write process, the controllers 111 need to convert the address carried in the read / write data request into an address that the hard disk can recognize. Therefore, the controllers 111 also have some basic computing functions.

[0083] In practical applications, the controller 111 can take various forms. In one case, the controller 111 includes a CPU and memory. The CPU is used to perform operations such as address translation and reading / writing data. The memory is used to temporarily store data to be written to the hard disk 113, or to read data from the hard disk 113 to be sent to the computing node 10. In addition, the memory may also store program instructions executable by the CPU. For example, in this embodiment, the memory stores program instructions for implementing the primary node and / or backup node where the storage node is located in the transaction processing system. Accordingly, the CPU can execute the program instructions so that the corresponding storage node 11 implements the relevant functions of the primary node and / or backup node where the storage object is located in the transaction processing system.

[0084] In the above Figure 1 In the system architecture shown, compute nodes and storage nodes are separated. Furthermore, the coordinator client in the distributed transaction processing system runs on the compute node, while the functionality of the primary or backup node containing the storage object is deployed on the storage node. That is, in the above... Figure 1 In the system shown, the compute node is the transaction initiating node, and the storage object that the transaction needs to access is located in the storage node.

[0085] In another possible implementation, a single node can deploy both a coordinator client and program instructions to implement the processing functions of the primary and / or backup nodes where the stored objects reside. That is, a node can act as both a transaction initiating node and a primary node for some stored objects and a backup node for others. See, for example... Figure 2 The system includes multiple nodes 20 ( Figure 2The diagram illustrates three nodes 20 (but is not limited to three nodes 20), which can communicate with each other. Each node 20 is a device with both computing and storage capabilities, such as a server or desktop computer. For example, an ARM server or an x86 server can serve as a node 20. Furthermore, in this embodiment, when each node 20 provides storage resources to store data, each storage object has not only a primary node but also a backup node; that is, the data persistently stored in this system uses a master-replica mechanism. The primary node of a storage object refers to the node that stores a master copy of that storage object, while the backup node of a storage object refers to the node that stores a backup copy of that storage object.

[0086] At the hardware level, such as Figure 2 As shown, node 20 includes at least a processor 201, memory 202, network interface card 203, and hard disk 204. The processor 201, memory 202, network interface card 203, and hard disk 204 are connected via a bus.

[0087] The processor 201 and memory 202 provide computing resources. Specifically, the processor 201 is a central processing unit (CPU) used to process data access requests from outside node 20 (application server or other nodes 20), as well as requests generated internally within node 20. These data access requests can be write or read requests.

[0088] Memory 202 refers to the internal memory that directly exchanges data with the processor 201. It can read and write data at any time at high speed, serving as temporary data storage for the operating system or other running programs. Memory 201 includes at least two types of memory, such as random access memory (RAM) or ROM. For example, RAM can be DRAM or SCM. However, DRAM and SCM are only illustrative examples in this embodiment, and memory can also include other RAMs, such as SRAM. For read-only memory, for example, it can be PROM, EPROM, etc. In addition, memory 202 can also be a DIMM, i.e., a module composed of DRAM, or an SSD. In practical applications, multiple memory modules 202 and different types of memory modules 202 can be configured in node 20. This embodiment does not limit the number and type of memory modules 202. Furthermore, memory modules 202 can be configured to have a power-saving function. The power-saving function means that when the system loses power and then regains power, the data stored in memory modules 202 will not be lost. Memory with a power-saving function is called non-volatile memory.

[0089] Network interface card 203 is used to communicate with other nodes 20. For example, in this embodiment, network interface card 203 can be an RDMA network interface card, in which case the RDMA network interface card in any node 20 can bypass the processor 201 of that node and directly access the memory in other nodes 20.

[0090] Hard disk 204 is used to provide storage resources, such as storing data. It can be a disk or other types of storage media, such as a solid-state drive or a shingled magnetic recording hard disk.

[0091] At the software level, such as Figure 2 As shown, node 20 has an application 205 (hereinafter referred to as the application) and a client program 206 (hereinafter referred to as the client) deployed on it. The application 205 can directly trigger write or read requests through the client 206 on node 20, which can then be processed by node 20 or sent to other nodes 20 for processing. In this case, the data access request sent by the client 206 to the local node 20 specifically refers to the data access request sent by the client to the processor.

[0092] For example, in this embodiment, client 206 can be a software client of a distributed transaction processing system. Client 206 may include a coordinator processing module, a master node processing module, and a backup node processing module. When application 205 in node 20 triggers a transaction processing request, the coordinator processing module in client 206 can receive the request and interact with the master node and backup node where the storage object to be accessed resides to coordinate the execution of the transaction, determine the steps to be executed, and decide whether the transaction should be committed or terminated. In this case, node 20 functions as a transaction initiating node. When node 20 receives a data access request triggered by another node 20 based on a transaction processing request, node 20 can process the request through the master node processing module and execute subsequent transaction processing steps under the scheduling of other nodes 20. In this case, node 20 functions as the master node where the storage object in a transaction resides. If node 20 receives a backup commit message from another node 20, node 20 can process the message through the backup node processing module and execute subsequent transaction processing steps under the scheduling of other nodes 20. In this case, the function implemented by node 20 is the function of the backup node where the stored object in a transaction resides.

[0093] As described above, in distributed transaction processing, nodes can be categorized into transaction initiation nodes, primary nodes (for the storage objects accessed by the transaction), and backup nodes, based on the different functions implemented by each node. Furthermore, it should be noted that in this embodiment, a node can be a single physical machine.

[0094] Currently, the transaction initiating node, the primary node storing the object, and the backup node typically handle distributed transactions based on the optimistic concurrency control (OCC) protocol.

[0095] In the distributed OCC protocol, transaction processing is divided into two phases: the execution phase and the commit phase. During the execution phase, the transaction initiating node possesses a temporary version of the storage object the transaction intends to access; this temporary version is a copy of the latest successfully committed version of the storage object. Furthermore, when the transaction includes write operations, the transaction initiating node can modify the temporary version of the write object and record the modified version. During the commit phase, the transaction initiating node interacts with the master nodes of each storage object to verify the version value of each storage object, determining whether the transaction's operations on the storage object conflict with operations on the same storage object by other transactions. If the verification is successful, meaning there is no conflict, the transaction initiating node interacts with the master and backup nodes of each storage object to complete the transaction commit. For write objects, this primarily involves persistently storing the modified version on the corresponding master and backup nodes.

[0096] In related technologies, when the first transaction to be processed includes both read and write operations, for example, ... Figure 3 As shown, when the two write operations in the first transaction target storage objects W1 and the one read operation targets storage object R1, during the execution phase, the transaction initiating node C first reads W1 from the master node P1 where W1 resides and reads R1 from the master node P2 where R1 resides. W1 includes a version value V1, and R1 includes a version value V2. Afterwards, the transaction initiating node C modifies the data item D1 in W1 and records the modified D1'.

[0097] During the commit phase, the transaction initiating node C can commit the transaction through the following five steps.

[0098] 1. Lock

[0099] In this step, the transaction initiating node C sends a lock message to the master node P1, which includes (V1, D1'). Master node P1 compares V1 with the version value of W1 stored in its own memory and locks its own stored W1. If V1 matches the version value of W1 stored in its own memory and the lock on W1 is successful, it returns a lock success response to the transaction initiating node C. If V1 differs from the version value of W1 stored in its own memory or the lock on W1 fails, it returns a lock failure response to the transaction initiating node C.

[0100] If the transaction initiating node C receives a successful lock response from the master node P1, it proceeds to step 2. If it receives a failed lock response from the master node P1, the transaction initiating node C aborts the transaction and sends an abandon message to the master node P1, instructing it to unlock the successfully locked objects.

[0101] 2. Verification

[0102] In this step, the transaction initiating node C reads R1 again from the master node P2. If the version value in R1 read again is the same as the version value V2 read in R1 during the execution phase, and R1 read again is not locked, then step 3 is executed.

[0103] If the version value in R1 read again is different from the version value V2 read in R1 during the execution phase, or if R1 read again is locked, the transaction initiating node C will abort the transaction process and send an abandon message to the master node P1 to indicate that the successfully locked object should be unlocked.

[0104] 3. Submit backup

[0105] In this step, the transaction initiating node C sends a backup commit message to the backup node B1 of W1. The content of this backup commit message is the same as that of the locking message in step 1. After receiving the backup commit message, backup node B1 can send a successful backup commit response back to the transaction initiating node C.

[0106] If the transaction initiating node C receives a backup commit success response from the backup node B1, then proceed to step 4.

[0107] If the transaction initiating node C does not receive a backup commit success response from the backup node B1, it aborts the transaction and sends an abandon message to the primary node P1 to indicate that the locked objects should be unlocked.

[0108] 4. Main commit

[0109] In this step, the transaction initiating node C sends a master commit message to the master node P1. After receiving the master commit message, the master node P1 updates the data item in its stored W1 with the D1' carried in the lock message received in step 1, and unlocks its stored W1. Then, it returns a master commit success response to the transaction initiating node C.

[0110] If the transaction initiating node C receives a successful primary commit response from the master node P1, it generates a transaction completion notification to inform the upper-layer application that the transaction has been completed. Afterward, the transaction initiating node C executes step 5.

[0111] 5. Delete

[0112] In this step, the transaction initiating node C sends deletion messages to the primary nodes P1 and P2, and the backup node B1. Upon receiving the deletion message, each primary node deletes all messages related to the transaction. Upon receiving the deletion message, the backup node modifies the corresponding write object's data item in its stored memory with the modified data item carried in the backup commit message, and then deletes all messages related to the transaction.

[0113] As described above regarding the transaction processing process, currently, during the commit phase, the version value of the read object can only be verified after the write object lock is successfully completed. This is because if the version value of the read object is verified before the write object lock is successful, the read object may still be modified during the write object locking process, potentially leading to errors in the transaction's operations on the write object. Therefore, by successfully locking the write object first and then verifying the version value of the read object, the correctness of the data can be guaranteed. Furthermore, during the commit phase, the commit to the backup node can only be completed before committing to the primary node, thus ensuring data reliability. However, while the order of write object locking and read object version value verification, as well as the order of backup commit and primary commit, ensures the correctness and reliability of data commit, it results in a longer transaction commit latency, which is unacceptable for some latency-sensitive businesses.

[0114] Based on this, embodiments of this application provide a transaction processing method, wherein a first node, based on the information of the write object and the read object included in a first transaction, reads the write object from the master node of the write object and the read object from the master node of the read object. After modifying the data items of the write object, the first node can send a write lock message to the master node of the write object and a read lock message to the master node of the read object. In this way, the master node of the write object and the master node of the read object can perform object locking and version value verification in an unison; that is, the first node can initiate locking and version value verification of the write object and version value verification of the read object in parallel. This shortens the transaction processing time compared to performing version value verification of the read object only after the write object has been successfully locked and the version value verification has passed. Furthermore, in this embodiment, even if the primary node of the read object returns a read lock response first, followed by the primary node of the write object returning a write lock response—that is, even if the version value of the read object is successfully verified before the write object is successfully locked—the primary node of the read object successfully acquires a read lock on the read object at the same time as verifying its version value. Therefore, the read object will not be tampered with by other transactions before the primary node of the write object successfully acquires a write lock on the write object, ensuring the correctness of the committed data. Thus, this embodiment reduces transaction commit latency while ensuring the correctness of the committed data.

[0115] The transaction processing method provided in the embodiments of this application will be described next.

[0116] Figure 4 This is a flowchart of a transaction processing method provided in an embodiment of this application. This method can be applied to a first node. The first node can be... Figure 1 Any computing node in the system architecture shown can also be Figure 2 Any node in the system architecture shown. Furthermore, this first node is the node that triggers transaction processing; that is, this first node is the transaction initiating node during the transaction processing process. See also... Figure 4 The method includes the following steps:

[0117] Step 401: Based on the information of the write object and the read object included in the first transaction, read the write object from the second node and read the read object from the third node. The write object includes a first data item. The second node is the master node where the write object is located, and the third node is the master node where the read object is located.

[0118] In this embodiment of the application, the information of the write object included in the first transaction to be processed may include the address information of the write object, and the information of the read object may include the address information of the read object. Based on this, the first node can read the write object from the master node where the write object is located, i.e., the second node, according to the address information of the write object, and read the read object from the master node where the read object is located, i.e., the third node, according to the address information of the read object.

[0119] For example, the first node can read the write object from the storage object stored by the second node through the RDMA network card according to the address information of the write object, and read the read object from the storage object stored by the third node through the RDMA network card according to the address information of the read object.

[0120] It should be noted that both the write object and the read object mentioned above can be referred to as storage objects. In the embodiments of this application, a storage object refers to a data unit stored in a node, for example, a data unit stored in the node's memory. A storage object may include metadata items and data items. The metadata items may include version values ​​and lock information.

[0121] Version values ​​are used to indicate the version of a stored object. In one possible implementation, version values ​​can include two types: intermediate version values ​​and stable version values.

[0122] The intermediate version value indicates that the updated data item of the storage object has not been successfully committed. That is, the updated data item of the storage object already exists in the primary node of the storage object, but the updated data item has not yet been notified to the backup node of the storage object, or the updated data item has been notified to the backup node of the storage object, but the backup node has not yet confirmed receipt of the updated data item.

[0123] A stable version value indicates that the updated data items of a storage object have been successfully committed. That is, the master node has updated the data items of the storage object it stores based on the updated data items, and the updated data items have been notified to all backup nodes of the storage object, and all backup nodes have confirmed receipt of the updated data items.

[0124] As an example, in this embodiment, intermediate version values ​​can be represented by odd numbers, and stable version values ​​can be represented by even numbers. For any intermediate version value, the corresponding stable version value can be equal to the intermediate version value plus 1. The intermediate version value and the corresponding stable version value are version values ​​during the process of modifying the storage object based on a transaction. Furthermore, for any stable version value, there is a unique next intermediate version value, which is equal to the stable version value plus 1. In this case, the stable version value is the version value after the updated data item of the storage object has been successfully committed based on a transaction, while the next intermediate version value corresponding to the stable version value is the version value of the storage object before the updated data item has been successfully committed during the process of modifying the storage object based on the version indicated by the stable version value by another transaction.

[0125] The above is an example of an intermediate version value and a stable version value given in this application. Obviously, the intermediate version value can also be represented by an even number. In this case, the stable version value can be represented by an odd number. This application will not elaborate further on this.

[0126] In another possible implementation, the version value may not distinguish between intermediate and stable versions. In this case, the current version value of the stored object is incremented by 1 each time an updated data item is committed based on a transaction; however, the version value of the stored object will not change until the commit is complete.

[0127] Lock information can include read lock fields and write lock fields. The read lock field is used to acquire a read lock on a storage object, while the write lock field is used to acquire a write lock on the storage object. For example, a write lock value of 1 indicates that a write lock is currently acquired on the storage object. A write lock value of 0 indicates that a write lock is not currently acquired on the storage object. Similarly, a read lock value of 0 indicates that a read lock is not currently acquired on the storage object, and a read lock value of n indicates the number of accessors currently holding a read lock on the storage object, i.e., how many accessors share the read access to the storage object. Here, n is a positive integer greater than 0. Furthermore, in this embodiment, the aforementioned accessor can refer to a transaction.

[0128] It is worth noting that in this embodiment, when a write lock is acquired on a storage object, it cannot be acquired with a read lock, or vice versa. For example, in the above examples of write lock and read lock field values, when the write lock field value of the storage object is 1, the read lock field value will be 0; when the read lock field value is n, the write lock field value will be 0. That is, the situation where the read lock field is n and the write lock field is 1 will not occur.

[0129] In addition to version value and lock information, the metadata items of the stored object may also include other information describing the data items, such as the length information of the data items. This application embodiment does not limit this.

[0130] Figure 5 This is a data structure diagram of a storage object provided in an embodiment of this application. For example... Figure 5 As shown, the storage object includes the aforementioned lock information, which includes a read lock field and a write lock field. Following the lock information is the version value of the storage object, followed by other metadata information, and then the data items of the storage object.

[0131] Step 402: Modify the first data item to obtain the updated first data item.

[0132] After reading the write object and the read object, the first node modifies the first data item included in the read write object to obtain the updated first data item. The first node can then cache the updated first data item locally.

[0133] Step 403: Send a write lock message to the second node and a read lock message to the third node. The read lock message is used to acquire a read lock on the read object and check whether the read object read by the first node is correct.

[0134] After modifying the first data item to obtain the updated first data item, the first node can send a write lock message to the second node and a read lock message to the third node. In this embodiment, the timing of the first node sending the write lock message and the read lock message is not limited; that is, the first node can send the write lock message and the read lock message in any order.

[0135] For example, the first node can send a write lock message to the second node while simultaneously sending a read lock message to the third node. Alternatively, the first node can first send a write lock message to the second node, and then send a read lock message to the third node before receiving a write lock success response from the second node based on the write lock message. Or, the first node can also first send a read lock message to the third node, and then send a write lock message to the second node before receiving a read lock success response from the third node based on the read lock message.

[0136] The write lock message instructs the second node to acquire a write lock on the write object and check whether the write object read by the first node is correct. For example, the write lock message includes a version value of the write object, which is the version value in the metadata item of the write object read by the first node from the second node. Therefore, checking whether the write object read by the first node is correct can refer to checking whether the version value of the write object read by the first node meets the verification conditions. Additionally, the write lock message may also include an updated first data item.

[0137] Optionally, when there are multiple write objects, and the second nodes where the multiple write objects reside are different, the write lock messages sent by the first node to each of the second nodes can be the same or different. When the write lock messages sent to each of the second nodes are the same, the write lock message includes the version value of each write object and the updated first data item of each write object. When the write lock messages sent to each of the second nodes are different, the write lock message sent to any second node includes the version value of the write object located on that second node, which is read by the first node among the multiple write objects, and the updated first data item.

[0138] The read lock message instructs the third node to acquire a read lock on the read object and check whether the read object read by the first node is correct. For example, the read lock message includes the version value of the read object, which is the version value in the metadata field of the read object read by the first node from the third node. Therefore, checking whether the read object read by the first node is correct can refer to checking whether the version value of the read object read by the first node meets the verification conditions.

[0139] It should be noted that, in this embodiment, the write lock message and read lock message, in addition to the information mentioned above, may also include the identifier of the first transaction and the message type. The identifier of the first transaction indicates that the write lock message and read lock message are messages related to the first transaction sent by the first node. The message type indicates which type of message the corresponding message is. Of course, in subsequent steps, the various messages sent by the first node to the second, third, and fourth nodes may also include the identifier of the first transaction and the message type. Furthermore, when a corresponding message instructs a node to operate on a storage object, the message may also include the object identifier of the object to be operated on. For example, the write lock message may include the object identifier of the write object so that the second node can determine the write object to be operated on based on the object identifier. Similarly, the read lock message may include the object identifier of the read object, which will not be elaborated further in this embodiment.

[0140] After receiving the write lock message, the second node caches the write lock message, acquires a write lock on the write object based on the write lock message, and checks whether the write object read by the first node is correct.

[0141] The second node can locate the write object it stores based on the object identifier in the write lock message. Then, it checks whether the write object is already locked (either write or read lock) based on the lock information of the found write object. If the lock information indicates that the write object is already locked (either write or read lock), the second node cannot add a write lock to the write object, and in this case, adding a write lock to the write object is considered a failure. If the lock information indicates that the write object is neither locked nor read lock, the second node can add a write lock to the write object by modifying the lock information.

[0142] For example, as described above, the lock information for a write object may include a read lock field and a write lock field. The second node can detect whether the values ​​of the read lock field and the write lock field are 0. If the value of the read lock field is not 0, it is determined that a read lock has been acquired on the write object; if the value of the write lock field is not 0, it is determined that a write lock has been acquired on the write object. In this case, acquiring a write lock on the write object is determined to have failed. If both the read lock field and the write lock field have values ​​of 0, the second node can modify the value of the write lock field to a non-zero value, for example, to 1, thereby acquiring a write lock on the write object.

[0143] Additionally, the second node can retrieve the version value of the write object carried in the write lock message and obtain the current version value of the write object stored within itself. Based on the current version value of the write object stored within itself, it determines whether the version value of the write object read by the first node in the write lock message meets the verification conditions.

[0144] In the first implementation, if the version value of the stored object includes both intermediate and stable versions, then when the first node reads an intermediate version value for the written object, the second node can determine whether its own stored version value of the written object corresponds to the stable version value read by the first node. If the current version value of the written object stored in the second node is the same as the stable version value read by the first node, then the written object read by the first node is indeed the stable version currently stored in the second node. In this case, the second node can determine that the version value read by the first node satisfies the verification condition, meaning the written object read by the first node is correct.

[0145] If the current version value of the write object stored in the second node is not the stable version value corresponding to the version value of the write object read by the first node, it indicates that the write object currently stored in the second node has been modified relative to the write object read by the first node. Alternatively, the write object currently stored in the second node has not been modified relative to the write object read by the first node, but the write object currently stored in the second node is currently being modified by other transactions, that is, the write object currently stored in the second node has not yet entered a stable state. In this case, the second node can determine that the version value of the write object read by the first node does not meet the verification condition, that is, the write object read by the first node is incorrect.

[0146] For example, suppose the first node reads a write object version value of 11. The corresponding stable state version value is 12. Therefore, if the second node stores a write object with a current version value of 12, the write object read by the first node is correct. If the second node stores a write object version value of 13, it means the write object has been modified by another transaction. In this case, the write object stored in the second node is different from the write object read by the first node, and the write object read by the first node is incorrect. If the second node stores a write object version value of 11, it means the write object is still being modified by another transaction. That is, the modification has not yet been successfully committed, and the write object has not yet entered a stable state. In this case, the second node cannot accept the modification by the first node, and therefore, the second node can determine that the write object read by the first node is incorrect.

[0147] When the first node reads a stable version value for the write object, the second node can determine if its stored current version value for the write object is the same as the version value read by the first node. If the current version value stored in the second node is the same as the version value read by the first node, it means that the write object read by the first node is the write object currently stored in the second node, and that the write object has not been modified by other transactions. In this case, the second node can determine that the version value of the write object meets the verification condition, that is, the write object read by the first node is correct.

[0148] If the current version value of the write object stored in the second node is not the same as the version value read by the first node, it means that the write object read by the first node is not the same as the write object currently stored in the second node. In this case, the second node can determine that the version value of the write object read by the first node does not meet the verification condition, that is, the write object read by the first node is incorrect.

[0149] For example, suppose the first node reads a version value of 12 for the write object. If the second node also stores a version value of 12 for the write object, then the write object read by the first node is correct. If the second node stores a version value of 13 for the write object, then the write object read by the first node is incorrect.

[0150] In the second implementation, if the version value of the stored object does not distinguish between intermediate and stable version values, the second node can determine whether the version value of the write object read by the first node in the write lock message is the same as the current version value of the write object stored by itself. If they are the same, it means that the write object read by the first node is the same as the write object stored by the second node. At this time, the second node can determine that the version value of the write object read by the first node meets the verification condition, that is, the write object read by the first node is correct.

[0151] If the version value of the write object read by the first node in the write lock message is different from the current version value of the write object stored by the second node, then the second node can determine that the version value of the write object read by the first node does not meet the verification condition, that is, the write object read by the first node is incorrect.

[0152] If the second node successfully acquires a write lock on the write object using the above method and determines that the write object read by the first node is correct, the second node can return a write lock success response to the first node. If the second node fails to acquire a write lock on the write object using the above method or determines that the write object read by the first node is incorrect, the second node can return a write lock failure response to the first node.

[0153] After receiving a read lock message, the third node can cache the read lock message, acquire a read lock on the read object based on the read lock message, and check whether the read object read by the first node is correct.

[0154] The third node can determine whether a read object has a read lock or a write lock by storing the lock information of the read object itself. If the read object already has a write lock, then acquiring a read lock on the read object has failed. If the read object does not have a write lock, then the third node can acquire a read lock on the read object again, regardless of whether a read lock has already been acquired.

[0155] The implementation method for determining whether a read object has a read lock or a write lock can refer to the relevant implementation methods described above, and will not be repeated here in this embodiment. Alternatively, the third node can also add a read lock to the read object by modifying the lock information. For example, the third node can increment the value of the read lock field in the lock information of the read object it stores by 1, thereby adding a read lock to the read object again.

[0156] In addition, the third node can also refer to the method of the second node to verify the version value of the write object, and verify the version value of the read object in order to detect whether the read object read by the first node is correct. This embodiment of the application will not be described in detail here.

[0157] If the third node successfully acquires a read lock on the read object and determines that the read object read by the first node is correct, the third node can return a read lock success response to the first node. If the third node fails to acquire a read lock on the read object or determines that the read object read by the first node is incorrect, the third node can return a read lock failure response to the first node.

[0158] When the first node receives a write lock success response from the second node and a read lock success response from the third node, it can execute step 404 below. Optionally, if the first node receives a write lock failure response from the second node, or a read lock failure response from the third node, or both, the first node can send a process abort message to the second and third nodes. This process abort message is used to indicate the abort of the processing of the first transaction, and it is also used to instruct the second and third nodes to unlock the successfully locked object.

[0159] It should be noted that, as described above, a write lock failure response might be returned by the second node if it successfully acquires a write lock on the write object but version value verification fails. Similarly, a read lock failure response might be returned by the third node if it successfully acquires a read lock on the read object but version value verification fails. Therefore, after receiving the process abort message, if the second node returns a write lock success response or a write lock failure response after successfully acquiring a write lock on the write object but version value verification fails, then the second node can release the write lock acquired on the write object. Likewise, if the third node returns a read lock success response or a read lock failure response after successfully acquiring a read lock on the read object but version verification fails, then the third node can release the read lock acquired on the read object based on the first transaction.

[0160] For example, the second node can modify the value of the write lock field in the lock information of the stored write object to 0, thereby unlocking the write object. The third node can decrement the value of the read lock field in the lock information of the stored read object, thereby releasing the read lock on the read object held by the first transaction.

[0161] Step 404: Upon receiving a write lock success response from the second node and a read lock success response from the third node, submit the updated first data item to the second node and the fourth node. The write lock success response indicates that the write lock on the write object was successfully acquired and the read write object is correct. The read lock success response indicates that the read lock on the read object was successfully acquired and the read read object is correct. The fourth node is a backup node for the write object.

[0162] When the first node receives a write lock success response from the second node and a read lock success response from the third node, it means that the write object and read object it reads are both correct and that the write object and read object have been successfully locked. In this case, the first node can submit the updated first data item to the primary node and backup node of the write object, namely the second node and the fourth node.

[0163] In the first implementation, if the version value of the stored object is implemented through two versions: a stable version value and an intermediate version value, then the first node can send a main commit message to the second node and a backup commit message to the fourth node. The backup commit message includes the updated first data item. Upon receiving a main commit success response from the second node and a backup commit success response from the fourth node, it is determined that the updated first data item has been successfully committed. The main commit success response is sent by the second node after updating the data item and the first version value of the stored write object based on the main commit message and the updated first data item. The updated write object includes a second version value, which is the next intermediate version value of the first version value. The backup commit success response is sent by the fourth node after receiving the backup commit message.

[0164] In this embodiment, the order in which the first node sends the main commit message and the backup commit message is not critical. For example, the first node can send the backup commit message to the fourth node simultaneously with sending the main commit message to the second node. Alternatively, the first node can send the main commit message to the second node after sending the backup commit message to the fourth node and before receiving a successful backup commit response. Or, the first node can send the backup commit message to the fourth node after sending the main commit message to the second node and before receiving a successful main commit response.

[0165] After receiving the main commit message, the second node can cache it. Based on the main commit message, it retrieves the updated first data item, and then updates the data items of its own stored write objects according to the updated first data item, as well as updating the version value of its own stored write objects.

[0166] For example, the main commit message may include the updated first data item. In this case, the second node can obtain the updated first data item from the main commit message. Alternatively, the aforementioned write lock message may include the updated first data item, while the main commit message may not. In this case, the second node can obtain the identifier of the first transaction from the main commit message, and based on the identifier of the first transaction, obtain a write lock message containing the identifier of the first transaction from its own cached write lock messages, and then obtain the updated first data item from the obtained write lock message.

[0167] After obtaining the updated first data item, the second node can replace the data item of the write object stored within itself with the updated first data item, and modify the first version value of the write object stored within itself to the second version value. Then, the second node can return a primary commit success response to the first node, notifying the first node that the updated data item of the write object submitted to the primary node has been updated.

[0168] It should be noted that, as shown in step 403, the second node verifies the version value of the write object read by the first node based on the intermediate and stable version values. Therefore, the first version value of the write object is the stable version value. Based on this, after the second node replaces the stored write object's data item with the updated first data item, since the write object has been modified and it's not yet certain whether the backup node has received the updated first data item, the second node can modify the first version value to the corresponding next intermediate version value, i.e., the second version value, to indicate that the write object is being modified. For example, the second node can increment the first version value by 1 to obtain the second version value.

[0169] After receiving the backup commit message, the fourth node caches it. This backup commit message includes the updated first data item, the object identifier of the write object, and its version value. This allows the fourth node to subsequently update the stored data items and version values ​​of the write object based on the updated first data item, the object identifier, and the version value from the backup commit message. After caching the backup commit message, the fourth node can send a backup commit success response to the first node to notify it that it has received the backup commit message.

[0170] In this embodiment, since the second node can identify the state of the write object by switching between two version values—a stable version value and an intermediate version value—even if the first node sends a main commit message before receiving a backup commit success response, the second node can still indicate that the write object is under modification by switching the version value of the write object it stores to an intermediate version value. Thus, for other transactions that need to modify the write object, the version value of the write object read by the corresponding transaction can be verified based on the intermediate version value using the method described above, thereby ensuring data correctness. In this way, by switching between the two version values, write conflicts to the stored object are avoided, ensuring the correctness of the data read by the transaction. Furthermore, the sending of the main commit message does not depend on the receipt of the backup commit success response. Therefore, the main commit message and the backup commit message can be executed with a very short time difference or even in parallel, shortening transaction processing time and improving transaction processing efficiency.

[0171] In the second implementation, after receiving both the write lock success response and the read lock success response, the first node can first send a backup commit message to the fourth node. After receiving the backup commit success response from the fourth node, the first node then sends a main commit message to the second node. Upon receiving the main commit success response from the second node, the first node confirms that the updated first data item has been successfully committed.

[0172] That is, in this embodiment of the application, the first node can first submit the updated first data item to the backup node of the write object, and then submit it to the master node after successfully submitting it to the backup node. In this case, the version value of the stored object can be implemented through intermediate version value and stable version value, or it can be implemented without distinguishing between intermediate version value and stable version value.

[0173] If the version value of the stored object is implemented through intermediate version value and stable version value, then the operation of the second node after receiving the main commit message can refer to the implementation method described above.

[0174] If the version value of a stored object does not distinguish between intermediate and stable versions, then after receiving the master commit message and updating the data items of the stored write object based on the master commit message, the second node can increment the first version value of the stored write object by 1 to obtain the second version value. Since the first node sends the master commit message upon receiving a backup commit success response, after the second node updates the data items and version value of the stored write object, it can determine that the updated first data item has been committed successfully. In this case, the second node can release the write lock on the stored write object and then return a master commit success response to the first node.

[0175] In addition, the operation of the fourth node after receiving the backup submission message can refer to the implementation method described above, and will not be repeated here in the embodiments of this application.

[0176] Optionally, if the second node fails to update the data items and version values ​​of the stored write object after receiving the main commit message, or if the second node does not receive the main commit message, then the second node will not return a main commit success response to the first node. Similarly, if the fourth node does not receive the backup commit message or fails to successfully cache the backup commit message, then the fourth node will not return a backup commit success response to the first node. Furthermore, if the first node does not receive a main commit success response from the second node, or a backup commit success response from the fourth node, or neither, then the first node can send a process abort message to the second, third, and fourth nodes to notify each node to abort the processing of the first transaction and instruct the second and third nodes to unlock the successfully locked objects.

[0177] As described above, the second node acquires a write lock on the write object, while the third node acquires a read lock on the read object. Therefore, if the first node fails to receive the second node's primary commit success response and / or the fourth node's backup commit success response, i.e., determines that the updated first data item has failed to commit, the first node can notify the second node to release the write lock acquired on the write object and notify the third node to also release the read lock acquired on the read object based on the first transaction. The implementation methods for releasing the write lock on the write object and the read lock acquired on the read object based on the first transaction can refer to the relevant implementation methods described above, and will not be repeated here.

[0178] Optionally, in some possible implementations, when the first node submits the updated first data item to the second and fourth nodes, or after the first node submits the updated first data item to the second and fourth nodes, the first node may also send a read lock release message to the third node to instruct the third node to release the read lock of the read object.

[0179] For example, the first node can send a read lock release message to the third node simultaneously with sending the main commit message and the backup commit message. Alternatively, the first node can send the read lock release message to the third node immediately after sending the main commit message and the backup commit message. Or, the first node can send the read lock release message to the third node after receiving the main commit success response and the backup commit success response, that is, after the updated first data item has been successfully committed.

[0180] After receiving the read lock release message, the third node can release the read lock that was added to the read object based on the first transaction.

[0181] Once the first node confirms that the updated first data item has been successfully committed, the first node can also generate a transaction completion notification and send the transaction completion notification to the upper-layer application to notify the upper-layer application that the first transaction has been completed.

[0182] Optionally, if the version value of the stored object in this embodiment includes both an intermediate version value and a stable version value, then after the first data item is successfully submitted, for example, after generating a transaction completion notification, the first node can also send a write lock release message to the second node. The write lock release message instructs the second node to update the second version value to a third version value and release the write lock of the updated write object. The third version value is the stable version value corresponding to the second version value.

[0183] As described above, when the version value of a stored object includes an intermediate version value and a stable version value, after the second node updates the data item of the write object based on the main commit message, it will also update the first version value to the second version value. At this time, the second version value is the intermediate version value. Based on this, when the first node determines that it has successfully committed the updated first data item to the second and fourth nodes, it can notify the second node to update the second version value to the corresponding stable version value, i.e., the third version value, to identify the write object currently stored in the second node as a successfully committed write object. For example, the second node can increment the second version value by 1 to obtain the third version value.

[0184] Optionally, after the first data item is successfully committed after being updated, the first node may also send a first deletion message to the second node, which instructs the second node to delete the write lock message and the main commit message; and send a second deletion message to the fourth node, which instructs the fourth node to update the data item and the first version value of the stored write object based on the backup commit message and delete the backup commit message.

[0185] In this scenario, the first node can send a first delete message to the second node and a second delete message to the fourth node after sending a write lock release message. Optionally, if the version value of the stored object does not distinguish between intermediate and stable version values, since the second node can release the write lock of the write object after updating the data items and version values ​​of the write object it stores, the first node does not need to send a write lock release message to the second node. In this case, the first node can immediately send the first delete message to the second node and the second delete message to the fourth node after the updated first data item is successfully committed or after generating a transaction completion notification.

[0186] After receiving the first deletion message, the second node searches its own cache for messages containing the identifier of the first transaction, based on the identifier of the first transaction carried in the first deletion message. The second node then deletes the found messages. These found messages include write lock messages and main commit messages. Optionally, the found messages may also include write lock release messages.

[0187] After receiving the second deletion message, the fourth node, based on the identifier of the first transaction carried in the second deletion message, looks up the cached backup commit message containing the identifier of the first transaction. Based on the backup commit message, it updates the data items and first version value of the stored write object and deletes the backup commit message.

[0188] It should be noted that the fourth node may currently store backup commit messages sent by transactions other than the first transaction after modifying the write object. That is, the fourth node may store backup commit messages from different transactions modifying and committing the same write object. For ease of explanation, the backup commit message corresponding to the first transaction (i.e., the backup commit message containing the identifier of the first transaction) will be referred to as the target backup commit message, while the backup commit messages corresponding to other transactions will be referred to as other backup commit messages. As described above, the target backup commit message includes the updated first data item and the version value of the write object. Based on this, after finding the target backup commit message, the fourth node retrieves other backup commit messages that also contain the object identifier of the write object, based on the object identifier included in the target backup commit message. Then, the fourth node can compare the version value carried by the target backup commit message with the version value carried by the retrieved other backup commit messages. If the version value in the target backup commit message is greater than the version value in the other backup commit messages, then the fourth node updates the stored write object based on the updated first data item and the version value of the write object in the target backup commit message.

[0189] For example, each backup commit message may carry the version value of the write object read by the corresponding transaction. In this case, when the fourth node updates the stored write object based on the updated first data item and the version value of the write object in the target backup commit message, it can replace the data item of the stored write object with the updated first data item, and update the version value of the stored write object based on the version value in the target backup commit message.

[0190] If the version value of the stored object includes an intermediate version value and a stable version value, the fourth node can update the first version value of the stored write object to the third version value based on the version value in the target backup commit message.

[0191] For example, when the version value in the target backup commit message is an intermediate version value, the fourth node can add 3 to that version value to obtain the third version value. When the version value is a stable version value, the fourth node can add 2 to that version value to obtain the third version value.

[0192] If the version value of the stored object does not distinguish between intermediate and stable versions, the fourth node can update the first version value of the stored write object to the second version value based on the version value in the target backup commit message. For example, the fourth node can increment the version value by 1 to obtain the second version value.

[0193] Optionally, each backup commit message may also carry the current version value of the write object, calculated by the transaction sending node of the corresponding transaction based on the version value of the read write object. In this case, when the fourth node updates the stored write object based on the updated first data item and the version value of the write object in the target backup commit message, it can replace the data item of the stored write object with the updated first data item and directly replace the version value of the stored write object with the version value carried in the target backup commit message.

[0194] After updating the data items and version values ​​of the write object, the fourth node can delete the cached backup commit message. In addition, the fourth node can also delete other messages containing the identifier of the first transaction.

[0195] Optionally, while sending deletion messages to the second and fourth nodes, the first node may also send a third deletion message to the third node to instruct the third node to delete the cached messages related to the first transaction.

[0196] For example, the third node can search for cached messages containing the identifier of the first transaction based on the identifier of the first transaction contained in the third deletion message, and then delete the found messages. The found deletion messages include the aforementioned read lock messages, and may also include read lock release messages.

[0197] In this embodiment, the first node reads the write object from the second node and the read object from the third node, then modifies the data items of the read write object. Afterwards, it can send a write lock message to the second node and a read lock message to the third node. This allows the second and third nodes to lock and verify the object's version value in parallel; that is, the first node can initiate locking and version value verification of the write object and verifying the version value of the read object in parallel. This shortens the transaction processing time compared to verifying the read object's version value only after successfully locking and verifying the write object's version value. Furthermore, in this embodiment, even if the third node returns a read lock success response before the second node returns a write lock success response—meaning the third node successfully verifies the read object's version value before the second node successfully locks the write object—the read object will not be modified by other transactions before the second node successfully acquires the write lock, ensuring the correctness of the committed data. Therefore, the embodiments of this application can shorten the transaction processing time while ensuring the correctness of the submitted data.

[0198] Furthermore, in this embodiment, since the second node can identify the state of the write object by switching between two version values—a stable version value and an intermediate version value—even if the first node sends a main commit message before receiving the backup commit success response, the second node can still indicate that the write object is under modification by switching its version value to an intermediate version value. This allows other transactions that need to modify the write object to verify the version value they read based on the intermediate version value, thus ensuring data correctness. In this way, by switching between the two version values, write conflicts to the storage object are avoided, ensuring the correctness of the data read by the transaction. Furthermore, the sending of the main commit message does not depend on the receipt of the backup commit success response. Therefore, the main commit message and the backup commit message can be executed with a very short time difference or even in parallel, shortening transaction processing time and improving transaction processing efficiency.

[0199] Figure 6 This is a flowchart of another transaction processing method provided in an embodiment of this application, which can be applied to a first node. The first node can be... Figure 1 Any computing node in the system architecture shown can also be Figure 2 Any node in the system architecture shown. Furthermore, this first node is the node that triggers transaction processing; that is, this first node is the transaction initiating node during the transaction processing process. See also... Figure 6 The method includes the following steps:

[0200] Step 601: Based on the information of the write object and the read object included in the first transaction, read the write object from the second node and read the read object from the third node. Both the write object and the read object include a version value, and the write object includes a first data item. The second node is the master node where the write object is located, and the third node is the master node where the read object is located.

[0201] The implementation method for this step can refer to that of step 401. As described in step 401, the storage object may include metadata items and data items, wherein the metadata items may include version values ​​and lock information.

[0202] In this embodiment, the version value of the stored object includes an intermediate version value and a stable version value. For a detailed explanation of intermediate and stable version values, please refer to the preceding text; this embodiment will not repeat the details here.

[0203] In addition, the lock information can be implemented in the manner described in step 401 above. That is, the metadata item includes a read lock field for implementing read locks on storage objects and a write lock field for implementing write locks on storage objects.

[0204] Optionally, unlike step 401, in this embodiment, the lock information may include only a write lock field. In this case, a write lock can be applied to the storage object through the write lock field, but a read lock cannot be applied to the storage object. In this case, the write lock applied to the storage object can also be called an exclusive lock. That is, for any storage object, multiple accessors can share reading the storage object if no write lock is applied to it.

[0205] Step 602: Modify the first data item to obtain the updated first data item.

[0206] The implementation method of this step can refer to the implementation method of step 602, and will not be described again in this embodiment of the application.

[0207] Step 603: If the write lock on the write object in the second node is successfully acquired and the write object and read object read by the first node are both correct, send a main commit message to the second node to commit the updated first data item, and send a backup commit message to the fourth node to commit the updated first data item. The fourth node is the backup node for the write object.

[0208] In this embodiment, after modifying the first data item included in the write object, if the lock information of the stored object includes a write lock field and a read lock field, the first node can send a write lock message to the second node and a write lock message to the third node in the manner described in step 403. Correspondingly, the second node can acquire a write lock on its own stored write object in the manner described in step 403, and the third node can acquire a read lock on its own stored read object in the manner described in step 403. In addition, the second and third nodes can also verify the version values ​​of the write and read objects read by the first node using the first implementation method described in step 403. In this case, when the first node receives the write lock success response and read lock success response from the second node, it determines that the write lock on the write object in the second node was successfully acquired, the read lock on the read object in the third node was successfully acquired, and the write and read objects read by the first node are correct.

[0209] Alternatively, in another possible implementation, if the lock information of the stored object includes a write lock field but not a read lock field, after modifying the first data item, the first node can first send a write lock message to the second node. Upon receiving a successful write lock response from the second node, the first node then verifies the version value of the read object. If the version value verification of the read object is successful, the first node determines that it has successfully acquired a write lock on the write object in the second node, and that both the write object and the read object read by the first node are correct.

[0210] For example, after receiving a write lock message, the second node locates the write object it stores based on the object identifier of the write object carried in the write lock message. Then, it checks whether the write object is already locked based on the lock information of the found write object. If the lock information indicates that the write object is already locked, the second node cannot add a write lock to the write object at this time, and in this case, it is determined that adding a write lock to the write object has failed. If the lock information indicates that the write object is not locked, the second node can add a write lock to the write object by modifying the lock information.

[0211] Specifically, if the write lock field of a write object is not 0, it is determined that the write object has been locked. If the write lock field of a write object is 0, it is determined that the write object has not been locked. In this case, the second node can modify the value of the write lock field to a non-zero value to lock the write object. For example, the value of the write lock field can be modified to 1.

[0212] In addition, the second node can also refer to the first method in step 401 above to verify the version value of the write object read by the first node carried in the write lock message.

[0213] If the second node successfully acquires a write lock on the write object and verifies the version value of the write object read by the first node, then the second node returns a write lock success response to the first node. If the second node fails to acquire a write lock on the write object and / or fails to verify the version value of the write object read by the first node, then the second node returns a write lock failure response to the first node.

[0214] When the first node receives a write lock success response, it can confirm that the write lock on the write object was successfully acquired. In this case, the first node can send a verification message to the third node, which carries the version value of the read object read by the first node. After receiving the verification message, the third node verifies the version value of the read object read by the first node using the first method described in step 403 above. If the verification of the version value of the read object read by the first node passes, the third node can return a verification success response to the first node. If the verification of the version value of the read object read by the first node fails, the third node returns a read verification failure response to the first node. After receiving the verification success response, the first node confirms that the read object it read is correct. After receiving the read verification failure response, the first node confirms that the read object it read is incorrect.

[0215] Optionally, in one possible implementation, after the first node successfully acquires the write lock on the write object, it can also read the read object again from the third node. Then, the first node can refer to the first method in step 403 above, using the version value in the reread read object as the current version value, and verify the version value of the initially read read object based on this current version value. If the verification passes, the first node determines that the read object it read is correct. If the verification fails, it determines that the read object it read is incorrect.

[0216] Once the first node successfully acquires a write lock on the write object using the aforementioned method, and confirms that the write and read objects it has read are correct, the first node can refer to the content described in the first implementation of step 404 above, and send a main commit message to the second node and a backup commit message to the fourth node. That is, in this embodiment, the order in which the first node sends the main commit message and the backup commit message is not important. This embodiment will not elaborate on this implementation process.

[0217] Optionally, if the first node determines, through the above methods, that acquiring a write lock on the write object has failed, or determines that the write object and / or read object it has read is incorrect, then the first node may send a process abort message to the second and third nodes. This process abort message instructs the second and third nodes to abort the processing of the first transaction. Furthermore, if the second node successfully acquired a write lock on the write object based on the first transaction in the aforementioned process, the process abort message also instructs the second node to unlock the successfully locked write object. If the third node successfully acquired a read lock on the read object based on the first transaction in the aforementioned process, the process abort message also instructs the third node to release the read lock acquired on the read object based on the first transaction.

[0218] Optionally, if the lock information of the stored object includes a read lock field, then when the first node submits the updated first data item to the second and fourth nodes, or after the first node submits the updated first data item to the second and fourth nodes, the first node can also send a read lock release message to the third node to instruct the third node to release the read lock of the read object. The relevant implementation method can refer to the read lock release implementation method in step 404 above.

[0219] Step 604: Upon receiving the primary commit success response from the second node and the backup commit success response from the fourth node, generate a transaction completion notification.

[0220] Once the first node receives the primary commit success response from the second node and the backup commit success response from the fourth node, it can determine that the updated first data item has been successfully committed. In this case, the first node can generate a transaction completion notification and send it to the upper-layer application to notify it that the first transaction has been completed.

[0221] After generating the transaction completion notification, the first node can also send a write lock release message to the second node. This write lock release message instructs the second node to update the intermediate version value of the currently stored write object, i.e., the second version value, to the third version value, and release the write lock of the updated write object. The third version value is the stable version value corresponding to the second version value. The implementation method for updating the version value is the same as the relevant implementation method in step 405 above, and will not be repeated here in this embodiment.

[0222] After sending the write lock release message, the first node can also send a first delete message to the second node, which instructs the second node to delete the write lock message and the main commit message; and send a second delete message to the fourth node, which instructs the fourth node to update the data items and first version value of the stored write object based on the backup commit message and delete the backup commit message.

[0223] The processing methods of the second and fourth nodes after receiving the deletion message can refer to the relevant implementation methods in step 405 above, and will not be repeated here in this embodiment of the application.

[0224] Optionally, while sending deletion messages to the second and fourth nodes, the first node may also send a third deletion message to the third node, instructing the third node to delete the cached messages related to the first transaction. Refer to step 405 for the relevant implementation details.

[0225] In this embodiment, the version value of a storage object can include a stable version value and an intermediate version value. The intermediate version value indicates that the updated data item of the storage object has not been successfully committed, while the stable version value indicates that the updated data item of the storage object has been successfully committed. Based on this, the state of the write object can be identified by switching between these two version values. Therefore, even if the first node sends a main commit message before receiving the backup commit success response, the main node of the write object, i.e., the second node, can still indicate that the write object is under modification by switching its version value to the intermediate version value. Thus, for other transactions that need to modify the write object, they can verify the version value of the write object they read based on the intermediate version value, thereby ensuring the correctness of the data. In this way, by switching between the two version values, write conflicts to the storage object by transactions are avoided, ensuring the correctness of the data read by the transactions. Furthermore, the sending of the main commit message does not depend on the receipt of the backup commit success response. Therefore, the steps of sending the main commit message and sending the backup commit message can be executed with a very short time difference or even in parallel, shortening the time required from starting to process the first transaction to notifying the upper-layer application that the transaction processing is complete.

[0226] Furthermore, in this embodiment, after modifying the first data item included in the write object, the first node can send a write lock message to the second node and a read lock message to the third node. This allows the second and third nodes to perform object locking and version value verification in parallel; that is, the first node can initiate locking and version value verification of the write object and version value verification of the read object in parallel. This shortens the transaction processing time compared to performing version value verification of the read object only after successful locking and version value verification of the write object. Moreover, in this embodiment, even if the third node returns a read lock success response first, followed by the second node's write lock success response—meaning the third node successfully verifies the version value of the read object before the second node successfully locks the write object—the read object will not be tampered with by other transactions before the second node successfully acquires the write lock, ensuring the correctness of the submitted data. Therefore, this embodiment shortens the transaction processing time while ensuring the correctness of the submitted data.

[0227] Next, taking the storage objects targeted by the two write operations in the first transaction as W1, and the storage object targeted by the one read operation as R1, with the first node being C, the primary node (also the second node) of W1 being P1, the backup node (also the fourth node) being B1, and the primary node (also the third node) of R1 being P2 as an example, we will use three exemplary embodiments to illustrate the above-mentioned... Figure 4 and Figure 6 The transaction processing method shown is illustrated with an example.

[0228] Figure 7 This is a flowchart of a transaction processing method provided in an embodiment of this application. See also... Figure 7 The transaction processing flow includes the following steps:

[0229] Step 701: Node C reads W1 from node P1 and R1 from node P2.

[0230] W1 includes version value V1 and data item D1, and R1 includes version value V2 and data item D2.

[0231] Step 702: Node C modifies data item D1 in W1 and records the modified D1'.

[0232] Here, D1' is the first data item after the update.

[0233] Step 703: Node C sends a write lock message to node P1 and a read lock message to node P2 at the same time.

[0234] The write lock message includes (V1, D1'). The read lock message includes V2.

[0235] Step 704: Node P1 acquires a write lock on the stored W1 and verifies V1.

[0236] Node P1 can acquire a write lock on W1 based on the method described in step 403 above.

[0237] Additionally, when V1 is odd, that is, when V1 is an intermediate version value, node P1 checks whether the version value V1' of W1 stored in itself is equal to V1+1. If V1' is equal to V1+1, the verification is considered successful. If V1' is not equal to V1+1, the verification is considered unsuccessful.

[0238] When V1 is even, that is, when V1 is a stable version value, node P1 checks whether the version value V1' of W1 stored in itself is equal to V1. If V1' is equal to V1, the verification is successful. If V1' is not equal to V1, the verification is unsuccessful.

[0239] Step 705: Node P2 acquires a read lock on the stored R1 and verifies V2.

[0240] In this process, node P2 acquires a read lock on R1 using the method described in step 403 above, and verifies V2 using the method described in step 704.

[0241] The execution order of steps 704 and 705 above is not important.

[0242] Step 706: If node P1 successfully acquires a write lock on W1 and V1 passes verification, it returns a write lock success response to node C.

[0243] Step 707: If node P2 successfully acquires a read lock on R1 and V2 verifies the read lock, it returns a read lock success response to node C.

[0244] The execution order of steps 706 and 707 above is not important.

[0245] Step 708: Node C sends a primary commit message to node P1, a backup commit message to node B1, and a read lock release message to node P2.

[0246] Step 709: Node P1 replaces the stored D1 with D1' based on the main commit message, and updates the version value V1' of the stored W1 to V1'+1.

[0247] Step 710: Node P1 returns a primary commit success response to node C.

[0248] Step 711: After caching the backup commit message, node B1 returns a backup commit success response to node C.

[0249] Step 712: Node P2 releases the read lock acquired for R1 based on the first transaction based on the read lock release message.

[0250] The execution order of steps 709 to 712 is not important.

[0251] Step 713: Node C notifies the upper-layer application that the first transaction has been completed.

[0252] Step 714: Node C sends a write lock release message to node P1.

[0253] Step 715: Node P1 releases the write lock on W1 and updates the version value of W1 from V1'+1 to V1'+2.

[0254] Step 716: Node C sends a delete message to nodes P1, B1, and P2.

[0255] Step 717: Node P1 deletes the relevant messages for the first transaction based on the deletion message.

[0256] Step 718: Node P2 deletes the relevant messages for the first transaction based on the deletion message.

[0257] Step 719: Node B1 updates the stored D1 to D1' and the stored V1' to V1'+2 based on the deletion message, and deletes the relevant messages of the first transaction.

[0258] The execution order of steps 717 to 719 is not important.

[0259] It should be noted that steps 701 and 702 above can be referred to as the transaction execution phase, steps 703 to 707 are the transaction locking and verification phase, steps 708 to 713 are the transaction commit phase, steps 714 and 715 are the write lock release phase, and step 716 is the deletion phase. A schematic diagram of the interaction sequence between the nodes in each phase is shown below. Figure 8 As shown. Figure 8 and Figure 3 A comparison reveals that, compared to related technologies, the embodiments of this application execute the locking and version verification of the storage object in parallel, and execute the steps of submitting the updated data items to the primary and backup nodes of the write object in parallel. This shortens the round-trip latency of interactions between nodes during transaction processing, improving transaction processing efficiency. Furthermore, compared to related technologies, the embodiments of this application require a shorter time from the start of transaction processing to notifying the upper-layer application that the transaction has been completed.

[0260] Figure 9 This is a flowchart of another transaction processing method provided in an embodiment of this application. See also... Figure 9 The transaction processing flow includes the following steps:

[0261] Step 901: Node C reads W1 from node P1 and R1 from node P2.

[0262] W1 includes version value V1 and data item D1, and R1 includes version value V2 and data item D2.

[0263] Step 902: Node C modifies data item D1 in W1 and records the modified D1'.

[0264] Here, D1' is the first data item after the update.

[0265] Step 903: Node C sends a write lock message to node P1 and a read lock message to node P2 at the same time.

[0266] The write lock message includes (V1, D1'). The read lock message includes V2.

[0267] Step 904: Node P1 acquires a write lock on the stored W1 and verifies V1 by determining whether V1 is equal to the version value V1' of W1 stored by itself.

[0268] Node P1 can acquire a write lock on W1 based on the method described in step 403 above.

[0269] Additionally, if V1' equals V1, the verification is considered successful. If V1' does not equal V1, the verification is considered unsuccessful.

[0270] Step 905: Node P2 acquires a read lock on the stored R1 and verifies V2 by determining whether V2 is equal to the version value V2' of its own stored R1.

[0271] In this process, node P2 acquires a read lock on R1 using the method described in step 403 above, and verifies V2 using the method described in step 904.

[0272] The execution order of steps 904 and 905 above is not important.

[0273] Step 906: If node P1 successfully acquires a write lock on W1 and V1 passes verification, it returns a write lock success response to node C.

[0274] Step 907: If node P2 successfully acquires a read lock on R1 and V2 verifies the read lock, it returns a read lock success response to node C.

[0275] The execution order of steps 906 and 907 above is not important.

[0276] Step 908: Node C sends a backup commit message to node B1.

[0277] Step 909: After caching the backup commit message, node B1 returns a backup commit success response to node C.

[0278] Step 910: Node C sends a master commit message to node P1 and a read lock release message to node P2.

[0279] Step 911: Node P1 replaces the stored D1 with D1' based on the main commit message, updates the version value V1' of the stored W1 to V1'+1, and releases the write lock of W1.

[0280] Step 912: Node P1 returns a primary commit success response to node C.

[0281] Step 913: Node P2 releases the read lock acquired for R1 based on the first transaction based on the read lock release message.

[0282] The execution order of steps 911 to 913 is not important.

[0283] Step 914: Node C notifies the upper-layer application that the first transaction is complete.

[0284] Step 915: Node C sends a deletion message to nodes P1, B1, and P2.

[0285] Step 916: Node P1 deletes the relevant messages for the first transaction based on the deletion message.

[0286] Step 917: Node P2 deletes the relevant messages for the first transaction based on the deletion message.

[0287] Step 918: Node B1 updates the stored D1 to D1' and the stored V1' to V1'+1 based on the deletion message, and deletes the relevant messages of the first transaction.

[0288] The execution order of steps 916 to 918 is not important.

[0289] It should be noted that steps 901 and 902 above can be referred to as the execution phase of the transaction, steps 903 to 907 are the locking and verification phase of the transaction, steps 908 to 914 are the commit phase of the transaction, and steps 915 to 918 are the deletion phase. A schematic diagram of the interaction sequence between the nodes of each phase is shown below. Figure 10 As shown. Figure 10 and Figure 3 A comparison reveals that, compared to related technologies, the embodiments of this application execute object locking and version verification in parallel, thereby shortening the round-trip latency of interactions between various nodes during transaction processing and improving transaction processing efficiency. Furthermore, compared to related technologies, the embodiments of this application require a shorter time from the start of transaction processing to notifying the upper-layer application that the transaction has been completed.

[0290] Figure 11 This is a flowchart of another transaction processing method provided in an embodiment of this application. See also... Figure 11 The transaction processing flow includes the following steps:

[0291] Step 1101: Node C reads W1 from node P1 and R1 from node P2.

[0292] W1 includes version value V1 and data item D1, and R1 includes version value V2 and data item D2.

[0293] Step 1102: Node C modifies data item D1 in W1 and records the modified D1'.

[0294] Here, D1' is the first data item after the update.

[0295] Step 1103: Node C sends a write lock message to node P1.

[0296] The write lock message includes (V1, D1').

[0297] Step 1104: Node P1 locks the stored W1 and verifies V1.

[0298] Node P1 can acquire a write lock on W1 based on the method described in step 603 above.

[0299] Alternatively, node P1 can verify V1 using the method described in step 704.

[0300] Step 1105: If node P1 successfully acquires a write lock on W1 and V1 is verified, it returns a write lock success response to node C.

[0301] Step 1106: Node C sends a verification message to node P2.

[0302] The verification message includes V2.

[0303] Step 1107: Node P2 verifies V2.

[0304] Node P2 verifies V2 in accordance with the method described in step 704 above.

[0305] Step 1108: If node P2 successfully verifies V2, it returns a verification success response to node C.

[0306] Step 1109: Node C sends a primary commit message to node P1 and a backup commit message to node B1.

[0307] Step 1110: Node P1 replaces the stored D1 with D1' based on the main commit message, and updates the version value V1' of the stored W1 to V1'+1.

[0308] Step 1111: Node P1 returns a primary commit success response to node C.

[0309] Step 1112: After caching the backup commit message, node B1 returns a backup commit success response to node C.

[0310] The execution order of steps 1110 to 1112 is not important.

[0311] Step 1113: Node C notifies the upper-layer application that the first transaction has been completed.

[0312] Step 1114: Node C sends a write lock release message to node P1.

[0313] Step 1115: Node P1 releases the write lock on W1 and updates the version value of W1 from V1'+1 to V1'+2.

[0314] Step 1116: Node C sends a deletion message to nodes P1, B1, and P2.

[0315] Step 1117: Node P1 deletes the relevant messages for the first transaction based on the deletion message.

[0316] Step 1118: Node P2 deletes the relevant messages for the first transaction based on the deletion message.

[0317] Step 1119: Node B1 updates the stored D1 to D1' and the stored V1' to V1'+2 based on the deletion message, and deletes the relevant messages of the first transaction.

[0318] The execution order of steps 1117 to 1119 is not important.

[0319] It should be noted that steps 1101 and 1102 above can be referred to as the transaction execution phase, steps 1103 to 1105 are the transaction locking phase, steps 1106 to 1108 are the verification phase, steps 1109 to 1113 are the transaction commit phase, steps 1114 and 1115 are the write lock release phase, and steps 1116 to 1119 are the deletion phase. A schematic diagram of the interaction sequence between the nodes in each phase is shown below. Figure 12 As shown. Figure 12 and Figure 3 A comparison reveals that, compared to related technologies, the embodiments of this application execute the steps of submitting updated data items to the primary node and backup node of the write object in parallel. Thus, compared to related technologies, the time required from the start of transaction processing to notifying the upper-layer application that the transaction has been completed is shorter in the embodiments of this application.

[0320] The above description exemplifies the scenario where the first transaction involves only one write object and one read object. It is worth noting that the first transaction may operate on more than one write object, and more than one read object. Alternatively, the first transaction may include write objects but not read objects, or it may include read objects but not write objects. When the first transaction includes write objects but not read objects, the operation steps related to read objects in the transaction processing flow described in the above embodiments can be deleted to operate on write objects. When it includes read objects but not write objects, the operation steps related to write objects in the transaction processing flow described in the above embodiments can be deleted to operate on read objects. This will not be elaborated further in this application.

[0321] The transaction processing apparatus provided in the embodiments of this application will be described next.

[0322] Figure 13 This is a schematic diagram illustrating the structure of a transaction processing apparatus according to an embodiment of this application. This transaction processing apparatus can be deployed in the aforementioned first node, such as... Figure 13 As shown, the transaction processing device 1300 includes a reading module 1301, a modifying module 1302, a sending module 1303, and a submitting module 1304.

[0323] The reading module 1301 is used to execute step 401 in the aforementioned embodiment;

[0324] Modify module 1302 to execute step 402 in the foregoing embodiments;

[0325] The sending module 1303 is used to execute step 403 in the foregoing embodiment;

[0326] Submission module 1304 is used to execute step 404 in the foregoing embodiments.

[0327] Optionally, the transmitting module 1303 is mainly used for:

[0328] Send a write lock message to the second node and a read lock message to the third node simultaneously; or, send a write lock message to the second node and, after sending the write lock message but before receiving a write lock success response, send a read lock message to the third node; or, send a read lock message to the third node and, after sending the read lock message but before receiving a read lock success response, send a write lock message to the second node.

[0329] Optionally, the sending module 1303 is also used for:

[0330] When the submission module 1304 submits the updated first data item to the second and fourth nodes, it sends a read lock release message to the third node. The read lock release message is used to instruct the third node to release the read lock of the read object.

[0331] Optionally, the sending module 1303 is also used for:

[0332] Upon receiving a write lock failure response from the second node and / or a read lock failure response from the third node, a process abort message is sent to the second and third nodes. The write lock failure response indicates that the write lock on the write object failed and / or the write object read by the first node is incorrect. The read lock failure response indicates that the read lock on the read object failed and / or the read object read by the first node is incorrect. The process abort message is used to indicate the abort of the processing of the first transaction, and the process abort message is also used to instruct the second and third nodes to unlock the objects that were successfully locked.

[0333] Optionally, both the write object and the read object read by the first node include a version value. The write lock message includes the version value of the write object read by the first node, and the read lock message includes the version value of the read object read by the first node. The correctness of the write object or read object read by the first node means that the version value of the corresponding object read by the first node meets the verification condition.

[0334] Optionally, the verification condition refers to the version value of the corresponding object read by the first node being an intermediate version value and the version value of the corresponding object in the corresponding master node being a stable version value corresponding to the version value of the corresponding object read by the first node. Alternatively, the verification condition refers to the version value of the corresponding object read by the first node being a stable version value and the version value of the corresponding object in the corresponding master node being the same as the version value of the corresponding object read by the first node. The intermediate version value is used to indicate that the updated data item of the corresponding object has not been successfully committed, and the stable version value is used to indicate that the updated data item of the corresponding object has been successfully committed.

[0335] Optionally, the write lock message also includes the updated first data item; the commit module 1304 is mainly used for:

[0336] Send a primary commit message to the second node and a backup commit message to the fourth node. The backup commit message includes the updated first data item.

[0337] Upon receiving a primary commit success response from the second node and a backup commit success response from the fourth node, it is determined that the updated first data item has been successfully committed. The primary commit success response is sent by the second node after updating the data item and the first version value of the stored write object based on the primary commit message and the updated first data item. The updated write object includes the second version value, which is the next intermediate version value of the first version value. The backup commit success response is sent by the fourth node after receiving the backup commit message.

[0338] Optionally, the submission module 1304 is primarily used for:

[0339] Send a primary commit message to the second node and a backup commit message to the fourth node at the same time;

[0340] Alternatively, send a backup commit message to the fourth node, and send a master commit message to the second node after sending the backup commit message and before receiving a successful backup commit response;

[0341] Alternatively, a primary commit message can be sent to the second node, and a backup commit message can be sent to the fourth node before a successful primary commit response is received.

[0342] Optionally, the sending module 1303 is also used for:

[0343] If no primary commit success response is received from the second node and / or a backup commit success response is received from the fourth node, a process abort message is sent to the second, third, and fourth nodes. The process abort message is used to indicate the abort of the processing of the first transaction, and the process abort message is also used to instruct the second and third nodes to unlock the objects that were successfully locked.

[0344] Optionally, the sending module 1303 is also used for:

[0345] Send a write lock release message to the second node. The write lock release message is used to instruct the second node to update the second version value to the third version value and release the write lock of the updated write object. The third version value is the stable version value corresponding to the second version value.

[0346] Optionally, the sending module 1303 is also used for:

[0347] Send a first delete message to the second node. The first delete message is used to instruct the second node to delete the write lock message and the main commit message.

[0348] A second deletion message is sent to the fourth node, which instructs the fourth node to update the data items and first version values ​​of the stored write object based on the backup commit message and delete the backup commit message.

[0349] In this embodiment, the first node reads the write object from the second node and the read object from the third node. After modifying the first data item included in the write object, it can send a write lock message to the second node and a read lock message to the third node. In this way, the second and third nodes can lock and verify the version value of the objects simultaneously; that is, the first node can initiate locking and version value verification of the write object and version value verification of the read object in parallel. This shortens the transaction processing time compared to performing version value verification of the read object only after the write object has been successfully locked and its version value verified. Furthermore, in this embodiment, even if the third node returns a read lock success response first, followed by the second node's write lock success response—that is, even if the third node successfully verifies the version value of the read object before the second node successfully locks the write object—the read object will not be tampered with by other transactions before the second node successfully acquires the write lock, ensuring the correctness of the submitted data. Therefore, the embodiments of this application can shorten the transaction processing time while ensuring the correctness of the submitted data.

[0350] Figure 14 This is a schematic diagram of another transaction processing device provided in an embodiment of this application. This transaction processing device is deployed in the first node, see [link / reference]. Figure 14 The transaction processing device 1400 includes a read module 1401, a modify module 1402, a submit module 1403, and a generate module 1404.

[0351] Reading module 1401 is used to execute step 601 in the foregoing embodiments;

[0352] Modify module 1402 to execute step 602 in the foregoing embodiments;

[0353] Submission module 1403 is used to execute step 603 in the foregoing embodiments;

[0354] The generation module 1404 is used to execute step 604 in the foregoing embodiments.

[0355] Optionally, the submission module 1403 is primarily used for:

[0356] Send a primary commit message to the second node and a backup commit message to the fourth node at the same time;

[0357] Alternatively, send a backup commit message to the fourth node, and send a master commit message to the second node after sending the backup commit message and before receiving a successful backup commit response;

[0358] Alternatively, a primary commit message can be sent to the second node, and a backup commit message can be sent to the fourth node before a successful primary commit response is received.

[0359] Optionally, the device 1400 further includes:

[0360] The sending module is used to send a write lock release message to the second node. The write lock release message is used to instruct the second node to update the second version value to the third version value and release the write lock of the updated write object. The third version value is the stable version value corresponding to the second version value.

[0361] In this embodiment, the version value of a storage object can include a stable version value and an intermediate version value. The intermediate version value indicates that the updated data item of the storage object has not been successfully committed, while the stable version value indicates that the updated data item of the storage object has been successfully committed. Based on this, the state of the write object can be identified by switching between these two version values. Therefore, even if the first node sends a main commit message before receiving the backup commit success response, the second node can still indicate that the write object is under modification by switching its version value to the intermediate version value. This allows other transactions that need to modify the write object to verify the version value they read based on the intermediate version value, thus ensuring data correctness. In this way, by switching between the two version values, write conflicts to the storage object by transactions are avoided, ensuring the correctness of the data read by the transactions. Furthermore, the sending of the main commit message does not depend on the receipt of the backup commit success response. Thus, the steps of sending the main commit message and sending the backup commit message can be executed with a very short time difference or even in parallel, shortening the time required from starting to process the first transaction to notifying the upper-layer application that the transaction processing is complete.

[0362] It should be noted that the transaction processing device provided in the above embodiments is only illustrated by the division of the above functional modules when processing transactions. In actual applications, the above 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 addition, the transaction processing device provided in the above embodiments and the aforementioned transaction processing method embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0363] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital versatile discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0364] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0365] The above description is merely an exemplary embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A transaction processing method, characterized in that, Applied to the first node, the method includes: Based on the information of the write object and the read object included in the first transaction, the write object is read from the second node and the read object is read from the third node. The write object includes a first data item. The second node is the master node where the write object is located, and the third node is the master node where the read object is located. Modify the first data item to obtain the updated first data item; Send a write lock message to the second node and a read lock message to the third node. The read lock message is used to acquire a read lock on the read object and check whether the read object read by the first node is correct. Upon receiving a write lock success response from the second node and a read lock success response from the third node, the updated first data item is submitted to the second node and the fourth node. The write lock success response indicates that the write lock was successfully acquired and the read object is correct. The read lock success response indicates that the read lock was successfully acquired and the read object is correct. The fourth node is a backup node for the write object.

2. The method according to claim 1, characterized in that, Sending a write lock message to the second node and a read lock message to the third node includes: Send the write lock message to the second node, and simultaneously send the read lock message to the third node; Alternatively, the write lock message is sent to the second node; and if the write lock success response has not been received after sending the write lock message, the read lock message is sent to the third node. Alternatively, the read lock message may be sent to the third node; and after sending the read lock message but before receiving the read lock success response, the write lock message may be sent to the second node.

3. The method according to claim 1 or 2, characterized in that, When submitting the updated first data item to the second and fourth nodes, the method further includes: Send a read lock release message to the third node, the read lock release message being used to instruct the third node to release the read lock on the read object.

4. The method according to claim 1 or 2, characterized in that, The method further includes: Upon receiving a write lock failure response from the second node and / or a read lock failure response from the third node, a process abort message is sent to the second node and the third node. The write lock failure response indicates that the write lock on the write object failed and / or the write object read by the first node is incorrect. The read lock failure response indicates that the read lock on the read object failed and / or the read object read by the first node is incorrect. The process abort message is used to indicate the abort of the processing of the first transaction, and the process abort message is also used to instruct the second node and the third node to unlock the object that was successfully locked.

5. The method according to claim 1, characterized in that, The write object and the read object read by the first node both include a version value. The write lock message includes the version value of the write object read by the first node, and the read lock message includes the version value of the read object read by the first node. The correctness of the write object or the read object read by the first node means that the version value of the corresponding object read by the first node meets the verification condition.

6. The method according to claim 5, characterized in that, The verification condition refers to the fact that the version value of the corresponding object read by the first node is an intermediate version value and the version value of the corresponding object in the corresponding master node is a stable version value corresponding to the version value of the corresponding object read by the first node, or the verification condition refers to the fact that the version value of the corresponding object read by the first node is a stable version value and the version value of the corresponding object in the corresponding master node is the same as the version value of the corresponding object read by the first node. The intermediate version value is used to indicate that the updated data item of the corresponding object has not been successfully submitted, and the stable version value is used to indicate that the updated data item of the corresponding object has been successfully submitted.

7. The method according to claim 6, characterized in that, The write lock message also includes the updated first data item; Submitting the updated first data item to the second node and the fourth node includes: Send a main commit message to the second node and a backup commit message to the fourth node, wherein the backup commit message includes the updated first data item; Upon receiving a primary commit success response from the second node and a backup commit success response from the fourth node, it is determined that the updated first data item has been successfully committed. The primary commit success response is sent by the second node after updating the data item and the first version value of the stored write object based on the primary commit message and the updated first data item. The updated write object includes a second version value, which is the next intermediate version value of the first version value. The backup commit success response is sent by the fourth node after receiving the backup commit message.

8. The method according to claim 7, characterized in that, Sending the main commit message to the second node and the backup commit message to the fourth node includes: Send the main commit message to the second node, and simultaneously send the backup commit message to the fourth node; Alternatively, the backup commit message is sent to the fourth node, and the main commit message is sent to the second node after the backup commit message is sent but before a successful backup commit response is received. Alternatively, a main commit message can be sent to the second node, and the backup commit message can be sent to the fourth node before the main commit success response is received.

9. The method according to claim 7, characterized in that, The method further includes: If no primary commit success response is received from the second node and / or a backup commit success response is received from the fourth node, a process abort message is sent to the second node, the third node, and the fourth node. The process abort message is used to indicate the abort of the processing of the first transaction, and the process abort message is also used to instruct the second node and the third node to unlock the object that was successfully locked.

10. The method according to claim 7 or 8, characterized in that, After the first updated data item is successfully submitted, the following is also included: Send a write lock release message to the second node. The write lock release message is used to instruct the second node to update the second version value to the third version value and release the write lock of the updated write object. The third version value is the stable version value corresponding to the second version value.

11. The method according to claim 7 or 8, characterized in that, After the first updated data item is successfully submitted, the following is also included: Send a first deletion message to the second node, the first deletion message being used to instruct the second node to delete the write lock message and the main commit message; A second deletion message is sent to the fourth node, which instructs the fourth node to update the data items and first version value of the stored write object based on the backup commit message and delete the backup commit message.

12. A transaction processing method, characterized in that, Applied to the first node, the method includes: Based on the information of the write object and the read object included in the first transaction, the write object is read from the second node and the read object is read from the third node. Both the write object and the read object include a version value, and the write object includes a first data item. The second node is the master node where the write object is located, and the third node is the master node where the read object is located. Modify the first data item to obtain the updated first data item; If the write lock on the write object in the second node is successfully acquired and both the write object and the read object read by the first node are correct, a main commit message for committing the updated first data item is sent to the second node, and a backup commit message for committing the updated first data item is sent to the fourth node. The correctness of the write object or read object read by the first node means that the version value of the corresponding object read by the first node is an intermediate version value and the version value of the corresponding object in the corresponding master node is the stable version value corresponding to the version value read by the first node; or, it means that the version value of the corresponding object read by the first node is a stable version value and the version value of the corresponding object in the corresponding master node is the same as the version value read by the first node. The intermediate version value indicates that the updated data item of the corresponding object has not been successfully committed, and the stable version value indicates that the updated data item of the corresponding object has been successfully committed. The fourth node is the backup node for the write object. Upon receiving a primary commit success response from the second node and a backup commit success response from the fourth node, a transaction completion notification is generated. The primary commit success response is sent by the second node after updating the data items and the first version value of the stored write object based on the primary commit message and the updated first data item. The updated write object includes a second version value, which is the next intermediate version value of the first version value. The backup commit success response is sent by the fourth node after receiving the backup commit message.

13. The method according to claim 12, characterized in that, The step of sending a main commit message to the second node to commit the updated first data item, and sending a backup commit message to the fourth node to commit the updated first data item, includes: Send the main commit message to the second node, and simultaneously send the backup commit message to the fourth node; Alternatively, the backup commit message is sent to the fourth node, and the main commit message is sent to the second node after the backup commit message is sent but before a successful backup commit response is received. Alternatively, a main commit message can be sent to the second node, and the backup commit message can be sent to the fourth node before the main commit success response is received.

14. The method according to claim 12 or 13, characterized in that, After generating the transaction completion notification, the method further includes: Send a write lock release message to the second node. The write lock release message is used to instruct the second node to update the second version value to the third version value and release the write lock of the updated write object. The third version value is the stable version value corresponding to the second version value.

15. A transaction processing apparatus, characterized in that, Applied to the first node, the device includes: The read module is used to read the write object from the second node and the read object from the third node based on the information of the write object and the read object included in the first transaction. The write object includes a first data item, the second node is the master node where the write object is located, and the third node is the master node where the read object is located. The modification module is used to modify the first data item to obtain the updated first data item; The sending module is used to send a write lock message to the second node and a read lock message to the third node. The read lock message is used to add a read lock to the read object and detect whether the read object read by the first node is correct. The submission module is used to submit the updated first data item to the second node and the fourth node when it receives a write lock success response from the second node and a read lock success response from the third node. The write lock success response indicates that the write object was successfully locked and the read object is correct. The read lock success response indicates that the read object was successfully locked and the read object is correct. The fourth node is a backup node for the write object.

16. The apparatus according to claim 15, characterized in that, The sending module is mainly used for: Send the write lock message to the second node, and simultaneously send the read lock message to the third node; Alternatively, send the write lock message to the second node; After sending the write lock message but before receiving the write lock success response, send the read lock message to the third node; Alternatively, the read lock message can be sent to the third node; After sending the read lock message but before receiving the read lock success response, send the write lock message to the second node.

17. The apparatus according to claim 15 or 16, characterized in that, The sending module is also used for: When the submission module submits the updated first data item to the second node and the fourth node, it sends a read lock release message to the third node. The read lock release message is used to instruct the third node to release the read lock of the read object.

18. The apparatus according to claim 15 or 16, characterized in that, The sending module is also used for: Upon receiving a write lock failure response from the second node and / or a read lock failure response from the third node, a process abort message is sent to the second node and the third node. The write lock failure response indicates that the write lock on the write object failed and / or the write object read by the first node is incorrect. The read lock failure response indicates that the read lock on the read object failed and / or the read object read by the first node is incorrect. The process abort message is used to indicate the abort of the processing of the first transaction, and the process abort message is also used to instruct the second node and the third node to unlock the object that was successfully locked.

19. The apparatus according to claim 15, characterized in that, The write object and the read object read by the first node both include a version value. The write lock message includes the version value of the write object read by the first node, and the read lock message includes the version value of the read object read by the first node. The correctness of the write object or the read object read by the first node means that the version value of the corresponding object read by the first node meets the verification condition.

20. The apparatus according to claim 19, characterized in that, The verification condition refers to the fact that the version value of the corresponding object read by the first node is an intermediate version value and the version value of the corresponding object in the corresponding master node is a stable version value corresponding to the version value of the corresponding object read by the first node, or the verification condition refers to the fact that the version value of the corresponding object read by the first node is a stable version value and the version value of the corresponding object in the corresponding master node is the same as the version value of the corresponding object read by the first node. The intermediate version value is used to indicate that the updated data item of the corresponding object has not been successfully submitted, and the stable version value is used to indicate that the updated data item of the corresponding object has been successfully submitted.

21. The apparatus according to claim 20, characterized in that, The write lock message also includes the updated first data item; the commit module is mainly used for: Send a main commit message to the second node and a backup commit message to the fourth node, wherein the backup commit message includes the updated first data item; Upon receiving a primary commit success response from the second node and a backup commit success response from the fourth node, it is determined that the updated first data item has been successfully committed. The primary commit success response is sent by the second node after updating the data item and the first version value of the stored write object based on the primary commit message and the updated first data item. The updated write object includes a second version value, which is the next intermediate version value of the first version value. The backup commit success response is sent by the fourth node after receiving the backup commit message.

22. The apparatus according to claim 21, characterized in that, The submission module is mainly used for: Send the main commit message to the second node, and simultaneously send the backup commit message to the fourth node; Alternatively, the backup commit message is sent to the fourth node, and the main commit message is sent to the second node after the backup commit message is sent but before a successful backup commit response is received. Alternatively, a main commit message can be sent to the second node, and the backup commit message can be sent to the fourth node before the main commit success response is received.

23. The apparatus according to claim 21, characterized in that, The sending module is also used for: If no primary commit success response is received from the second node and / or a backup commit success response is received from the fourth node, a process abort message is sent to the second node, the third node, and the fourth node. The process abort message is used to indicate the abort of the processing of the first transaction, and the process abort message is also used to instruct the second node and the third node to unlock the object that was successfully locked.

24. The apparatus according to claim 21 or 22, characterized in that, The sending module is also used for: Send a write lock release message to the second node. The write lock release message is used to instruct the second node to update the second version value to the third version value and release the write lock of the updated write object. The third version value is the stable version value corresponding to the second version value.

25. The apparatus according to claim 21 or 22, characterized in that, The sending module is also used for: Send a first deletion message to the second node, the first deletion message being used to instruct the second node to delete the write lock message and the main commit message; A second deletion message is sent to the fourth node, which instructs the fourth node to update the data items and first version value of the stored write object based on the backup commit message and delete the backup commit message.

26. A transaction processing apparatus, characterized in that, Applied to the first node, the device includes: The read module is used to read the write object from the second node and the read object from the third node based on the information of the write object and the read object included in the first transaction. Both the write object and the read object include a version value, and the write object includes a first data item. The second node is the master node where the write object is located, and the third node is the master node where the read object is located. The modification module is used to modify the first data item to obtain the updated first data item; The commit module is used to send a main commit message to the second node to commit the updated first data item and to the fourth node to commit the updated first data item when the write lock on the write object in the second node is successfully acquired and the write object and the read object read by the first node are both correct. The correctness of the write object or read object read by the first node means that the version value of the corresponding object read by the first node is an intermediate version value and the version value of the corresponding object in the corresponding master node is the stable version value corresponding to the version value read by the first node; or, the version value of the corresponding object read by the first node is a stable version value and the version value of the corresponding object in the corresponding master node is the same as the version value read by the first node. The intermediate version value indicates that the updated data item of the corresponding object has not been successfully committed, and the stable version value indicates that the updated data item of the corresponding object has been successfully committed. The fourth node is a backup node for the write object. The generation module is used to generate a transaction completion notification upon receiving a primary commit success response from the second node and a backup commit success response from the fourth node. The primary commit success response is sent by the second node after updating the data items and the first version value of the stored write object based on the primary commit message and the updated first data item. The updated write object includes a second version value, which is the next intermediate version value of the first version value. The backup commit success response is sent by the fourth node after receiving the backup commit message.

27. The apparatus according to claim 26, characterized in that, The submission module is mainly used for: Send the main commit message to the second node, and simultaneously send the backup commit message to the fourth node; Alternatively, the backup commit message is sent to the fourth node, and the main commit message is sent to the second node after the backup commit message is sent but before a successful backup commit response is received. Alternatively, a main commit message can be sent to the second node, and the backup commit message can be sent to the fourth node before the main commit success response is received.

28. The apparatus according to claim 26 or 27, characterized in that, The device further includes: The sending module is used to send a write lock release message to the second node. The write lock release message is used to instruct the second node to update the second version value to the third version value and release the write lock of the updated write object. The third version value is the stable version value corresponding to the second version value.

29. A node, characterized in that, The node includes a processor and a memory, the memory being used to store at least one program instruction or code, and the processor being used to execute the at least one program instruction or code stored in the memory to implement the transaction processing method according to any one of claims 1 to 11 or claims 12 to 14.

30. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the transaction processing method according to any one of claims 1 to 11 or 12 to 14.

Images