Transaction processing method and device for multi-version concurrency control and computer equipment

Abstract

The invention relates to a transaction processing method and device for multi-version concurrency control and computer equipment. The method comprises the steps of obtaining a data version information table under the condition that a transaction processing request is received; the data version information table comprises a historical version identifier and a historical transaction identifier; determining at least one candidate version identifier from the data version information table according to a transaction isolation rule; determining a target version identifier from the at least one candidate version identifier based on the transaction processing request and the transaction correlation between the historical transaction requests of the historical transaction identifiers; sending the transaction processing request and the target version identifier to a transaction execution node corresponding to the transaction processing request so as to indicate the transaction execution node to perform transaction processing on the original data according to the transaction processing request, and obtaining and returning target data; and the target data is received, and the transaction processing result of the transaction processing request is obtained according to the target data, so that the transaction processing precision and accuracy are improved.

Description

Technical Field

[0001] The present application relates to the field of transaction processing technology, and in particular to a transaction processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product for multi-version concurrent control. Background Art

[0002] In modern distributed systems, data consistency and transaction management are key issues to ensure system reliability and efficiency. As the scale of the system expands and the complexity of business increases, transaction processing across multiple nodes becomes particularly important. For example, in power grid systems, scenarios such as real-time updates of substation load data require efficient and reliable transaction processing mechanisms, which usually require coordinating transactions between multiple nodes to ensure data consistency and integrity while optimizing concurrent processing and system performance.

[0003] In order to support concurrent reading and writing of transactions, database management systems usually use multi-version concurrency control technology, combined with lock-based mechanisms to lock and unlock during transaction execution to ensure data consistency and isolation. However, in scenarios with high concurrency or high conflicts, transactions need to be frequently rolled back and retried due to factors such as lock conflicts, which increases the complexity and overhead of the system and reduces transaction processing efficiency. Summary of the invention

[0004] Based on this, it is necessary to provide a transaction processing method, device, computer equipment, computer-readable storage medium and computer program product for multi-version concurrency control that can improve the transaction processing efficiency of the system in high concurrency scenarios in response to the above technical problems.

[0005] In a first aspect, the present application provides a transaction processing method for multi-version concurrency control, the method comprising:

[0006] When a transaction processing request is received, a data version information table is obtained; the data version information table includes a historical version identifier representing the version to which the data belongs and a historical transaction identifier corresponding to the historical version identifier;

[0007] According to the transaction isolation rule, at least one candidate version identifier matching the target transaction identifier of the transaction processing request is determined from the data version information table; the data under the version identified by the at least one candidate version identifier supports transaction processing according to the transaction processing request;

[0008] determining a target version identifier from the at least one candidate version identifier based on a transaction correlation between the transaction processing request and the historical transaction requests of each of the historical transaction identifiers;

[0009] Sending the transaction processing request and the target version identifier to at least one transaction execution node corresponding to the transaction processing request, so as to instruct the at least one transaction execution node to perform transaction processing on the original data according to the transaction processing request, and obtain and return the target data, wherein the original data belongs to the version identified by the target version identifier;

[0010] Receive the target data returned by each of the at least one transaction execution nodes, and obtain the transaction processing result of the transaction processing request according to the target data returned by each of the at least one transaction execution nodes.

[0011] In one of the embodiments, determining the target version identifier from the at least one candidate version identifier based on the transaction correlation between the transaction processing request and the historical transaction requests of each of the historical transaction identifiers includes:

[0012] Performing transaction correlation analysis on the transaction processing request and the historical transaction requests of each of the historical transaction identifiers to obtain a correlation analysis result between the transaction processing request and the historical transaction requests of each of the historical transaction identifiers;

[0013] According to the correlation analysis result and each of the historical transaction identifiers, a target version identifier is determined from the at least one candidate version identifier.

[0014] In one of the embodiments, determining at least one candidate version identifier that matches the target transaction identifier of the transaction processing request from the data version information table according to the transaction isolation rule includes:

[0015] Using the historical transaction identifier as an index, traverse each of the historical version identifiers in the data version information table;

[0016] For each of the historical version identifiers, according to the transaction isolation rule, determining a matching result of processing the data under the identified version of the historical version identifier according to the transaction processing request;

[0017] When the matching result indicates that the data under the version identified by the historical version identifier supports processing according to the transaction processing request, the historical version identifier is determined as a candidate version identifier that matches the target transaction identifier.

[0018] In one embodiment, the method further comprises:

[0019] Sending a status judgment instruction to the at least one transaction execution node respectively, so as to instruct the at least one transaction execution node to judge the processing status of the transaction processing request of the local end, and return respective status judgment results;

[0020] Receive the respective status judgment results returned by the at least one transaction execution node, and when the respective status judgment results returned by the at least one transaction execution node meet the data submission trigger condition, send data submission instructions to the at least one transaction execution node respectively to instruct the at least one transaction execution node to return the respective target data.

[0021] In one embodiment, before sending the data pre-commit instruction to the at least one transaction execution node respectively, the method further includes:

[0022] Sending execution condition judgment instructions to the at least one transaction execution node respectively, so as to instruct the at least one transaction execution node to judge the execution condition of the transaction processing request of the local end, and return respective execution condition judgment results;

[0023] When the execution condition judgment result returned by the at least one transaction execution node meets the state judgment triggering condition, a state judgment instruction is generated.

[0024] In one embodiment, the method further comprises:

[0025] When the respective target data returned by the at least one transaction execution node is successfully received, a data update instruction is sent to the at least one transaction execution node to instruct the at least one transaction execution node to update the original data according to the target data.

[0026] In one embodiment, the data update instruction is further used to instruct the at least one transaction execution node to return a data update result; the method further includes:

[0027] In a case where the received data update result satisfies a data synchronization trigger condition, determining at least one associated transaction associated with the current transaction corresponding to the transaction processing request, and determining an associated transaction node corresponding to the at least one associated transaction;

[0028] The target data and data synchronization instructions are sent to each of the associated transaction nodes according to a preset synchronization rule, so as to instruct each of the transaction execution nodes to update their corresponding original data according to the target data.

