Transaction processing method, system, device and storage medium

Abstract

Embodiments of the present application provide a transaction processing method, system, device and storage medium. The method is suitable for a first computing node in a transaction system. The method comprises: after starting a first transaction, obtaining a transaction identifier of a second transaction involved in a latest modification of a first data object from a database; the first data object is an object to be accessed by the first transaction; obtaining target transaction state information from a memory of a second computing node processing the second transaction according to the transaction identifier; the transaction system comprises the second computing node; the memory of the second computing node stores transaction state information of transactions processed by the second computing node; and determining whether a modification result of the first data object by the second transaction is visible to the first transaction based on the target transaction state information. The technical solution provided by the embodiments of the present application can improve the performance of the transaction system.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a transaction processing method, system, device and storage medium. Background Technology

[0002] A transaction is a sequence of database operations that access and potentially manipulate various data objects (such as data records). These operations are either all executed or none are executed; it is an indivisible unit of work.

[0003] Transaction systems are the guarantee for achieving the ACID properties (atomicity, consistency, isolation, and durability) of databases. Their performance affects the response time and overall throughput of the entire transaction system for transaction processing. Summary of the Invention

[0004] This application provides a transaction processing method, system, device, and storage medium that can improve the performance of a transaction system.

[0005] Therefore, in one embodiment of this application, a transaction processing method is provided. The method is applicable to the first computing node in a transaction system;

[0006] The method includes:

[0007] After initiating the first transaction, retrieve the transaction identifier of the second transaction involved in the most recent modification of the first data object from the database; the first data object is the object to be accessed by the first transaction.

[0008] Based on the transaction identifier, the target transaction status information is obtained from the memory of the second computing node that processes the second transaction; the transaction system includes the second computing node; the memory of the second computing node stores the transaction status information of the transaction processed by the second computing node;

[0009] Based on the target transaction status information, determine whether the modification result of the second transaction on the first data object is visible to the first transaction.

[0010] In another embodiment of this application, a transaction system is provided. The transaction system includes: a plurality of computing nodes; the plurality of computing nodes includes a first computing node;

[0011] The first computing node is used for:

[0012] After initiating the first transaction, retrieve the transaction identifier of the second transaction involved in the most recent modification of the first data object from the database; the first data object is the object to be accessed by the first transaction.

[0013] Based on the transaction identifier, the target transaction status information is obtained from the memory of the second computing node that processes the second transaction; the transaction system includes the second computing node; the memory of the second computing node stores the transaction status information of the transaction processed by the second computing node;

[0014] Based on the target transaction status information, determine whether the modification result of the second transaction on the first data object is visible to the first transaction.

[0015] In another embodiment of this application, an electronic device is provided, comprising: a memory and a processor, wherein,

[0016] The memory is used to store programs;

[0017] The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps in the transaction processing method described above.

[0018] In another embodiment of this application, a computer-readable storage medium storing a computer program is provided, wherein the computer program, when executed by a computer, is capable of implementing the transaction processing method described above.

[0019] In the technical solution provided in this application embodiment, the computing node stores the transaction status of the transactions it processes locally in its local memory; one computing node can directly obtain the required transaction status information from the memory of another computing node. Compared with the prior art scheme of obtaining transaction status information by querying the rollback log on the disk of the storage node, disk operations can be avoided, which not only reduces the overhead of obtaining transaction status information, but also reduces transaction latency, thereby effectively improving the performance of the transaction system. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic diagram of the structure of a transaction system provided in an embodiment of this application;

[0022] Figure 2 A schematic flowchart illustrating a transaction processing method provided in an embodiment of this application;

[0023] Figure 3 This is another schematic flowchart illustrating a transaction processing method provided in an embodiment of this application;

[0024] Figure 4 This is a structural block diagram of a transaction processing apparatus provided in an embodiment of this application;

[0025] Figure 5 This is a structural block diagram of an electronic device provided in another embodiment of this application. Detailed Implementation

[0026] Currently, in existing transaction systems, the transaction status information of all transactions processed by computing nodes is stored in rollback logs, which need to be swapped to the disks of storage nodes. Therefore, after a computing node starts a transaction, it needs to query the rollback logs stored on the storage node's disk to obtain the transaction status information. This querying of the rollback logs on the storage node's disk incurs high overhead and time delays, resulting in low transaction processing efficiency and poor performance in the transaction system.

[0027] To address the aforementioned issues, this application provides a transaction processing method. In this method, a computing node stores the transaction state of the transactions it processes locally in its local memory; one computing node can directly obtain the required transaction state information from the memory of another computing node. Compared to existing solutions that require backtracking to the rollback logs on the storage node's disk to obtain transaction state information, this method avoids disk operations, reducing not only the overhead of obtaining transaction state information but also transaction latency, thereby effectively improving the performance of the transaction system.

