Transaction processing method and apparatus, distributed database system, and electronic device

Abstract

Embodiments of the present application provide a transaction processing method and device, a distributed database system and electronic equipment, and relate to the technical field of databases. The specific implementation scheme is as follows: when a processing request of a read transaction is received, determine the row data to which the read transaction is directed; wherein the read transaction carries a read timestamp; if the data state of the row data is modified by a write transaction and the write transaction is in a preparation state, determine the preparation timestamp corresponding to the write transaction; wherein the preparation timestamp is the maximum timestamp currently obtained by the transaction manager issuing to the resource manager when the write transaction enters the preparation state; compare the size of the preparation timestamp and the read timestamp; if the preparation timestamp is greater than or equal to the read timestamp, determine that the current version of the row data modified by the write transaction is invisible to the read transaction; if the preparation timestamp is less than the read timestamp, block the read transaction.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to a transaction processing method, apparatus, distributed database system, and electronic device. Background Technology

[0002] A distributed database is a database built on a distributed cluster, which can scale transaction processing performance by splitting data across multiple server nodes. Distributed databases typically use a timestamp-based approach to handle distributed transactions and ensure consistent reads.

[0003] In related technologies, when a read transaction reads a row of data, if the data state of that row has been modified by a write transaction and the write transaction is in the prepare state, the visibility of that row of data cannot be determined because the read timestamp of the read transaction and the commit timestamp of the write transaction cannot be determined. In this case, the read transaction is blocked until the commit timestamp of the write transaction is written to that row of data; this is known as write-blocked read.

[0004] During a write-blocking read, the locks and connection resources held by the read transaction cannot be released in a timely manner. If the blocked transaction waits for too long, the database performance will obviously experience significant fluctuations. Summary of the Invention

[0005] The purpose of this invention is to provide a transaction processing method, apparatus, distributed database system, and electronic device to minimize the probability of write-blocking reads, thereby ensuring stable database performance. The specific technical solution is as follows: In a first aspect, embodiments of the present invention provide a transaction processing method applied to a resource manager, the method comprising: When a read transaction processing request is received, the row data targeted by the read transaction is determined; wherein, the read transaction carries a read timestamp; If the data status of the row data is modified by a write transaction and the write transaction is in the preparation state, determine the preparation timestamp corresponding to the write transaction; wherein, the preparation timestamp is the maximum timestamp that has been obtained so far when the write transaction enters the preparation state and is issued by the transaction manager to the resource manager. Compare the size of the preparation timestamp with the size of the read timestamp; If the preparation timestamp is greater than or equal to the read timestamp, it is determined that the current version of the row data modified by the write transaction is not visible to the read transaction. If the preparation timestamp is less than the read timestamp, the read transaction is blocked.

[0006] Optionally, before determining the preparation timestamp corresponding to the write transaction, the method further includes: The transaction manager receives the maximum timestamp that has been obtained at the moment the write transaction enters the preparation state, and uses it as the preparation timestamp corresponding to the write transaction.

[0007] Optionally, receiving the maximum currently acquired timestamp issued by the transaction manager when the write transaction enters the preparation state, as the preparation timestamp corresponding to the write transaction, includes: Receive an instruction from the transaction manager to instruct the write transaction to enter the preparation state; wherein the instruction carries the maximum timestamp currently obtained by the transaction manager; Extract the maximum timestamp from the instruction and use it as the preparation timestamp for the write transaction.

[0008] Optionally, after determining that the current version of the row data modified by the write transaction is not visible to the read transaction, the method further includes: Get the previous version of the current version of the row data; Compare the commit timestamp in the previous version with the size of the read timestamp; If the read timestamp is greater than or equal to the commit timestamp in the previous version, the data in the previous version is read as the response result of the read transaction.

[0009] Secondly, embodiments of the present invention provide a distributed database system, the system comprising: a transaction manager and a resource manager; The resource manager, upon receiving a read transaction processing request, determines the row data targeted by the read transaction, wherein the read transaction carries a read timestamp; if the data status of the row data is modified by a write transaction and the write transaction is in a ready state, it obtains the ready timestamp corresponding to the write transaction, wherein the ready timestamp is the maximum timestamp currently obtained, issued by the transaction manager to the resource manager when the write transaction enters the ready state; it compares the ready timestamp with the read timestamp; if the ready timestamp is greater than or equal to the read timestamp, it determines that the current version of the row data modified by the write transaction is not visible to the read transaction; if the ready timestamp is less than the read timestamp, it blocks the read transaction; The transaction manager is used to send the currently acquired maximum timestamp to the resource manager when the write transaction enters the preparation state.

[0010] Optionally, the system further includes: a global timestamp server; The transaction manager is also used to obtain the timestamp to be used for each write / read transaction from the global timestamp server; The global timestamp server is used to assign timestamps to the write / read transaction.