[0029] In a second aspect, the present application further provides a transaction processing device for multi-version concurrency control, the device comprising:

[0030] An information acquisition module is used to acquire a data version information table when a transaction processing request is received; the data version information table includes a historical version identifier representing the version to which the data belongs and a historical transaction identifier corresponding to the historical version identifier;

[0031] A version screening module, configured to determine, according to a transaction isolation rule, at least one candidate version identifier that matches a target transaction identifier of the transaction processing request from the data version information table; the data under the version identified by the at least one candidate version identifier supports transaction processing according to the transaction processing request.

[0032] A version determination module, configured to determine a target version identifier from the at least one candidate version identifier based on the transaction correlation between the transaction processing request and the historical transaction requests of each of the historical transaction identifiers.

[0033] An information sending module, configured to send the transaction processing request and the target version identifier to at least one transaction execution node corresponding to the transaction processing request, so as to instruct the at least one transaction execution node to perform transaction processing on the original data according to the transaction processing request respectively, obtain and return target data, where the original data belongs to the version identified by the target version identifier.

[0034] A result determination module, configured to receive the target data returned by each of the at least one transaction execution node, and obtain a transaction processing result of the transaction processing request according to the target data returned by each of the at least one transaction execution node.

[0035] In a third aspect, the present application further provides a computer device, including a memory and a processor, where the memory stores a computer program, and when the processor executes the computer program, the steps of the above method are implemented.

[0036] In a fourth aspect, the present application further provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the above method are implemented.

[0037] In a fifth aspect, the present application further provides a computer program product, including a computer program, and when the computer program is executed by a processor, the steps of the above method are implemented.

[0038] The transaction processing method, apparatus, computer device, computer-readable storage medium and computer program product for multi-version concurrent control described above obtain a data version information table upon receiving a transaction processing request; the data version information table includes a historical version identifier representing the version to which the data belongs and a historical transaction identifier corresponding to the historical version identifier; according to the transaction isolation rule, at least one candidate version identifier matching the target transaction identifier of the transaction processing request is determined from the data version information table; based on the transaction correlation between the transaction processing request and the historical transaction requests of each historical transaction identifier, the target version identifier is determined from at least one candidate version identifier; the transaction processing request and the target version identifier are sent to at least one transaction execution node corresponding to the transaction processing request to instruct at least one transaction execution node to perform transaction processing on the original data according to the transaction processing request, obtain and return the target data, and the original data belongs to the version identified by the target version identifier; and the at least one transaction execution node receives the response from each of the at least one transaction execution nodes. , and obtain the transaction processing result of the transaction processing request according to the target data returned by at least one transaction execution node; in the transaction processing process, the target transaction and the historical transaction are identified by the transaction identifier to determine the historical version identifier corresponding to each transaction, and the transaction isolation rule is combined to determine whether to support targeted processing of the data under the version identified by each historical version identifier according to the transaction processing request to determine at least one candidate version identifier, and based on the correlation between the historical transaction corresponding to the data under the version identified by the candidate version identifier and the current transaction corresponding to the transaction processing request, the target version identifier is determined, so that at least one transaction execution node obtains the original data according to the target version identifier and processes it. On the one hand, it can ensure that the transaction obtains a consistent data version during the execution process to reduce conflicts between transactions. On the other hand, it can also consider the correlation between transactions to improve the processing precision and accuracy of transactions, thereby improving the overall performance of the database system for transaction processing. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0040] Figure 1 An application environment diagram of a transaction processing method for multi-version concurrent control in one embodiment;

[0041] Figure 2 A flowchart of a transaction processing method for multi-version concurrent control in one embodiment;

[0042] Figure 3 A flowchart of a transaction processing method for multi-version concurrent control in another embodiment;

[0043] Figure 4 It is a structural block diagram of a transaction processing device for multi-version concurrent control in one embodiment;

[0044] Figure 5 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0045] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0046] The transaction processing method for multi-version concurrency control provided in the embodiment of the present application can be applied to Figure 1 In the application environment shown, the transaction execution node 102 communicates with the server 104 through the network. The data storage system can store data that the server 104 needs to process. The data storage system can be integrated on the server 104, or placed on the cloud or other network servers. The server 104 responds to a transaction processing request from a client or other application, and upon receiving the transaction processing request, obtains a data version information table; the data version information table includes a historical version identifier representing the version to which the data belongs and a historical transaction identifier corresponding to the historical version identifier; then, the server 104 determines at least one candidate version identifier that matches the target transaction identifier of the transaction processing request from the data version information table in accordance with the transaction isolation rule, and determines the target version identifier from the at least one candidate version identifier based on the transaction correlation between the transaction processing request and the historical transaction requests of each historical transaction identifier; then, the server 104 sends the transaction processing request and the target version identifier to at least one transaction execution node corresponding to the transaction processing request, so as to instruct the at least one transaction execution node to perform transaction processing on the original data in accordance with the transaction processing request, obtain and return the target data, and the original data belongs to the version identified by the target version identifier; finally, the server 104 receives the target data returned by each of the at least one transaction execution nodes, and obtains the transaction processing result of the transaction processing request according to the target data returned by each of the at least one transaction execution nodes.

[0047] The data processing node 102 may be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, IoT devices, and portable wearable devices. The IoT devices may be smart speakers, smart TVs, smart air conditioners, smart vehicle-mounted devices, projection devices, etc., or data computing nodes deployed in the aforementioned devices or deployed as computing nodes in a distributed database. Portable wearable devices may be smart watches, smart bracelets, head-mounted devices, etc. The head-mounted devices may be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. The server 104 may be an independent physical server, or a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides cloud computing services.

[0048] In one embodiment, Figure 2 As shown, a transaction processing method for multi-version concurrency control is provided, and the method is applied to Figure 1 The server 104 in FIG. 1 is used as an example to illustrate. It is understandable that the method can also be applied to Figure 1 The transaction execution node 102 in the embodiment can also be applied to a system including the transaction execution node 102 and the server 104, and is implemented through the interaction between the transaction execution node 102 and the server 104. The method of this embodiment includes the following steps 201 to 205. Among them:

[0049] Step 201: upon receiving a transaction processing request, obtain a data version information table.

[0050] Among them, a transaction request refers to a set of atomic operation instructions from a client or other application to perform a certain business operation (such as query, change, add, delete, etc.) on the data in the database. These operation instructions are required to be either all successfully executed to ensure data consistency, or all rolled back in the event of an error to ensure that the data is not in an inconsistent state. The database can be of various types, such as a relational database, a non-relational database, an object database, a distributed database, a parallel database, a cloud database, and a data warehouse; this embodiment is described by taking a distributed database as an example.

[0051] Among them, the data version information table refers to a table that records different version information of data to track different versions of data, and thus supports consistent reading and writing of data in concurrent transaction processing. The data version information table is usually stored in the operation log of the database and the storage node. In the data version information table, it includes a historical version identifier representing the version to which the data belongs and a historical transaction identifier corresponding to the historical version identifier. When data needs to be read, the server will refer to the data version information table to determine which version of data is visible to the transaction processing request corresponding to the current transaction, that is, the transaction processing request corresponding to the current transaction can process the data of this version to solve the data conflict and consistency problems in concurrent transactions.

[0052] Among them, in different historical transactions, different data versions may be generated. The version to which the data belongs refers to the data version generated after transaction processing according to the historical transaction requests corresponding to each historical transaction. In the specific implementation of this embodiment, the historical transaction can be a transaction that has completed transaction submission, or a transaction that has started at the current moment but has not completed transaction submission (that is, is still active). Correspondingly, the historical transaction request corresponds to the transaction processing request, and can be the processing request corresponding to the transaction that has completed transaction submission, or the processing request corresponding to the transaction that has started at the current moment but has not completed transaction submission (that is, is still active). Similarly, the data version corresponding to the historical transaction can be a submitted data version or an unsubmitted data version.

[0053] The historical transaction identifier refers to a unique identifier used to identify and distinguish different historical transactions. The historical transaction identifier can be a transaction ID (Identity document, that is, identity identifier), string, tag data, timestamp, etc. preset or generated by the server according to different historical transactions. For example, an incrementing integer is used to track and distinguish different transactions to ensure that the current transaction processing request can be correctly identified from other transaction processing requests during concurrent transaction processing and the current transaction processing request can be correctly identified from the historical transaction requests when determining the version identifier of the data. The historical version identifier refers to a unique identifier used to identify and distinguish the data versions obtained after transaction processing of different historical transactions. The historical version identifier corresponds to the historical transaction identifier, and the two are usually in a one-to-one correspondence, that is, one historical transaction identifier corresponds to one historical transaction and the historical version identifier of the data version obtained after the transaction processing of this historical transaction.

[0054] Exemplarily, when the client or other applications initiate a transaction processing request, the server receives the transaction processing request and, after receiving it, obtains the data version information table from the operation log or storage node of the database to determine the historical version identifier representing the version to which the data belongs and the historical transaction identifier corresponding to the historical version identifier.

[0055] Step 202: According to the transaction isolation rule, at least one candidate version identifier matching the target transaction identifier of the transaction processing request is determined from the data version information table.

[0056] Among them, the transaction isolation rule refers to the rule for isolating the current transaction and other concurrent transactions defined during the execution of the transaction, which is used to determine the visibility of the transaction when reading or accessing data, that is, whether the data version of a concurrent other transaction is visible relative to the current transaction, that is, whether the transaction processing request of the current transaction can read or access the data version of the other concurrent transaction. Transaction isolation rules may include but are not limited to read uncommitted, read committed, repeatable read, etc., among which read uncommitted means that the current transaction is allowed to read data versions that have not been committed by other transactions, read committed means that the current transaction can only read data versions that have been committed by other transactions, and repeatable read means that the data versions are consistent when the current transaction reads the same data multiple times.

[0057] Among them, the target transaction identifier refers to a unique identifier used to identify and distinguish the current transaction from historical transactions. Similar to the historical transaction identifier, the target transaction identifier can be a transaction ID (Identity document), string, tag data, timestamp, etc. preset or generated by the server based on different historical transactions.

[0058] Matching means that data under the version identified by at least one candidate version identifier supports transaction processing according to the transaction processing request.

[0059] The candidate version identifier refers to a data version that is determined from all historical version identifiers in the data version information table and that supports transaction processing according to the transaction processing request.

[0060] Exemplarily, the server determines a transaction isolation rule according to an application scenario of the transaction processing request, and determines at least one candidate version identifier that matches a target transaction identifier of the transaction processing request from the data version information table according to the determined transaction isolation rule.

[0061] Step 203: determine a target version identifier from at least one candidate version identifier based on the transaction correlation between the transaction processing request and the historical transaction requests of each historical transaction identifier.

[0062] Among them, transaction correlation refers to the dependency relationship between the current transaction corresponding to the transaction processing request and the historical transactions corresponding to each historical transaction request due to the same processing environment, execution environment and transaction processing requests. By analyzing the transaction correlation between the two transactions, the target version identifier is determined from at least one candidate version identifier based on the transaction correlation to ensure that the transaction processing request can read or query a more appropriate data version, so as to improve the accuracy and consistency of transaction processing.

[0063] The target version identifier refers to a version identifier determined from at least one candidate version identifier for guiding data reading by the transaction processing request. The data version identified by the target version identifier is the data version that is ultimately processed by the transaction processing request.

[0064] Exemplarily, the server determines the target version identifier from at least one candidate version identifier based on the transaction correlation between the transaction processing request and the historical transaction requests of each historical transaction identifier.

[0065] Step 204, sending the transaction processing request and the target version identifier to at least one transaction execution node corresponding to the transaction processing request, to instruct at least one transaction execution node to perform transaction processing on the original data according to the transaction processing request, obtain and return the target data, and the original data belongs to the version identified by the target version identifier.

