A transaction processing method, apparatus and device across data centers

Abstract

This specification discloses a cross-datacenter transaction processing method, apparatus, and device. Applied to a distributed system consisting of multiple data centers, the scheme includes: a coordinator node in a first data center receiving and parsing a transaction request sent by a client to obtain one or more sub-transactions corresponding to different data centers; the coordinator node determining the data center corresponding to the sub-transaction as a second data center; if the second data center is not the first data center, determining a proxy coordinator node within the second data center and sending the sub-transaction to the proxy coordinator node; the proxy coordinator node determining the data node where the copy of the data shard involved in the sub-transaction is located within the second data center, executing the sub-transaction through remote direct memory access to the data node, and responding to the coordinator node based on the execution result; the coordinator node continuing to process transaction requests based on the responses from each proxy coordinator node.

Description

Technical Field

[0001] This specification relates to the field of database technology, and in particular to a method, apparatus, and device for cross-data center transaction processing. Background Technology

[0002] Currently, with the continuous expansion of cluster scale, the high availability of distributed database systems is a key and challenging issue facing both industry and academia. Typically, distributed systems use redundancy to store multiple copies of each data shard across different nodes. When some nodes fail, the nodes storing the same data shard can take over and continue providing external access, preventing data loss or prolonged system downtime. However, for situations such as a complete power outage in the data center or a city-wide power system failure that could lead to a data center-wide failure, backup nodes need to be set up for the data shards in other data centers across different data centers or cities to achieve disaster recovery.

[0003] Providing redundant copies for data sharding can improve system availability, but it also introduces additional overhead, such as hardware costs, performance, and consistency issues. In distributed systems spanning multiple data centers, network factors, especially cross-data center networks, are typically the main issues affecting the performance of distributed transaction execution and replica synchronization.

[0004] Therefore, for scenarios spanning multiple data centers, a more efficient and reliable distributed transaction processing solution is needed. Summary of the Invention

[0005] This specification provides one or more embodiments of a cross-data center transaction processing method, apparatus, device, and storage medium to solve the following technical problem: for cross-data center scenarios, a more efficient and reliable distributed transaction processing solution is needed.

[0006] To solve the above-mentioned technical problems, one or more embodiments of this specification are implemented as follows:

[0007] This specification provides one or more embodiments of a cross-datacenter transaction processing method, applied to a distributed system consisting of multiple data centers, each containing multiple nodes, with data sharded for storage, and each data shard having replicas in two or more of the data centers. The method includes:

[0008] The coordinator node in the first data center receives and parses the transaction requests sent by the client, and obtains one or more sub-transactions corresponding to one data center respectively.

[0009] The coordinator node determines the data center corresponding to the sub-transaction as the second data center. If the second data center is not the first data center, a proxy coordinator node is determined within the second data center, and the sub-transaction is sent to the proxy coordinator node.

[0010] The agent coordinator node determines the data node in the second data center where the replica of the data shard involved in the sub-transaction is located, executes the sub-transaction by performing remote direct memory access on the data node, and responds to the coordinator node based on the execution result;

[0011] The coordinator node continues to process the transaction request based on the responses from each of the proxy coordinator nodes.

[0012] This specification provides one or more embodiments of a cross-datacenter transaction processing apparatus, applied to a distributed system consisting of multiple data centers, each data center containing multiple nodes, with data sharded for storage, each data shard having replicas in two or more of the data centers. The apparatus includes:

[0013] The request parsing module of the coordinator node located in the first data center receives and parses the transaction requests sent by the client, and obtains one or more sub-transactions corresponding to one data center respectively.

[0014] The transaction sending module of the coordinator node determines the data center corresponding to the sub-transaction as the second data center. If the second data center is not the first data center, a proxy coordinator node is determined in the second data center, and the sub-transaction is sent to the proxy coordinator node.

[0015] The transaction execution module of the agent coordinator node located in the second data center determines the data node in the second data center where the copy of the data shard involved in the sub-transaction is located, executes the sub-transaction by performing remote direct memory access on the data node, and responds to the coordinator node according to the execution result;

[0016] The response processing module of the coordinator node continues to process the transaction request based on the responses of each of the proxy coordinator nodes.

[0017] This specification provides one or more embodiments of a cross-datacenter transaction processing device, applied to a distributed system consisting of multiple data centers, each data center containing multiple nodes, with data sharded for storage, each data shard having replicas in two or more of the data centers. The device includes:

[0018] At least one processor; and,

[0019] A memory communicatively connected to the at least one processor; wherein,

[0020] The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to:

[0021] The coordinator node in the first data center receives and parses the transaction requests sent by the client, and obtains one or more sub-transactions corresponding to one data center respectively.

[0022] The coordinator node determines the data center corresponding to the sub-transaction as the second data center. If the second data center is not the first data center, a proxy coordinator node is determined within the second data center, and the sub-transaction is sent to the proxy coordinator node.

[0023] The agent coordinator node determines the data node in the second data center where the replica of the data shard involved in the sub-transaction is located, executes the sub-transaction by performing remote direct memory access on the data node, and responds to the coordinator node based on the execution result;

[0024] The coordinator node continues to process the transaction request based on the responses from each of the proxy coordinator nodes.

[0025] This specification provides one or more embodiments of a non-volatile computer storage medium applied to a distributed system consisting of multiple data centers. Each data center contains multiple nodes, and data within the data center is stored in shards. Each data shard has copies in two or more of the data centers. The medium stores computer-executable instructions configured as follows:

[0026] The coordinator node in the first data center receives and parses the transaction requests sent by the client, and obtains one or more sub-transactions corresponding to one data center respectively.

[0027] The coordinator node determines the data center corresponding to the sub-transaction as the second data center. If the second data center is not the first data center, a proxy coordinator node is determined within the second data center, and the sub-transaction is sent to the proxy coordinator node.

[0028] The agent coordinator node determines the data node in the second data center where the replica of the data shard involved in the sub-transaction is located, executes the sub-transaction by performing remote direct memory access on the data node, and responds to the coordinator node based on the execution result;

[0029] The coordinator node continues to process the transaction request based on the responses from each of the proxy coordinator nodes.

[0030] The above-described at least one technical solution adopted in one or more embodiments of this specification can achieve the following beneficial effects: a remote direct memory access network is built in each data center of the distributed system, which improves the efficiency of data reading and writing and communication between replicas within the data center. For communication between data centers, through the coordinator node and the proxy coordinator node, the large amount of cross-data center TCP / IP communication (or some other cross-domain communication) currently required to execute distributed transactions is transformed into remote direct memory access requests within the data center where the proxy coordinator node is located. This improves the processing efficiency of distributed transactions, ensures data consistency across data centers, and has good reliability. Moreover, it avoids the unreasonable expansion of the remote direct memory access network and effectively restricts the increase in costs. Attached Figure Description

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

[0032] Figure 1 A schematic diagram of a cross-data center data sharding replica and network deployment provided for one or more embodiments of this specification;

[0033] Figure 2 A flowchart illustrating a cross-data center transaction processing method provided for one or more embodiments of this specification;

[0034] Figure 3 This diagram illustrates an implementation scheme for cross-datacenter transaction read / write and verification phases in a practical application scenario provided by one or more embodiments of this specification.

[0035] Figure 4 A schematic diagram of the structure of a cross-data center transaction processing apparatus provided for one or more embodiments of this specification;

[0036] Figure 5 This is a schematic diagram of the structure of a cross-data center transaction processing device provided for one or more embodiments of this specification. Detailed Implementation

[0037] This specification provides an embodiment of a cross-data center transaction processing method, apparatus, device, and storage medium.

[0038] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0039] In one or more embodiments of this specification, a data sharding and distributed deployment strategy is used to build massive amounts of data on low-cost PC servers. This provides database scalability while avoiding the dependence of traditional databases on high-performance servers, significantly reducing the hardware cost of building a database cluster. Furthermore, Remote Direct Memory Access (RDMA) technology is employed, which, compared to traditional networks, features high bandwidth and low latency. Building an RDMA network within the data center greatly improves network access efficiency within the same data center.

[0040] However, due to the stringent requirements of RDMA technology on network scale and underlying hardware, it is currently unsuitable for cross-data center or cross-metropolitan area use, and also difficult to use for cross-data center data access. Therefore, this application addresses distributed systems across data centers by building an RDMA network within the same data center. This transforms the cross-data center communication (mainly TCP / IP communication) required for read / write verification and replica synchronization of distributed transactions into RDMA access within the same data center as much as possible, thereby maximizing the network advantages of RDMA to improve the overall performance of transaction execution in the distributed system. Based on this approach, the solution of this application will be further described in detail below.

[0041] Figure 1 This specification provides a schematic diagram of cross-data center data sharding replication and network deployment for one or more embodiments. The distributed system consists of multiple data centers, each containing multiple nodes, and each node containing one or more machines. Data within a data center can be stored in shards, and each data shard has replicas in two or more data centers (the same data shard has multiple identical replicas, each of which is called a replica). The replicas of the same data shard are synchronized according to a predetermined strategy to ensure data consistency as much as possible.

[0042] exist Figure 1The diagram illustrates two data centers within a distributed system, designated as the first and second data centers. The first data center contains nodes 1 and 2, while the second data center contains nodes 3 and 4. Data shards A, B, C, and D are also shown. A has one replica on each of nodes 1, 2, and 4; B has one replica on each of nodes 1, 2, and 3; C has one replica on each of nodes 1, 3, and 4; and D has one replica on each of nodes 2, 3, and 4. The replica deployment strategy employed includes having at least three replicas for each data shard: one primary replica and the rest secondary replicas. The primary replica and at least one secondary replica are deployed on different nodes within the same data center. Simultaneously, secondary replicas are deployed in at least one other data center to provide disaster recovery capabilities. For example, if the replica of A on node 1 is the primary replica, then the replicas of A on nodes 2 and 4 are both secondary replicas. In the event of a primary replica failure, a rapid switchover to a secondary replica is possible within the data center. Furthermore, even if the entire data center fails, a switchover to a secondary replica in another data center is still possible. This data shard replica deployment method balances efficiency and reliability.

[0043] Within the same data center, RDMA communication is used. Cross-data center communication, such as TCP / IP communication, is used between different data centers. For example, when synchronizing different replicas of the same data shard, taking A as an example, when replicas of A on nodes 1 and 2 are synchronized, RDMA communication is used because they are both in the first data center. When replicas of A on nodes 1 and 4 are synchronized, TCP / IP communication is used because they are in the first and second data centers respectively. Other data shards, such as B, follow a similar pattern and will not be elaborated further. Figure 1 The deployment approach described in the document explains the processing flow of distributed transactions.