[0028] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present application without creative effort are within the scope of protection of the present application.

[0029] Furthermore, some processes described in the specification, claims, and accompanying drawings of this application include multiple operations that appear in a specific order. These operations may be performed out of order or in parallel. Operation numbers such as 101, 102, etc., are merely used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be performed sequentially or in parallel. It should be noted that the terms "first," "second," etc., used herein are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0030] Before introducing the transaction processing method provided in the embodiments of this application, the transaction system involved in the method will be described. For example... Figure 1 As shown, the transaction processing system includes multiple computing nodes 20 and multiple storage nodes 30. Each computing node 20 is used to process its own transaction, which can specifically be a distributed transaction. The number of computing nodes 20 and the number of storage nodes 30 can be designed according to actual needs, and this embodiment does not specifically limit this. In this embodiment, the above-mentioned computing node 20 can be understood as a transaction coordination node, used to distribute transactions to the relevant storage nodes involved in the transaction for execution. In practical applications, the multiple computing nodes 20 may include one or more computing nodes that support read and write. In a one-write-multiple-read transaction system, the multiple computing nodes 20 include one computing node that supports read and write, and the others are computing nodes that only support read; in a multiple-write transaction system, the multiple computing nodes 20 may all be computing nodes that support read and write; or, the multiple computing nodes 20 may include multiple computing nodes that support read and write and at least one computing node that only supports read.

[0031] In one example, the transaction system includes multiple computing nodes; the multiple computing nodes include a first computing node;

[0032] Wherein, the first computing node is used for:

[0033] After initiating the first transaction, retrieve the transaction identifier of the second transaction involved in the most recent modification of the first data object from the database; the first data object is the object to be accessed by the first transaction.

[0034] Based on the transaction identifier, the target transaction status information is obtained from the memory of the second computing node that processes the second transaction; the transaction system includes the second computing node; the memory of the second computing node stores the transaction status information of the transaction processed by the second computing node;

[0035] Based on the target transaction status information, determine whether the modification result of the second transaction on the first data object is visible to the first transaction.

[0036] In another instance, such as Figure 1 As shown, the aforementioned transaction system may also include a time synchronization service node. Specifically, the time synchronization service node can be a server cluster, which improves the reliability of the time synchronization service provided by the time synchronization service node.

[0037] The data processing flow within each node of the above transaction system and the information interaction process between each node will be described in detail in the following embodiments.

[0038] Figure 2A flowchart illustrating a transaction processing method according to an embodiment of this application is shown. The method is applicable to the first computing node in a transaction system; that is, the execution subject of this method is the first computing node in the transaction system. Figure 2 The method includes:

[0039] 201. After starting the first transaction, retrieve the transaction identifier of the second transaction involved in the most recent modification of the first data object from the database.

[0040] The first data object is the object that the first transaction needs to access;

[0041] 202. Based on the transaction identifier, obtain the target transaction status information from the memory of the second computing node that is processing the second transaction.

[0042] The transaction system includes the second computing node; the memory of the second computing node stores the transaction status information of the transactions processed by the second computing node.

[0043] 203. Based on the target transaction status information, determine whether the modification result of the second transaction on the first data object is visible to the first transaction.

[0044] In step 201 above, after the first computing node initiates the first transaction, it can determine the first data object that the first transaction needs to access; then, it retrieves the transaction identifier of the second transaction involved in the most recent modification of the first data object from the database. Specifically, this database can be a distributed database, which is distributed across multiple storage nodes (e.g., ...). Figure 1 (As shown). The transaction identifier for the second transaction is generated by the second computing node that processes the second transaction.

[0045] In step 202 above, the memory of the second computing node stores transaction status information of the transactions processed by the second computing node. The first computing node can obtain the target transaction status information from the memory of the second computing node based on the transaction identifier.

[0046] The target transaction status information is stored in the memory of the second computing node before the first computing node obtains it.

[0047] In step 203 above, based on the target transaction status information, it is determined whether the modification result of the second transaction on the first data object is visible to the first transaction. Visibility determination ensures data consistency and transaction isolation among multiple nodes.

[0048] In the technical solution provided in this application embodiment, the computing node stores the transaction status of the transactions it processes locally in its local memory; one computing node can directly obtain the required transaction status information from the memory of another computing node. Compared with the prior art solution that requires backtracking to the rollback log on the disk where the database is located to obtain transaction status information, disk operations can be avoided, which not only reduces the overhead of obtaining transaction status information, but also reduces transaction latency, thereby effectively improving the performance of the transaction system.