[0066] Among them, the transaction execution node refers to the node or engine responsible for transaction processing in the database system. The transaction execution node usually corresponds to the processing unit in the database system. In a distributed database, transactions usually need to be executed on multiple transaction execution nodes to ensure data consistency and availability. The transaction execution node can be a database server, a microservice instance, or other computing resources that can process transaction requests, such as data processing nodes and data storage nodes deployed in a distributed database. The transaction execution node can receive instructions from the server (or transaction coordinator), process the original data according to the instructions, and return the processing results.

[0067] Among them, transaction processing refers to the process of performing data operations on original data to obtain target data; data operations include but are not limited to one or more of query, delete, update and add.

[0068] The original data refers to the data processed by the transaction processing request; in this embodiment, the original data belongs to the version identified by the target version identifier. The target data refers to the new data generated after the transaction processing is completed, and the target data can be used to reflect the data operation performed by the transaction processing request on the original data.

[0069] Exemplarily, the server sends the transaction processing request and the target version identifier to at least one transaction execution node corresponding to the transaction processing request, so that after receiving the transaction processing request and the target version identifier, each transaction execution node can obtain the original data according to the target version identifier and perform transaction processing on the original data according to the transaction processing request, thereby obtaining and returning the target data.

[0070] Step 205: receiving target data returned by at least one transaction execution node, and obtaining a transaction processing result of the transaction processing request according to the target data returned by at least one transaction execution node.

[0071] Among them, the transaction processing result refers to the final result obtained based on the target data returned by each transaction execution node. In specific implementation, the transaction processing result can be determined directly based on each target data, or by weighting, filtering, splicing, etc. of each target data.

[0072] Exemplarily, the server receives target data returned by at least one transaction execution node, and after receiving the target data, the server obtains a transaction processing result of the transaction processing request according to the target data returned by at least one transaction execution node.

[0073] In the transaction processing method of multi-version concurrent control, upon receiving a transaction processing request, a data version information table is obtained; the data version information table includes a historical version identifier representing the version to which the data belongs and a historical transaction identifier corresponding to the historical version identifier; according to the transaction isolation rule, at least one candidate version identifier matching the target transaction identifier of the transaction processing request is determined from the data version information table; based on the transaction correlation between the transaction processing request and the historical transaction requests of each historical transaction identifier, the target version identifier is determined from at least one candidate version identifier; the transaction processing request and the target version identifier are sent to at least one transaction execution node corresponding to the transaction processing request to instruct at least one transaction execution node to perform transaction processing on the original data according to the transaction processing request, obtain and return the target data, and the original data belongs to the version identified by the target version identifier; the target data returned by each of the at least one transaction execution nodes is received, and according to at least one The target data returned by each transaction execution node is used to obtain the transaction processing result of the transaction processing request; in the transaction processing process, the target transaction and the historical transaction are identified by the transaction identifier to determine the historical version identifier corresponding to each transaction, and the transaction isolation rule is combined to determine whether to support targeted processing of the data under the version identified by each historical version identifier according to the transaction processing request, so as to determine at least one candidate version identifier, and based on the correlation between the historical transaction corresponding to the data under the version identified by the candidate version identifier and the current transaction corresponding to the transaction processing request, the target version identifier is determined, so that at least one transaction execution node obtains the original data according to the target version identifier and processes it. On the one hand, it can ensure that the transaction obtains a consistent data version during the execution process to reduce conflicts between transactions. On the other hand, it can also consider the correlation between transactions to improve the processing precision and accuracy of transactions, thereby improving the overall performance of the database system for transaction processing.

[0074] In one embodiment, step 202 includes:

[0075] Using the historical transaction identifier as an index, traverse each historical version identifier in the data version information table; for each historical version identifier, determine the matching result of processing the data under the version identified by the historical version identifier in accordance with the transaction processing request in accordance with the transaction isolation rule; when the matching result indicates that the data under the version identified by the historical version identifier supports processing in accordance with the transaction processing request, determine the historical version identifier as a candidate version identifier that matches the target transaction identifier.

[0076] Among them, traversal refers to querying or obtaining the historical transaction identifiers in the data version information table one by one. The matching result refers to matching the historical transaction identifier with the target transaction identifier according to the transaction isolation rule, and determining whether the original data identified by the historical version identifier corresponding to the historical transaction identifier is visible or queryable for the transaction processing request corresponding to the target transaction identifier, that is, whether the original data identified by the historical version identifier supports the transaction processing request for transaction processing.

[0077] In an exemplary embodiment, the server queries the data version information table according to the historical transaction identifier, starting from the largest (or latest) historical transaction identifier. For each historical transaction identifier queried, the server can determine whether the historical transaction corresponding to the historical transaction identifier is executing transaction processing or whether its corresponding data version is submitted. If the transaction processing is being executed or the data version is not submitted, the data version does not support the transaction processing request for transaction processing, and the historical version identifier corresponding to the historical transaction identifier does not match the target transaction identifier, and the historical version identifier is not a candidate version identifier. On the contrary, if the historical transaction has been executed or the data version has been submitted, the data version can support the transaction processing request for transaction processing, and the historical version identifier corresponding to the historical transaction identifier is determined as a candidate version identifier, until all historical version identifiers that match the target transaction identifier are judged to be completed, and all candidate version identifiers are obtained.

[0078] In this embodiment, by traversing the data version information table and combining the transaction isolation rules, the historical data version that matches the target transaction can be efficiently and accurately screened out, ensuring that the transaction processing request can be executed on the correct and consistent data version, thereby improving the accuracy of data processing and the consistency of transaction processing.

[0079] In one embodiment, step 203 includes:

[0080] Perform transaction correlation analysis on the transaction processing request and the historical transaction requests of each historical transaction identifier to obtain a correlation analysis result between the transaction processing request and the historical transaction requests of each historical transaction identifier; determine a target version identifier from at least one candidate version identifier based on the correlation analysis result and each historical transaction identifier.

[0081] Transaction correlation analysis refers to the process of analyzing the degree of correlation between two or more transactions. When performing the analysis, the correlation coefficient between two or more transactions can be calculated to evaluate the linear relationship, nonlinear relationship and other relationships between transactions, so as to quantify the potential conflicts, dependencies or data access patterns between transactions. The correlation analysis result is obtained after the correlation analysis of each transaction.