[0044] Figure 2 This document illustrates a flowchart of a cross-datacenter transaction processing method provided in one or more embodiments. This method can be applied to various business domains, including electronic payment, e-commerce, instant messaging, gaming, and government services. The process can be executed on machines in a distributed system, typically distributed database servers or cloud computing devices. Certain input parameters or intermediate results within the process can be manually adjusted to improve accuracy.

[0045] Figure 2 The process may include the following steps:

[0046] S202: The coordinator node in the first data center receives and parses the transaction requests sent by the client, and obtains one or more sub-transactions corresponding to one data center respectively.

[0047] This process is executed by any two data centers from multiple data centers working together. For ease of description, the data center that currently receives the transaction request will be referred to as the first data center.

[0048] In one or more embodiments of this specification, when database operations are required, the client sends a corresponding transaction request to the distributed system. The node in the distributed system that receives the transaction request is designated as the coordinator node. In this case, coordinator nodes exist in each data center, and the specific nodes that are coordinator nodes can change dynamically. For distributed transactions that need to be processed across data centers, the coordinator node performs cross-data center communication to instruct another data center to execute the transaction portion belonging to that data center.

[0049] Here, a transaction refers to a sequence of database operations that access or modify data items. When the nodes accessed or involved in the computation of these operations are not all located on the same machine (this falls under the category of cross-datacenter operations), the transaction is a distributed transaction; otherwise, it is a single-machine transaction. Like single-machine transactions, distributed transactions must satisfy atomicity, consistency, isolation, and durability.

[0050] A transaction request is used to request the execution of a transaction involving one or more data shards. The sequence of operations contained in the transaction is executed on these data shards. As mentioned earlier, if a data shard has multiple replicas, the corresponding operation can be executed on any one of the replicas. The other replicas are synchronized based on that replica to maintain data consistency. In scenarios that distinguish between master and slave replicas, the corresponding operation is executed on the master replica first.

[0051] In one or more embodiments of this specification, since the transaction corresponding to the transaction request may involve multiple data shards, and these data shards may belong to different data centers, the transaction is divided into multiple sub-transactions, each with its own corresponding data center. The data that the sub-transaction needs to operate on is contained within its corresponding data center. This facilitates more precise and minimal cross-data center communication by the coordinator node based on sub-transactions.

[0052] The granularity of sub-transaction division can be further refined. For example, sub-transactions corresponding to the same data center can be further divided according to the different data shards involved, so that each sub-transaction corresponds to a data shard within a data center.

[0053] In scenarios that distinguish between master and slave replicas, sub-transactions and their corresponding data centers are determined based on the master replica. Specifically, during the parsing of a transaction request sent by a client, the data shards involved in the transaction corresponding to the client's request are identified, and the data centers where the master replicas of each data shard reside are determined. For each data shard, the set of data shards whose master replicas reside in the same data center is defined as a sub-transaction within the transaction, and this data center is designated as the data center corresponding to that sub-transaction.

[0054] S204: The coordinator node determines the data center corresponding to the sub-transaction as the second data center. If the second data center is not the first data center, then a proxy coordinator node is determined in the second data center, and the sub-transaction is sent to the proxy coordinator node.

[0055] S202 may yield multiple sub-transactions, some of which correspond to data centers other than the first data center. S204 and S206 are for these sub-transactions; this is the first case.

[0056] Of course, there may also be another part of the sub-transactions corresponding to the first data center. In this second case, the second data center is the first data center. In this case, there is no need to communicate across data centers. The coordinator node directly determines the data node in the first data center where the copy of the data shard involved in the other part of the sub-transaction is located. Then, within the first data center, the sub-transaction is executed by remote direct memory access to the data node.

[0057] In comparison, this application focuses more on the first scenario, which requires communication across data centers. The following embodiments are further described primarily for the first scenario.

[0058] Within each data center, a small number of nodes (e.g., one) can act as proxy coordinator nodes, representing the nodes within that data center in responding to coordinator nodes from other data centers. This allows cross-data center communication to be concentrated between coordinator nodes and proxy coordinator nodes belonging to different data centers. Other nodes can communicate within their own data centers using more efficient RDMA (Remote Data Memory) communication. Previously, without coordinator and proxy coordinator nodes, it was necessary to establish separate TCP / IP connections across data centers with the nodes containing the data to be accessed. These numerous cross-data center TCP / IP connections are currently the performance bottleneck of distributed systems.

[0059] In one or more embodiments of this specification, a node can be pre-designated as the proxy coordinator node, providing direct communication between the coordinator node and the proxy coordinator node. Alternatively, the coordinator node can dynamically select the proxy coordinator node based on the actual situation of the current sub-transaction. For example, the node containing the most primary replicas involved in the current sub-transaction can be selected as the proxy coordinator node for this transaction (in which case most data accesses can be performed on the proxy coordinator node itself), thus further reducing inter-node communication within the second data center.

[0060] It should be noted that most of the examples above use TCP / IP communication as an example of cross-data center communication. Of course, other methods can also be used, such as UDP communication. However, the efficiency of these optional communication methods is lower than that of RDMA communication.

[0061] S206: The agent coordinator node determines the data node in the second data center where the copy of the data shard involved in the sub-transaction is located, executes the sub-transaction by performing remote direct memory access on the data node, and responds to the coordinator node according to the execution result.