[0011] Optionally, the resource manager is further configured to receive, before determining the preparation timestamp corresponding to the write transaction, the maximum timestamp currently obtained issued by the transaction manager when the write transaction enters the preparation state, as the preparation timestamp corresponding to the write transaction.

[0012] Optionally, the resource manager is further configured to: after determining that the current version of the row data modified by the write transaction is not visible to the read transaction, Get the previous version of the current version of the row data; Compare the commit timestamp in the previous version with the size of the read timestamp; If the read timestamp is greater than or equal to the commit timestamp in the previous version, the data in the previous version is read as the response result of the read transaction.

[0013] Thirdly, embodiments of the present invention provide a transaction processing apparatus applied to a resource manager, the apparatus comprising: The first determining module is used to determine the row data targeted by the read transaction when a read transaction processing request is received; wherein the read transaction carries a read timestamp; The second determining module is used to determine the preparation timestamp corresponding to the write transaction if the data status of the row data is modified by a write transaction and the write transaction is in the preparation state; wherein, the preparation timestamp is the maximum timestamp that has been obtained so far when the write transaction enters the preparation state and is sent by the transaction manager to the resource manager. The comparison module is used to compare the size of the preparation timestamp with the read timestamp; The determination module is used to determine that if the preparation timestamp is greater than or equal to the read timestamp, the current version of the row data modified by the write transaction is not visible to the read transaction. A blocking module is used to block the read transaction if the preparation timestamp is less than the read timestamp.

[0014] Fourthly, embodiments of the present invention provide an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the transaction processing method steps described above.

[0015] Fifthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the transaction processing method steps described above.

[0016] Sixthly, embodiments of the present invention also provide a computer program product containing instructions that, when run on a computer, cause the computer to perform any of the transaction processing methods described above.

[0017] Beneficial effects of the embodiments of the present invention: This invention provides a transaction processing method. After determining the row data targeted by the read transaction, when the data state of the row data is modified by a write transaction and the write transaction is in a ready state, the method determines the ready timestamp corresponding to the write transaction. The ready timestamp is the maximum timestamp currently obtained, issued by the transaction manager to the resource manager when the write transaction enters the ready state, and is necessarily less than the commit timestamp when the write transaction commits. Then, the method compares the ready timestamp with the read timestamp. If the ready timestamp is greater than or equal to the read timestamp, it can be determined that the current version of the row data is not visible to the read transaction; otherwise, the read transaction is blocked. Therefore, by introducing a comparison between the ready timestamp and the read timestamp, the method reduces the possibility of the current version of the row data being unrecognizable to the read transaction, thereby minimizing the probability of write blocking reads and ensuring stable database performance.

[0018] Of course, implementing any product or method of the present invention does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention 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 only some embodiments of the present invention. For those skilled in the art, other embodiments can be obtained based on these drawings.

[0020] Figure 1 This is a schematic diagram of row data provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the architecture of a transaction processing method provided in an embodiment of the present invention; Figure 3 A flowchart of a transaction processing method provided in an embodiment of the present invention; Figure 4This is another flowchart of a transaction processing method provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a distributed database system provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of a transaction processing device provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0021] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of the present invention.

[0022] A distributed database refers to a database that uses high-speed computer networks to connect multiple physically dispersed data storage units to form a logically unified database. The basic idea of ​​a distributed database is to distribute the data from a centralized database across multiple network-connected data storage nodes to achieve greater storage capacity and higher concurrent access. A distributed transaction refers to a transaction where the participants, supporting servers, resource managers, and transaction managers reside on different nodes within a different distributed system. Essentially, distributed transactions aim to ensure data consistency across different databases.

[0023] Furthermore, both write and read transactions handled by the resource manager are branch transactions, and multiple branch transactions constitute a distributed transaction. In the application scenario of MVCC (Multi-Version Concurrency Control), the distributed database records row data, and each row (also called a row record) can have multiple versions of data. Any write transaction is used to generate a new version of data for a specific row; while any read transaction is used to read a visible version of data from the various versions of the row data.

[0024] In related technologies, a timestamp-based approach is generally used to handle data consistency reads in distributed transactions within a distributed database. When a transaction manager generates a read transaction for a resource manager, it requests the start timestamp (RTS) of the read transaction from the global timestamp server and issues the read transaction to the resource manager using an SQL (Structured Query Language) statement, which carries the RTS. Similarly, when a transaction manager generates a write transaction for a resource manager, it also requests the start timestamp of the write transaction from the global timestamp server and issues the write transaction to the resource manager using an SQL statement, which carries the start timestamp. After receiving the write transaction, i.e., after receiving the write transaction processing request, the resource manager processes the row data targeted by the write transaction (i.e., the processing represented by the write transaction), thus starting the write transaction, which is in an Active state. Then, to ensure distributed data consistency, after the write transaction processes the row data, it enters a segmented commit process: The first phase is the preparation phase: The transaction manager sends a prepare instruction to the resource manager to inquire whether it is ready to commit. The resource manager then returns a success or failure message to the transaction manager based on its own situation. After the resource manager receives the prepare instruction, the write transaction is in the prepare state. The second phase is the transaction commit or rollback phase: If the transaction manager receives success messages from all resource managers, it issues a commit command (the commit command carries a commit timestamp) to the resource managers. Upon receiving the commit command, the resource managers persist the modified version data, i.e., commit the transaction; otherwise, a rollback command is issued. Rollback refers to the action of restoring the program or data to its previous correct state when a program or data processing error occurs.