[0082] Exemplarily, the server performs transaction correlation analysis on the transaction processing request and the historical transaction requests of each historical transaction identifier, respectively, to obtain the correlation analysis results between the transaction processing request and the historical transaction requests of each historical transaction identifier; then, the server determines the target version identifier from at least one candidate version identifier based on the correlation analysis results and each historical transaction identifier.

[0083] In an optional embodiment, when the server determines the target version identifier based on the correlation analysis results and the historical transaction identifier, it can further perform weighting, splicing, filtering and other operations on each correlation analysis result and then determine the target version identifier in combination with the historical transaction identifier to increase the accuracy of the target version identifier determination.

[0084] In this embodiment, by performing transaction correlation analysis on transaction processing requests and historical transaction requests, historical transactions that may conflict or depend on the current transaction can be accurately identified, thereby ensuring that the data version corresponding to the selected target version identifier is consistent with the current transaction processing request to avoid data inconsistency issues.

[0085] In one embodiment, the method further includes:

[0086] Sending a status judgment instruction to at least one transaction execution node respectively to instruct at least one transaction execution node to judge the processing status of the transaction processing request of the local end and return the respective status judgment result; receiving the respective status judgment result returned by at least one transaction execution node, and when the respective status judgment result returned by at least one transaction execution node meets the data submission trigger condition, sending a data submission instruction to at least one transaction execution node respectively to instruct at least one transaction execution node to return the respective target data.

[0087] Among them, the status judgment instruction refers to an instruction used to instruct the transaction execution node to judge the processing status of the transaction processing request on the local side, so that after receiving the status judgment instruction, the transaction execution node will judge and return the corresponding status judgment result based on the local transaction processing log or status information. The processing status refers to the status of whether the transaction execution node successfully processes the transaction for the original data on the local side. The status judgment result refers to the result judged and returned by the transaction execution node based on the local transaction processing status and log information after receiving the status judgment instruction. The status judgment result indicates the current processing status of the transaction processing request, such as completed, in progress, failed, or needs to be rolled back.

[0088] Among them, the data submission trigger condition refers to the condition used to determine when to trigger the data submission operation. The data submission trigger condition is determined based on the status judgment result of the transaction processing request. In some other embodiments, it can also be determined based on factors such as the dependency relationship between transactions, data consistency requirements, and system performance. When the server determines that the data submission trigger condition is met, the server will send a data submission instruction to the relevant transaction execution node. In this embodiment, the data submission trigger condition is usually that all transaction execution nodes have successfully executed the transaction processing request, or the proportion of transaction execution nodes that have successfully executed the transaction processing request reaches a certain threshold, which can trigger data submission. The data submission instruction refers to the instruction sent by the server to the transaction execution node, which is used to instruct the transaction execution node to submit the target data obtained by the current transaction.

[0089] Exemplarily, the server sends a status judgment instruction to each transaction execution node respectively, so that after receiving the status judgment instruction, each transaction execution node can judge whether the transaction processing request on the local side is successfully executed, and return a status judgment result such as completed, in progress, failed, or needs to be rolled back; then, the server receives each status judgment result returned by each transaction execution node, and judges each status judgment result according to the data submission trigger condition. If the status judgment results returned by each transaction execution node indicate that the transaction processing request is successfully executed, a data submission instruction is sent to each transaction execution node respectively, so that after receiving the data submission instruction, each transaction execution node returns its own target data to the server.

[0090] In this embodiment, a status judgment instruction is sent to the transaction execution node to instruct the transaction execution node to return a status judgment result. By analyzing the status judgment result, the execution status of the transaction processing request of each transaction execution node can be quickly understood, so that data is submitted only when all transaction execution nodes meet the submission conditions, avoiding data inconsistency and resource waste.

[0091] In one embodiment, before sending the data pre-commit instruction to at least one transaction execution node respectively, the method further includes:

[0092] An execution condition judgment instruction is sent to at least one transaction execution node respectively to instruct at least one transaction execution node to judge the execution condition of the transaction processing request of the local end and return the respective execution condition judgment results; when the respective execution condition judgment results returned by the at least one transaction execution node meet the status judgment trigger condition, a status judgment instruction is generated.

[0093] Among them, the execution condition judgment instruction refers to an instruction used to instruct the transaction execution node to judge the execution condition of the transaction processing request of the local end, so that the transaction execution node can judge whether the local end can or has resources to execute the transaction processing request after receiving the execution condition judgment instruction. The execution condition refers to the condition used to determine whether each transaction execution node can execute the transaction processing request. In specific implementation, the execution condition can be the priority of the transaction processing request, the dependency relationship between transactions, the resource locking status, the data consistency requirement, etc. The execution condition judgment result refers to the result returned by the transaction execution node after receiving the execution condition judgment instruction to determine whether the local end meets the execution condition of the transaction processing request.

[0094] Among them, the state judgment trigger condition refers to the condition used to determine when to trigger the state judgment operation. The data submission trigger condition is determined based on the execution condition judgment result of the transaction processing request. Similarly, in some other embodiments, it can also be determined based on the dependency relationship between transactions, data consistency requirements, system performance and other factors. In this embodiment, the state judgment trigger condition is usually that all transaction execution nodes have the conditions to execute the transaction processing request, or the proportion of transaction execution nodes that meet the execution conditions of the transaction processing request reaches a certain threshold or the key transaction execution nodes meet the execution conditions, before the state judgment can be triggered.

[0095] Exemplarily, the server sends an execution condition judgment instruction to each transaction execution node respectively, so that after receiving the execution condition judgment instruction, each transaction execution node can judge the execution condition of the transaction processing request on the local side and return its own execution condition judgment result; then, the server receives the respective execution condition judgment results returned by each transaction execution node, and judges each execution condition judgment result according to the status judgment trigger condition, and generates a status judgment instruction when each execution condition judgment result indicates that the transaction execution node can execute the transaction processing request.