[0062] In one or more embodiments of this specification, RDMA communication is pre-built in the second data center for database operations between nodes in the second data center, including data read / write, synchronization between replicas, etc.

[0063] RDMA can directly copy data from one computer's memory to the remote computer's memory, reducing the overhead of the remote CPU. Compared to traditional TCP / IP networks, RDMA networks feature high bandwidth and low latency. Furthermore, RDMA offers two key advantages: zero-copy and kernel bypass. Zero-copy means RDMA does not require copying data back and forth between user space and kernel space; kernel bypass means that I / O can prepare data and notify the network card to send and receive data at the user level, without going through the kernel, thus reducing system calls and context switching overhead.

[0064] For the scenario described in this solution, RDMA networks can reduce the CPU's involvement in network communication, and the saved CPU overhead can be used for transaction execution, thereby improving the efficiency of system transaction execution.

[0065] S208: The coordinator node continues to process the transaction request based on the responses of each of the proxy coordinator nodes.

[0066] In one or more embodiments of this specification, if the first data center also has a corresponding sub-transaction, the coordinator node can execute this sub-transaction. Based on the execution result and the responses of each proxy coordinator node, a comprehensive decision is made on how to continue processing the overall transaction corresponding to the transaction request, whether to directly commit to make the transaction truly effective, whether to roll back the transaction due to an anomaly, or whether to further verify the transaction, etc.

[0067] pass Figure 2 This method establishes a remote direct memory access network within each data center of the distributed system, improving the efficiency of data read / write and communication between replicas within the data center. For communication between data centers, through coordinator nodes and proxy coordinator nodes, the large amount of cross-data center TCP / IP communication (or other cross-domain communication) currently required for executing distributed transactions is transformed into remote direct memory access requests within the data center where the proxy coordinator node resides. This improves the processing efficiency of distributed transactions, ensures data consistency across data centers, and provides good reliability. Furthermore, it avoids the unreasonable expansion of the remote direct memory access network, effectively limiting cost increases.

[0068] based on Figure 2 In addition to the method described herein, this specification also provides some specific implementation schemes and extension schemes of this method, which will be further explained below.

[0069] As mentioned earlier in one or more embodiments of this specification, a transaction consists of a sequence of operations that read or modify database data items, including a read-write set. The read set contains the unique key values ​​of the data items the transaction needs to read and the results of those reads. The write set contains the key values ​​and the new values ​​to be written. Depending on the specific concurrency control algorithm, the read-write set often needs to record additional information; for example, for multi-version concurrency control algorithms, the read set needs to record the version being read, and so on.

[0070] Based on read-write sets, the execution process of a sub-transaction includes at least a read-write phase. To ensure the correct order between transactions, there is an optional verification phase after the read-write phase. If concurrency control algorithms that can correctly control the transaction order are used, such as No-Wait and Wait-Die algorithms based on two-phase locks, or T / O algorithms based on timestamp sorting, then the aforementioned verification phase is not required.

[0071] Based on this, after the proxy coordinator node receives the sub-transaction from the coordinator node, during the read / write phase of the sub-transaction, it accesses the corresponding nodes in the second data center via the RDMA network to perform corresponding read / write operations on the replicas (preferably primary replicas) of the relevant data shards according to the read / write set. Afterwards, it feeds back the corresponding read / write operation results to the coordinator node. If the sub-transaction also has a verification phase, the coordinator node, after receiving all read / write operation results, can further verify them with at least the necessary proxy coordinator nodes. In this case, the verification phase of the sub-transaction corresponding to these proxy coordinator nodes begins, and the verification results are also fed back to the coordinator node by the proxy coordinator nodes. If all required verifications are successful and all read / write operations are successful, the coordinator node can commit the transaction. However, if the processing results of one or more phases of the sub-transaction reported by the proxy coordinator nodes are abnormal, or if the coordinator node itself experiences an abnormality in executing the sub-transaction, the coordinator node can roll back the transaction. Thus, the reliability of the distributed transaction processing process is guaranteed globally.

[0072] In one or more embodiments of this specification, although a proxy coordinator node is set, the communication channel between data centers is narrowed by the proxy coordinator node. Therefore, when the amount of sub-transactions sent by the coordinator node is large, the burden on the proxy coordinator node will increase. Especially in the case of a dynamic proxy coordinator node, a node with ordinary capabilities may be used as a dynamic proxy coordinator node, which will adversely affect the normal business on that node.

[0073] To address the issues raised in the previous paragraph, this application further provides solutions, including: minimizing the burden on the proxy coordinator node within the second data center to further address the target nodes (the nodes where the primary replicas of the sub-transactions reside) for each sub-transaction; allowing the proxy coordinator node to cooperate with as few target nodes as possible within the second data center to quickly and relatively evenly distribute a large number of sub-transactions throughout the entire second data center; then, at least most of the nodes within the second data center adaptively and distributedly process the sub-transaction flow based on the RDMA network within the center; and finally, the proxy coordinator node can collect the processing results within the center.