[0049] In one feasible approach, the second computing node pre-allocates a first memory region for storing transaction status information; this first memory region stores the transaction status information of all active transactions on the second computing node. This ensures that other nodes can obtain the transaction status information of any active transaction on the second computing node. An active transaction refers to a transaction that has been started but not yet committed.

[0050] In one example, the phrase "obtain target transaction status information from the memory of the second computing node processing the second transaction according to the transaction identifier" in step 202 above specifically means: reading the target transaction status information from the memory of the second computing node processing the second transaction through a Remote Direct Data Access (RDMA) read operation according to the transaction identifier.

[0051] RDMA read operations are unilateral operations that do not require CPU involvement, reducing CPU waiting time. Therefore, RDMA read operations can quickly obtain non-local transaction status information, improving the efficiency of single-machine judgment of cross-machine transactions and thus improving the performance of the entire transaction system. It should be noted that a prerequisite for implementing RDMA read operations is that the transaction status information of the transaction processed by the second compute node is pre-stored in memory. Only then can the first compute node read the target transaction status information pre-stored in the second compute node's memory using RDMA read operations.

[0052] In practical applications, both the first and second computing nodes are equipped with RDMA network cards; the second computing node can pre-register the memory addresses of the first memory range to the RDMA network card it is equipped with. This pre-registration reduces the latency of obtaining transaction status.

[0053] Optionally, the step 202 above, "reading the target transaction status information from the memory of the second computing node processing the second transaction according to the transaction identifier," can be implemented using the following steps:

[0054] 2021. Based on the node identifier in the transaction identifier, determine the second computing node that processes the second transaction.

[0055] 2022. Based on the memory block identifier in the transaction identifier, read the target data in the memory block identified by the memory block identifier from the memory of the second computing node.

[0056] The target data includes the target transaction status information.

[0057] In the aforementioned 2021, the transaction identifier includes the node identifier of the second computing node processing the second transaction. Thus, the second computing node processing the second transaction can be determined based on the node identifier in the transaction identifier. Specifically, the node identifier can be a node ID number.

[0058] In the aforementioned 2022, the transaction identifier includes a memory block identifier in the memory of the second computing node used to store transaction status information of the second transaction. Based on the memory block identifier in the transaction identifier, the target data in the memory block identified by the memory block identifier is read from the memory of the second computing node. Specifically, based on the memory block identifier in the transaction identifier, the target data in the memory block identified by the memory block identifier can be read from the memory of the second computing node through a Remote Direct Data Access (RDMA) read operation.

[0059] Specifically, the memory block identifier can be the memory address of the aforementioned memory block.

[0060] In addition, the above methods may also include:

[0061] 204. Based on the number of write overwrites in the transaction identifier and the number of write overwrites in the target data, determine whether the target transaction status information is the transaction status information of the second transaction.

[0062] 205. When the target transaction status information is the transaction status information of the second transaction, the step of determining whether the modification result of the second transaction on the first data object is visible to the first transaction based on the target transaction status information is triggered.

[0063] In the above 204 scenario, in practical applications, once the transaction status information of a certain transaction stored in the memory block changes to a committed state, it may be overwritten by the transaction status of a new transaction. Each time the memory block is overwritten, the write overwrite count recorded in the memory block is updated accordingly. Therefore, it is necessary to determine whether the target transaction status information is the transaction status information of the second transaction based on the write overwrite count in the transaction identifier and the write overwrite count in the target data.

[0064] Specifically, if the write coverage count in the transaction identifier matches the write coverage count in the target data, the target transaction status information is determined to be the transaction status information of the second transaction. If the write coverage count in the transaction identifier does not match the write coverage count in the target data, the target transaction status information is determined not to be the transaction status information of the second transaction. Typically, if the two are inconsistent, it necessarily means that the write coverage count in the target data is greater than the write coverage count in the transaction identifier.

[0065] In step 205 above, when the target transaction status information is the transaction status information of the second transaction, the step of determining whether the modification result of the second transaction on the first data object is visible to the first transaction based on the target transaction status information is triggered.

[0066] In practical applications, the above methods may also include:

[0067] 206. When the target transaction status information is not the transaction status information of the second transaction, it is determined that the modification result of the second transaction on the first data object is visible to the first transaction.

[0068] Since the transaction status information of a certain transaction stored in the memory block may be overwritten by the transaction status of a new transaction after it becomes committed, the fact that the target transaction status information is not the same as the second transaction's indicates that the second transaction's transaction status has been overwritten, meaning the second transaction can be considered to have already been committed. Therefore, the modifications made by the second transaction to the first data object are visible to the first transaction.

[0069] In one example, the step 203 above, "based on the target transaction status information, determining whether the modification result of the second transaction on the first data object is visible to the first transaction," can be implemented using the following steps:

[0070] 2031. Determine whether the target transaction status information contains a transaction commit timestamp (CTS).