[0025] To facilitate understanding of distributed consistent reads in distributed databases, which handle distributed transactions based on timestamps, the following explanation is provided with reference to the accompanying diagram: like Figure 1 As shown in the figure, ROW1_DATA is the data in the first row, ROW2_DATA is the data in the second row, CTS is the commit timestamp persisted to the row data, new_version represents the latest version of the row data, i.e., the current version, and old_version is the previous version of the row data.

[0026] Taking read transaction TrxA reading a row of data ROW1 as an example: If ROW1_DATA has not been modified by other transactions, then compare TrxA_RTS (read timestamp of the read transaction) and ROW1_CTS. new (The commit timestamp of the current version in the first row of data), if TrxA_RTS >= ROW1_CTS new If the current version of ROW1 is visible to TrxA, then TrxA can read the data from the current version of ROW1; otherwise, it is necessary to go back to the previous version of ROW1 and continue comparing the sizes of TrxA_RTS and ROW1_CTS. old .

[0027] When ROW1 is modified by write transaction TrxB, and TrxB is in an Active state, the current version of ROW1 is not visible to TrxA. It is necessary to backtrack to the previous version of ROW1 and compare TrxA_RTS and ROW1_CTS. old .

[0028] When ROW1 is modified by write transaction TrxB, and TrxB is in the Prepare state, since the CTS (Commit Timestamp of TrxB, which corresponds to the commit timestamp of the current version modified by TrxB) is not known at this time, there is a possibility that TrxA_RTS is greater than, equal to, or less than TrxB_CTS (TrxB's CTS). Therefore, the data visibility of the current version of that row cannot be determined, and TrxA is blocked until TrxB_CTS is reached. new A write-blocking read occurs when the data is written to that line.

[0029] The process of reading ROW2_DATA is similar to that of reading ROW1_DATA.

[0030] Understandably, when TrxB is in the Active state, it hasn't entered the two-phase commit process yet. Subsequent commit timestamp requests will definitely be larger than the current read transaction's timestamp. Therefore, the current version of ROW1 is not visible to TrxA. However, when TrxB is in the Prepare state, it may have already requested a commit timestamp. This means the timestamp requests for the read transaction and the current write transaction's commit timestamp are out of order, so there's no guarantee which is larger. Therefore, TrxA will be blocked until TrxB_CTS. new Until it is written into the data in that row.

[0031] Additionally, once a write transaction is in the Prepare state, the transaction manager needs to retrieve the CTS from the global timestamp server. After obtaining the CTS, it encapsulates it into an XA COMMIT (distributed transaction commit) instruction (i.e., the commit instruction mentioned above) and sends it to the resource manager. This process takes approximately two RTTs (Round Trip Time). Therefore, blocked transactions are suspended for two RTTs, during which their held lock resources, connection resources, etc., cannot be released in a timely manner, resulting in significant performance fluctuations.

[0032] Based on the above, in order to minimize the probability of write-blocking reads and ensure stable database performance, this invention provides a transaction processing method, apparatus, distributed database system, and electronic device.

[0033] The following section will first introduce a transaction processing method provided by an embodiment of the present invention.

[0034] The transaction processing method provided in this embodiment of the invention is applied to a resource manager, which communicates with a transaction manager. In specific applications, such as... Figure 2 As shown, when the transaction manager receives a business SQL statement, it generates either a write transaction or a read transaction based on the relevant content in the business SQL statement and sends them to the resource manager. When the transaction manager executes the aforementioned distributed transaction, it requests the corresponding timestamp from the global timestamp server and sends the relevant execution instructions and the requested timestamp to the resource manager, which then performs the corresponding processing operations.

[0035] It is understandable that the resource manager can be deployed in a distributed storage system, on a storage node used to store data resources; while the transaction manager can be deployed in a management node used in a distributed data system.

[0036] The transaction processing method provided in this embodiment of the invention may include the following steps: When a read transaction processing request is received, the row data targeted by the read transaction is determined; wherein, the read transaction carries a read timestamp; If the data status of the row data is modified by a write transaction and the write transaction is in the preparation state, determine the preparation timestamp corresponding to the write transaction; wherein, the preparation timestamp is the maximum timestamp that has been obtained so far when the write transaction enters the preparation state and is issued by the transaction manager to the resource manager. Compare the size of the preparation timestamp with the size of the read timestamp; If the preparation timestamp is greater than or equal to the read timestamp, it is determined that the current version of the row data modified by the write transaction is not visible to the read transaction. If the preparation timestamp is less than the read timestamp, the read transaction is blocked.

[0037] In the solution provided by this embodiment of the invention, after determining the row data targeted by the read transaction, when the data state of the row data is modified by a write transaction and the write transaction is in a ready state, the ready timestamp corresponding to the write transaction is determined. The ready timestamp is the maximum timestamp currently obtained, issued by the transaction manager to the resource manager when the write transaction enters the ready state, and it is always less than the commit timestamp when the write transaction commits. Then, the ready timestamp is compared with the read timestamp. If the ready timestamp is greater than or equal to the read timestamp, it can be determined that the current version of the row data is not visible to the read transaction; otherwise, the read transaction is blocked. Therefore, by introducing a comparison between the ready timestamp and the read timestamp, the situation where the visibility of the current version of the row data to the read transaction cannot be determined is reduced, thereby minimizing the probability of write blocking reads and ensuring stable database performance.

[0038] The transaction processing method provided by the embodiments of the present invention will be described below with reference to the accompanying drawings.

[0039] like Figure 3 As shown in the figure, a transaction processing method provided by an embodiment of the present invention may include the following steps: S301, when a read transaction processing request is received, the row data targeted by the read transaction is determined; wherein, the read transaction carries a read timestamp; In this embodiment, when the resource manager receives a read transaction processing request from the transaction manager, it can analyze the information carried in the processing request to determine the row data targeted by the read transaction. The processing request may carry the row data ID, but is not limited to this. For example, the read transaction processing request carries the row data ID; when the resource manager receives the read transaction processing request, it determines the row data targeted by the read transaction based on the row data ID.

[0040] Understandably, since a read transaction needs to compare the commit timestamp and read timestamp of the row data when reading row data to determine whether each version of the row data is visible to the read transaction, the read transaction also needs to carry a read timestamp. In one implementation, the read timestamp can be carried in the processing request when the transaction manager sends the read transaction processing request to the resource manager. For example, before sending the read transaction processing request to the transaction manager, the resource manager requests a read timestamp from the global timestamp server. After obtaining the read timestamp, it sends the processing request carrying the read timestamp to the resource manager.

[0041] S302, if the data status of the row data is modified by a write transaction and the write transaction is in a ready state, determine the ready timestamp corresponding to the write transaction; wherein, the ready timestamp is the maximum timestamp that has been obtained so far when the write transaction enters the ready state and is sent by the transaction manager to the resource manager. If the row data is in a state of being modified by a write transaction and the write transaction is in a ready state, the read timestamp and the write transaction's commit timestamp may be indeterminate because the transaction manager may have already requested the commit timestamp of the write transaction from the global timestamp server. Therefore, to reduce the likelihood of indeterminate read timestamp and write transaction commit timestamp, in this embodiment, if the row data is in a state of being modified by a write transaction and the write transaction is in a ready state, the ready timestamp corresponding to the write transaction is determined. Subsequently, different processing is performed based on the relationship between the ready timestamp of the write transaction and the read timestamp of the read transaction.

[0042] The preparation timestamp is the maximum timestamp currently obtained, issued by the transaction manager to the resource manager when the write transaction enters the preparation state. It is understood that the transaction manager manages multiple transactions and requests timestamps from the global timestamp server at different stages of each transaction; therefore, the transaction manager can obtain multiple timestamps. In this case, the preparation timestamp is the maximum timestamp currently obtained, issued by the transaction manager to the resource manager when the write transaction enters the preparation stage.

[0043] Optionally, before determining the preparation timestamp corresponding to the write transaction, the method further includes: The transaction manager receives the maximum timestamp that has been obtained at the moment the write transaction enters the preparation state, and uses it as the preparation timestamp corresponding to the write transaction.

[0044] In this implementation, before determining the preparation timestamp corresponding to the write transaction, the resource manager receives the maximum timestamp currently acquired, issued by the transaction manager when the write transaction enters the preparation state, and uses it as the preparation timestamp corresponding to the write transaction. The maximum timestamp can be included in the instruction issued by the transaction manager to the resource manager, or it can be issued to the resource manager separately.

[0045] Optionally, in one implementation, receiving the maximum currently acquired timestamp issued by the transaction manager when the write transaction enters the preparation state, as the preparation timestamp corresponding to the write transaction, includes steps A1-A2: A1, receives an instruction from the transaction manager to instruct the write transaction to enter the preparation state (i.e., the preparation instruction mentioned above); wherein the instruction carries the maximum timestamp currently obtained by the transaction manager; In other words, after receiving the instruction from the transaction manager instructing the write transaction to enter the preparation state, the resource manager executes the corresponding operation to enter the preparation state. The maximum timestamp can be included in the instruction and sent to the resource manager.

[0046] A2, extract the maximum timestamp from the instruction and use it as the preparation timestamp corresponding to the write transaction.

[0047] After receiving the instruction issued by the transaction manager, the maximum timestamp can be extracted from the information carried by the instruction by analyzing the information carried by the instruction, and used as the preparation timestamp corresponding to the write transaction.

[0048] Optionally, if the data state of the row data is modified by a write transaction and the write transaction is in a ready state, before determining the ready timestamp corresponding to the write transaction, the data state of the row data can also be detected. Any implementation method for detecting the data state of the row data can be applied to this embodiment.

[0049] For example, the resource manager can record the status information of each row of data: whether it is being modified by a write transaction, and if so, the status of the write transaction (Active state and Prepare state); thus, in one implementation, the data status of the row of data can be detected based on the pre-recorded status information during the subsequent processing of read transactions.

[0050] For example, after receiving a write transaction processing request, the resource manager can record the write transaction identifier in the current version of the row data modified by the write transaction, and record the transaction state corresponding to the write transaction: Active state, Prepare state, and Commit state. When the write transaction is in the Commit state, since the write transaction has completed the commit phase, it indicates that the row data has not been modified by other transactions. Therefore, in another implementation, the data state of the row data can be detected based on the write transaction identifier in the row record.

[0051] S303, compare the size of the preparation timestamp with the read timestamp; In this embodiment, since the preparation timestamp determined in step S302 is the timestamp obtained when the read transaction is in the preparation state before committing, it is definitely smaller than the commit timestamp of the read transaction. Therefore, by further comparing the size of the preparation timestamp and the read timestamp, i.e., adding a new comparison object, a more detailed comparison result will be obtained. Thus, in the subsequent judgment process, the situation where the size of the read timestamp and the preparation timestamp cannot be determined is reduced.

[0052] S304, if the preparation timestamp is greater than or equal to the read timestamp, it is determined that the current version of the row data modified by the write transaction is not visible to the read transaction; In this embodiment, since the preparation timestamp is less than the commit timestamp, if the preparation timestamp is greater than or equal to the read timestamp, then the commit timestamp must be greater than the read timestamp. In this case, the current version of the row data modified by the write transaction is not visible to the read transaction.

[0053] Since the preparation timestamp is the maximum timestamp currently obtained issued by the transaction manager when the write transaction enters the preparation state, it is definitely less than the commit timestamp of the write transaction. Therefore, a comparison relationship between the preparation timestamp and the read timestamp can be introduced. Thus, when the preparation timestamp is greater than or equal to the read timestamp, it is determined that the current version of the row data is not visible to the read transaction, thereby reducing the probability of the read transaction being blocked.

[0054] S305, if the preparation timestamp is less than the read timestamp, the read transaction is blocked.

[0055] In this embodiment, if the preparation timestamp is less than the read timestamp, the read timestamp may be greater than, less than or equal to the commit timestamp. Therefore, the size of the commit timestamp and the read timestamp cannot be determined, and the visibility of the current version of the row data to the read transaction cannot be determined. At this time, the read transaction is blocked until the write transaction is completed and submitted.

[0056] Additionally, if the data status of the row data is that it has not been modified by a write transaction, or if it has been modified by a write transaction but the write transaction is not in a ready state, then the visibility of the current version of the row data to the read transaction needs to be determined separately.

[0057] For example, if the data state of the row data is that it has not been modified by a write transaction, then the read timestamp of the read transaction is compared with the commit timestamp of the current version of the row data. If the read timestamp is greater than or equal to the commit timestamp, the current version of the row data is obviously visible to the read transaction. Otherwise, it is necessary to backtrack to the previous version of the row data and continue to compare the read timestamp with the commit timestamp of the previous version of the row data.

[0058] For example, if the data state of the row data is modified by a write transaction, but the write transaction is in an active state, then the current version of the row data is not visible to the read transaction. It is necessary to backtrack to the previous version of the row data and continue to compare the read timestamp with the commit timestamp of the previous version of the row data.

[0059] In the solution provided by this embodiment of the invention, after determining the row data targeted by the read transaction, when the data state of the row data is modified by a write transaction and the write transaction is in a ready state, the ready timestamp corresponding to the write transaction is determined. The ready timestamp is the maximum timestamp currently obtained, issued by the transaction manager to the resource manager when the write transaction enters the ready state, and it is always less than the commit timestamp when the write transaction commits. Then, the ready timestamp is compared with the read timestamp. If the ready timestamp is greater than or equal to the read timestamp, it can be determined that the current version of the row data is not visible to the read transaction; otherwise, the read transaction is blocked. Therefore, by introducing a comparison between the ready timestamp and the read timestamp, the situation where the visibility of the current version of the row data to the read transaction cannot be determined is reduced, thereby minimizing the probability of write blocking reads and ensuring stable database performance.

[0060] Alternatively, in another embodiment of the invention, such as Figure 4 As shown, after determining that the current version of the row data modified by the write transaction is not visible to the read transaction, the method further includes the following steps: S401, Obtain the previous version of the current version of the row data; In this embodiment, if the preparation timestamp is greater than or equal to the read timestamp, then the commit timestamp of the write transaction must be greater than the read timestamp. The read transaction cannot read the data in the current version of the row data modified by the write transaction. Therefore, the resource manager needs to obtain the previous version of the current version of the row data. That is, the row data targeted by the read transaction is traced back to the previous version of the current version of the row data.

[0061] S402, compare the size of the commit timestamp in the previous version with the size of the read timestamp; In this embodiment, after obtaining the previous version of the current version of the row data, the commit timestamp of the write transaction in the previous version and the read timestamp are compared to determine whether the previous version is visible to the read transaction. In one implementation, the commit timestamp is persisted to the row data when the write transaction is committed, and the commit timestamp in the previous version can be found in the row data using information such as the write transaction ID and the version of the row data.

[0062] S403, if the read timestamp is greater than or equal to the commit timestamp in the previous version, read the data in the previous version as the response result of the read transaction.

[0063] In this embodiment, if the data read timestamp is greater than or equal to the comparison timestamp in the previous version, then the data in the previous version is definitely visible to the read transaction. At this time, the read transaction reads the data in the previous version.

[0064] As can be seen, through this embodiment, after determining that the current version of the row data modified by the write transaction is not visible to the read transaction, the commit timestamp and read timestamp of the write transaction in the previous version are compared. This allows the read transaction to continue reading the data in the previous version after the current version is not visible, thereby ensuring the normal execution of the read transaction.

[0065] To better illustrate the content of the embodiments of the present invention, the generation and use of preparation timestamps will be described below with reference to a specific example.

[0066] Prepare for timestamp generation: (1) When managing transactions, the transaction manager records the maximum value of the timestamps obtained in real time, which is recorded as Node_Max_TS; (2) When any write transaction enters the ready state, the transaction manager sends a Node_Max_TS to the resource manager that handles the write transaction, and the resource manager uses the received Node_Max_TS as the PTS corresponding to the write transaction. Specifically, the transaction manager can encapsulate Node_Max_TS into an instruction that indicates the write transaction to be in a ready state, and send the instruction to the resource manager that processes the write transaction; thus, the resource manager can extract Node_Max_TS from the instruction and obtain the ready timestamp PTS corresponding to the write transaction.

[0067] In addition, during the commit phase of a write transaction, the transaction manager obtains the CTS from the global timestamp server and encapsulates the CTS into a commit command, which is then sent to the resource manager. Since Node_MAX_TS records the maximum timestamp that the transaction manager has obtained when the write transaction enters the preparation state, it is definitely less than the timestamp that the global timestamp server has not yet allocated, so it can be guaranteed that PTS < CTS.

[0068] Preparing to use timestamps: (1) If the row data read by ROW1 (read by transaction TrxA) has not been modified by other transactions, then compare TrxA_RTS (read timestamp of the read transaction) and ROW1_CTS. new(Commit timestamp in the latest version), if TrxA_RTS >= ROW1_CTS new ROW1 is visible to TrxA; otherwise, it is necessary to go back to the previous version of ROW1 and continue comparing TrxA_RTS and ROW1_CTS. old (The commit timestamp from the previous version).

[0069] (2) When ROW1 is modified by write transaction TrxB and TrxB is in the Active state, the current version of ROW1 is not visible to TrxA. It is necessary to backtrack to the previous version of ROW1 and compare TrxA_RTS and ROW1_CTS. old .

[0070] (3) When ROW1 is modified by write transaction TrxB and TrxB is in the Prepare state, compare TrxA_RTS and ROW1_PTS (the preparation timestamp corresponding to the write transaction).

[0071] If TrxA_RTS <= ROW1_PTS, then TrxA_RTS must be less than the commit timestamp of the write transaction TrxB. The current version of this row of data is not visible to TrxA, and we need to backtrack to the previous version of ROW1 and continue comparing TrxA_RTS and ROW1_CTS. old .

[0072] If TrxA_RTS > ROW1_PTS, the relationship between TrxA_RTS and the commit timestamp of write transaction TrxB cannot be determined, and TrxA is blocked until TrxB_CTS is written to the current version of the data in that row.

[0073] As can be seen, by introducing a preparation timestamp, the probability of write blocking reads can be minimized, ensuring stable performance data; and PTS can be generated with zero overhead, without requiring additional computing resources.

[0074] Corresponding to the above method embodiments, this invention also provides a distributed database system, such as... Figure 5 As shown, the system includes: a resource manager 510 and a transaction manager 520; The resource manager 510 is configured to, upon receiving a read transaction processing request, determine the row data targeted by the read transaction, wherein the read transaction carries a read timestamp; if the data state of the row data is modified by a write transaction and the write transaction is in a ready state, obtain the ready timestamp corresponding to the write transaction, wherein the ready timestamp is the maximum timestamp currently obtained, issued by the transaction manager 520 to the resource manager when the write transaction enters the ready state; compare the size of the ready timestamp with the read timestamp; if the ready timestamp is greater than or equal to the read timestamp, determine that the current version of the row data modified by the write transaction is not visible to the read transaction; if the ready timestamp is less than the read timestamp, block the read transaction; The transaction manager 520 is used to send the currently acquired maximum timestamp to the resource manager 510 when the write transaction enters the preparation state.

[0075] Optionally, the system further includes: a global timestamp server; The transaction manager is also used to obtain the timestamp to be used for each write / read transaction from the global timestamp server; The global timestamp server is used to assign timestamps to the write / read transaction.

[0076] Optionally, the resource manager is further configured to receive, before determining the preparation timestamp corresponding to the write transaction, the maximum timestamp currently obtained issued by the transaction manager when the write transaction enters the preparation state, as the preparation timestamp corresponding to the write transaction.

[0077] Optionally, the resource manager is specifically used for: Receive an instruction from the transaction manager to instruct the write transaction to enter the preparation state; wherein the instruction carries the maximum timestamp currently obtained by the transaction manager; Extract the maximum timestamp from the instruction and use it as the preparation timestamp for the write transaction.

[0078] Optionally, the resource manager is further configured to: after determining that the current version of the row data modified by the write transaction is not visible to the read transaction, Get the previous version of the current version of the row data; Compare the commit timestamp in the previous version with the size of the read timestamp; If the read timestamp is greater than or equal to the commit timestamp in the previous version, the data in the previous version is read as the response result of the read transaction.

[0079] Corresponding to the above method embodiments, this invention also provides a transaction processing apparatus applied to a resource manager, such as... Figure 6 As shown, the device includes: The first determining module 610 is used to determine the row data targeted by the read transaction when a processing request for a read transaction is received; wherein the read transaction carries a read timestamp. The second determining module 620 is used to determine the preparation timestamp corresponding to the write transaction if the data status of the row data is modified by a write transaction and the write transaction is in a preparation state; wherein, the preparation timestamp is the maximum timestamp that has been obtained so far when the write transaction enters the preparation state and is sent by the transaction manager to the resource manager. Comparison module 630 is used to compare the size of the preparation timestamp and the read timestamp; The determination module 640 is used to determine that if the preparation timestamp is greater than or equal to the read timestamp, the current version of the row data modified by the write transaction is not visible to the read transaction. The blocking module 650 is used to block the read transaction if the preparation timestamp is less than the read timestamp.

[0080] Optionally, the device further includes: The receiving module is configured to receive the maximum timestamp currently acquired issued by the transaction manager when the write transaction enters the preparation state, before the second determining module executes the determination of the preparation timestamp corresponding to the write transaction, and use it as the preparation timestamp corresponding to the write transaction.

[0081] Optionally, the receiving module is specifically used for: Receive an instruction from the transaction manager to instruct the write transaction to enter the preparation state; wherein the instruction carries the maximum timestamp currently obtained by the transaction manager; Extract the maximum timestamp from the instruction and use it as the preparation timestamp for the write transaction.

[0082] Optionally, the device further includes: The acquisition module is used to acquire the previous version of the row data after the determination module determines that the current version of the row data modified by the write transaction is not visible to the read transaction; The second comparison module is used to compare the size of the commit timestamp and the read timestamp in the previous version; The read module is used to read data from the previous version as the response result of the read transaction if the read timestamp is greater than or equal to the commit timestamp in the previous version.

[0083] This invention also provides an electronic device, such as... Figure 7 As shown, it includes a processor 701, a communication interface 702, a memory 703, and a communication bus 704, wherein the processor 701, the communication interface 702, and the memory 703 communicate with each other through the communication bus 704. Memory 703 is used to store computer programs; When the processor 701 executes the program stored in the memory 703, it implements the steps of any of the transaction processing methods provided in the embodiments of the present invention.

[0084] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0085] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0086] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0087] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0088] In another embodiment of the present invention, a computer-readable storage medium is also provided, wherein a computer program is stored therein, and when the computer program is executed by a processor, it implements the steps of any of the above-described transaction processing methods.