[0074] For example, if the second data center is not the first data center, the coordinator node determines whether multiple sub-transactions correspond to the same second data center (this may occur if sub-transactions are divided according to data sharding). If so, and the second data center is not the first data center, these multiple sub-transactions are packaged into a sub-transaction packet, and sent to the proxy coordinator node in a single round of communication (meaning that for a transaction request, only one sub-transaction is sent to the same second data center). This avoids multiple rounds of communication caused by multiple sub-transactions. Furthermore, after sending the sub-transaction packet to the proxy coordinator node, the proxy coordinator node triggers the sub-transaction packet to perform a random walk among nodes in the second data center via the RDMA network for adaptive processing of the sub-transactions, without needing to correctly access the target nodes corresponding to each sub-transaction in the packet. During the random walk, for each node reached, it is determined whether the node can support the execution of at least some of the transactions in the sub-transaction packet. If so, the at least some transactions are executed and the sub-transaction packet is modified accordingly, and the walk continues until the sub-transaction packet is completed.

[0075] For the node reached during the current walk, the current node or the previous node can determine whether the current node can support the execution of at least part of the transactions in the sub-transaction package (i.e., whether it has a partial corresponding primary replica). If so, at least part of the transactions are executed and the sub-transaction package is modified accordingly (e.g., marking whether the sub-transaction is executed, or removing executed sub-transactions, etc.). Then the walk continues until the sub-transaction package is completed. During the random walk, there is no need for the proxy coordinator node to intervene or access the nodes. It can simply wait for node feedback, thereby effectively reducing the burden on the proxy coordinator node and making fuller use of the capabilities of the RDMA network in the second data center.

[0076] Furthermore, in the schemes described above, the more sub-transaction packets that simultaneously perform random walks within the same second data center, the higher the adaptive processing efficiency may be, and the lower the proportion of invalid walks (where the walk leads to a node that does not have the corresponding primary replica). Based on this, the scheme can be restarted under appropriate conditions. For example, it can be determined whether the number of sub-transactions contained in a sub-transaction packet exceeds a set threshold, and / or whether the frequency at which the proxy coordinator node receives sub-transaction packets sent by the coordinator node exceeds a set threshold. If so, the scheme can be restarted; otherwise, it can be temporarily deactivated, and a scheme where the proxy coordinator node precisely accesses the target node for the sub-transactions can be adopted instead.

[0077] Based on the above description, and more intuitively, one or more embodiments of this specification also provide a schematic diagram of an implementation scheme for cross-datacenter transaction read / write and verification phases in a practical application scenario, such as... Figure 3As shown in the diagram. In this scenario, the sub-transaction has a read / write phase and a verification phase. There are three data shards A, B, and C, each with three replicas. LeaderX represents the primary replica of data shard X, FollowerX_1 represents the secondary replica of data shard X within the same data center, and FollowerX_2 represents the secondary replica of data shard X in another data center. When the primary replica is available, only the primary replica is accessed.

[0078] exist Figure 3 The transaction processing procedure in [the context of the transaction] includes the following steps:

[0079] ① The coordinator node (node ​​1) receives a transaction request from a client, the corresponding transaction is denoted as Txn 1, and parses it to obtain the set of operations (which can represent the corresponding sub-transactions) on each data center involved in executing the transaction. In this example, the specific parsing involves the set of operations Ops 1 on the first data center and the set of operations Ops 2 on the second data center.

[0080] ② The coordinator node selects a node as the proxy coordinator node for the transaction in each data center and sends the set of operations in that data center to the corresponding proxy coordinator. In this example, the coordinator node selects node 3 as the proxy coordinator node for the transaction in the second data center and sends Ops 2 from the second data center to node 3 via the TCP / IP network.

[0081] ③ The coordinator node and the proxy coordinator node complete the read and write operations of the corresponding sub-transactions based on the operation set on their respective data centers. At this time, access within the data center is based on local memory or on the RDMA network within the data center, resulting in low network latency. In this example, the coordinator node and the proxy coordinator node execute the corresponding sub-transactions SubTxn 1 and SubTxn 2 read and write requests based on Ops 1 and Ops 2, respectively.

[0082] ④ After completing the data access for the sub-transaction, the agent coordinator node returns the corresponding read / write access results to the coordinator node via the TCP / IP network.

[0083] ⑤ The coordinator node waits for all proxy coordinator nodes to return read and write access results, and then sends a verification request to all proxy coordinator nodes to enable each sub-transaction to enter the verification phase synchronously.

[0084] ⑥ The coordinator node and the proxy coordinator node each complete the verification of the local read / write set based on the operation set on their respective data centers. At this time, access within the data center is based on local memory or on the RDMA network within the data center, resulting in low network latency. In this example, the coordinator node and the proxy coordinator node verify the corresponding SubTxn 1 and SubTxn 2 based on Ops 1 and Ops 2, respectively.

[0085] ⑦ After the proxy coordinator nodes complete the verification of their respective sub-transactions, they send the verification results to the coordinator node. The coordinator node then combines the verification results of each sub-transaction to determine whether the transaction (the corresponding sub-transaction or Txn 1 as a whole) has passed the verification, and thus decides whether the transaction needs to be committed or rolled back.

[0086] pass Figure 3 The proposed solution optimizes the read, write, and verification mechanism for cross-data center transactions based on internal RDMA in a distributed system with multiple data centers. By leveraging the RDMA network to accelerate the internal network of the data center, the solution reduces the number of cross-domain TCP / IP network communications by converting cross-data center remote TCP / IP network communications into RDMA network communications within the data center as much as possible when accessing remote data. This improves both CPU utilization and transaction throughput.