[0071] 2032. When the target transaction status information includes a transaction commit timestamp, based on the transaction commit timestamp and the creation timestamp of the read view corresponding to the first transaction, determine whether the modification result of the second transaction on the first data object is visible to the first transaction.

[0072] In section 2031 above, after a transaction is committed, a node can write the transaction commit timestamp to the memory block allocated for that transaction to store the transaction status information.

[0073] If the target transaction status information contains a transaction commit timestamp, it means that the second transaction has been committed; if the target transaction status information does not contain a transaction commit timestamp, it means that the second transaction has not been committed.

[0074] In the above 2032, when the target transaction status information includes a transaction commit timestamp, it is determined whether the modification result of the second transaction on the first data object is visible to the first transaction based on the transaction commit timestamp and the creation timestamp of the read view corresponding to the first transaction.

[0075] Specifically, the step 2032 above, "determining whether the modification result of the second transaction on the first data object is visible to the first transaction based on the transaction commit timestamp and the creation timestamp of the read view corresponding to the first transaction," can be implemented using the following steps:

[0076] S11. The transaction commit timestamp is earlier than the creation timestamp, thus determining that the modification result of the second transaction on the first data object is visible to the first transaction.

[0077] S12. The transaction commit timestamp is later than the creation timestamp, and it is determined that the modification result of the second transaction on the first data object is not visible to the first transaction.

[0078] In S11 above, the transaction commit timestamp is earlier than the creation timestamp, indicating that the second transaction was committed before the first transaction accessed the first data object. Therefore, the modification results of the second transaction on the first data object are visible to the first transaction.

[0079] In S12 above, the transaction commit timestamp is later than the creation timestamp, indicating that the second transaction is committed after the first transaction accesses the first data object. Therefore, the modification results of the second transaction on the first data object are not visible to the first transaction.

[0080] Furthermore, step 203 above, "based on the target transaction status information, determining whether the modification result of the second transaction on the first data object is visible to the first transaction," may further include the following steps:

[0081] S13. When the target transaction status information does not contain a transaction commit timestamp, it is determined that the modification result of the second transaction on the first data object is not visible to the first transaction.

[0082] In S13 above, the target transaction status information does not include a transaction commit timestamp, indicating that the second transaction has not yet been committed. Therefore, the modification result of the second transaction on the first data object is not visible to the first transaction.

[0083] In one feasible solution, such as Figure 1 As shown, the transaction system further includes a time synchronization service node 10; the method further includes:

[0084] 207. When creating the read view corresponding to the first transaction, obtain the creation timestamp corresponding to the read view from the time synchronization service node.

[0085] The transaction commit timestamp of the second transaction is obtained by the second computing node from the time synchronization service node when the second transaction commits.

[0086] In step 207 above, when creating the read view corresponding to the first transaction, that is, when the first compute node executes the select statement of the first transaction, it obtains the creation timestamp corresponding to the read view from the time synchronization service node. Each node accesses the time synchronization service node to obtain the global timestamp, which can guarantee the transaction order of the entire one-write-many-read or many-write transaction system and is a guarantee for providing a globally consistent view.

[0087] To reduce latency and improve efficiency, the phrase "when creating the read view corresponding to the first transaction, obtain the creation timestamp corresponding to the read view from the time synchronization service node" in section 207 above may specifically include:

[0088] 2071. When creating the read view corresponding to the first transaction, an atomic operation is added based on the RDMA read to obtain the global maximum timestamp stored in the memory of the time synchronization service node, which is used as the creation timestamp corresponding to the read view.

[0089] The first compute node retrieves the global maximum timestamp from the time service node's memory via an RDMA read-add atomic operation (fetch and add, FAD). After the RDMA read-add atomic operation, the global maximum timestamp automatically increments, and the increment can be set according to actual needs, for example, by 1.

[0090] RDMA read-add atomic operations are also one-sided operations, requiring no CPU involvement and reducing CPU wait time. Therefore, RDMA read-add atomic operations can quickly obtain timestamps, improving efficiency, reducing latency, and thus improving the overall performance of the transaction system. It should be noted that a prerequisite for implementing RDMA read-add atomic operations is that the global maximum timestamp on the time synchronization service node is pre-stored in memory. This allows the first compute node to read the global maximum timestamp pre-stored in the time synchronization service node's memory via RDMA read-add atomic operations.

[0091] When the second computing node executes the commit operation of the second transaction, it can also read the global maximum timestamp from the memory of the time synchronization service node through an RDMA read atomic operation to use it as the transaction commit timestamp of the second transaction. Specifically, the first computing node, the second computing node, and the time synchronization service node are each equipped with an RDMA network card; the time synchronization service node can pre-register the memory address of the second memory range used to store the global maximum timestamp to the RDMA network card it is equipped with.

