Distributed transaction processing method and device, electronic equipment and storage medium
By forwarding distributed transaction requests to the primary GTM node and backup GTM node in the distributed database, generating GTIDs and synchronizing the active transaction list, the performance limitation of the distributed database is solved, and the multi-active nature of the GTM node and the resource utilization rate are improved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-27
- Publication Date
- 2026-04-14
AI Technical Summary
Traditional centralized databases face challenges in terms of scalability, availability, and cost, while the performance of distributed databases is limited by the processing power of the master GTM node.
Distributed transaction requests are forwarded to the primary GTM node and the backup GTM node. All GTM nodes can generate GTIDs and synchronize the list of active transactions to the backup GTM node, thereby achieving multi-active GTM nodes and improving resource utilization and performance processing limits.
By increasing the efficiency of GTM in generating distributed transaction IDs, the performance processing capability of the GTM cluster was improved, enabling multi-active operation of GTM nodes and effective utilization of resources.
Smart Images
Figure CN121858664A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of distributed database and distributed transaction management technology, and more specifically, to a method, apparatus, electronic device, and storage medium for processing distributed transactions. Background Technology
[0002] With the rapid development of industries such as the Internet, finance, and the Internet of Things, the volume of data is exploding, posing severe challenges to traditional centralized databases in terms of scalability, availability, and cost. Against this backdrop, distributed database systems have become the mainstream solution due to their excellent horizontal scalability and high availability. Compared to centralized databases, distributed databases store data across multiple physical nodes, meaning a single transaction may operate on data on different physical nodes. Furthermore, distributed databases must still meet the fundamental requirement of ACID properties for transactions. Therefore, distributed databases generally involve a Global Transaction Manager (GTM) component. This component is primarily used to generate globally unique distributed transaction identifiers (GTIDs), serving both to uniquely identify distributed transactions and to manage the parallel read and write operations of multiple concurrent distributed transactions.
[0003] In the target GTM architecture, only one GTM node provides services, and each distributed transaction needs to apply for a distributed transaction ID. Therefore, the upper limit of the performance processing capability of the distributed database is also subject to the processing capability of the master GTM node. Summary of the Invention
[0004] In view of the above situation, embodiments of this application provide a method, apparatus, electronic device and storage medium for processing distributed transactions, which aim to solve the above problems or at least partially solve the above problems.
[0005] In a first aspect, embodiments of this application provide a method for processing distributed transactions, the method comprising: In response to receiving one or more distributed transaction requests, the distributed transaction request is sent to the corresponding target node, which is determined from one primary distributed transaction management component (GTM) node or multiple backup GTM nodes; Obtain the first globally distributed transaction identifier (GTID) generated by the primary GTM node and the second GTID generated by each backup GTM node, and record the first GTID in the active transaction list of the primary GTM node; The second GTID generated by each backup node is sent to the primary GTM node and recorded in the active transaction list of the primary GTM. The list of active transactions of the primary GTM node is synchronized to each backup GTM node.
[0006] Secondly, embodiments of this application also provide a distributed transaction processing apparatus, the apparatus comprising: The sending module is used to send the distributed transaction request to the corresponding target node in response to receiving one or more distributed transaction requests, wherein the target node is determined from one primary distributed transaction management component (GTM) node or multiple backup GTM nodes. The recording module is used to obtain the first globally distributed transaction identifier (GTID) generated by the master GTM node and the second GTID generated by each backup GTM node, and record the first GTID in the active transaction list of the master GTM node. The sending module is also used to send the second GTID generated by each backup node to the primary GTM node and record it in the active transaction list of the primary GTM; The synchronization module is used to synchronize the list of active transactions of the primary GTM node to each backup GTM node.
[0007] Thirdly, embodiments of this application also provide an electronic device, including: a processor; and a memory arranged to store computer-executable instructions, which, when executed, cause the processor to perform the steps described in the first aspect.
[0008] Fourthly, embodiments of this application also provide a computer-readable storage medium that stores one or more programs, which, when executed by an electronic device including multiple applications, cause the electronic device to perform the steps described in the first aspect.
[0009] The at least one technical solution adopted in this application can achieve the following beneficial effects: by forwarding distributed transaction requests to the primary GTM node and the backup GTM node respectively, both the primary and backup GTM nodes can process the distributed transaction requests, generate corresponding GTIDs, record all GTIDs in the active transaction list, and synchronize the active transaction list to the backup GTM node. This application utilizes the backup GTM node, with all GTM nodes responsible for generating distributed transaction IDs, effectively expanding the efficiency of GTM in generating distributed transaction IDs, improving resource utilization, achieving multi-active GTM nodes, and increasing the performance processing limit of the GTM cluster. Attached Figure Description
[0010] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1A flowchart illustrating the GTM architecture in the related technologies provided in the embodiments of this application is shown; Figure 2 A flowchart illustrating the distributed transaction processing method provided in an embodiment of this application is shown. Figure 3 A flowchart of a distributed transaction processing method provided in another embodiment of this application is shown; Figure 4 A flowchart of a distributed transaction processing method provided in another embodiment of this application is shown; Figure 5 A structural diagram of the distributed transaction processing apparatus provided in an embodiment of this application is shown; Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation
[0011] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0012] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such use can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the term "comprising" and its variations should be interpreted as open-ended terms meaning "including but not limited to."
[0013] As described in the background section, in the relevant GTM architecture, only one GTM node provides the service, such as... Figure 1 As shown, the master node is responsible for generating IDs for distributed transactions, while the standby node is responsible for synchronizing relevant information from the master node. It does not need to generate new distributed transaction IDs; only when the master GTM node fails will a standby GTM be promoted to master, taking over the services provided by the failed GTM. Because only one GTM node provides services, and each distributed transaction requires a distributed transaction ID, the performance limit of the distributed database is further constrained by the processing capacity of the master GTM node.
[0014] Based on this, the present invention proposes a method for processing distributed transactions. Distributed transaction requests are forwarded to both the primary GTM node and the backup GTM node. Both the primary and backup GTM nodes can process the distributed transaction requests, generate corresponding GTIDs, and record all GTIDs in an active transaction list. This active transaction list is then synchronized to the backup GTM node. This application utilizes the backup GTM node, with all GTM nodes responsible for generating distributed transaction IDs. This effectively expands the efficiency of GTM in generating distributed transaction IDs, improves resource utilization, enables multi-active GTM nodes, and increases the performance ceiling of the GTM cluster.
[0015] The present application will now be described in detail through specific embodiments.
[0016] Figure 2 This document illustrates a flowchart of a distributed transaction processing method provided in an embodiment of this application. Figure 2 It can be seen that this application includes at least steps S101-S104: Step S101: In response to receiving one or more distributed transaction requests, send the distributed transaction requests to the corresponding target nodes.
[0017] In some embodiments, when an application cluster sends a distributed transaction request to access a distributed database, the distributed transaction request is forwarded to the compute nodes after passing through a software / hardware load balancer. The compute nodes then sequentially send different distributed requests to the corresponding target nodes. Specifically, in one link, one distributed transaction request is sent to one GTM node, and subsequent distributed transactions are sent to the next GTM node.
[0018] The target node is determined from one primary GTM node or multiple backup GTM nodes.
[0019] Specifically, based on preset rules, different distributed transaction requests are sent to the corresponding target nodes.
[0020] In some embodiments, the default rule is round-robin. Specifically, when a compute node starts up, it obtains a list of currently available GTM nodes through the cluster management module, including: 1 GTM master node and N GTM standby nodes. Each node can correspond to one round-robin index. Based on the current round-robin index, the corresponding GTM node is selected from the node list. For example, if the current index is i, then the i-th node in the list is selected as the target node. If a GTM node failure is detected, it is removed from the round-robin list, the list is updated, and the round-robin index is adjusted according to the new list length.
[0021] In some embodiments, the preset rule is the number of distributed requests currently being processed by each GTM node. Specifically, upon receiving a distributed transaction request, the current request count of all available GTM nodes is obtained, and the node with the fewest current request counts is selected as the target node. If multiple nodes have the same request count, a round-robin selection is used to avoid a single node being continuously selected.
[0022] In some embodiments, the preset rule is the priority of distributed transaction requests. Specifically, priorities can be set for distributed transaction requests, such as prioritizing the allocation of nodes to requests with higher priorities, or matching nodes with corresponding processing capabilities based on the priority of the requests.
[0023] Step S102: Obtain the first GTID generated by the primary GTM node and the second GTID generated by each backup GTM node, and record the first GTID in the active transaction list of the primary GTM node.
[0024] In some embodiments, since there is parallel access among distributed transactions, it is necessary to use the distributed transaction ID to determine the order of transactions. Therefore, the generated GTID is a timestamp-based identifier with a timestamp precision of at least microseconds.
[0025] Step S103: Send the second GTID generated by each backup node to the primary GTM node and record it in the active transaction list of the primary GTM.
[0026] In some embodiments, since multiple nodes are involved, time synchronization needs to be configured between each GTM node. After the GTID is generated, it is sent synchronously to the master GTM node.
[0027] Step S104: Synchronize the list of active transactions of the primary GTM node to each standby GTM node.
[0028] like Figure 3 The diagram illustrates the data turnover process between steps S101-104 above: After various applications running in the APP cluster initiate distributed transaction requests, these requests are routed to the corresponding compute nodes (CNs). Each CN requests a GTID from the corresponding primary GTM node or backup GTM node based on the distributed transaction request. After each node generates a GTID, the primary GTM records the generated GTID in the active transaction list, and the backup GTM records the generated GTID in the active transaction list of the primary node. The primary node then synchronizes the active transaction list to all backup GTM nodes.
[0029] from Figure 2 and Figure 3As shown in the method, this application forwards distributed transaction requests to both the primary and backup GTM nodes. Both the primary and backup GTM nodes can process the distributed transaction requests, generate corresponding GTIDs, record all GTIDs in the active transaction list, and synchronize the active transaction list to the backup GTM node. This application utilizes the backup GTM node, with all GTM nodes responsible for generating distributed transaction IDs, effectively expanding the efficiency of GTM in generating distributed transaction IDs, improving resource utilization, achieving multi-active GTM nodes, and increasing the performance ceiling of the GTM cluster.
[0030] In some embodiments of this application, in the above method, after a distributed transaction is committed or rolled back, the corresponding GTID is removed from the active transaction list of the primary GTM node.
[0031] Specifically, the application sends a transaction end command to the distributed database through the compute node (CN). The command carries the GTID of the transaction. The CN verifies the transaction status: first, it checks the locally cached transaction-GTM node mapping relationship (recording which GTM node generated the GTID), confirms that the transaction is in an active state (not prematurely terminated), and then forwards the end request to the corresponding GTM node (which may be the primary node or the standby node). If the end request is sent to the standby node: the standby node first completes the commit / rollback of its own transaction log, and then forwards the GTID end notification to the primary GTM node, which handles the removal operation uniformly. If the end request is sent directly to the primary node: the primary node directly confirms that the transaction has been completed and triggers the removal process.
[0032] In some embodiments, if the primary GTM node fails before removing the GTID: the newly elected primary GTM node (the original backup GTM node) loads the active transaction list and finds that the GTID is still active, but the corresponding transaction has exceeded the preset timeout period (e.g., 30 seconds), then automatically performs forced removal. If the primary GTM node does not synchronize with the backup node after removal: when the new primary GTM node starts, it compares its own active list with the latest data in Redis, and automatically deletes the redundant GTID locally after finding a difference.
[0033] In some embodiments of this application, in the above method, when the primary GTM node fails, such as Figure 4 As shown, distributed transaction requests are forwarded to the normally operating backup GTM nodes; a new primary GTM node is elected from multiple backup GTM nodes, the new primary GTM node takes over the active transaction list, and all subsequent GTIDs generated by backup GTM nodes are sent to the new primary GTM node.
[0034] Specifically, the GTM cluster management module can confirm the failure of the primary GTM through two mechanisms: Heartbeat detection: The primary GTM sends a heartbeat packet (containing node status and load metrics) to the management module every second. If no heartbeat is received for three consecutive times (3 seconds), it is marked as a suspected failure. Service activation detection: The management module sends a simulated GTID generation request (empty transaction) to the suspected failed primary GTM. If there is no response within 100ms, the primary node failure is confirmed. Before initiating a new primary node election, the management module filters nodes that meet the conditions from the backup GTM nodes, and then selects a new primary GTM node based on preset conditions. For example, the backup node with the smallest synchronization delay between the active transaction list and the original primary node is selected (e.g., backup GTM1 has a synchronization delay of 15ms, backup GTM2 has a synchronization delay of 25ms, so backup GTM1 is selected); another example is the node with the lowest CPU utilization and memory utilization (e.g., backup GTM1 has a load of 60%, backup GTM2 has a load of 70%, so backup GTM1 is selected).
[0035] Furthermore, a promotion command is sent to the selected standby GTM. The new master GTM inherits the active transaction list of the original master GTM node and starts GTID generation, master-standby synchronization services, etc. A GTM master node switchover notification is sent to all compute nodes (CNs) via the cluster message bus (such as Kafka). Additionally, if the original master GTM recovers, the new master GTM node can be demoted to a standby GTM node, or the original master GTM can be demoted to a standby GTM node, synchronizing the new master's active transaction list to ensure data consistency.
[0036] In some embodiments of this application, during the above method, the GTID of the current transaction, the GTID in the active transaction list, and the GTID stored in the data record are compared during data read and write operations. If the GTID in the data table record is not in the active transaction list, the record is updated by other active transactions. If the GTID in the data table record is in the active transaction list, the record cannot be updated by other parallel distributed transactions, and the read operation on the record is performed according to the database isolation level rules.
[0037] Specifically, each record in the data table stores an additional `last_gtid` field to record the GTID of the last distributed transaction that modified the record. Simultaneously, the primary GTM node maintains a globally active transaction list through distributed storage, recording all uncommitted or unrolled GTIDs, and this list is synchronized in real-time to the backup GTM nodes and the local cache of each CN. When a write operation is performed, the CN first parses the GTID of the current transaction (let's say G1), then reads the `last_gtid` of the target record (let's say G0), and then queries the active transaction list to determine if G0 exists: if G0 is not in the active transaction list, it means the transaction that last modified the record has completed (committed or rolled back), and the current transaction G1 can execute the modification normally, updating the record's `last_gtid` to G1 after the operation is complete; if G0 is in the active transaction list, it means the transaction that last modified the record is still in progress, and the current transaction G1 needs to wait (enter the blocking queue) or return a transaction conflict according to the conflict policy, avoiding consistency issues caused by concurrent transactions modifying the same data.
[0038] For read operations, at the Read Committed level, CN checks whether the record's last_gtid (G0) is in the active list. If it is not, the record is read directly; if it is, the previous version of the record is read. At the Repeatable Read level, CN obtains a snapshot GTID set at the start of a transaction. During read operations, only the version of the record whose last_gtid is not in this snapshot set is read, ensuring that the read results are consistent during the transaction.
[0039] In summary, this application can be used to improve the processing performance of the distributed transaction manager GTM in existing distributed databases. After applying this application, the hardware resources of all GTM nodes are effectively utilized, improving the responsiveness of GTM and enhancing the distributed transaction processing capability.
[0040] In some embodiments of this application, a distributed transaction processing apparatus is provided, which corresponds one-to-one with the distributed transaction processing methods in the above embodiments. For example... Figure 5 As shown, the distributed transaction processing device includes a sending module 101, a recording module 102, a synchronization module 103, a cleanup module 104, an election module 105, and a comparison module 106.
[0041] Sending module 101 is used to send the distributed transaction request to the corresponding target node in response to receiving one or more distributed transaction requests, wherein the target node is determined from one primary distributed transaction management component (GTM) node or multiple backup GTM nodes; The recording module 102 is used to obtain the first globally distributed transaction identifier (GTID) generated by the master GTM node and the second GTID generated by each backup GTM node, and record the first GTID in the active transaction list of the master GTM node. The sending module 101 is also used to send the second GTID generated by each backup node to the primary GTM node and record it in the active transaction list of the primary GTM; The synchronization module 103 is used to synchronize the active transaction list of the primary GTM node to each backup GTM node.
[0042] In some embodiments of this application, in the above-described apparatus, the sending module 101 is specifically used to send different distributed transaction requests to the corresponding target nodes based on preset rules; the preset rules include at least one of the following: polling, the number of distributed requests currently being processed by each GTM node, and the priority of the distributed transaction requests.
[0043] In some embodiments of this application, in the above-described apparatus, the generated GTID is a timestamp-based identifier with a timestamp accuracy of at least microseconds.
[0044] In some embodiments of this application, in the above-described apparatus, the time of each GTM node is kept synchronized before the GTID is generated; the sending module 101 is specifically used to synchronously send the second GTID generated by each backup node to the master GTM node.
[0045] In some embodiments of this application, in the above-described apparatus, the cleanup module 104 is used to remove the corresponding GTID from the active transaction list of the master GTM node after a distributed transaction is committed or rolled back.
[0046] In some embodiments of this application, in the above-described apparatus, the election module 105 is used to forward distributed transaction requests to normally operating backup GTM nodes when the primary GTM node fails; elect a new primary GTM node from the plurality of backup GTM nodes, and the new primary GTM node takes over the active transaction list. In some embodiments of this application, in the above-described apparatus, the comparison module 106 is used to compare the GTID of the current transaction, the GTID in the active transaction list, and the GTID stored in the data record during data read / write operations. If the GTID in a data table record is not in the list of active transactions, the record is updated by other active transactions; If the GTID in a data table record is in the list of active transactions, the record cannot be updated by other parallel distributed transactions, and read operations on the record are performed according to the database isolation level rules.
[0047] It should be noted that any of the above-mentioned distributed transaction processing devices can implement the aforementioned distributed transaction processing methods one by one, which will not be elaborated here.
[0048] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Figure 6 As shown, at the hardware level, this electronic device includes a processor, and optionally also includes an internal bus, a network interface, and memory. The memory may include main memory, such as high-speed random-access memory (RAM), or it may include non-volatile memory, such as at least one disk drive. Of course, this electronic device may also include other hardware required for other business operations.
[0049] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 6 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.
[0050] Memory is used to store programs. Specifically, programs may include program code, which includes computer operation instructions. Memory may include main memory and non-volatile memory, and provides instructions and data to the processor.
[0051] The processor reads the corresponding computer program from non-volatile memory into main memory and then runs it, forming a distributed transaction processing device at the logical level. The processor executes the program stored in memory and specifically performs the aforementioned methods.
[0052] The processor may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in the memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method.
[0053] The electronic device can execute the distributed transaction processing method provided in several embodiments of this application, and is implemented as a distributed transaction processing device. Figure 5 The functions of the embodiments shown are not described in detail here.
[0054] This application also proposes a computer-readable storage medium that stores one or more programs, the programs including instructions that, when executed by an electronic device including multiple applications, enable the electronic device to perform the distributed transaction processing method provided in several embodiments of this application.
[0055] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0056] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0057] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0058] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0059] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.
[0060] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.
[0061] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.
[0062] It should also be noted that 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 limitation, 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.
[0063] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0064] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.
Claims
1. A method for processing distributed transactions, characterized in that, The method includes: In response to receiving one or more distributed transaction requests, the distributed transaction request is sent to the corresponding target node, which is determined from one primary distributed transaction management component (GTM) node or multiple backup GTM nodes; Obtain the first globally distributed transaction identifier (GTID) generated by the primary GTM node and the second GTID generated by each backup GTM node, and record the first GTID in the active transaction list of the primary GTM node; The second GTID generated by each backup node is sent to the primary GTM node and recorded in the active transaction list of the primary GTM. The list of active transactions of the primary GTM node is synchronized to each backup GTM node.
2. The method according to claim 1, characterized in that, Sending each distributed transaction request to the corresponding target node includes: Based on preset rules, different distributed transaction requests are sent to the corresponding target nodes; The preset rules include at least one of the following: polling, the number of distributed requests currently being processed by each GTM node, and the priority of distributed transaction requests.
3. The method according to claim 1, characterized in that, The generated GTID is a timestamp-based identifier with a timestamp precision of at least microseconds.
4. The method according to claim 1, characterized in that, Before generating GTID, the time of each GTM node is kept synchronized; Sending the second GTID generated by each backup node to the primary GTM node includes: The second GTID generated by each backup node is synchronously sent to the primary GTM node.
5. The method according to claim 1, characterized in that, The method further includes: After a distributed transaction is committed or rolled back, the corresponding GTID is removed from the list of active transactions of the primary GTM node.
6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: When the primary GTM node fails, the distributed transaction request is forwarded to the normally operating backup GTM node; A new primary GTM node is elected from the plurality of backup GTM nodes, and the new primary GTM node takes over the list of active transactions.
7. The method according to claim 1, characterized in that, The method further includes: During data read and write operations, compare the GTID of the current transaction, the GTID in the active transaction list, and the GTID stored in the data record; If the GTID in a data table record is not in the list of active transactions, the record is updated by other active transactions; If the GTID in a data table record is in the list of active transactions, the record cannot be updated by other parallel distributed transactions, and read operations on the record are performed according to the database isolation level rules.
8. A distributed transaction processing apparatus, characterized in that, The device includes: The sending module is used to send the distributed transaction request to the corresponding target node in response to receiving one or more distributed transaction requests, wherein the target node is determined from one primary distributed transaction management component (GTM) node or multiple backup GTM nodes. The recording module is used to obtain the first globally distributed transaction identifier (GTID) generated by the master GTM node and the second GTID generated by each backup GTM node, and record the first GTID in the active transaction list of the master GTM node. The sending module is also used to send the second GTID generated by each backup node to the primary GTM node and record it in the active transaction list of the primary GTM; The synchronization module is used to synchronize the list of active transactions of the primary GTM node to each backup GTM node.
9. An electronic device, comprising: processor; as well as A memory configured to store computer-executable instructions, characterized in that, when executed, the executable instructions cause the processor to perform the steps of the distributed transaction processing method as described in any one of claims 1-7.
10. A computer-readable storage medium storing one or more programs, characterized in that, When the one or more programs are executed by an electronic device comprising multiple applications, the electronic device performs the steps of the distributed transaction processing method as described in any one of claims 1-7.