[0087] Based on the same idea, one or more embodiments of this specification also provide apparatus and devices corresponding to the above methods, such as... Figure 4 , Figure 5 As shown.

[0088] Figure 4 This specification provides a schematic diagram of a cross-datacenter transaction processing apparatus according to one or more embodiments, applicable to a distributed system consisting of multiple data centers. Each data center contains multiple nodes, and data within each data center is stored in shards. Each data shard has replicas in two or more of the data centers. The apparatus includes:

[0089] The request parsing module 402 of the coordinator node located in the first data center receives and parses the transaction request sent by the client to obtain one or more sub-transactions corresponding to one data center respectively.

[0090] The transaction sending module 404 of the coordinator node determines the data center corresponding to the sub-transaction as the second data center. If the second data center is not the first data center, a proxy coordinator node is determined in the second data center, and the sub-transaction is sent to the proxy coordinator node.

[0091] The transaction execution module 406 of the agent coordinator node located in the second data center determines the data node in the second data center where the copy of the data shard involved in the sub-transaction is located, executes the sub-transaction by performing remote direct memory access on the data node, and responds to the coordinator node according to the execution result;

[0092] The response processing module 408 of the coordinator node continues to process the transaction request based on the responses of each of the proxy coordinator nodes.

[0093] Optionally, the sub-transaction includes a read-write set;

[0094] The transaction execution module 406 performs corresponding read and write operations on the copies of the data shards involved, according to the read and write set, during the read and write phase of the sub-transaction.

[0095] The response processing module 408, based on the response of the proxy coordinator node, if it determines that the read / write phase has been successfully completed and the sub-transaction has a verification phase, sends a verification request to the proxy coordinator node so that the sub-transaction enters the verification phase to verify whether the order between transactions is correct.

[0096] Optionally, the response processing module 408 determines whether to commit or roll back the transaction corresponding to the transaction request based on the processing results of one or more stages of the sub-transaction fed back by each of the agent coordinator nodes.

[0097] Optionally, each data shard may have one primary replica and the rest secondary replicas among its multiple replicas.

[0098] The request parsing module 402 determines the data fragments involved in the transaction corresponding to the transaction request sent by the client;

[0099] Determine the data center where the primary replica of each data shard resides;

[0100] For each data shard, the set of data shards whose primary replicas are in the same data center is defined as a sub-transaction in the transaction, and the corresponding data center is designated as the data center corresponding to the sub-transaction.

[0101] Optionally, each data shard has two or more slave replicas, one in the data center where the primary replica resides and one in at least another data center, and the primary and slave replicas of the same data shard in the same data center are on different nodes.

[0102] Optionally, the device further includes:

[0103] After obtaining one or more sub-transactions corresponding to a data center, if the second data center is the first data center, the local execution module 410 of the coordinator node determines the data node in the first data center where the copy of the data shard involved in the sub-transaction is located, and executes the sub-transaction by performing remote direct memory access on the data node.

[0104] Optionally, the transaction sending module 404 determines whether there are multiple sub-transactions corresponding to the same second data center;

[0105] If so, and the second data center is not the first data center, then the multiple sub-transactions are packaged into a sub-transaction package, and the sub-transaction package is sent to the agent coordinator node in a unified round of communication.

[0106] Optionally, a remote direct memory access network is built within the data center for executing the sub-transactions;

[0107] After sending the sub-transaction packet to the agent coordinator node, the transaction execution module 406 triggers the sub-transaction packet to perform a random walk among nodes in the second data center through the remote direct memory access network.

[0108] For the node reached during the current traversal, determine whether the node can support the execution of at least some of the transactions in the sub-transaction package. If so, execute the at least some transactions and modify the sub-transaction package accordingly, and then continue traversing until the sub-transaction package is completed.

[0109] Optionally, the transaction execution module 406 determines, before triggering the sub-transaction package to perform a random walk among nodes in the second data center via the remote direct memory access network, that the number of sub-transactions contained in the sub-transaction package is greater than a set threshold; and / or,

[0110] The frequency at which the proxy coordinator node receives sub-transaction packets sent by the coordinator node is greater than a set threshold.

[0111] Optionally, the coordinator node and the proxy coordinator node, which are not located in the same data center, communicate via TCP / IP.

[0112] Figure 5 This specification provides a schematic diagram of a cross-datacenter transaction processing device according to one or more embodiments, applicable to a distributed system consisting of multiple data centers. Each data center contains multiple nodes, and data within each data center is stored in shards. Each data shard has replicas in two or more of the data centers. The device includes:

[0113] At least one processor; and,

[0114] A memory communicatively connected to the at least one processor; wherein,

[0115] The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to:

[0116] The coordinator node in the first data center receives and parses the transaction requests sent by the client, and obtains one or more sub-transactions corresponding to one data center respectively.

[0117] The coordinator node determines the data center corresponding to the sub-transaction as the second data center. If the second data center is not the first data center, a proxy coordinator node is determined within the second data center, and the sub-transaction is sent to the proxy coordinator node.

[0118] The agent coordinator node determines the data node in the second data center where the replica of the data shard involved in the sub-transaction is located, executes the sub-transaction by performing remote direct memory access on the data node, and responds to the coordinator node based on the execution result;

[0119] The coordinator node continues to process the transaction request based on the responses from each of the proxy coordinator nodes.

[0120] The processor and memory can communicate via a bus, and the device can also include input / output interfaces for communicating with other devices.