[0092] In practical applications, nodes can choose whether to write the transaction's commit timestamp to the database of the data objects accessed by the transaction during the transaction commit phase. If written, subsequent transactions on other nodes can directly determine visibility based on the commit timestamp in the data object when they need to access these data objects, reducing transaction latency caused by cross-machine retrieval of transaction status information. For example: when a transaction modifies a small number of data objects, it can choose to write the transaction's commit timestamp to each modified data object in the database during the transaction commit phase; when a transaction modifies a large number of data objects, writing the transaction's commit timestamp to all modified data objects in the database would take a lot of time, causing severe transaction latency. Therefore, it can choose to write the transaction's commit timestamp to only some modified data objects in the database, or not write it to any of them and directly complete the commit operation.

[0093] Therefore, the above method may also include:

[0094] 208. After starting the first transaction, determine whether the first data object records a transaction commit timestamp.

[0095] 209. If the first data object records a transaction commit timestamp, then based on the transaction commit timestamp and the creation timestamp of the read view corresponding to the first transaction, determine whether the modification result of the second transaction on the first data object is visible to the first transaction.

[0096] The specific implementation of the step of determining whether the modification result of the second transaction on the first data object is visible to the first transaction based on the transaction commit timestamp and the creation timestamp of the read view corresponding to the first transaction can be found in the corresponding content of the above embodiments, and will not be repeated here.

[0097] Optionally, the above method may also include:

[0098] 210. If the first data object does not record a transaction commit timestamp, then the step of obtaining the transaction identifier of the second transaction involved in the most recent modification of the first data object from the database is triggered.

[0099] It should be added that, in step 204 above, when it is determined that the target transaction status information is not the transaction status information of the second transaction, the creation timestamp of the earliest current version of the first data object (i.e., the earliest readview) can be asynchronously filled into the first data object in the database. This allows other nodes to directly perform visibility checks when accessing the first data object, avoiding cross-machine access. The purpose of selecting the earliest current version creation timestamp of the first data object is to ensure that the modification results of the second transaction on the first data object are visible to all active transactions in the current system. In addition to filling in the earliest current version creation timestamp of the first data object, a specific dummy (DUMMY) value can also be selected. The size of the dummy value can be designed according to actual needs, as long as it ensures that the modification results of the second transaction on the first data object are visible to all active transactions in the current system.

[0100] In practical applications, the above methods may also include:

[0101] 211. After starting the first transaction, search for available memory blocks in the third memory region pre-allocated on the first computing node for storing transaction status information.

[0102] The available memory block refers to a memory block that does not store transaction status information or whose stored transaction status information indicates that the transaction has been committed.

[0103] 212. Update the write overwrite count recorded in the available memory block.

[0104] 213. Allocate the available memory block to the first transaction to store the transaction status information of the first transaction.

[0105] When allocating available memory blocks to the first transaction, there is no need to allocate them in strict order, so that more active transactions can be accommodated in a smaller space.

[0106] The following will combine Figure 3 The transaction processing method provided in the embodiments of this application will be described in detail below:

[0107] Step 1: After the first compute node (which can be a read-write node, i.e., master) starts the first transaction, it searches for available memory blocks in the third memory region pre-allocated on the first compute node for storing transaction status information.

[0108] The available memory block refers to a memory block that does not store transaction status information or whose stored transaction status information indicates that the transaction has been committed. The third memory region is used to store the CTS log, and the available memory block is also a slot in the CTS log.