[0096] In this embodiment, by sending an execution condition judgment instruction to the transaction execution node, the execution condition of the transaction processing request can be accurately verified to ensure that the transaction is executed at the appropriate time and state, which is conducive to reducing erroneous execution or transaction failure caused by unsatisfied conditions, and further helps to improve the execution accuracy and efficiency of the transaction.

[0097] In one embodiment, the method further includes:

[0098] When the respective target data returned by at least one transaction execution node is successfully received, a data update instruction is sent to at least one transaction execution node to instruct the at least one transaction execution node to update the original data according to the target data.

[0099] Among them, the data update instruction refers to an instruction used to instruct the transaction execution node to update the original data using the target data generated by the local end, so that after receiving the data update instruction, the transaction execution node can delete the original data on the corresponding storage node and write the target data to the storage node.

[0100] Exemplarily, when the server successfully receives the respective target data returned by at least one transaction execution node, it can generate a data update instruction and send the data update instruction to each transaction execution node, so that each transaction execution node can delete the original data on the corresponding storage node after receiving the data update instruction, and write the target data to the storage node to achieve data update.

[0101] In this embodiment, after successfully acquiring the target data returned by the transaction execution node, each transaction execution node can be promptly instructed to update the original data, thereby maintaining the consistency and accuracy of the data.

[0102] In one embodiment, the data update instruction is also used to instruct at least one transaction execution node to return a data update result.

[0103] Based on the above, the method of this embodiment further includes:

[0104] When the received data update result meets the data synchronization trigger condition, determine at least one associated transaction associated with the current transaction corresponding to the transaction processing request, and determine the associated transaction node corresponding to the at least one associated transaction; send target data and data synchronization instructions to each associated transaction node according to the preset synchronization rules to instruct each transaction execution node to update its corresponding original data according to the target data.

[0105] The data synchronization trigger condition refers to the condition for determining when to trigger the data synchronization operation, and the data synchronization trigger condition is determined based on the data update result. In this embodiment, the data synchronization trigger condition is usually the condition that all transaction execution nodes have completed data update, or the proportion of transaction execution nodes that have completed data update reaches a certain threshold or key transaction execution nodes have completed data update, before data synchronization can be triggered.

[0106] Among them, an associated transaction refers to a transaction that is logically or data-related to the current transaction. Usually, an associated transaction needs to maintain consistency or synchronization with the data of the current transaction. For example, in a bank transfer system, the current transaction needs to transfer money from account A to account B. After the transfer operation is completed, it is necessary to execute a transaction that reduces the balance of account A and increases the balance of account B. At this time, this transaction is an associated transaction to maintain data consistency and synchronization.

[0107] The associated transaction node refers to a node used to execute the associated transaction. The associated transaction node is similar to the transaction execution node. For details, please refer to the relevant description of the transaction execution node, which will not be repeated here.

[0108] Among them, the preset synchronization rules refer to the rules for data synchronization between the transaction execution node and the associated transaction nodes, which are determined according to the consistency requirements of data synchronization between the transaction execution node and the associated transaction nodes. Among them, the consistency requirements can be strict consistency requirements and non-strict consistency requirements. Strict consistency requirements mean that all associated transaction nodes need to be updated synchronously during the data synchronization process, that is, the data in each associated transaction node needs to be strictly consistent, and the data inconsistency of some nodes is not allowed. Non-strict consistency requirements allow the corresponding data of some nodes in the associated transaction nodes to be temporarily inconsistent during the data synchronization process, but they are consistent in the end. In specific implementation, the synchronization rules can be preset during the node configuration process according to the consistency requirements of data synchronization between nodes, and can be adaptively updated as the nodes change. For example, when the node changes, the synchronization rules can be adaptively reconfigured according to the data consistency requirements before and after the node changes; the synchronization rules can also be obtained by the server in real time configuration according to the association relationship between each node during the node execution transaction processing.

[0109] The data synchronization instruction refers to an instruction for instructing the associated transaction node to perform the same data update operation on its local end according to the data update operation of the transaction execution node.

[0110] Exemplarily, the server receives the data update result and uses the data synchronization trigger condition to judge the data update result. If the data update result meets the data synchronization trigger condition, at least one associated transaction associated with the current transaction corresponding to the transaction processing request is determined, and the associated transaction node corresponding to the at least one associated transaction is determined; then, the server sends target data and data synchronization instructions to each associated transaction node according to the preset synchronization rules to instruct each transaction execution node to update its corresponding original data according to the target data.

[0111] In an exemplary embodiment, for synchronization rules with strict consistency requirements, each associated transaction node can adopt a multi-round voting mechanism to achieve data synchronization, that is, the server determines a leader node among all associated transaction nodes, and the other associated transaction nodes serve as follower nodes. When performing data synchronization, the server determines a synchronization identifier and sends a synchronization request carrying the synchronization identifier to all follower nodes respectively. Each follower node determines whether to accept the synchronization request based on the synchronization request and the corresponding synchronization identifier, and returns the corresponding synchronization request acceptance result. The server collects the synchronization request acceptance results of all follower nodes through the leader node, and adopts the majority principle. If most of the follower nodes accept the synchronization request, the target data is sent to each follower node through the leader node, and the original data is synchronously updated after the synchronization data reaches each follower node to ensure that each node updates the data synchronously.

[0112] Furthermore, when determining the leader node and follower nodes, the server can adopt a leader election mechanism. Specifically, if each follower node does not receive a heartbeat message from the leader node within a preset time, it will be converted to a candidate node state. The candidate node increases its term number and requests votes from other nodes. Each node can only cast one vote during the same term, supporting the candidate node with the latest log. The candidate node obtains majority support to become the new leader node. The leader node receives the client request and adds it to the log. The leader node sends the log entry to all follower nodes. The leader node marks the log entry replicated by the majority as committed. The leader node and follower nodes apply the submitted log entries to the state machine. The leader node sends heartbeat messages periodically. The follower node does not receive a heartbeat from the leader node within the election timeout, triggering a new election. The node writes the log entry to persistent storage, and the node recovers the log entry from persistent storage.

