A method for monitoring the running environment of a distributed transaction commit protocol

Abstract

This disclosure relates to a method for monitoring the runtime environment of a distributed transaction commit protocol, belonging to the field of distributed transaction processing technology. This disclosure uses an RLSM robustness level state machine to maintain the system environment of each participant. The state maintained by this state machine can be dynamically adjusted by inputting different parameters to track the environment of each participant in real time. The coordinator can determine the system environment level based on the state of the participant's corresponding RLSM, breaking the fixed assumptions about the system environment in existing distributed transaction commits. This allows distributed transaction commits to dynamically adjust the commit protocol according to the system environment, improving the efficiency of distributed transaction processing. Furthermore, by setting the state machine input to be set by the current protocol and its results, the automatic adjustment of the participant's RLSM state is achieved. Furthermore, the input parameters for the state machine to lower the level are not fixed, but learned through reinforcement learning based on the execution results of historical commit protocols, which is more consistent with the distributed transaction processing environment and improves transaction processing efficiency.

Description

Technical Field

[0001] This disclosure relates to the field of distributed transaction processing technology, and in particular to a method for monitoring the runtime environment of a distributed transaction commit protocol. Background Technology

[0002] Transactions are widely used in databases to store important information. They integrate a series of critical user operations and guarantee the four ACID properties (Atomicity, Consistency, Isolation, and Durability). Among these four properties, atomicity guarantees that operations within a transaction occur simultaneously, but this property also introduces additional overhead to databases, especially distributed databases. In distributed databases, data is split and distributed across different nodes to achieve horizontal scaling. This presents a new challenge to ensuring transaction atomicity: all participating nodes need to maintain consistency on committing or rolling back a transaction. The distributed transaction commit problem thus arose and has received widespread attention from industry and academia. However, to our knowledge, existing distributed transaction commit protocols all suffer from a fundamental flaw: they make fixed assumptions about the system environment (node ​​behavior and network connectivity). This flaw limits further improvements in the efficiency of distributed databases. Summary of the Invention

[0003] The purpose of this disclosure is to overcome or partially overcome the above-mentioned technical problems and provide an environment detection method for distributed transaction commit. This method enables the coordinator to have a comprehensive understanding of the system environment and to promptly change the distributed transaction commit protocol according to changes in the environment, thereby improving the efficiency of distributed databases.

[0004] In a first aspect, embodiments of this disclosure provide a method for monitoring the runtime environment of a distributed transaction commit protocol, including a coordinator. and several matters T Participants ,

[0005] Maintain a robust hierarchy state machine (RLSM) for each participant;

[0006] RLSM comprises three states, representing three fault levels of the environment in which a distributed transaction commit occurs: no fault level, crash fault level, and network fault level.

[0007] RLSM transitions between three states depending on the input;

[0008] according to The RLSM status of each participant determines the environmental level. ,in The fault level is categorized as no-fault level, crash fault level, or network fault level. Used to determine the distributed transaction Submitted Agreement .

[0009] In a second aspect, embodiments of this disclosure provide an electronic device, including:

[0010] Memory;

[0011] Processor; and

[0012] Computer programs;

[0013] The computer program is stored in the memory and configured to be executed by the processor to implement the method described in the first aspect.

[0014] Thirdly, embodiments of this disclosure provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect.

[0015] Beneficial effects:

[0016] The method disclosed herein maintains the system environment for each participant using a robust hierarchical state machine (RLSM). The state maintained by this state machine can be dynamically adjusted based on different input parameters to track the environment of each participant in real time. The coordinator can determine the system environment level based on the state of the participant's corresponding RLSM, breaking the fixed assumptions about the system environment during existing distributed transaction commits. This allows distributed transaction commits to dynamically adjust the commit protocol according to the system environment, thereby improving the efficiency of distributed transaction processing. Furthermore, by setting the state machine input to be jointly set by the current distributed transaction commit protocol and its execution result, the automatic adjustment of the participant's RLSM state machine state can be achieved. That is, the participant's state is dynamically determined by the execution result of the previous commit protocol, and its current state determines the commit protocol to be used in the next distributed transaction commit. Furthermore, the input parameters for downgrading the state machine level are not fixed but learned through reinforcement learning based on the execution results of historical commit protocols, which is more consistent with the distributed transaction processing environment and improves the efficiency of distributed transaction processing. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0018] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 is a schematic diagram of the 2PC protocol flow;

[0020] Figure 2 is a schematic diagram of the 3PC protocol flow;

[0021] Figure 3 This is a schematic diagram of the structure of an existing distributed system;

[0022] Figure 4 This is a schematic diagram of a distributed system architecture with environmental awareness capabilities.

[0023] Figure 5 This is a schematic diagram of the Robust Graded State Machine (RLSM) provided in this disclosure;

[0024] Figure 6 This is a schematic diagram of the reinforcement learning optimizer structure provided in this disclosure;

[0025] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure;

[0026] Figure 8 The diagram illustrates the performance of each protocol under stable conditions; (a) shows the performance of throughput as the number of clients increases, and (b) shows the performance of latency as the number of clients increases.

[0027] Figure 9 for and A diagram illustrating the impact on PRAC throughput. s-CF, s-NF respectively represent periods of The crashes and network errors; where (a) is a periodic crash failure. Regarding the impact on PRAC throughput, (b) is under periodic network failure. Impact on PRAC throughput;