[0109] Step 2: The first compute node updates the write overwrite count recorded in the available memory block (wrap#).

[0110] Step 3: Allocate the available memory block to the first transaction to store the transaction status information of the first transaction, that is, the transaction commit timestamp of the first transaction, and generate the transaction identifier trx_id of the first transaction based on the node identifier master_id of the first computing node, the slot identifier cts_log_slot (that is, the memory block identifier in the above embodiment) and the write overwrite count wrap#.

[0111] Each slot can record the transaction commit timestamp (CTS) and write overwrite count (wrap#) of the corresponding transaction, as well as the transaction pointer (trx_t*). The transaction pointer (trx_t*) points to a transaction structure, which stores relevant information about the corresponding transaction.

[0112] Step 4: When the first compute node executes the select statement of the first transaction, it reads the global maximum timestamp from the memory of the time service node through RDMA read and adds an atomic operation, so as to use it as the creation timestamp of the read view corresponding to the first transaction.

[0113] Step 5: The first compute node determines whether the first data object in the database records a transaction commit timestamp.

[0114] The first data object is the object that the first transaction needs to access.

[0115] If there is a record, proceed to step 6; otherwise, proceed to step 7.

[0116] Step 6: Based on the transaction commit timestamp and the creation timestamp of the read view corresponding to the first transaction, determine whether the modification result of the second transaction on the first data object is visible to the first transaction.

[0117] Step 7: Retrieve the transaction identifier of the second transaction involved in the most recent modification of the first data object from the database.

[0118] Step 8: Determine the second computing node for processing the second transaction based on the node identifier in the transaction identifier.

[0119] If the determined second computing node is the same as the first computing node, then proceed to step 9a; if the determined second computing node is a different node from the first computing node, then proceed to step 9b.

[0120] Step 9a: Based on the memory block identifier in the transaction identifier, directly read the target data in the memory block identified by the memory block identifier from the memory of the second computing node.

[0121] Step 9b: Based on the memory block identifier in the transaction identifier, read the target data in the memory block identified by the memory block identifier from the memory of the second computing node through an RDMA read operation.

[0122] The target data includes the target transaction status information.

[0123] Step 10: Determine whether the target transaction status information is the transaction status information of the second transaction based on the write overwrite count in the transaction identifier and the write overwrite count in the target data.

[0124] If yes, proceed to step 11; otherwise, proceed to step 12.

[0125] Step 11: Determine whether the target transaction status information contains a transaction commit timestamp.

[0126] Yes, proceed to step 6 above; no, proceed to step 13.

[0127] Step 12: Determine that the modification result of the second transaction on the first data object is visible to the first transaction.

[0128] Step 13: Determine that the modification result of the second transaction on the first data object is not visible to the first transaction.

[0129] It's important to note that when any transaction begins modifying a data object in the database, the database writes the transaction ID of that transaction into that data object. After any transaction commits, its commit timestamp is written to the slot allocated to that transaction. Whether the commit timestamp is written to the data object is determined according to a preset strategy. Specifically, after a transaction commits, based on the data pages and record list (i.e., the data object list) recorded in the transaction, a preset strategy determines whether to backfill the transaction's commit timestamp (CTS) into the corresponding data pages and record lists.

[0130] Compared with the prior art, the technical solution provided in this application has the following beneficial effects:

[0131] 1. In a distributed transaction system, the CTS_LOG, which manages the transaction status information on each computing node, is stored in memory. When allocating CTS LOG slots, there is no need to strictly follow the order. More active transactions can be accommodated in a smaller space, and the status of active transactions will not be swapped to disk. This ensures that the transaction status can be quickly determined.

[0132] 2. Through RDMA technology, the memory address of the memory range for managing transaction status information of each computing node is pre-registered in RDMA. In this way, it is possible to access the transaction status information of other computing nodes remotely through RDMA read operations (One-side Remote Atomic Read). This helps to reduce or even avoid interference with the CPU operation of participating computing nodes, shortens transaction response time, and improves transaction processing efficiency.

[0133] 3. Each compute node uses RDMA reads followed by atomic operations to access the Time Service Node (TSO) to quickly obtain the global Time Service Node (CTS), ensuring the transaction order of the entire multi-write transaction system and providing a globally consistent view. Furthermore, the technical solution provided in this application implements a lightweight design for the global management node, which acts as the TSO. All compute nodes only obtain the CTS when committing a transaction and creating a read view, and these are all RDMA reads followed by atomic operations.

[0134] 4. When there are no conflicts in the transaction, that is, when there is no need to access the transaction state across machines, the performance degradation is very small.

[0135] In summary, the embodiments of this application solve a series of problems related to transaction state synchronization and querying in a database multi-write architecture by adopting a combination of in-memory transaction state information, RDMA one-sided operation, and transaction state information sinking (that is, writing the transaction commit timestamp into the corresponding data object in the database).

[0136] Figure 4 A structural block diagram of a transaction processing apparatus according to another embodiment of this application is shown. This apparatus is applied to the first computing node in a transaction system. Figure 5 As shown, the device includes:

[0137] The first acquisition module 401 is used to retrieve the transaction identifier of the second transaction involved in the most recent modification of the first data object from the database after the first transaction is started; the first data object is the object to be accessed by the first transaction.

[0138] The second acquisition module 402 is used to acquire target transaction status information from the memory of the second computing node that processes the second transaction according to the transaction identifier; the transaction system includes the second computing node; the memory of the second computing node stores the transaction status information of the transaction processed by the second computing node;

[0139] The first determining module 403 is used to determine, based on the target transaction status information, whether the modification result of the second transaction on the first data object is visible to the first transaction.

[0140] Optionally, the second computing node has a first memory region pre-allocated in its memory for storing transaction status information;

[0141] The first memory region stores the transaction status information of all active transactions on the second computing node.

[0142] Optionally, the second acquisition module 402 is specifically used for:

[0143] Based on the transaction identifier, the target transaction status information is read from the memory of the second computing node that is processing the second transaction through a Remote Direct Data Access (RDMA) read operation.

[0144] Optionally, the first computing node and the second computing node are each equipped with an RDMA network card;

[0145] The second computing node pre-registers the memory addresses of the first memory range to the RDMA network card configured on it.

[0146] Optionally, the second acquisition module 402 is specifically used for:

[0147] The second computing node for processing the second transaction is determined based on the node identifier in the transaction identifier;

[0148] Based on the memory block identifier in the transaction identifier, read the target data from the memory block identified by the memory block identifier from the memory of the second computing node;

[0149] The target data includes the target transaction status information.

[0150] Optionally, the above-mentioned device further includes:

[0151] The second determining module is used to determine whether the target transaction status information is the transaction status information of the second transaction based on the write overwrite count in the transaction identifier and the write overwrite count in the target data.

[0152] The first triggering module is used to trigger the step of determining whether the modification result of the second transaction on the first data object is visible to the first transaction based on the target transaction status information when the target transaction status information is the transaction status information of the second transaction.

[0153] Optionally, the first determining module 403 is further configured to:

[0154] When the target transaction status information is not the transaction status information of the second transaction, it is determined that the modification result of the second transaction on the first data object is visible to the first transaction.

[0155] Optionally, the first determining module 403 is specifically used for:

[0156] Determine whether the target transaction status information contains a transaction commit timestamp;

[0157] When the target transaction status information includes a transaction commit timestamp, based on the transaction commit timestamp and the creation timestamp of the read view corresponding to the first transaction, it is determined whether the modification result of the second transaction on the first data object is visible to the first transaction.

[0158] Optionally, the transaction system may also include a time synchronization service node;

[0159] The device further includes:

[0160] The third acquisition module is used to obtain the creation timestamp corresponding to the read view from the time synchronization service node when creating the read view corresponding to the first transaction.

[0161] The transaction commit timestamp of the second transaction is obtained by the second computing node from the time synchronization service node when the second transaction commits.

[0162] Optionally, the above-mentioned device further includes:

[0163] The third determination module is used to determine whether the first data object contains a transaction commit timestamp after the first transaction is started.

[0164] The first determining module is further configured to, if the first data object records a transaction commit timestamp, determine whether the modification result of the second transaction on the first data object is visible to the first transaction based on the transaction commit timestamp and the creation timestamp of the read view corresponding to the first transaction.

[0165] Optionally, the above-mentioned device further includes:

[0166] The second triggering module is used to trigger the step of obtaining the transaction identifier of the second transaction involved in the most recent modification of the first data object from the database if the first data object does not record a transaction commit timestamp.

[0167] Optionally, the above-mentioned device further includes:

[0168] The query module is used to search for available memory blocks in the third memory range pre-allocated on the first computing node for storing transaction status information after the first transaction is started; the available memory blocks refer to memory blocks that do not store transaction status information or whose stored transaction status information is in the transaction commit completed state.

[0169] The update module is used to update the write overwrite count recorded within the available memory block;

[0170] The allocation module is used to allocate the available memory block to the first transaction for storing the transaction status information of the first transaction.

[0171] It should be noted that the transaction processing apparatus provided in the above embodiments can implement the technical solutions described in the above method embodiments. The specific implementation principles of the above modules or units can be found in the corresponding contents of the above method embodiments, and will not be repeated here.

[0172] Figure 5 A schematic diagram of the structure of an electronic device according to an embodiment of this application is shown. Figure 5 As shown, the electronic device includes a memory 1101 and a processor 1102. The memory 1101 can be configured to store various other data to support operation on the electronic device. Examples of such data include instructions for any application or method used to operate on the electronic device. The memory 1101 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0173] The memory 1101 is used to store programs;

[0174] The processor 1102 is coupled to the memory 1101 and is used to execute the program stored in the memory 1101 to implement the transaction processing method provided in the above-described method embodiments.

[0175] Furthermore, such as Figure 5 As shown, the electronic device also includes: communication component 1103, display 1104, power supply component 1105, audio component 1106, and other components. Figure 5 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 5 The components shown.

[0176] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a computer, can implement the steps or functions of the transaction processing methods provided in the above-described method embodiments.

[0177] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0178] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0179] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A transaction processing method, wherein, The method is applicable to the first computing node in a transaction system, including: After initiating the first transaction, the transaction identifier of the second transaction involved in the most recent modification of the first data object is obtained from the database; the first data object is the object to be accessed by the first transaction; the transaction identifier includes the memory address of the target memory block and the first write overwrite count; According to the transaction identifier, target data is obtained from the target memory block of the second computing node processing the second transaction through a Remote Direct Data Access (RDMA) read operation. The target data includes target transaction status information and a second write overwrite count. The transaction system includes the second computing node. The memory of the second computing node stores the transaction status information of the transaction processed by the second computing node. The target transaction status information is stored in the memory of the second computing node before the first computing node obtains it. If the first write overwrite count is the same as the second write overwrite count, the target transaction status information is determined to be the transaction status information of the second transaction, and based on the target transaction status information, it is determined whether the modification result of the second transaction on the first data object is visible to the first transaction. Otherwise, it is determined that the target transaction status information is not the transaction status information of the second transaction, and it is determined that the modification result of the second transaction on the first data object is visible to the first transaction; Specifically, when the transaction status information stored in the target memory block indicates that the transaction has been committed, the target memory block can be reused by a new transaction. When the target memory block is reused by a new transaction, the second write overwrite count is updated.