[0089] In another embodiment of the present invention, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to perform any of the transaction processing methods described above.

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

[0091] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0092] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0093] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention are included within the scope of protection of the present invention.

Claims

1. A transaction processing method, characterized in that, Applied to File Explorer, the method includes: When a read transaction processing request is received, the row data targeted by the read transaction is determined; wherein, the read transaction carries a read timestamp; If the data status of the row data is modified by a write transaction and the write transaction is in a ready state, determine the ready timestamp corresponding to the write transaction; wherein, the ready timestamp is the maximum timestamp currently obtained by the transaction manager when the write transaction enters the ready state; the ready state is the state of the write transaction after the resource manager receives the ready instruction issued by the transaction manager; the ready instruction is used to query the resource manager whether it is ready to commit; the write transaction being in a ready state indicates that the write transaction has modified the row data but has not yet committed the modified version data; the ready timestamp is less than the commit timestamp when the write transaction committed the modified version data. Compare the size of the preparation timestamp with the size of the read timestamp; If the preparation timestamp is greater than or equal to the read timestamp, determine that the current version of the row data modified by the write transaction is not visible to the read transaction; obtain the previous version of the current version of the row data; compare the commit timestamp in the previous version with the read timestamp; if the read timestamp is greater than or equal to the commit timestamp in the previous version, read the data in the previous version as the response result of the read transaction; If the preparation timestamp is less than the read timestamp, the read transaction is blocked; Before determining the preparation timestamp corresponding to the write transaction, the method further includes: Receive an instruction from the transaction manager to instruct the write transaction to enter the preparation state; wherein the instruction carries the maximum timestamp currently obtained by the transaction manager; Extract the maximum timestamp from the instruction and use it as the preparation timestamp for the write transaction.