[0113] In an exemplary embodiment, for synchronization rules that do not have strict consistency requirements, each associated transaction node can be implemented by asynchronous replication. In asynchronous replication, the data update is first executed on one of the associated transaction nodes, and then gradually propagated to other associated transaction nodes through an asynchronous mechanism. For example, the order of propagation is determined according to the priority and association relationship between the associated transaction nodes to ensure that the data update of all associated transaction nodes is finally achieved. Since the data updates on each associated transaction node have a sequence in the process of asynchronous replication, conflicts may exist in the data update process. Therefore, timestamp priority, merge update, external intervention and other methods can be used to resolve the conflicts. For example, in the scenario of timestamp priority, the update operation with the latest timestamp can be selected as the final result. For example, in the scenario of merge update, multiple conflicting updates can be merged into a new version, and the results of the two updates can be retained.

[0114] In this embodiment, by detecting the data update results and triggering the synchronization conditions, it is possible to ensure that the associated transactions associated with the current transaction are updated in a timely manner, thereby maintaining the consistency of the data in the entire distributed system, and performing data synchronization according to preset synchronization rules. Data synchronization instructions can be sent in a targeted manner, which is conducive to avoiding unnecessary data transmission and processing, thereby improving the efficiency of data synchronization.

[0115] In an exemplary embodiment, Figure 3 As shown, a transaction processing method for multi-version concurrency control is provided, comprising the following steps:

[0116] Step 301: The client sends a transaction processing request for a distributed database to the server.

[0117] Step 302: The server receives a transaction processing request and obtains a data version information table.

[0118] Step 303: The server determines at least one candidate version identifier that matches the target transaction identifier of the transaction processing request from the data version information table according to the transaction isolation rule.

[0119] Step 304: The server determines a target version identifier from at least one candidate version identifier based on the transaction processing request and the transaction correlation between the historical transaction requests of each historical transaction identifier.

[0120] Step 305: The server sends the transaction processing request and the target version identifier to at least one transaction execution node corresponding to the transaction processing request.

[0121] Step 306: The transaction execution node receives the transaction processing request and the target version identifier, and performs transaction processing on the original data according to the transaction processing request to obtain the target data.

[0122] Step 307: The transaction execution node sends the target data to the server.

[0123] Step 308: The server receives the target data and obtains the transaction processing result of the transaction processing request.

[0124] Step 309: The server sends the transaction processing result to the client.

[0125] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0126] Based on the same inventive concept, the embodiment of the present application also provides a multi-version concurrent control transaction processing device for implementing the multi-version concurrent control transaction processing method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more multi-version concurrent control transaction processing device embodiments provided below can refer to the limitations of the multi-version concurrent control transaction processing method above, and will not be repeated here.

[0127] In an exemplary embodiment, Figure 4 As shown, a transaction processing device for multi-version concurrent control is provided, including: an information acquisition module 401, a version screening module 402, a version determination module 403, an information sending module 404 and a result determination module 405, wherein:

[0128] The information acquisition module 401 is used to acquire a data version information table when a transaction processing request is received; the data version information table includes a historical version identifier representing the version to which the data belongs and a historical transaction identifier corresponding to the historical version identifier;

[0129] The version screening module 402 is used to determine at least one candidate version identifier that matches the target transaction identifier of the transaction processing request from the data version information table according to the transaction isolation rule; the data under the version identified by the at least one candidate version identifier supports transaction processing according to the transaction processing request;

[0130] A version determination module 403, configured to determine a target version identifier from at least one candidate version identifier based on a transaction correlation between a transaction processing request and respective historical transaction requests of each historical transaction identifier;

[0131] An information sending module 404 is used to send the transaction processing request and the target version identifier to at least one transaction execution node corresponding to the transaction processing request, so as to instruct the at least one transaction execution node to perform transaction processing on the original data according to the transaction processing request, obtain and return the target data, and the original data belongs to the version identified by the target version identifier;

[0132] The result determination module 405 is used to receive the target data returned by at least one transaction execution node, and obtain the transaction processing result of the transaction processing request according to the target data returned by at least one transaction execution node.

[0133] In an optional embodiment, the version screening module 402 is also used to traverse each historical version identifier in the data version information table using the historical transaction identifier as an index; for each historical version identifier, according to the transaction isolation rule, determine the matching result of processing the data under the version identified by the historical version identifier according to the transaction processing request; when the matching result indicates that the data under the version identified by the historical version identifier supports processing according to the transaction processing request, the historical version identifier is determined as a candidate version identifier that matches the target transaction identifier.

[0134] In an optional embodiment, the version determination module 403 is further used to perform transaction correlation analysis on the transaction processing request and the historical transaction requests of each historical transaction identifier, to obtain the correlation analysis results between the transaction processing request and the historical transaction requests of each historical transaction identifier; and to determine the target version identifier from at least one candidate version identifier based on the correlation analysis results and each historical transaction identifier.

[0135] In an optional embodiment, the above-mentioned device also includes a data submission indication module, which is used to send status judgment instructions to at least one transaction execution node respectively to instruct at least one transaction execution node to judge the processing status of the transaction processing request of the local end and return the respective status judgment results; receive the respective status judgment results returned by at least one transaction execution node, and when the status judgment results returned by at least one transaction execution node meet the data submission trigger condition, send data submission instructions to at least one transaction execution node respectively to instruct at least one transaction execution node to return the respective target data.

[0136] In an optional embodiment, the above-mentioned device also includes a data pre-commitment indication module, which is used to send execution condition judgment instructions to at least one transaction execution node respectively, so as to instruct at least one transaction execution node to judge the execution conditions of the transaction processing request of the local end and return the respective execution condition judgment results; when the respective execution condition judgment results returned by the at least one transaction execution node meet the status judgment trigger condition, a status judgment instruction is generated.

[0137] In an optional embodiment, the above-mentioned device also includes a data update module, which is used to send a data update instruction to at least one transaction execution node when the respective target data returned by at least one transaction execution node is successfully received, so as to instruct at least one transaction execution node to update the original data according to the target data.