2. The method according to claim 1, wherein, The second computing node has a first memory region pre-allocated in its memory for storing transaction status information; The first memory region stores the transaction status information of all active transactions on the second computing node.

3. The method according to claim 2, wherein, Both the first computing node and the second computing node are equipped with RDMA network cards; The second computing node pre-registers the memory addresses of the first memory range to the RDMA network card configured on it.

4. The method according to any one of claims 1 to 3, wherein, Based on the transaction identifier, the target data is obtained from the target memory block of the second computing node processing the second transaction via a Remote Direct Data Access (RDMA) read operation, including: The second computing node for processing the second transaction is determined based on the node identifier in the transaction identifier; Based on the memory block identifier in the transaction identifier, the target data in the memory block identified by the memory block identifier is read from the memory of the second computing node.

5. The method according to any one of claims 1 to 3, wherein, Based on the target transaction status information, determining whether the modification result of the second transaction on the first data object is visible to the first transaction includes: Determine whether the target transaction status information contains a transaction commit timestamp; When the target transaction status information includes a transaction commit timestamp, based on the transaction commit timestamp and the creation timestamp of the read view corresponding to the first transaction, it is determined whether the modification result of the second transaction on the first data object is visible to the first transaction.

6. The method according to claim 5, wherein, Determining whether the modification result of the second transaction on the first data object is visible to the first transaction based on the target transaction status information further includes: When the target transaction status information does not contain a transaction commit timestamp, it is determined that the modification result of the second transaction on the first data object is not visible to the first transaction.