[0121] Based on the same idea, one or more embodiments of this specification also provide corresponding... Figure 2 A non-volatile computer storage medium is provided for use in a distributed system consisting of multiple data centers, each containing multiple nodes. Data within each data center is stored in shards, with each shard having copies in two or more data centers. The medium stores computer-executable instructions configured as follows:

[0122] The coordinator node in the first data center receives and parses the transaction requests sent by the client, and obtains one or more sub-transactions corresponding to one data center respectively.

[0123] The coordinator node determines the data center corresponding to the sub-transaction as the second data center. If the second data center is not the first data center, a proxy coordinator node is determined within the second data center, and the sub-transaction is sent to the proxy coordinator node.

[0124] The agent coordinator node determines the data node in the second data center where the replica of the data shard involved in the sub-transaction is located, executes the sub-transaction by performing remote direct memory access on the data node, and responds to the coordinator node based on the execution result;

[0125] The coordinator node continues to process the transaction request based on the responses from each of the proxy coordinator nodes.

[0126] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0127] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, ASICs, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0128] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0129] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0130] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments of this specification can take the form of a computer program product implemented 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.

[0131] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. 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, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0132] 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.

[0133] 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.

[0134] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0135] 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.

[0136] 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.

[0137] 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.

[0138] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0139] The various embodiments in this specification are described in a progressive 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 embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0140] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0141] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A cross-datacenter transaction processing method, applied to a distributed system consisting of multiple data centers, wherein each data center contains multiple nodes, and data within each data center is stored in shards, with each data shard having replicas in two or more of the data centers, the method comprising: The coordinator node in the first data center receives and parses the transaction requests sent by the client, and obtains one or more sub-transactions corresponding to one data center respectively. The coordinator node determines the data center corresponding to the sub-transaction as the second data center. If the second data center is not the first data center, a proxy coordinator node is determined within the second data center, and the sub-transaction is sent to the proxy coordinator node. The agent coordinator node determines the data node in the second data center where the replica of the data shard involved in the sub-transaction is located, executes the sub-transaction by performing remote direct memory access on the data node, and responds to the coordinator node based on the execution result; The coordinator node continues to process the transaction request based on the responses from each of the proxy coordinator nodes; Within each data center, there is one node that acts as a proxy coordinator node, which is used to respond to coordinator nodes from other data centers on behalf of the nodes within that data center.

2. The method as described in claim 1, wherein the sub-transaction comprises a read-write set; The agent coordinator node executes the sub-transaction, specifically including: During the read / write phase of the sub-transaction, the agent coordinator node performs corresponding read / write operations on the replicas of the data shards involved, based on the read / write set. The coordinator node continues to process the transaction request, specifically including: If the coordinator node determines that the read / write phase has been successfully completed and the sub-transaction has a verification phase based on the response from the proxy coordinator node, it sends a verification request to the proxy coordinator node to allow the sub-transaction to enter the verification phase for verifying whether the order of transactions is correct.

3. The method as described in claim 2, wherein continuing to process the transaction request based on the responses of each of the agent coordinator nodes specifically includes: Based on the processing results of one or more stages of the sub-transaction reported by each of the agent coordinator nodes, it is determined whether to commit or roll back the transaction corresponding to the transaction request.

4. The method as described in claim 1, wherein each data shard has multiple replicas, including one primary replica and the rest are secondary replicas; The parsing of transaction requests sent by the client specifically includes: Determine the data fragments involved in the transaction corresponding to the transaction request sent by the client; Determine the data center where the primary replica of each data shard resides; For each data shard, the set of data shards whose primary replicas are in the same data center is defined as a sub-transaction in the transaction, and the corresponding data center is designated as the data center corresponding to the sub-transaction.

5. The method of claim 4, wherein each data shard has two or more slave replicas, one of which is located in the data center where the primary replica is located and one in at least another data center, and the primary replica and slave replica of the same data shard in the same data center are on different nodes.

6. The method of claim 1, wherein after obtaining one or more sub-transactions each corresponding to a data center, the method further comprises: If the second data center is the same as the first data center, the coordinator node determines the data node in the first data center where the copy of the data shard involved in the sub-transaction is located, and executes the sub-transaction by performing remote direct memory access on the data node.

7. The method as described in claim 1, wherein if the second data center is not the first data center, determining a proxy coordinator node within the second data center and sending the sub-transaction to the proxy coordinator node specifically includes: Determine whether there are multiple sub-transactions corresponding to the same second data center; If so, and the second data center is not the first data center, then the multiple sub-transactions are packaged into a sub-transaction package, and the sub-transaction package is sent to the agent coordinator node in a unified round of communication.

8. The method as described in claim 7, wherein a remote direct memory access network is established within the data center for executing the sub-transaction; After sending the sub-transaction packet to the proxy coordinator node, the method further includes: The agent coordinator node triggers the sub-transaction packet to perform a random walk among nodes in the second data center through the remote direct memory access network; For the node reached during the current traversal, determine whether the node can support the execution of at least some of the transactions in the sub-transaction package. If so, execute the at least some transactions and modify the sub-transaction package accordingly, and then continue traversing until the sub-transaction package is completed.

9. The method of claim 8, wherein before triggering the sub-transaction packet to perform a random walk among nodes in the second data center via the remote direct memory access network, the method further comprises: Determine that the number of sub-transactions contained in the sub-transaction package is greater than a set threshold; And / or, The frequency at which the proxy coordinator node receives sub-transaction packets sent by the coordinator node is greater than a set threshold.