[0028] Figure 10 for A schematic diagram illustrating the impact of PRAC in an unstable environment; where (a) is... Regarding the impact on the proportion of executions along the error path (Error Rate), (b) is... Impact on the average robustness level;

[0029] Figure 11 This is a diagram illustrating the comparison between the various protocol levels.

[0030] Figure 12 This is a diagram illustrating the comparison of throughput under reinforcement learning and different fixed parameters; where (a) represents the throughput under different fixed parameters. A comparison of PRAC throughput when adjusted by reinforcement learning (RL), fixed at 1 (fast and robust degradation transition), and fixed at 128 (reducing false hypotheses), (b) is when Comparison of PRAC throughput when adjusted by reinforcement learning (RL), fixed at 1 (fast robust degradation transition), and fixed at 128 (reducing false assumptions). Detailed Implementation

[0031] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0032] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0033] Currently, widely used distributed transaction commit protocols include two-phase commit protocols (2PC or two-phase commit), such as... Figure 1 As shown, see Nadia Nouali, Anne Doucet, and Habiba Drias. 2005. A two-phase commit protocol for mobile wireless environment. In Proceedings of the 16th Australasian database conference - Volume 39. 135–143., and the three-phase commit protocol (3PC or three-phase commit), such as... Figure 2As shown, see Dale Skeen. 1981. Nonblocking Commit Protocols (SIGMOD '81). Association for ComputingMachinery, New York, NY, USA, 133–142. https: / / doi.org / 10.1145 / 582318.582339. 2PC cannot guarantee nonblocking in the event of a failure, while 3PC, although guaranteeing nonblocking by introducing a new phase, suffers from reduced efficiency in distributed transaction commits due to its additional message transmission, especially when the system is running without failures for an extended period. The industry categorizes expected failures during distributed transaction commits into two types:

[0034] Crash failure: The node is paused or terminated.

[0035] Network failure: Message transmission between nodes took longer than expected.

[0036] Based on these two types of failures, we categorize the execution of the distributed transaction commit protocol into three types. In particular, we only consider network failures between participants:

[0037] Trouble-free execution: No crashes or network failures occurred.

[0038] Crash failure execution: No network failure occurs, but a crash failure may still occur.

[0039] Network failure execution: Both types of failures can occur.

[0040] A distributed transaction commit protocol that can withstand network failures must also be able to withstand crash failures, and such a protocol will inevitably execute correctly in a fault-free environment. Therefore, existing technologies select distributed transaction commit protocols based on the fault level of the environment in which they will be executed. For example, if an application environment requires ensuring identity, validity, and non-blocking even during network failures, 3PC is likely to be chosen. However, when 3PC operates in an environment where network failures occur occasionally but the system is fault-free most of the time, it significantly reduces the efficiency of distributed transaction commits, resulting in a loss of system throughput. Similarly, when 2PC is chosen as the commit protocol, although system throughput is high, it will block and become unavailable in the event of a crash or network failure. The reason for these problems is that the system cannot dynamically perceive the environment and adjust the distributed commit protocol it should use based on dynamic changes in the environment. Therefore, this disclosure provides an environment detection method for distributed transaction commits that can monitor the system's environmental status in real time.

[0041] Figure 3 It is a prototype of an existing distributed system, a coordinator. Receive transactions from clients from time to time The request is sent synchronously to multiple relevant participants for execution, and feedback is sent to the client upon successful execution. Here, "transaction" refers to this process. All of these are based on fixed assumptions about the system environment and are executed using fixed commit protocols, regardless of whether the entire system is fault-free or has experienced a crash or network failure.

[0042] Therefore, this public announcement proposes that the coordinator An environmental detector is installed at the location, and the following environmental detection method is executed to sense the system environment and send it to the system. The provision requires several participants Execute the current transaction T Recommendations for distributed commit protocols, such as Figure 4 As shown.

[0043] Figure 5 This disclosure provides a method for monitoring the runtime environment of a distributed transaction commit protocol, including a coordinator. and several distributed transactions T Participants ,in

[0044] Maintain a robust hierarchy state machine (RLSM) for each participant;

[0045] RLSM comprises three states, representing the three failure levels of distributed transaction commits: no failure, crash, and network failure; for example... Figure 5 As shown;

[0046] RLSM transitions between three states depending on the input;

[0047] according to The RLSM status of each participant determines the environmental level. ,in The fault level is categorized as no-fault level, crash fault level, or network fault level. Used to determine the distributed transaction Submitted Agreement .

[0048] Coordinator By using RLSM to maintain the system environment for each participant, which can be dynamically adjusted by inputting different parameters to track the status of each participant in real time, the coordinator can determine the system environment level based on the participants' status. This breaks the fixed assumptions about the system environment during existing distributed transaction commits, allowing distributed transaction commits to dynamically change the commit protocol according to the system environment, thereby improving the efficiency of distributed transaction processing. For example, when there are 3 participants... To this end, each of the three participants maintains an RLSM. Each RLSM is currently either in a fault-free state, a crashed state, or a network fault state, switching between these states based on input. When a transaction needs to be committed, it can determine the current environment level of the system based on the three RLSM states, and then determine the commit protocol to be used based on that level. Therefore, It can dynamically monitor the environment, understand the system's environmental status in real time, and adjust the submission strategy based on the system's current environmental level.

[0049] according to The RLSM status of each participant determines the environmental level. , The determination can be made through various methods, such as The best player The average state of the participants, etc. Preferably, this disclosure will... The RLSM status level assigned to the participant with the worst system environment. The system environments are categorized from best to worst as follows: fault-free, crash-prone, and network-prone. The participant environment in the fault-free state is considered the best, followed by the crash-prone state, and the worst is the network-prone state. Therefore, the commit protocol selected by the participant in the worst-case scenario will always satisfy the transaction commit requirements of participants in better states.

[0050] Specifically, set the initial state of RLSM to the fault-free level;

[0051] Input is or , Indicates a crash or failure. Indicates a network failure. This indicates a shift from reduced robustness at the crash failure level, i.e., the RLSM at the crash failure level, in continuous... After the first trouble-free execution, the status will be downgraded to the trouble-free level; This indicates a shift from reduced robustness to a network failure level, i.e., the RLSM at the network failure level, in continuous... After the first trouble-free execution, the status will be downgraded to the trouble-free level;

[0052] The transition process of RLSM between the three states is as follows, depending on the input:

[0053] When the RLSM is in the fault-free level, if input is received If robustness is improved, the system will transition to a crash failure level if input is received. If so, robustness improvements will be implemented to transfer to a network fault level;

[0054] When RLSM is in a crash failure level, if input is received If robustness is improved, the fault level is shifted to a network failure level; if input is received... If so, robust degradation will be implemented and the system will be transferred to a fault-free level;

[0055] When RLSM is in a network fault level, if input is received If the condition is not met, a robust reduction and transfer to a fault-free level will be implemented.

[0056] The operation of RLSM can be configured differently in different application scenarios. For example, the initial state may be set to the worst-case scenario or randomly. The input and the state transition process based on the input also vary depending on the application environment. In this example, the initial state of RLSM is set to the best-case scenario, i.e., the fault-free level, which objectively reflects the fact that the network or device is usually fault-free. Furthermore, the input is categorized into several different symbolic representations that correspond to objective reality. Then, the state transition is performed based on the corresponding symbol of the input when the corresponding scenario occurs, mirroring the real-world situation. For instance, when RLSM is in the fault-free level, if an input is received... This means that the participant corresponding to the RLSM has crashed, and its robustness level should be adjusted to the crash state. Therefore, in this example, its robustness level should be increased to transition to the crash state. If input is received... This means that the participant corresponding to the RLSM has experienced a network failure. In this case, it should be adjusted to a network failure state. Therefore, in this example, its robustness level should be increased to directly transition to the network failure state. Similarly, when the RLSM is in a crash failure state, if it receives input... If robustness is improved, the state is transitioned to a network failure level. However, during robustness reduction transitions, an RLSM in a crash failure level state is required, continuously... Only after a fault-free execution is the status downgraded to the fault-free level, i.e., upon receiving input. Then the state transitions to the fault-free level; RLSMs in the network fault level state, in continuous Only after a fault-free execution is the status downgraded to the fault-free level, i.e., upon receiving input. If so, the status will be transferred to the fault-free level.

[0057] Specifically, the input of RLSM is based on and Execution result Determined based on the following principles:

[0058] like For the fault-free level protocol, check Can the results in the input determine the existence of a malicious network fault? If so, input... Adjust the Determine the network fault level; otherwise, check. Does the participant represented by the input itself exhibit a malicious crash failure? If so, input... Adjust the The crash failure level;

[0059] like For the crash failure level protocol, check Can the results in the input determine the existence of a malicious network fault? If so, input... Adjust the The network failure level is determined; otherwise, the number of consecutive fault-free executions is checked, and if that number reaches [a certain threshold], [further details are needed]. Then input ;

[0060] like For the network fault level protocol, check the number of consecutive fault-free executions. If that number reaches... Then input .

[0061] RLSM inputs can come from various sources, such as Based on the participant status collected by computer programs such as network management processes or network monitoring threads, these programs can periodically communicate with participants to obtain their status and determine the input to the RLSM when their status changes. For example, if a crash occurs, the input to the RLSM is... In this example, it is preferred to be done by a transaction. Execution Protocol and execution results To determine the inputs that trigger RLSM state transitions, we can... This achieves a self-operating loop that does not rely on other means. Specifically, when a transaction needs to be executed, it requests an environment level from the environment detector (i.e., the environment detection method disclosed herein). The environment detector then returns the level, which is the transaction's commit protocol. , After execution, The execution result This feedback is then sent to the environmental detector, which then... and Determining the input to the RLSM also determines whether the RLSM needs to perform a state transition. This creates a positive loop where the protocol submission is determined based on the environment state, and the environment state is monitored and transitioned based on the protocol execution result.

[0062] Specifically, the criteria for determining a malicious crash are: if If it is a fault-free level protocol or a crash fault level protocol, then check... Are there any missing participant results? If so, use them for... The network connection between the participant and the participant is a synchronous connection. If the result is lost, it means that the corresponding participant encountered a crash before sending the result. Therefore, it is determined that a serious crash occurred on the missing participant.

[0063] Criteria for determining a malicious network failure: If If the fault-free level protocol is in place and no malicious crash fault is detected, then check... The decision on whether a conflict exists is made; if so, a malicious network failure is determined among the participants; otherwise... For a crash failure level protocol, then if If conflicting decisions occur during the execution of a distributed transaction commit protocol, it is determined that a malicious network failure has occurred among the participants. This is because, according to the nature of the protocol, the decisions of all participants should remain consistent in the absence of an intolerable failure. Therefore, it is clear that an intolerable failure must have occurred during the execution of the protocol.

[0064] Based on the execution results of all participants under different protocols It determines whether a participant has experienced a malicious crash or network failure, so that state machine transitions depend only on the execution result of transaction T. This simplifies the design complexity of the system, avoids the additional overhead of fault detection, and improves the system's independence.

[0065] Specifically, and / or based on This can be achieved through reinforcement learning. Existing reinforcement learning methods, such as Deep Q-Learning and Policy Gradient, can be used to learn it.

[0066] , The presence of these two parameters means that the robustness reduction transition does not need to be performed immediately, because we can completely sacrifice some efficiency rather than correctness to use a high-robust-level protocol to perform the work of a low-robust-level protocol. and The protocol balances two factors: smaller parameters mean more sensitive transfers, allowing for more opportunities to handle transactions with lightweight protocols; larger parameters mean more cautious transfers, helping us avoid running on time-consuming, faulty paths. Users can manually adjust these parameters, but this is not easy, and using preset fixed values ​​may result in efficiency sacrifices. Therefore, we set... and / or Based on The parameter values ​​learned through reinforcement learning, based on the execution results of historical transactions, can fully reflect the environmental changes of each participant, achieving reasonable environmental tracking and efficient transaction processing. The system uses the adjusted environmental level for reinforcement learning; that is, if the transaction... If a fault occurs during execution, that fault will first be used for adjustment. After that, It is sent to the reinforcement learning optimizer. Subsequent transactions will be executed based on the adjusted... Define the agreement. For example, if we are... If a fault-free protocol is selected, but a network failure occurs during protocol execution, then... The network fault level will be changed and sent to the reinforcement learning optimizer.

[0067] by Taking reinforcement learning as an example, specifically, reinforcement learning is implemented through a reinforcement learning optimizer, which includes a collector, a decision maker, and a learner; for example... Figure 6 As shown, where,

[0068] Collector receives and caches ,like If the environment level differs from the previous cached environment, the buffer is cleared, and the average system throughput during the buffering period is set. and Send them together to the decision-maker, and send a reset command to the learner; if The environment level remains the same as the previous cache. If the buffer is full, it will be cleared, and the average system throughput during the buffering period will be adjusted accordingly. and Send them together to the decision-maker;

[0069] The decision-maker is equipped with a counter and stores parameters. , This indicates a need to strengthen learning and acquisition. The initial value of the counter is 1. The initial value is k, where k is a real number and differs from any value that the decision-maker might take during operation; in this example, k is set to -1; the decision-maker receives... Count pairs, determine:

[0070] like If the fault-free level is reached, the counter is decremented by 1. If the counter is 0, a decision is made; otherwise, the process is exited.

[0071] like If the fault level is not zero, then reset.

[0072] The decision includes the following:

[0073] like If it is not k, then the corresponding RLSM transition is triggered, and the input of the RLSM is set to k. And reset;

[0074] like If the value is k, then send to the learner and obtain a feedback number. And a feedback decision that may be sent back along with it. ;like If the value is 0, the corresponding RLSM transfer is triggered, and the counter is set to 1; otherwise, the counter is set to... If successfully received Then set for ;

[0075] The reset includes the following:

[0076] like If the value is k, then the counter is set to 1;

[0077] like If it is not k, then set the counter to ;

[0078] If the learner receives a reset command from the collector, it adjusts its reinforcement learning model to its initial state; if it receives a reset command from the decision-maker... Then In return, the reinforcement learning model is trained, and the decision numbers fed back by the model are used. Feedback is given to the decision-maker; if the reinforcement learning model has completed training, its decision scheme is converted into numerical values. This information is then fed back to the decision-maker.

[0079] For parameters The process of reinforcement learning is the same as above, as long as... Replace with That's fine, and not as good as The learning process involves a participant's corresponding RLSM being learned by a reinforcement learning optimizer; for The learning process involves all participants using a reinforcement learning optimizer to learn their corresponding RLSMs; the learning process will not be described in detail here.

[0080] Existing reinforcement learning methods, such as the standard Markov Decision Process (MDP), can be used to refine the parameters. Learning is then performed. Preferably, this example uses a q-learning model. The reinforcement learning optimizer described above, based on the learner built from the reinforcement learning model, adds a collector and a decision-maker. The collector receives and caches the environment levels from the RLSM. The collector aggregates and sends the cached results to the decision-maker when the ranking changes or the cache is full. The collector's cache avoids excessively frequent access to the decision-maker and reinforcement learning model, reducing the computational overhead on the system and preventing it from affecting transaction processing efficiency. The decision-maker processes the received results and, when the counter is reset, calculates the average throughput. The parameters are sent to the learner for learning and decision-making. Specifically, after the learner's reinforcement learning model is trained, the decision-maker will locally cache the parameters learned by the learner. The decision-maker transforms the decisions learned by the learner into parameters for system use. Furthermore, it caches these parameters upon completion of learning, avoiding further access to the learner and reducing computational overhead.

[0081] This disclosure innovatively incorporates a Reinforcement State Machine (RLSM) for distributed transaction commits to rapidly monitor the system environment. This provides a feasible solution for distributed commit protocols to move away from fixed assumptions about the system environment, giving them a method to perceive the system environment and thus unlocking more optimization potential. Furthermore, this disclosure incorporates reinforcement learning to improve the protocol's adaptability and performance in unstable environments, enabling automatic system parameter tuning. To our knowledge, RLSM is the first real-time system environment (crash failure, network failure) monitor that leverages existing protocol results and incorporates reinforcement learning.

[0082] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure. This device can execute the processing flow provided in the above-described method embodiments, such as... Figure 7 As shown, the Internet of Things device 110 includes: a memory 111, a processor 112, a computer program, and a communication interface 113; wherein the computer program is stored in the memory 111 and configured to be executed by the processor 112 as described above.

[0083] In addition, this disclosure also provides a computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor to implement the methods described in the above embodiments.

[0084] The present invention conducted the following experiments to verify the above-mentioned environmental testing method.

[0085] In our experiments, we designed corresponding protocols for both fault-free and crash-fault levels. For the crash-fault level protocol, we leveraged the synchronous nature of connections between participants, allowing them to exchange votes directly rather than through a coordinator, thus reducing message latency required for transaction execution. For the fault-free level protocol, we introduced implicit voting technology based on the crash-fault level protocol, further reducing message transmission between participants. For the network fault level, we directly used 3PC.

[0086] We integrate these optimized protocols into a distributed transaction commit protocol, denoted as PRAC, using the environmental monitoring methods described in this disclosure. Based on this protocol, we conducted extensive experiments to evaluate the performance improvements brought about by the environmental monitoring methods.

[0087] The following section details the implementation process and the evaluation process:

[0088] This document compares PRAC with standard protocols such as 2PC (two-phase commit) and 3PC (three-phase commit), as well as one of the most advanced protocols currently available, G-PAC (Sujaya Maiyya, Faisal Nawab, Divyakant Agrawal, and Amr El Abbadi. 2019. Unifying consensus and atomic commitment for effective cloud datamanagement. Proceedings of the VLDB Endowment 12, 5 (2019), 611–623.). We also tested a centralized variant of G-PAC called C-PAC.

[0089] The effectiveness of reinforcement learning in improving the adaptability of PRAC in unstable system environments.

[0090] (1) Implementation of the experimental system

[0091] We implemented the RLSM-based distributed transaction commit protocol PRAC using Golang and Python. Our system handles transactions in a Percolator-like manner, using... The distributed transaction commit protocol is restricted to committing write operations, thus avoiding the influence of other parts on experimental comparisons. All protocols are built on the same key-value store and share... To avoid the influence of irrelevant factors, we map database table rows to key-value pairs and adjust the storage size according to the amount of data. For two-phase commit, we borrowed the implementation design from TiDB (2021. TiDB. https: / / github.com / pingcap / tidb. Online; accessed: 2021-09-01.). In the 2PC two-phase commit protocol, a message will be resent three times if there is no reply. For the 3PC three-phase commit protocol, we adopted the design mentioned in (Suyash Gupta and Mohammad Sadoghi. 2018. EasyCommit: A Non-blocking Two-phase Commit Protocol.. In EDBT. 157–168.). The G-PAC implementation comes from its authors Sujaya Maiyya, Faisal Nawab, DivyakantAgrawal, and Amr El Abbadi. 2019. Unifying consensus and atomic commitment for effective cloud data management. Proc. VLDB Endow. 12, 5 (January 2019), 611–623. We also implemented a centralized version of G-PAC, denoted as C-PAC, in which the head node of the protocol is fixed as the leader. Similar to PAC, C-PAC requires three phases to execute a transaction: (i) it collects initial votes from all nodes, (ii) consensus is reached on a majority of nodes, and (iii) the decision is sent asynchronously to all nodes.

[0092] (2) Experimental setup

[0093] We conducted the experiment using Google E2 servers deployed in four different data centers. The participants included one coordinator and three participants. These data centers are located in Singapore-a ( ), Hong Kong, China - a ( ), Taiwan Province, China -a( ) and Jakarta-a ( We use Jakarta-a ( The node acts as the coordinator, while the other nodes act as participants. For all experiments, we used a computationally optimized E2 mid-range machine equipped with 2 vCPUs, 4GB of memory, a Debian GNU / Linux 10 (buster) system, and 10GB of disk space.

[0094] For small-scale testing, we use the YCSB-like dataset [(Sujaya Maiyya, Faisal Nawab, Divyakant Agrawal, and Amr El Abbadi. 2019. Unifying consensus and atomiccommitment for effective cloud data management. Proceedings of the VLDBEndowment 12, 5 (2019), 611–623.), (Brian F Cooper, Adam Silberstein, ErwinTam, Raghu Ramakrishnan, and Russell Sears. 2010. Benchmarking cloud servingsystems with YCSB. In Proceedings of the 1st ACM symposium on Cloudcomputing. 143–154.), (Thamir M Qadah and Mohammad Sadoghi. 2021. HighlyAvailable Queueoriented Speculative Transaction Processing. arXiv [preprintarXiv:2107.11378 (2021)] was used to evaluate the performance of all protocols. In the tests, the client continuously generated transactions that read and wrote multiple records using a closed-loop thread, and to simulate a real-world environment, we concentrated 90% of the operations on 10% of the data objects. In the original tests, all transactions were cross-node, which may not accurately reflect real-world operations. Therefore, in this experiment, we ensured that 30% of the transactions involved only a single node, and the remaining transactions were cross-node. For large datasets, we used TPC-C, the standard test suite for OLTP systems, which includes three types of read / write transactions and two types of read-only transactions. We established warehouses in three data centers. Each warehouse contained 10 different regions, and each region maintained information for 3000 clients. We used a closed-loop thread that continuously sent transactions to the coordinator to simulate the client, and controlled the data volume by adjusting the number of threads.

[0095] The experiment involves the following three sets of parameters: (i) using two parameters and To control the number of consecutive fault-free executions required for downscrambling in crash and network failure levels. (ii) In the experiments, we created two different environments: a stable environment and an unstable environment, to simulate the occurrence of failures in the real world. Specifically, we generated failures in the unstable environment at a specific frequency: every The system operates on a cycle of one second, and will... A crash or network failure occurs within seconds, then in the remaining... It returned to normal within seconds. (iii) We use network buffer parameters. To adjust the latency of long message transmission. We will Longest message delay between every two participants Multiply to calculate the upper limit of message latency used in the algorithm.

[0096] (3) Testing under stable conditions

[0097] First, we evaluated the performance of the PRAC, 2PC, 3PC, G-PAC, and C-PAC protocols in a stable environment where no faults would be injected. Figure 8 As shown, Figure 8The results of these protocols tested on a YCSB-like dataset in a stable environment are shown. The horizontal axis represents the number of clients (Client Number), the vertical axis in (A) represents throughput, and the vertical axis in (B) represents latency. Here, PRAC demonstrates a significant improvement in both latency and throughput. When there are 512 clients (represented by dashed lines), PRAC improves throughput by 2.30x, 2.67x, 2.47x, and 1.62x compared to G-PAC, C-PAC, and 2PC, respectively, while its latency is 94.8%, 145.3%, 10.4%, and 22.8% of the other protocols, respectively. Here, we explain the reasons for this result. First, PRAC outperforms 2PC because PRAC is non-blocking, making it less susceptible to delayed messages under high contention. Furthermore, PRAC outperforms 3PC, C-PAC, and G-PAC thanks to its adaptability to system environments: in stable environments, PRAC switches to a more lightweight, fault-free level for transaction processing than other protocols. Note that in this experiment, G-PAC gained more advantages in latency than 2PC, but less in throughput, which differs slightly from the results reported in the literature (Sujaya Maiyya, Faisal Nawab, DivyakantAgrawal, and Amr El Abbadi. 2019. Unifying consensus and atomic commitment for effective cloud data management. Proceedings of the VLDB Endowment 12, 5(2019), 611–623.). This is because in our implementation of 2PC, each transaction was retried three times, increasing throughput at the cost of higher latency. C-PAC's asynchronous decision-making phase reduces its latency overhead. Moreover, compared to G-PAC, it does not require a leader re-election during transaction execution, achieving lower latency than G-PAC.

[0098] (4) Testing under unstable environments

[0099] We evaluate the performance of PRAC in unstable environments by injecting crashes or network failures into nodes and network connections. This failure injection is determined by parameters. Control: Once the fault is triggered, it will continue. Seconds, period is 2 Seconds. We started 5+2 on all machines. The experiment was conducted after a few seconds to ensure stable results. Each protocol was run 10 times and the average result was taken.

[0100] We adjust the parameters and To achieve a balance between level conversion overhead and conversion speed. Specifically, and The RLSM control needs to see how many fault-free executions before resetting to the fault-free level. We fix this in each experimental run. and The value of was determined by varying it across different experimental groups to investigate the effect of this parameter on the protocol. Figure 9 In this study, we investigated the different environmental stability conditions. and Impact on PRAC performance.

[0101] Specifically, Figure 9(a) shows the different levels of periodic crash failure. The throughput at the value can be observed to increase with... The increase first rises and then falls. We attribute this non-monotonic trend to the increase... This brings two opposing effects: First, when When the number of transactions increases, PRAC requires more fault-free execution before RLSM transitions to a fault-free level, so robust degradation transitions occur less frequently. Simultaneously, fewer transactions will enter error paths. Figure 10(a) shows when... When this is increased, the number of transactions entering incorrect paths will decrease, meaning fewer unnecessary robust degradation transitions and transaction reruns. Specifically, for example... Figure 9 As shown by the 1s-CF line in (a), when the environment is unstable ( This cost saving is particularly significant when the time is 1 second. In this case, the system experiences a crash failure lasting 1 second every 2 seconds, while the throughput of PRAC decreases as the system speed increases. The increase from 1 to 16 improved the throughput from 618 TPS to 778 TPS. On the other hand, the cautious robustness of degradation transitions compromised PRAC's adaptability. RLSM tends to remain at a stricter level, thus missing the opportunity to handle transactions using lightweight protocols, such as... Figure 10 As shown in (b). For all The average level of PRAC all followed This indicates that more transactions are being processed at a more stringent level. This explains why... In the case of 1 second, as With a throughput of 128, PRAC's throughput dropped to 466 tps.

[0102] Figure 9(b) reports the PRAC in different throughput ( Robust degradation transitions for controlling network failure levels. We can observe that PRAC always prefers smaller... .exist When the time is 1s, 4s, or 16s respectively, PRAC always... They reach their peak performance when approaching 1. As shown by the dashed lines, their throughputs reach 1540, 1303, and 1273 tps, respectively. We will and The different impacts are attributed to differences in performance gains, specifically the crash failure level protocol PRAC. CF and Network Fault Level Protocol (PRAC) NF The throughput difference between them. In particular, we compared three non-switchable versions of PRAC, each running at a fixed tier. Figure 11 Comparison of protocols from crash failure level (PRAC) CF ) or network fault level (PRAC) NF Switching to fault-free level (PRAC) FF The throughput gain is approximately 1.6x, while the latter achieves a significant 2.14x increase. This difference explains why PRAC is always better suited for use with smaller... This refers to rapid, robust degradation transitions. Despite the increasing number of incorrect assumptions and the resulting costly corrections, PRAC still gains performance from a more lenient level.

[0103] In the experiments described above, we have confirmed that the robust degradation transformation parameters... It's difficult to adjust. Specifically, Figure 9 (a) shows that as the system becomes unstable, The optimal value will change from 2 to 16. This demonstrates the difficulty of manually tuning the parameters and prompts us to use reinforcement learning (RL) to adjust the parameters based on feedback from changes in system performance.

[0104] Figure 10 when and The throughput of PRAC is obtained through reinforcement learning, set to 1, and set to 128, respectively. Specifically, reinforcement learning has learned the following for environments with 1s-CF, 4s-CF, and 16s-CF: 16, 4, 1. And it learned 1s-NF, 4s-NF, and 16s-NF respectively for the environment. 1, 2, 2.

[0105] Figure 12 (a) reported that and The throughput of PRAC is obtained through reinforcement learning, set to 1, and set to 128, respectively. Specifically, reinforcement learning has learned the following for environments with 1s-CF, 4s-CF, and 16s-CF: 16, 4, 1. And it learned 1s-NF, 4s-NF, and 16s-NF respectively for the environment. 1, 2, 2. When A comparison of PRAC throughput under reinforcement learning (RL) tuning, fixed at 1 (fast robust degradation transition), and fixed at 128 (reducing false hypotheses). We can observe that in all experimental settings (faults are... =1, 4 and 16 In the periodic occurrence, RL adjustment It always produces better throughput. More specifically, when =1 At that time, RL learning Achieved compared to =1 represents a 25.7% increase in throughput, when compared with When compared to 128, the improvement even reached 66.7%. In particular, further investigation revealed that the learned... The average value is close to 16 in this setting. Conversely, when =4 The performance gain decreases at this point: using the learned parameters only improves throughput by 6.4%. This is because the learned parameters at this point... It is 4, close to a fixed value. =1, thus bringing only a small performance difference. Nevertheless, its throughput is still higher than... =128 is 39.1% higher. Finally, when =16 At that time, learning parameters and =1 achieved the same performance (779 tps). This is in line with our expectations, because the learned parameter at this point is 1, compared to a fixed value. =1 has the same effect. Furthermore, they are both compared to =128 improved throughput by 21.9%. Overall, this experiment demonstrates that using RL to adjust the crash failure level... It can produce more than Assigning a fixed value yields better results.

[0106] In addition, we also applied RL to adjust and its throughput with A comparison was made when the values ​​were fixed at 1 and 128. Figure 12(b) shows the experimental results, adjusted using RL. The throughput at the parameter setting is significantly better than The throughput at =128, however, compared to When =1, its throughput lags slightly behind but approaches. Specifically, when When configured to 1 second, it is adjusted by RL. and =1 produced a similar throughput (1540 tps). This is because in this setup, the learning curve is... The value is also 1. We saw this earlier... Figure 9 (b) describes the situation regarding =1, 4 and 16 The optimal parameter selection, where =1 is the optimal value. This means that RL can still help us... Adjusting to near-optimal values: It can produce results that are almost identical to the optimal settings. =1, which offers the same high throughput. However, in practice, we recommend configuring parameters... Set it directly to 1 to support fast, robust degradation transitions and achieve optimal performance.

[0107] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

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

Claims

1. A method for monitoring the runtime environment of a distributed transaction commit protocol, including a coordinator. and several distributed transactions T Participants Its features are: Maintain a robust hierarchy state machine (RLSM) for each participant; RLSM comprises three states, representing three fault levels of the environment in which a distributed transaction commit occurs: no fault level, crash fault level, and network fault level. RLSM transitions between three states depending on the input; according to The RLSM status of each participant determines the environmental level. ,in The fault level is categorized as no-fault level, crash fault level, or network fault level. Used to determine the distributed transaction Submitted Agreement ; The initial state of the RLSM is a fault-free level; The input is or , Indicates a crash or failure. Indicates a network failure. This indicates a shift from reduced robustness at the crash failure level, i.e., the RLSM at the crash failure level, in continuous... After the first trouble-free execution, the status will be downgraded to the trouble-free level; This indicates a shift from reduced robustness to a network failure level, i.e., the RLSM at the network failure level, in continuous... After the first trouble-free execution, the status will be downgraded to the trouble-free level; The RLSM transitions between the three states based on the different inputs as follows: When the RLSM is in a fault-free state, if an input is received... If robustness is improved, the system will transition to a crash failure level if input is received. If so, robustness improvements will be implemented to transfer to a network fault level; When the RLSM is at a crash failure level, if input is received If robustness is improved, the fault level is shifted to a network failure level; if input is received... If so, robust degradation will be implemented and the system will be transferred to a fault-free level; When the RLSM is in a network fault level, if input is received If so, robust degradation will be implemented and the system will be transferred to a fault-free level; The input is based on the and the aforementioned Execution result Determined based on the following principles: If the above For the fault-free level protocol, check the following Can the results in the input determine the existence of a malicious network fault? If so, input... Adjust the The network fault level is determined by the following criteria; otherwise, check the above. Does the participant represented by the input itself exhibit a malicious crash failure? If so, input the following: Adjust the The crash failure level; If the above For the crash failure level protocol, check the following Can the results in the input determine the existence of a malicious network fault? If so, input... Adjust the The network failure level is determined; otherwise, the number of consecutive fault-free executions is checked, and if that number reaches the specified level... Then input ; If the above For the network fault level protocol, check the number of consecutive fault-free executions; if this number reaches the specified value... Then input ; The Based on the above Obtained through reinforcement learning; the aforementioned Based on the above Acquired through reinforcement learning.

2. The method according to claim 1, characterized in that: The For the The participant with the worst system environment corresponds to the RLSM status level, with the system environment ranging from best to worst as follows: no fault level, crash fault level, and network fault level.

3. The method according to claim 1, characterized in that: The criteria for determining a severe crash are: If If it is a fault-free level protocol or a crash fault level protocol, then check... If there are missing participants in the results, then it is determined that a malicious crash has occurred on the missing participant. The criteria for determining a malicious network failure are: If If the fault-free level protocol is in place and no malicious crash fault is detected, then check... The decision on whether a conflict exists is made; if so, a malicious network failure is determined among the participants; otherwise... For a crash failure level protocol, then if If there are conflicting decisions, it is determined that a malicious network failure has occurred among the participants.

4. The method according to claim 1, characterized in that: The reinforcement learning is implemented through a reinforcement learning optimizer, which includes a collector, a decision-maker, and a learner; wherein... The collector receives and caches the... If the above If the environment level differs from the previous cached environment, the buffer is cleared, and the average system throughput during the buffering period is set. and stated Send them together to the decision-maker, and send a reset command to the learner; if If the environment level is the same as the last cached environment and the buffer is full, then the buffer is cleared, and the average throughput of the system during the buffering period is calculated. and stated Send them together to the decision-maker; The decision-maker is equipped with a counter and stores parameters. , This represents the need to strengthen the learning and acquisition of the aforementioned The counter is initially set to 1. The initial value is k, where k is a real number and differs from the value that the decision-maker takes during its operation; the decision-maker receives... Count pairs, determine: like For the fault-free level, decrement the counter by 1. If the counter is 0, make a decision; otherwise, exit. like If the fault-free level is not specified, then a reset is performed; The decision includes the following: like If it is not k, then the corresponding RLSM transition is triggered, that is, the input of the RLSM is set to k. ; like If the value is k, then send to the learner and obtain a feedback number. And a feedback decision that will be sent back along with it. ;like If the value is 0, the corresponding RLSM transfer is triggered, and the counter is set to 1; otherwise, the counter is set to... If successfully received Then set for ; The reset includes the following: like If the value is k, then the counter is set to 1; like If it is not k, then set the counter to ; If the learner receives a reset instruction from the collector, it adjusts its reinforcement learning model to its initial state; if it receives a reset instruction from the decision-maker... Then In return, the reinforcement learning model is trained, and the decision numbers fed back by the model are used. Feedback is given to the decision-maker; if the reinforcement learning model has completed training, its decision scheme is converted into numerical values. This information is then fed back to the decision-maker.

5. The method according to claim 1, characterized in that: The reinforcement learning is implemented through a reinforcement learning optimizer, which includes a collector, a decision-maker, and a learner; wherein... The collector receives and caches the... If the above If the environment level differs from the previous cached environment, the buffer is cleared, and the average system throughput during the buffering period is set. and stated Send them together to the decision-maker, and send a reset command to the learner; if If the environment level is the same as the last cached environment and the buffer is full, then the buffer is cleared, and the average throughput of the system during the buffering period is calculated. and stated Send them together to the decision-maker; The decision-maker is equipped with a counter and stores parameters. , This represents the need to strengthen the learning and acquisition of the aforementioned The counter is initially set to 1. The initial value is k, where k is a real number and differs from the value that the decision-maker takes during its operation; the decision-maker receives... Count pairs, determine: like For the fault-free level, decrement the counter by 1. If the counter is 0, make a decision; otherwise, exit. like If the fault-free level is not specified, then a reset is performed; The decision includes the following: like If it is not k, then the corresponding RLSM transition is triggered, i.e., the setting is... The input of the RLSM for each participant is ; like If the value is k, then send to the learner and obtain a feedback number. And a feedback decision that will be sent back along with it. ;like If the value is 0, the corresponding RLSM transfer is triggered, and the counter is set to 1; otherwise, the counter is set to... If successfully received Then set for ; The reset includes the following: like If the value is k, then the counter is set to 1; like If it is not k, then set the counter to ; If the learner receives a reset instruction from the collector, it adjusts its reinforcement learning model to its initial state; if it receives a reset instruction from the decision-maker... Then In return, the reinforcement learning model is trained, and the decision numbers fed back by the model are used. Feedback is given to the decision-maker; if the reinforcement learning model has completed training, its decision scheme is converted into numerical values. This information is then fed back to the decision-maker.

6. The method according to claim 4 or 5, characterized in that: The reinforcement learning model is a q-learning model.

Images