2. A distributed database system, characterized in that, The system includes: a transaction manager and a resource manager; The resource manager, upon receiving a read transaction processing request, determines the row data targeted by the read transaction, wherein the read transaction carries a read timestamp; if the data state of the row data is modified by a write transaction and the write transaction is in a ready state, it determines the ready timestamp corresponding to the write transaction, wherein the ready timestamp is the maximum timestamp currently obtained, issued by the transaction manager to the resource manager when the write transaction enters the ready state; it compares the ready timestamp with the read timestamp; if the ready timestamp is greater than or equal to the read timestamp, it determines that the current version of the row data modified by the write transaction is not visible to the read transaction; it obtains the previous version of the current version of the row data; and compares... The read timestamp and the commit timestamp of the previous version are compared. If the read timestamp is greater than or equal to the commit timestamp of the previous version, the data in the previous version is read as the response result of the read transaction. If the read timestamp is less than the read timestamp, the read transaction is blocked. The read state is the state of the write transaction after the resource manager receives the read instruction from the transaction manager. The read instruction is used to ask the resource manager whether it is ready to commit. The write transaction being in the read state indicates that the write transaction has modified the row data but has not yet committed the modified version data. The read timestamp is less than the commit timestamp when the write transaction committed the modified version data. The transaction manager is used to send the currently acquired maximum timestamp to the resource manager when the write transaction enters the preparation state; The resource manager is further configured to receive an instruction issued by the transaction manager, which instructs the write transaction to enter a preparation state, before determining the preparation timestamp corresponding to the write transaction; wherein the instruction carries the maximum timestamp currently obtained by the transaction manager; and extract the maximum timestamp from the instruction as the preparation timestamp corresponding to the write transaction.