10. The method according to any one of claims 1 to 9, wherein the coordinator node and the proxy coordinator node, which are not located in the same data center, communicate via TCP / IP.

11. A cross-datacenter transaction processing apparatus, applied to a distributed system consisting of multiple data centers, wherein each data center contains multiple nodes, and data within each data center is stored in shards, each data shard having replicas in two or more of the data centers, the apparatus comprising: The request parsing module of the coordinator node located in the first data center receives and parses the transaction requests sent by the client, and obtains one or more sub-transactions corresponding to one data center respectively. The transaction sending module of the coordinator node determines the data center corresponding to the sub-transaction as the second data center. If the second data center is not the first data center, a proxy coordinator node is determined in the second data center, and the sub-transaction is sent to the proxy coordinator node. The transaction execution module of the agent coordinator node located in the second data center determines the data node in the second data center where the copy of the data shard involved in the sub-transaction is located, executes the sub-transaction by performing remote direct memory access on the data node, and responds to the coordinator node according to the execution result; The response processing module of the coordinator node continues to process the transaction request based on the responses of each of the proxy coordinator nodes; Within each data center, there is one node that acts as a proxy coordinator node, which is used to respond to coordinator nodes from other data centers on behalf of the nodes within that data center.

12. The apparatus of claim 11, wherein the sub-transaction comprises a read-write set; The transaction execution module performs corresponding read and write operations on the copies of the data shards involved, according to the read and write set, during the read and write phase of the sub-transaction. The response processing module, based on the response of the proxy coordinator node, if it determines that the read / write phase has been successfully completed and the sub-transaction has a verification phase, sends a verification request to the proxy coordinator node to enable the sub-transaction to enter the verification phase for verifying whether the order between transactions is correct.

13. The apparatus of claim 12, wherein the response processing module determines whether to commit or roll back the transaction corresponding to the transaction request based on the processing results of one or more stages of the sub-transaction fed back by each of the agent coordinator nodes.

14. The apparatus of claim 11, wherein each data shard has a plurality of replicas, including one primary replica and the remainder being secondary replicas; The request parsing module determines the data shards involved in the transaction corresponding to the transaction request sent by the client. Determine the data center where the primary replica of each data shard resides; For each data shard, the set of data shards whose primary replicas are in the same data center is defined as a sub-transaction in the transaction, and the corresponding data center is designated as the data center corresponding to the sub-transaction.

15. The apparatus of claim 14, wherein each data shard has two or more slave replicas, one of which is located in the data center where the primary replica is located and one in at least another data center, and the primary replica and slave replica of the same data shard are located on different nodes in the same data center.

16. The apparatus of claim 11, further comprising: After obtaining one or more sub-transactions corresponding to a data center, if the second data center is the first data center, the local execution module of the coordinator node determines the data node in the first data center where the copy of the data shard involved in the sub-transaction is located, and executes the sub-transaction by performing remote direct memory access on the data node.

17. The apparatus of claim 11, wherein the transaction sending module determines whether there are multiple sub-transactions corresponding to the same second data center; If so, and the second data center is not the first data center, then the multiple sub-transactions are packaged into a sub-transaction package, and the sub-transaction package is sent to the agent coordinator node in a unified round of communication.

18. The apparatus of claim 17, wherein a remote direct memory access network is established within the data center for executing the sub-transaction; After the transaction execution module sends the sub-transaction packet to the agent coordinator node, it triggers the sub-transaction packet to perform a random walk among nodes in the second data center through the remote direct memory access network. For the node reached during the current traversal, determine whether the node can support the execution of at least some of the transactions in the sub-transaction package. If so, execute the at least some transactions and modify the sub-transaction package accordingly, and then continue traversing until the sub-transaction package is completed.

19. The apparatus of claim 18, wherein the transaction execution module determines, before triggering the sub-transaction packet to perform a random walk among nodes in the second data center via the remote direct memory access network, that the number of sub-transactions contained in the sub-transaction packet is greater than a set threshold; and / or, The frequency at which the proxy coordinator node receives sub-transaction packets sent by the coordinator node is greater than a set threshold.

20. The apparatus of any one of claims 11 to 19, wherein the coordinator node and the proxy coordinator node, which are not located in the same data center, communicate via TCP / IP.

21. A cross-datacenter transaction processing device, applied to a distributed system consisting of multiple data centers, wherein each data center contains multiple nodes, and data within each data center is stored in shards, with each data shard having replicas in two or more of the data centers, the device comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: The coordinator node in the first data center receives and parses the transaction requests sent by the client, and obtains one or more sub-transactions corresponding to one data center respectively. The coordinator node determines the data center corresponding to the sub-transaction as the second data center. If the second data center is not the first data center, a proxy coordinator node is determined within the second data center, and the sub-transaction is sent to the proxy coordinator node. The agent coordinator node determines the data node in the second data center where the replica of the data shard involved in the sub-transaction is located, executes the sub-transaction by performing remote direct memory access on the data node, and responds to the coordinator node based on the execution result; The coordinator node continues to process the transaction request based on the responses from each of the proxy coordinator nodes; Within each data center, there is one node that acts as a proxy coordinator node, which is used to respond to coordinator nodes from other data centers on behalf of the nodes within that data center.

Images