[0138] In an optional embodiment, the data update instruction is also used to instruct at least one transaction execution node to return a data update result. The above-mentioned device also includes a data synchronization module, which is used to determine at least one associated transaction associated with the current transaction corresponding to the transaction processing request and determine the associated transaction node corresponding to the at least one associated transaction when the received data update result meets the data synchronization trigger condition; send target data and data synchronization instructions to each associated transaction node according to preset synchronization rules to instruct each transaction execution node to update its corresponding original data according to the target data.

[0139] Each module in the transaction processing device of the multi-version concurrent control can be implemented in whole or in part by software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each module.

[0140] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Figure 5As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data version information tables, transaction isolation rules, various version identifiers, and original data under the versions identified by various version identifiers. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a transaction processing method for multi-version concurrent control is implemented.

[0141] Those skilled in the art will understand that Figure 5 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0142] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the transaction processing method for multi-version concurrency control in the above embodiment is implemented.

[0143] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the transaction processing method for multi-version concurrency control in the above embodiment is implemented.

[0144] In one embodiment, a computer program product is provided, including a computer program. When the computer program is executed by a processor, the transaction processing method for multi-version concurrency control in the above embodiment is implemented.

[0145] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0146] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0147] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0148] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A transaction processing method for multi-version concurrency control, characterized in that: The method comprises: When a transaction processing request is received, a data version information table is obtained; the data version information table includes a historical version identifier representing the version to which the data belongs and a historical transaction identifier corresponding to the historical version identifier; According to the transaction isolation rule, at least one candidate version identifier matching the target transaction identifier of the transaction processing request is determined from the data version information table; the data under the version identified by the at least one candidate version identifier supports transaction processing according to the transaction processing request; determining a target version identifier from the at least one candidate version identifier based on a transaction correlation between the transaction processing request and the historical transaction requests of each of the historical transaction identifiers; Sending the transaction processing request and the target version identifier to at least one transaction execution node corresponding to the transaction processing request, so as to instruct the at least one transaction execution node to perform transaction processing on the original data according to the transaction processing request, and obtain and return the target data, wherein the original data belongs to the version identified by the target version identifier; Receive the target data returned by each of the at least one transaction execution nodes, and obtain the transaction processing result of the transaction processing request according to the target data returned by each of the at least one transaction execution nodes.

2. The method according to claim 1, characterized in that The determining the target version identifier from the at least one candidate version identifier based on the transaction correlation between the transaction processing request and the historical transaction requests of each of the historical transaction identifiers comprises: Performing transaction correlation analysis on the transaction processing request and the historical transaction requests of each of the historical transaction identifiers to obtain a correlation analysis result between the transaction processing request and the historical transaction requests of each of the historical transaction identifiers; According to the correlation analysis result and each of the historical transaction identifiers, a target version identifier is determined from the at least one candidate version identifier.

3. The method according to claim 1, characterized in that: The determining, according to the transaction isolation rule, from the data version information table, at least one candidate version identifier that matches the target transaction identifier of the transaction processing request comprises: Using the historical transaction identifier as an index, traverse each of the historical version identifiers in the data version information table; For each of the historical version identifiers, according to the transaction isolation rule, determining a matching result of processing the data under the identified version of the historical version identifier according to the transaction processing request; When the matching result indicates that the data under the version identified by the historical version identifier supports processing according to the transaction processing request, the historical version identifier is determined as a candidate version identifier that matches the target transaction identifier.

4. The method according to claim 1, characterized in that: The method further comprises: Sending a status judgment instruction to the at least one transaction execution node respectively, so as to instruct the at least one transaction execution node to judge the processing status of the transaction processing request of the local end, and return respective status judgment results; Receive the respective status judgment results returned by the at least one transaction execution node, and when the respective status judgment results returned by the at least one transaction execution node meet the data submission trigger condition, send data submission instructions to the at least one transaction execution node respectively to instruct the at least one transaction execution node to return the respective target data.

5. The method according to claim 4, characterized in that Before sending the data pre-commit instruction to the at least one transaction execution node respectively, the method further includes: Sending execution condition judgment instructions to the at least one transaction execution node respectively, so as to instruct the at least one transaction execution node to judge the execution condition of the transaction processing request of the local end, and return respective execution condition judgment results; When the execution condition judgment result returned by the at least one transaction execution node meets the state judgment triggering condition, a state judgment instruction is generated.

6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: When the respective target data returned by the at least one transaction execution node is successfully received, a data update instruction is sent to the at least one transaction execution node to instruct the at least one transaction execution node to update the original data according to the target data.

7. The method according to claim 6, characterized in that The data update instruction is also used to instruct the at least one transaction execution node to return a data update result; the method further includes: In a case where the received data update result satisfies a data synchronization trigger condition, determining at least one associated transaction associated with the current transaction corresponding to the transaction processing request, and determining an associated transaction node corresponding to the at least one associated transaction; The target data and data synchronization instructions are sent to each of the associated transaction nodes according to a preset synchronization rule, so as to instruct each of the transaction execution nodes to update their corresponding original data according to the target data.

8. A transaction processing device for multi-version concurrent control, characterized in that: The device comprises: An information acquisition module is used to acquire a data version information table when a transaction processing request is received; the data version information table includes a historical version identifier representing the version to which the data belongs and a historical transaction identifier corresponding to the historical version identifier; A version screening module, configured to determine, from the data version information table, according to a transaction isolation rule, at least one candidate version identifier that matches a target transaction identifier of the transaction processing request; data under the version identified by the at least one candidate version identifier supports transaction processing according to the transaction processing request; a version determination module, configured to determine a target version identifier from the at least one candidate version identifier based on a transaction correlation between the transaction processing request and the historical transaction requests of each of the historical transaction identifiers; an information sending module, configured to send the transaction processing request and the target version identifier to at least one transaction execution node corresponding to the transaction processing request, so as to instruct the at least one transaction execution node to perform transaction processing on the original data according to the transaction processing request, obtain and return the target data, wherein the original data belongs to the version identified by the target version identifier; The result determination module is used to receive the target data returned by each of the at least one transaction execution nodes, and obtain the transaction processing result of the transaction processing request according to the target data returned by each of the at least one transaction execution nodes.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images