7. The method according to claim 5, wherein, The transaction system also includes a time synchronization service node; The method further includes: When creating the read view corresponding to the first transaction, the creation timestamp corresponding to the read view is obtained from the time synchronization service node; The transaction commit timestamp of the second transaction is obtained by the second computing node from the time synchronization service node when the second transaction commits.

8. The method according to claim 7, wherein, When creating the read view corresponding to the first transaction, the creation timestamp corresponding to the read view is obtained from the time synchronization service node, including: When creating the read view corresponding to the first transaction, an atomic operation is added based on the RDMA read to obtain the global maximum timestamp stored in the memory of the time service node, which is used as the creation timestamp corresponding to the read view.

9. A transaction system, wherein, include: Multiple computing nodes; The plurality of computing nodes includes a first computing node; The first computing node is used for: After initiating the first transaction, the transaction identifier of the second transaction involved in the most recent modification of the first data object is obtained from the database; the first data object is the object to be accessed by the first transaction; the transaction identifier includes the memory address of the target memory block and the first write overwrite count; According to the transaction identifier, target data is obtained from the target memory block of the second computing node processing the second transaction through a Remote Direct Data Access (RDMA) read operation. The target data includes target transaction status information and a second write overwrite count. The transaction system includes the second computing node. The memory of the second computing node stores the transaction status information of the transaction processed by the second computing node. The target transaction status information is stored in the memory of the second computing node before the first computing node obtains it. If the first write overwrite count is the same as the second write overwrite count, the target transaction status information is determined to be the transaction status information of the second transaction, and based on the target transaction status information, it is determined whether the modification result of the second transaction on the first data object is visible to the first transaction. Otherwise, it is determined that the target transaction status information is not the transaction status information of the second transaction, and it is determined that the modification result of the second transaction on the first data object is visible to the first transaction; Specifically, when the transaction status information stored in the target memory block indicates that the transaction has been committed, the target memory block can be reused by a new transaction. When the target memory block is reused by a new transaction, the second write overwrite count is updated.

10. An electronic device, wherein, include: Memory and processor, among which, The memory is used to store programs; The processor, coupled to the memory, is configured to execute the program stored in the memory to implement the steps of the transaction processing method according to any one of claims 1 to 8.

11. A computer-readable storage medium storing a computer program, wherein, When the computer program is executed by a computer, it can implement the steps in the transaction processing method of any one of claims 1 to 8.

Images