3. The system according to claim 2, characterized in that, The system also includes: a global timestamp server; The transaction manager is also used to obtain the timestamp to be used for each write / read transaction from the global timestamp server; The global timestamp server is used to assign timestamps to the write / read transaction.

4. A transaction processing apparatus, characterized in that, Applied to a file explorer, the device includes: The first determining module is used to determine the row data targeted by the read transaction when a read transaction processing request is received; wherein the read transaction carries a read timestamp; The second determining module is used to determine the preparation timestamp corresponding to the write transaction if the data status of the row data is modified by a write transaction and the write transaction is in a preparation state; wherein, the preparation timestamp is the maximum timestamp currently obtained by the transaction manager when the write transaction enters the preparation state; the preparation state is the state of the write transaction after the resource manager receives the preparation instruction issued by the transaction manager; the preparation instruction is used to query the resource manager whether it is ready to commit; the write transaction being in a preparation state indicates that the write transaction has modified the row data but has not yet committed the modified version data; the preparation timestamp is less than the commit timestamp when the write transaction committed the modified version data. The comparison module is used to compare the size of the preparation timestamp with the read timestamp; The determination module is used to determine that if the preparation timestamp is greater than or equal to the read timestamp, the current version of the row data modified by the write transaction is not visible to the read transaction; obtain the previous version of the current version of the row data; compare the commit timestamp in the previous version with the read timestamp; if the read timestamp is greater than or equal to the commit timestamp in the previous version, read the data in the previous version as the response result of the read transaction; The blocking module is used to block the read transaction if the preparation timestamp is less than the read timestamp; The second determining module is further configured to receive an instruction issued by the transaction manager, which instructs the write transaction to enter the preparation state, before determining the preparation timestamp corresponding to the write transaction; extract the maximum timestamp from the instruction as the preparation timestamp corresponding to the write transaction; wherein the instruction carries the maximum timestamp currently obtained by the transaction manager.

5. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the steps of the method of claim 1.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method described in claim 1.

Images