Distributed service system, failure recovery method, device, storage medium, and program product

Abstract

Embodiments of the present disclosure provide a distributed service system, a failure recovery method, a device, a storage medium, and a program product. In a leaderless replicated state machine scenario, a plurality of service nodes decide on a logical timestamp of a request and a conflicting request set according to a leaderless consensus protocol, and wait for a decision to be reached on logical timestamps of the conflicting request set. If waiting times out, according to a leaderless consensus protocol request corresponding to a target conflicting request for which no decision has been reached on a logical timestamp thereof, a stage that a decision process of the logical timestamp of the target conflicting request has reached is determined, and the decision process of the logical timestamp of the target conflicting request may be executed at the stage, thereby reaching a decision on the logical timestamp of the target conflicting request and achieving failure recovery. As the decision process of the logical timestamp of the target conflicting request does not employ one‑hop fast path optimization, there is no need to distinguish which scheme is used to decide on the logical timestamp of the target conflicting request during failure recovery, thereby simplifying the failure recovery process and improving failure recovery efficiency.

Description

Distributed service systems, disaster recovery methods, equipment, storage media and software products

[0001] This disclosure claims priority to Chinese Patent Application No. 202510072443.X, filed with the China National Intellectual Property Administration on January 16, 2025, entitled “Distributed Service System, Disaster Recovery Method, Device, Storage Medium and Program Product”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure relates to the field of cloud service technology, and in particular to a distributed service system, disaster recovery method, device, storage medium and program product. Background Technology

[0003] A distributed service system is a system composed of multiple cooperating services, typically distributed across different hosts or servers and communicating over a network. To improve the reliability and disaster recovery capabilities of a distributed service system, multiple service nodes can be deployed for mutual backup of the same service instance. If one service node fails, the other service nodes can continue to provide service.

[0004] For stateful distributed service systems, the effective means to achieve the above-mentioned fault tolerance goals cannot bypass the replicated state machine model. As shown in Figure 1, the principle of this model is to maintain a deterministic finite state machine (DFSM) with the same mechanism for each server in a service cluster. If it can be guaranteed that the input of each state machine is a completely consistent sequence of commands, then each state machine in this set will eventually provide read and write services to the outside world in the same state, thus having the ability to tolerate the failure of some state machines.

[0005] In practical applications, state machine command sequences are typically implemented using read-only append-only logs. Each state machine maintains a read-only log sequence containing the commands to be executed. For example, in step 1 of Figure 1, the client sends a request to the server. In step 2, the consensus protocol module on the server determines the order of the requests in the log sequence. In step 3, the requests are applied to the state machines sequentially according to the order recorded in the log sequence. Finally, in step 4, the processing result is returned to the client. In the example in Figure 1, the log sequence seen by each state machine must be strictly consistent: "x < -3", "y < -1", "y < -9", ... Each state machine executes the same command sequence, and the final state presented externally is always: x = 3, y = 9. Clearly, in the replicated state machine model, the problem of ensuring data consistency between state machines is transformed into the problem of ensuring strict consistency of the log sequences on each machine. Therefore, ensuring strict consistency of log sequences across all servers in a service cluster is the core challenge of the replicated state machine model, which is precisely the responsibility of the consensus protocol. Existing methods for achieving log sequence consistency require adaptation to complex disaster recovery schemes, resulting in low disaster recovery efficiency. Summary of the Invention

[0006] This disclosure provides a distributed service system, disaster recovery method, device, storage medium, and program product to simplify the disaster recovery process in ownerless consensus scenarios and improve disaster recovery efficiency.

[0007] This disclosure provides a distributed service system, including: multiple service nodes; each service node independently maintains a state machine; the distributed service system adopts a masterless replication state machine mechanism;

[0008] When serving as the coordinating node among the plurality of service nodes, it is used to resolve, through the target unclaimed consensus protocol, the target logical timestamp of the target request and the first set of interference requests with the replica nodes of the coordinating node; the target request is a request proposed by the coordinating node, and the replica nodes refer to service nodes other than the first service node among the plurality of service nodes.

[0009] The replica node and the coordinating node are used to wait for the logical timestamps of the interference requests in the first interference request set to form a resolution.

[0010] The second service node in the replica node and the coordinating node is configured to, when the waiting time reaches a set time threshold, if there is a target interference request in the first interference request set whose logical timestamp has not been resolved, obtain the target unclaimed consensus protocol request of the target interference request; and, according to the target unclaimed consensus protocol request, execute the resolution process of the logical timestamp of the target interference request to form a resolution of the logical timestamp of the target interference request with other services.

[0011] The plurality of service nodes are configured to determine the order in which the target request is applied to the state machine, based on the resolution of the target logical timestamp and the logical timestamp of the interference request in the first interference request set, when a resolution is reached on the logical timestamp of the interference request in the first interference request set.

[0012] This disclosure also provides a disaster recovery method applicable to any one of multiple service nodes in a distributed service system, wherein the multiple service nodes independently maintain a state machine; the distributed service system adopts a masterless replication state machine mechanism.

[0013] When any one of the multiple service nodes acts as a coordinating node, it forms a resolution with the replica nodes of the coordinating node to determine the target logical timestamp of the target request and the first set of interference requests through the target ownerless consensus protocol; the target request is a request proposed by the coordinating node; the replica node refers to the service node other than the first service node among the multiple service nodes.

[0014] The method includes:

[0015] Wait for the logical timestamps of the interference requests in the first set of interference requests to form a resolution;

[0016] If the waiting time reaches the set time threshold, and there is a target interference request in the first interference request set whose logical timestamp has not yet formed a resolution, then the target masterless consensus protocol request of the target interference request is obtained.

[0017] According to the target ownerless consensus protocol request, execute the resolution process of the logical timestamp of the target interference request, so as to form a resolution of the logical timestamp of the target interference request with other service nodes;

[0018] When a resolution is reached based on the logical timestamps of the interference requests in the first set of interference requests, the order in which the target request is applied to the state machine is determined according to the resolution of the target logical timestamp and the logical timestamps of the interference requests in the first set of interference requests.

[0019] This disclosure also provides an electronic device, including: a memory and a processor; wherein the memory is used to store a computer program;

[0020] The processor is coupled to the memory and is used to execute the computer program for performing the steps in the aforementioned disaster recovery method.

[0021] This disclosure also provides a computer-readable storage medium storing computer instructions that, when executed by one or more processors, cause the one or more processors to perform the steps in the aforementioned disaster recovery method.

[0022] This disclosure also provides a computer program product, including a computer program that, when executed by one or more processors, causes the one or more processors to perform the steps in the aforementioned disaster recovery method.

[0023] In this embodiment of the disclosure, in a masterless replication state machine scenario, multiple service nodes resolve the logical timestamp of a target masterless consensus protocol request without distinguishing whether the request has an interfering request resolution process. If multiple service nodes wait for the logical timestamp of an interfering request to be resolved and a timeout occurs, for the target interfering request whose logical timestamp has not been resolved at the timeout, the logical timestamp resolution process of the target interfering request can be determined based on the target masterless consensus protocol request of the target interfering requests currently existing in the multiple service nodes. Other service nodes then take over the logical timestamp resolution process of the target interfering request from that stage, forming a resolution for the logical timestamp of the target interfering request, thus achieving disaster recovery of the masterless replication state machine. Since the logical timestamp resolution process of the target interfering request abandons the traditional one-hop fast path optimization scheme, it is not necessary to distinguish which method the logical timestamp of the target interfering request is resolved during disaster recovery, which simplifies the disaster recovery process and helps improve disaster recovery efficiency (i.e., disaster recovery efficiency). Attached Figure Description

[0024] The accompanying drawings, which are included to provide a further understanding of this disclosure and form part of this disclosure, illustrate exemplary embodiments of the present disclosure and are used to explain the disclosure, but do not constitute an undue limitation of the disclosure. In the drawings:

[0025] Figure 1 shows a schematic diagram of a replication state machine, which is widely used in distributed storage systems.

[0026] Figure 2 is a schematic diagram illustrating the working principle of the strong master consensus protocol;

[0027] Figure 3 is a schematic diagram illustrating the working principle of the masterless consensus protocol;

[0028] Figure 4 is a schematic diagram of the structure of the distributed service system provided in the embodiment of this disclosure;

[0029] Figure 5 is a role diagram of the masterless consensus protocol provided in the embodiments of this disclosure;

[0030] Figure 6 is a schematic diagram of the structure of the logical timestamp provided in the embodiment of this disclosure;

[0031] Figure 7 is a schematic diagram of the disaster recovery process provided in the embodiments of this disclosure;

[0032] Figure 8 is a schematic diagram of the process of forming a logical timestamp of a request and a set of interference requests through a masterless consensus protocol according to an embodiment of this disclosure;

[0033] Figure 9 is a detailed schematic diagram of the disaster recovery process provided in the embodiments of this disclosure;

[0034] Figure 10 is a schematic diagram of the grayscale upgrade process provided in the embodiments of this disclosure;

[0035] Figure 11 is a schematic flowchart of the disaster recovery method provided in the embodiments of this disclosure;

[0036] Figure 12 is a schematic diagram of the structure of the electronic device provided in the embodiment of this disclosure. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of this disclosure clearer, the technical solutions of this disclosure will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0038] It should be noted that, in the cases involving user information in the embodiments of this disclosure, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this disclosure are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0039] Consensus protocols: A series of protocols proposed to solve the data consistency problem in distributed systems, such as Two-Phase Commit Protocol (2PC), Three-Phase Commit Protocol (3PC), Paxos consensus protocol, and Raft protocol, etc.

[0040] Paxos consensus protocol is an algorithm used to achieve consensus in distributed systems. It aims to solve the problem of how multiple nodes in a distributed environment can reach a consensus on a certain value (such as configuration, state updates, etc.), ensuring consistency even if some nodes fail or the network is unstable. The Paxos consensus protocol ensures consistency through two phases: the Prepare Phase and the Accept Phase.

[0041] The Raft protocol is a distributed consensus algorithm for managing replicated logs. It provides similar functionality to the Paxos protocol but is easier to understand and implement. The Raft protocol ensures consistency through three phases: leader election, log replication, and safety.

[0042] Strong consistency: In a distributed storage system, strong consistency means that the system guarantees that the data is consistent at any time. That is, no matter what operation is performed on any node, the latest data can be accessed immediately on all nodes.

[0043] Eventual consistency: In a distributed storage system, eventual consistency requires that once an update is successful, the data on each replica will eventually reach a completely consistent state, but the time required to reach a completely consistent state cannot be guaranteed.

[0044] Logical clock: This concept was introduced to distinguish it from physical clocks in the real world. It aims to ensure consistency between nodes in the order of events, rather than in physical time. Therefore, a logical clock refers to the time mechanism used in a distributed system to distinguish the order of events. In a sense, physical time in the real world is a special case of a logical clock.

[0045] Replicated State Machine: In a distributed system, this refers to a cluster of multiple servers. Each server runs a Deterministic Finite State Machine (DFSM), meaning that for a given input, the state machine always produces the same output and state transitions. The goal is to ensure that these state machines reach a consistent state so that, from the outside, it appears as if only one state machine is operating. If it can be ensured that all state machines receive the exact same sequence of commands and execute them in the same order, then these state machines will eventually reach the same final state. This means that regardless of which replica of the state machine a client connects to, it will get the same result. Because each state machine runs the same logic independently, the system can tolerate the failure of some state machines without affecting the overall quality of service.

[0046] Figure 1 illustrates a schematic diagram of a replicated state machine, widely used in distributed storage systems. As shown in Figure 1, in a replicated state machine scenario, each state machine maintains a log that records all received commands. The order of the logs is crucial, as it determines the order in which the state machines execute commands. A consensus protocol can be used to ensure that the logs on all state machines have a consistent sequence. Through the consensus protocol, it can be determined which commands should be added to the log and their order.

[0047] The following describes the research and development ideas of the solutions provided by the embodiments of this disclosure proposed by the inventors.

[0048] Figure 2 illustrates the principle of a strong-master consensus protocol. As shown in Figure 2, assuming the service instance includes three service nodes A, B, and C, solid arrows represent the access points to the service instance, dashed arrows represent the synchronization links between service nodes, and dashed lines represent the election links between service instances. Strong-master consensus protocols include Paxos, Raft, and ZAB. As shown in Figure 2, these consensus protocols are all strong-master protocols, requiring a single leader node replica to resolve request conflicts. This strong-master design offers high decision-making efficiency but also introduces some stability-related vulnerabilities.

[0049] (1) Single point of failure in availability: Once the leader node fails, a new election will be triggered. Until a new leader node is elected, the system service will be unavailable. Even if the leader node appears to be dead (i.e., not completely dead), the entire system service will remain interrupted. Here, "dead but not completely dead" means that although the leader node is still physically running, its functionality is severely impaired or it cannot provide normal service. In this state, the leader node may not be able to respond to client requests, communicate with other nodes, or perform critical tasks, but it has not completely crashed or stopped running. Therefore, other monitoring mechanisms may not be able to detect the leader node's failure immediately. In this state, other nodes cannot perceive the leader node's failure and will not trigger a leader election, leading to a complete system service interruption.

[0050] (2) Single Point of Failure at Access: Most consensus systems based on consensus protocols such as Paxos or Raft typically only provide access services to the outside world, in order to ensure strong consistency read capabilities. This creates a single point of failure at the access point. If the network between the client and the master node is interrupted, the client will be unable to access the entire consensus system. If the slave nodes also need to provide strong consistency read services, additional auxiliary mechanisms are required. For example, the slave node can perform a synchronization operation before executing a read request to ensure that the current replica's state is up-to-date, or the read request itself can carry a version number to ensure that data with a version number no less than the current version number is read. As shown in Figure 2, the Apache ZooKeeper (ZAB) protocol exposes all replicas to provide read and write services. The Apache ZooKeeper node is an open-source distributed coordination service that provides distributed lock services to applications through a tree-structured data model. Even so, as a strong master consensus protocol, the ZAB protocol does not fully utilize the network connectivity between replicas B and C, so it cannot be considered a perfect disaster recovery.

[0051] (3) Lack of canary deployment capability: Version upgrades of replicated state machine systems based on strong master consensus protocols typically follow an upgrade sequence from slave nodes to master nodes to minimize service unavailability during the upgrade process. However, for such consistency systems based on strong master consensus protocols, upgrading slave nodes lacks canary deployment capability for verifying the functionality of the new version. This is because the main processing logic of replicated state machines based on strong master consensus protocols resides on the master node. This upgrade is essentially a "one-shot" process, meaning that when upgrading to a master node replica, the master node verifies whether the new version has any risks. If a version problem is discovered only after upgrading to the master node, the overall service has already been compromised.

[0052] To address the stability challenges of the aforementioned strong-master consensus protocols, this disclosure proposes a masterless replication state machine. As shown in Figure 3, solid arrows represent the access entry points for service instances, dashed arrows represent the synchronization links between service nodes, and dashed lines represent the election links for service instances. In a distributed service system based on a masterless replication state machine, each replica can provide read and write access, and each replica can initiate proposals. If any replica fails, the remaining replicas will proactively take over the unresolved requests (i.e., Inflight requests) proposed by the failed replica. An Inflight request is a request proposed by the failed replica that has not yet reached a decision. This masterless replication state machine system possesses fault tolerance capabilities for both the access entry point and data synchronization links. Furthermore, each replica has the same processing logic and the same load pressure, making version canary upgrades truly meaningful.

[0053] Ownerless consensus protocols (such as EPaxos, Tempo, and Cassandra Accord) have not yet been truly implemented in industry due to performance, resource overhead, or engineering implementation complexity. Taking EPaxos as an example, each replica can reach consensus on a proposal request and its dependencies (linear dependencies that must be followed in the final global order). Then, each replica asynchronously performs a deterministic, globally consistent linear ordering on a series of requests and dependencies. The challenge in implementing EPaxos is that each replica needs to construct a directed connected graph for its dependencies, requiring topological sorting on this graph. However, this directed connected graph may contain cycles, resulting in high overall computational complexity. Furthermore, as new proposals are continuously generated, older proposals may depend on newer proposals, and newer proposals may depend on even newer proposals. This can lead to an endless, unending dependency chain, preventing the sorting process from proceeding and creating a livelock problem.

[0054] The Tempo protocol is one of the earliest known leaderless consensus protocols to introduce logical timestamps for ordering. The idea is that each replica proposes a logical timestamp for each request to be proposed, and a consensus is reached on this timestamp. This allows for simple asynchronous ordering by directly comparing the logical timestamps of the requests. The main challenge in industrial deployment of this protocol lies in the lack of explicit consensus communication regarding the dependencies of each proposed request. This leads to each replica needing to repeatedly broadcast communication with other replicas, waiting for all requests with timestamps smaller than its own proposal to be applied to the state machine before the proposed request can be applied to the state machine. This waiting time is relatively long. Therefore, the Tempo protocol is inefficient in determining when a request should be applied to the state machine.

[0055] The Cassandra Accord protocol (a type of leaderless consensus protocol) solves most of the problems of the aforementioned leaderless consensus protocols. It introduces logical timestamps for request ordering and establishes consensus on the dependencies of each request. When interfering requests exist in a proposed request, this protocol uses a leaderless consensus mechanism to reach consensus on request ordering and dependencies, i.e., a two-hop slow-path consensus. When interfering requests exist, it uses a 2PC protocol to reach consensus on request ordering, achieving a one-hop fast-path consensus, thus improving the efficiency of request ordering. However, this leads to a common problem in leaderless consensus protocols: because it maintains a one-hop optimization, disaster recovery scenarios require identifying the current state of a request and determining, based on information from limited replicas, whether a request previously reached consensus via a direct one-hop fast-path or a two-hop slow-path. This results in complex and inefficient disaster recovery, which is one of the challenges in implementing leaderless consensus protocols.

[0056] In some embodiments of this disclosure, in a masterless replication state machine scenario, multiple service nodes resolve the logical timestamp of a request through a masterless consensus protocol, without distinguishing whether the request has an interfering request resolution process. If multiple service nodes wait for the logical timestamp of an interfering request to be resolved and a timeout occurs, for the target interfering request whose logical timestamp has not been resolved at the time of timeout, the stage of the logical timestamp resolution process of the target interfering request can be determined based on the current masterless consensus protocol requests of the target interfering requests held by multiple service nodes. Other service nodes then take over the logical timestamp resolution process of the target interfering request Yi from that stage, forming a resolution for the logical timestamp of the target interfering request, thus achieving disaster recovery of the masterless replication state machine. Since the logical timestamp resolution process of the target interfering request abandons the traditional one-hop fast path optimization scheme, it is not necessary to distinguish which method the logical timestamp of the target interfering request is resolved during disaster recovery, which simplifies the disaster recovery process and helps improve disaster recovery efficiency (i.e., disaster recovery efficiency).

[0057] The technical solutions provided by the embodiments of this disclosure are described in detail below with reference to the accompanying drawings.

[0058] It should be noted that the same reference numerals in the following figures and embodiments denote the same object or the same step. Therefore, once an object or step is defined in one figure or embodiment, it does not need to be discussed further in subsequent figures and embodiments.

[0059] Figure 4 is a schematic diagram of the structure of the distributed service system provided in this embodiment of the disclosure. As shown in Figure 4, the system includes multiple service nodes 10. Each of the multiple service nodes 10 independently maintains a state machine. The distributed service system provided in this embodiment of the disclosure is a distributed service system in a masterless replicated state machine scenario. In Figure 4, solid arrows represent access points to service instances, dashed arrows represent synchronization links between service nodes, and dashed lines represent election links for service instances.

[0060] In a masterless replicated state machine scenario, each state machine maintains a log that records all received requests. The order of the logs determines the order in which the state machines execute the requests. A consensus protocol can be used to ensure that the logs on all state machines have a consistent sequence. The consensus protocol determines which requests should be added to the log and their execution order.

[0061] For any request to be processed, it requires the agreement of more than half of the service nodes (i.e., acceptance by more than half of the service nodes). Therefore, if more than half of the service nodes are operating normally, the service instance can provide the services it supports, and disaster recovery can be achieved for anomalies of less than half of the service nodes. For example, if there are 5 or 6 service nodes, disaster recovery can be achieved for anomalies of 2 service nodes. In this embodiment, "multiple" means at least 3, that is, 3 or more (including 3). Figure 4 only illustrates 3 service nodes (10), but this is not a limitation. The number of service nodes can be odd or even. Preferably, the number of service nodes is odd, because the disaster recovery capability of an odd number of service nodes is the same as that of an even number of service nodes that is 1 greater than the odd number. For example, the disaster recovery capability of 5 and 6 service nodes is the same as that of 2 service nodes.

[0062] In this embodiment of the disclosure, in addition to providing consistency coordination services, the multiple service nodes 10 can also provide other services supported by the service instance. These include partition scheduling services, load balancing services, and data storage services provided by the management node of the distributed storage system.

[0063] Multiple service nodes 10 are service nodes of the same service instance. A service instance refers to a specific instance that provides a specific service. The service instance runs on multiple service nodes 10. The service nodes specifically undertake the resources required for the corresponding service. In this embodiment of the disclosure, the specific content of the service running on the service instance is not limited. For example, the service instance can be a management instance in a distributed storage system, providing partition scheduling services, load balancing services, and data storage services, etc. As another example, the service instance can be a distributed lock service instance in a distributed lock system, providing distributed lock services, etc.

[0064] In this embodiment of the disclosure, multiple service nodes 10 are independent of each other, have independent resources, and do not share resources with each other. The resources of the service nodes 10 include, but are not limited to, processing resources such as processors, storage resources such as memory and disks, and input / output (IO) resources.

[0065] The consensus protocol provided in this embodiment is a target-no-master consensus protocol. As shown in Figure 5, this target-no-master consensus protocol includes two types of roles: a coordinator and replica nodes. The coordinator is responsible for proposing received requests and completing the process from proposal to resolution through the target-no-master consensus protocol. The replica nodes are responsible for receiving target-no-master consensus protocol requests sent by the coordinator and providing corresponding responses. A service node is both a coordinator and a replica node. For multiple service nodes, the one that proposes a request becomes the coordinator, and the other service nodes act as replica nodes of that coordinator.

[0066] The Targetless Consensus Protocol (DSCP) refers to a protocol that completes a request from proposal to resolution through a DSCP request. A DSCP request can include: a Pre-Accept request, an Accept request, and a Commit request. The Pre-Accept request is used to propose a request. The Accept request is used to broadcast that more than half of the service nodes have accepted the request. The Commit request is used to broadcast that more than half of the service nodes have reached a resolution on the request. For the Commit request, replica nodes can asynchronously apply the process to the state machine. Replica nodes can also proactively take over the subsequent resolution process of the Inflight request as needed.

[0067] To maintain consistency across multiple service nodes, each service node 10 independently maintains its own state machine. To ensure a consistent sequence of logs across all state machines, it is necessary to determine that the order of requests in the logs is consistent. For example, as shown in Figure 4, the log order across multiple service nodes 10 is: "x < -3", "y < -1", "y < -9", ..., each state machine executes the same command sequence, and the final state presented externally is: x is 3, y is 9. In this embodiment, the concept of a logical timestamp is introduced to determine the order of requests in the logs. A logical timestamp is a time mechanism to distinguish the order of requests; the execution order of requests can be determined by comparing the magnitudes of the logical timestamps. Generally, the larger the logical timestamp, the later the request is executed.

[0068] In this disclosure, the implementation form of the logical timestamp is not limited. In some embodiments, as shown in FIG6, the logical timestamp can be implemented as a triple, including: a physical timestamp, a sequence ID, and a replica ID. The physical timestamp is consistent with the physical clock in the real world and is used to record the physical time when the coordinating node proposes a request. The sequence number is an incrementing numerical sequence. The replica ID is the identifier of the service node.

[0069] The following explains how the logical timestamp relationship is determined. For logical timestamps T1 and T2, if the physical timestamp of T1 is greater than the physical timestamp of T2, it means that the request with logical timestamp T1 arrived later than the request with logical timestamp T2. Therefore, it can be determined that logical timestamp T1 is greater than T2. ​​In this way, the request with logical timestamp T2 will be listed before the request with logical timestamp T1 in the log, allowing the earlier-arriving request to be executed first.

[0070] If the physical timestamp of T1 equals the physical timestamp of T2, and the sequence number of T1 is greater than the sequence number of T2, it means that the request with the logical timestamp of T1 arrived later than the request with the logical timestamp of T2. Therefore, it can be determined that the logical timestamp of T1 is greater than T2. ​​In this way, the request with the logical timestamp of T2 will be placed before the request with the logical timestamp of T1 in the log order, so that the earlier-arriving request will be executed first.

[0071] If the physical timestamp of T1 is equal to the physical timestamp of T2, the sequence number of T1 is greater than the sequence number of T2, and the replica identifier of T1 is greater than the replica identifier of T2, then it means that the request with logical timestamp T1 and the request with logical timestamp T2 are concurrent requests proposed by different service nodes. The execution order of concurrent requests is not limited. Therefore, it can be determined that the logical timestamp T1 is greater than T2 or the logical timestamp T1 is less than T2, which means that the logical timestamps of concurrent requests are different.

[0072] The logical timestamp of a request, which is composed of a physical timestamp, a sequence number, and a replica identifier, can also be called a sequence coordinate. This ensures that no proposed requests with the same logical timestamp will appear in service instances.

[0073] Based on the logical timestamp of the request, in this embodiment of the disclosure, when any service node proposes a request (defined as target request X), as shown in step 1 of Figure 7, the service node, acting as the coordinating node 101 of the target request X (the first service node in Figures 7 and 8), can reach a resolution on the target logical timestamp Tx0 of the target request X with the replica node 102 through the target ownerless consensus protocol. Here, replica node 102 refers to a service node other than the coordinating node among multiple service nodes.

[0074] Because there may be interfering requests that affect the final state of the state machine, interfering requests to target request X refer to other requests that affect the order of target request X in the log. These requests will affect the final state of the state machine. Interfering requests to target request X can be prerequisite requests that target request X depends on, and are generally conflicting requests to target request X. Conflicting requests to target request X refer to requests that operate on the same object as target request X. These types of requests may affect the order in which target request X is applied to the state machine. For example, if target request X is used to request that the value of x be changed to 1; and request Y is used to request that the value of x be changed to 2, then the order of target request X and request Y in the log will affect the final state of the state machine. Based on this, coordinating node 101 can also reach a resolution with replica node 102 on the set C0 of interfering requests to target request X through the target masterless consensus protocol.

[0075] Coordinating node 101 can asynchronously reach a consensus with replica node 102 via a target-less consensus protocol to determine the target logical timestamp Tx0 of target request X and the set of interfering requests C0 of target request X. In this way, the coordination node 101 and replica node 102's determination of the target logical timestamp Tx0 of target request X and the set of interfering requests C0 of target request X will not block these service nodes from determining the logical timestamps and interfering request sets of other requests, allowing each request to occupy a logical timestamp in discrete time and space in a non-blocking manner.

[0076] Based on the aforementioned logical timestamps of the requests, the target masterless consensus protocol provided in this disclosure includes three phases: a pre-acceptance request phase, an acceptance request phase, and a resolution request phase. The coordinating node, through these three phases, reaches a resolution with the replica nodes regarding the logical timestamps of the requests and the set of interfering requests. In the pre-acceptance and acceptance request phases, the coordinating node determines the resolution of the logical timestamps of the requests based on the pre-acceptance and acceptance requests, and collects a set of conflicting requests. This set of conflicting requests can be empty or non-empty. A conflicting request refers to another request with the same operation object as the current request. Such conflicting requests may affect the order in which requests are applied to the state machine. In the resolution request phase, the coordinating node, through the resolution request, reaches a resolution with the replica nodes regarding the logical timestamps of the requests and the set of interfering requests. This set of interfering requests can be empty or non-empty. Interfering requests are other requests that affect the order in which requests are applied to the state machine. An interfering request is always a conflicting request, but a conflicting request is not necessarily an interfering request.

[0077] Specifically, the coordinating node 101 can asynchronously determine the target logical timestamp Tx0 and collect the conflict request set C0 of the target request X by broadcasting the pre-acceptance request and acceptance request for the target request X. ′ A conflicting request to target request X is a request whose operation object is the same as target request X. Such requests may affect the order in which target request X is applied to the state machine; therefore, the set C0 of conflicting requests to target request X is determined. ′ This can provide a reference for subsequent decisions regarding interference requests that truly affect the order in which target request X is applied to the state machine.

[0078] The following describes how the coordinating node 101 can asynchronously broadcast a pre-accept request and an accept request for target request X, determine the target logical timestamp Tx0, and collect a set of conflicting requests for target request X. The specific process is illustrated below. As shown in step 1 of Figure 8, when proposing target request X, the coordinating node 101 can broadcast a pre-accept request for target request X. The pre-accept request includes: the logical timestamp Tx1 configured by the coordinating node 101 for target request X and the target payload of target request X. The target payload of target request X records the operation object of target request X and the processing content performed by the operation object.

[0079] Accordingly, replica node 102 and coordinating node 101 can obtain the pre-acceptance request of target request X and persist the pre-acceptance request of target request X. The fact that replica node 102 and coordinating node 101 have persisted the pre-acceptance request of target request X indicates that the node has accepted the pre-acceptance request of target request X. Further, as shown in step 2 of Figure 8, replica node 102 and coordinating node 101 can determine the conflicting request set C1 of target request X based on the target payload.

[0080] Specifically, replica node 102 and coordinating node 101 can obtain the operation object of target request X from the target payload, and from the requests carried by the acquired target unclaimed consensus protocol request, obtain the set of requests whose operation objects are the same as the operation objects of the target payload, as the conflict request set C1 of target request X. Since the conflict requests of target request X may affect the order in which target request X is applied to the state machine, determining the conflict request set C1 of target request X can provide a reference for subsequent resolution of interference requests that truly affect the order in which target request X is applied to the state machine. Among them, the acquired target unclaimed consensus protocol request may include pre-acceptance requests, acceptance requests, and resolution requests.

[0081] If a service node (replica node or coordinator node) does not have any conflicting requests for target request X, then the set C1 of conflicting requests for target request X determined by that service node is an empty set. If a service node (replica node or coordinator node) has conflicting requests for target request X, then the set C1 of conflicting requests for target request X determined by that service node is a non-empty set, which is the set of conflicting requests for target request X.

[0082] After obtaining the conflict request set C1 of target request X, as shown in step 2 of Figure 8, "Determine the logical timestamp Tx2 of target request X", replica node 102 and coordinating node 101 can determine the logical timestamp Tx2 of target request X based on the maximum logical timestamp Ty of the requests in their respective conflict request sets C1. Tx2 is greater than Ty. Since determining that the logical timestamp Tx2 of target request X will not be less than the maximum logical timestamp Ty of the conflict requests based on the conflict request set C1 ensures that target request X becomes the maximum logical timestamp of the conflict request set for subsequent target request X. When a pre-acceptance request for a conflict request Z of target request X is subsequently received, the logical timestamp of conflict request Z determined by this node will be greater than the logical timestamp Tx2 of target request X. The subsequently received conflict request Z of target request X will not be older than target request X at this node, meaning that the subsequently received conflict request Z of target request X will not be prioritized before target request X, thus not affecting the order in which target request X is applied to the state machine.

[0083] In some embodiments, if the aforementioned maximum logical timestamp Ty is greater than or equal to the logical timestamp Tx1 carried by the pre-accepted request of the target request X (i.e., Ty ≥ Tx1), then the logical timestamp of the target request X can be updated based on the maximum logical timestamp Ty to obtain the logical timestamp Tx2 of the target request X, where Tx2 > Ty. This ensures that conflicting requests Z subsequently received by the node for the target request X will not precede the target request X, thus not affecting the order in which the target request X is applied to the state machine.

[0084] Based on the triple consisting of the physical timestamp, sequence number, and replica identifier, the physical timestamp of the logical timestamp Tx1 of the target request X can be updated to the physical timestamp in the maximum logical timestamp Ty; the sequence number of the logical timestamp Tx1 of the target request X can be updated to the sequence number in the maximum logical timestamp Ty plus a set value. The set value is a positive integer, typically set to 1, ensuring that the sequence numbers of the target request X and its conflicting requests are consecutive, facilitating log sorting of the target request X and its conflicting requests. Correspondingly, the physical timestamp of the logical timestamp Tx1 of the target request X can also be updated to the replica identifier of this service node to obtain the logical timestamp Tx2 of the target request X. This ensures that the logical timestamp of a subsequent conflicting request Z of the target request X received by this service node will not be smaller than the logical timestamp Tx2 of the target request X on this service node, thus preventing the conflicting request Z from being prioritized before the target request X and avoiding affecting the order in which the target request X is applied to the state machine.

[0085] Accordingly, if the aforementioned maximum logical timestamp Ty is less than the logical timestamp Tx1 carried by the pre-acceptance request of the target request X (i.e., Ty < Tx1), then the logical timestamp Tx1 carried by the pre-acceptance request of the target request X can be determined as the logical timestamp Tx2 of the target request X. Since the logical timestamp Tx1 of the target request X is already the maximum logical timestamp among requests with the same operating object, this ensures that the logical timestamp of the conflicting request Z of the target request X received subsequently by this service node will not be smaller than the logical timestamp Tx2 of the target request X on this service node. Consequently, the conflicting request Z will not be ranked before the target request X, and thus will not affect the order in which the target request X is applied to the state machine.

[0086] As shown in step 3 of Figure 8, for replica node 102, after determining the logical timestamp Tx2 of the target request X on this service node, it can return a pre-accept request to the coordinating node 101. This pre-accept request may include the logical timestamp Tx2 of the target request X determined by this service node and the set of conflicting requests C1 of the target request X.

[0087] Since the consensus protocol uses the majority rule for request processing, to ensure the high availability of the distributed service system and allow the entire system to continue functioning even when some service nodes fail, the majority rule can also be applied when deciding on the target logical timestamp Tx0 of the target request X and the set of interfering requests C0. Based on this, the coordinating node 101 can count the number of pre-acceptance confirmation requests it receives. These pre-acceptance confirmation requests include those generated by the protocol node 101 itself.

[0088] Furthermore, if the number of pre-acceptance confirmation requests received is greater than or equal to a set number R, as shown in step 4 of Figure 8, the coordinating node 101 determines the target logical timestamp Tx0 of the target request X based on the logical timestamp Tx2 carried by the received pre-acceptance confirmation requests. Generally, the coordinating node 101 can obtain the largest logical timestamp from the logical timestamps Tx2 carried by the received pre-acceptance confirmation requests as the target logical timestamp of the target request X. The largest logical timestamp ensures that the target request X has a unique timestamp that is larger than all previous operations, simplifying the conflict detection and resolution process and reducing the need for additional processing.

[0089] Specifically, the number R is set to be greater than or equal to half of the total number M of the aforementioned service nodes 10, and less than the total number M of the service nodes 10. That is, M / 2 ≤ R < M. In this way, more than half of the service nodes 10 corresponding to the same service instance participate in resolving the target logical timestamp of the target request X. Even if some service nodes fail, the remaining service nodes can still form a majority and continue to process the request, ensuring the high availability and fault tolerance of the system.

[0090] On the other hand, in a distributed service system, if only a few nodes participate in the decision-making process, multiple different target logical timestamps may be confirmed, leading to data inconsistency. Therefore, having more than half of the nodes participate in the decision-making process for the target logical timestamp of target request X can effectively prevent this from happening.

[0091] In this embodiment of the disclosure, as shown in step 4 of FIG8, the coordinating node 101 can further determine the conflict request set C2 of the target request X based on the conflict request set C1 carried by the obtained pre-acceptance confirmation requests when the number of pre-acceptance confirmation requests is greater than or equal to a set number R. The conflict request set C2 can be the union of the conflict request sets C1. In this way, the coordinating node 101 can integrate conflict requests from multiple service nodes 10, providing a more comprehensive basis for subsequently determining the interference requests that truly affect the application of the target request X to the state machine.

[0092] It is worth noting that if the set of conflict requests C1 carried by the pre-acceptance confirmation request obtained by coordinating node 101 is an empty set, then the set of conflict requests C2 is also an empty set. If the set of conflict requests C1 carried by the pre-acceptance confirmation request obtained by coordinating node 101 is not empty, then the set of conflict requests C2 is also not empty.

[0093] To ensure that the multiple service nodes 10 of the service instance reach a consensus on the target logical timestamp of target request X and the conflict request set C2 of target request X, as shown in step 5 of Figure 8, the coordinating node 101 can also broadcast an acceptance request for target request X. The acceptance request includes the target logical timestamp of target request X and the conflict request set C2 of target request X.

[0094] Accordingly, replica node 102 can receive and persistently store the acceptance request for use in accepting the request. Since the target logical timestamp is determined by coordinating node 101 based on the logical timestamp carried in the pre-acceptance confirmation request (e.g., the largest logical timestamp among those carried in the pre-acceptance confirmation request), replica node 102 and coordinating node 101 may also receive conflict requests for target request X with logical timestamps less than the target logical timestamp Tx0 after issuing the pre-acceptance confirmation request. To ensure the comprehensiveness of the subsequently resolved set of interfering requests C0 for target request X, replica node 102 and coordinating node 101 can also obtain target conflict requests Y1 with logical timestamps less than the target logical timestamp from the locally stored conflict requests for target requests. The target conflict request Y1 may or may not exist, depending primarily on whether replica node 102 or coordinating node 101 receives conflict requests for target request X with logical timestamps less than the target logical timestamp Tx0 after issuing the pre-acceptance confirmation request. If a target conflict request Y1 exists, the union of target conflict request Y1 and conflict request set C2 can be used to determine the conflict request set C3 of target request X (as shown in step 6 of Figure 8, "Determine the conflict request set C3 with logical timestamps less than Tx0"). Further, as shown in step 6 of Figure 8, replica node 102 can return an AcceptOK request to coordinating node 101. The AcceptOK request includes the conflict request set C3 of target request X. The fifth conflict request set C3 can be empty or non-empty.

[0095] Accordingly, as shown in step 8 of Figure 8, the coordinating node 101 can obtain the acceptance confirmation request; and collect the set of conflict requests C3 carried by the obtained acceptance confirmation request as the set of conflict requests C0′ of the target request X.

[0096] Specifically, if the number of received acceptance confirmation requests is greater than or equal to a set number R, the coordinating node 101 can determine the union of the conflict request sets C3 carried by the received acceptance confirmation requests as the conflict request set C0′ of the target request X. In this way, more than half of the service nodes 10 corresponding to the same service instance participate in resolving the conflict request set C0′ of the target request X. Even if some service nodes fail, the remaining service nodes can still form a majority and continue to process the request, ensuring the high availability and fault tolerance of the system.

[0097] On the other hand, in a distributed service system, if only a few nodes participate in the decision-making process, multiple different conflict request sets C0′ may be confirmed, which may lead to data inconsistency. Therefore, having more than half of the nodes participate in the decision-making process for the conflict request set C0′ of the target request X can effectively prevent this from happening.

[0098] Further, as shown in step 8 of Figure 8, the coordinating node 101 can determine the interfering request set C0 of the target request X based on the collected conflicting request set C0′. The interfering request set C0 can be either empty or non-empty. If all conflicting request sets C3 carried by the acceptance confirmation requests obtained by the coordinating node 101 are empty, then the interfering request set C0 is empty. If any conflicting request set C3 carried by the acceptance confirmation requests obtained by the coordinating node 101 is non-empty, then the interfering request set C0 is non-empty.

[0099] Specifically, the coordinating node 101 can determine the union of the conflict request set C3 carried by the received acceptance confirmation request as the interference request set C0 of the target request X. Furthermore, the coordinating node 101 can broadcast a resolution request for the target request X to form a resolution with the replica node 102 regarding the target logical timestamp Tx0 and the interference request set C0.

[0100] Specifically, as shown in step 9 of Figure 8, the coordinating node 101 can broadcast a resolution request for the target request X, which includes the target logical timestamp Tx0 and the interference request set C0, so as to form a resolution with the replica node 102 regarding the target logical timestamp Tx0 and the interference request set C0.

[0101] Through the above process, coordinating node 101, via the target ownerless consensus protocol, and replica node 102, reach a resolution on the target logical timestamp Tx0 and the interference request set C0. This interference request set C0 can be empty or non-empty, depending on whether protocol node 101 and replica node 102 have received requests that conflict with the target request X.

[0102] In this embodiment, when resolving the logical timestamp of the request and the set of interfering requests, the resolution process for whether a request has interfering requests is no longer differentiated. A unified target-less consensus protocol is used, specifically a two-hop slow-path resolution of the request's logical timestamp and the set of interfering requests, abandoning the traditional one-hop fast-path optimization. The traditional one-hop fast-path optimization refers to the following: after step 4 in Figure 8, if the set C1 of conflicting requests for target request X carried by the pre-acceptance confirmation request obtained by the coordinating node 101 is empty, the coordinating node directly broadcasts a resolution request. This resolution request includes the target logical timestamp Tx0 of target request X, directly forming a resolution of the logical timestamp of target request X with the replica node 102, without executing steps 5-9 in Figure 8. The resolution of the logical timestamp of the request provided in this embodiment can provide basic support for simplifying disaster recovery. This part will be described in the following embodiments and will not be repeated here.

[0103] After multiple service nodes 10 reach a resolution on the target logical timestamp Tx0 of the target request X and the set of interference requests C0 of the target request X, in the embodiment where the first set of interference requests for the target request X is empty, since there are no interference requests for the target request X, the coordinating node 101 and the replica node 102 can directly apply the target request X to the state machine sequence.

[0104] In embodiments where the interference request set C0 is non-empty, since the interference request set C0 of the target request X affects the order in which the target request X is applied to the state machine, as shown in step 2 of Figure 7, the coordinating node 101 and the replica node 102 can wait for the logical timestamps of each interference request in the interference request set C0 of the target request X to form a resolution. After the logical timestamps of each interference request in the interference request set C0 of the target request X are resolved, the order in which the target request X is applied to the state machine is determined based on the resolution of the target logical timestamp Tx0 of the target request X and the logical timestamps of each interference request in the interference request set C0. This achieves consistency in the order in which the target request X is applied to the state machine among multiple service nodes, thereby maintaining data consistency among multiple service nodes. This implementation takes into account the influence of the interference request set C0 on the order in which the target request X is applied to the state machine, which helps to improve the accuracy of the order in which the target request X is applied to the state machine.

[0105] Specifically, for any service node, the relationship between the target logical timestamp of target request X and the logical timestamps of each interfering request of target request X can be determined. Specifically, the logical timestamp includes: physical timestamp, sequence number, and replica identifier. Correspondingly, for any two logical timestamps among the target logical timestamp of target request X and the logical timestamps of each interfering request of target request X, defined as the first logical timestamp T1 and the second logical timestamp T2, the relationship between the first logical timestamp T1 and the second logical timestamp T2 can be determined. For specific implementation methods of determining the first logical timestamp T1 and the second logical timestamp T2, please refer to the relevant content of the foregoing embodiments, which will not be repeated here. Using the same method, the relationship between the target logical timestamp of target request X and the logical timestamps of each interfering request of target request X can be determined. Furthermore, the order in which target request X is applied to the state machine can be determined based on the relationship between the target logical timestamp of target request X and the logical timestamps of each interfering request of target request X. In this embodiment, the order in which target request X is applied to the state machine precedes interference requests whose logical timestamp resolution is greater than the target logical timestamp Tx0, and follows interference requests whose logical timestamp resolution is less than the target logical timestamp Tx0. That is, the order in which requests are applied to the state machine is inversely proportional to the size of their logical timestamps; requests with larger logical timestamps are applied to the state machine later. The order in which interference requests of target request X are applied to the state machine is determined by the resolution of the logical timestamp of the interference request and the resolutions of the logical timestamps of each interference request in the interference request set. In this embodiment, determining the order in which requests are applied to the state machine based on the relationship between the logical timestamps of the requests simplifies the logic for determining the order and improves the efficiency of determining the order.

[0106] However, in practical applications, during the process of waiting for the interference requests in the interference request set C0 of the target request X to reach a decision, the coordinating node 101 and replica node 102 may encounter an anomaly while waiting for the interference requests to form a decision. This could cause the coordinating node 101 and replica node 102 to time out and enter failover recovery mode. In this embodiment of the disclosure, for ease of description and distinction, the coordinating node that proposes the target request X is defined as the first coordinating node; and the coordinating node that proposes the interference request Y2 is defined as the second coordinating node. The first and second coordinating nodes may be the same service node or different service nodes. The disaster recovery process provided in this embodiment of the disclosure is described below as an example.

[0107] As shown in step 2 of Figure 7, the coordinating node 101 and replica node 102 wait for the logical timestamps of the interference requests in the interference request set C0 of the target request X to form a resolution. If, after the waiting time reaches the set time threshold, there is still a target interference request Yi in the interference request set C0 whose logical timestamp has not formed a resolution, then the system enters the failover recovery mode. Specifically, for any service node, if it receives a resolution request for interference request Yi, it determines that the logical timestamp of interference request Yi has formed a resolution; if, after the waiting time reaches the set time threshold, it has not received a resolution request for interference request Yi, it determines that the logical timestamp of interference request Yi has not formed a resolution, thus identifying interference request Yi as the target interference request Yi, and the service node enters the failover recovery mode.

[0108] In this embodiment of the disclosure, regardless of whether there is an interference request, the logical timestamp of the request is resolved through the target masterless consensus protocol. The logical timestamp resolution process of the target interference request Yi is also completed by the target masterless consensus protocol. Therefore, based on the target masterless consensus protocol requests of the target interference request Yi currently existing on multiple service nodes, it can be determined which stage the logical timestamp resolution process of the target interference request Yi has reached. In this way, other service nodes take over the logical timestamp resolution process of the target interference request Yi from that stage, thus forming the logical timestamp resolution of the target interference request Yi.

[0109] For example, if multiple service nodes have resolution requests for the target interference request Yi, it means that the logical timestamp of the target interference request Yi and the interference request set D0 of the target interference request Yi have been resolved. Then, a service node can broadcast the resolution request for the target interference request Yi to form a resolution for the logical timestamp of the target interference request Yi. As another example, if multiple service nodes have acceptance requests for the target interference request Yi, but no resolution requests for the target interference request Yi, it means that the logical timestamp of the target interference request Yi has been resolved, but the interference request set D0 of the target interference request Yi has not yet been resolved. Then, other service nodes can start executing the process of the logical timestamp of the target interference request Yi and the interference request set D0 of the target interference request Yi from broadcasting the acceptance request for the target interference request Yi.

[0110] Based on this, as shown in step 3 of Figure 7, after entering disaster recovery mode, the service node (defined as the second service node) can obtain the target unclaimed consensus protocol request for the target interference request Yi. The target unclaimed consensus protocol request includes one or more of the following: a pre-acceptance request, an acceptance request, and a resolution request. "Multiple" refers to two or more types (including two). Of course, there may not be a target unclaimed consensus protocol request for the target interference request Yi. The second service node and the aforementioned first service node can be the same service node or different service nodes.

[0111] In some embodiments, as shown in step 3 of FIG9, if the second service node determines that the logical timestamp wait of the interference request of the target request X has timed out, it can broadcast a recovery request for the target interference request Yi. This recovery request may include the identifier of the target interference request Yi. Other service nodes (service nodes other than the second service node) can receive the recovery request for the target interference request Yi. As shown in step 4 of FIG9, if the second service node and other service nodes receive the recovery request for the target interference request Yi, they can reject the pre-acceptance request and acceptance request for the target interference request Yi sent by other service nodes besides the second service node. This discards the original decision process for the logical timestamp of the target interference request Yi. If the old pre-acceptance request or acceptance request for the target interference request Yi is still accepted at this time, it may lead to a conflict between the old and new states in the logical timestamp decision process of the target interference request Yi, disrupting consistency. Rejecting the pre-acceptance request and acceptance request of the target interference request Yi sent by other service nodes besides the second service node ensures the strong consistency of the original decision process that can safely discard the logical timestamp of the target interference request Yi.

[0112] When the second service node and other service nodes receive a recovery request for the target interference request Yi, they also retrieve the target unclaimed consensus protocol request for the target interference request Yi from their local storage. Then, as shown in step 5 of Figure 9, they return the target unclaimed consensus protocol request for the target interference request Yi to the second service node. The second service node can collect the target unclaimed consensus protocol requests for the target interference request Yi returned by other service nodes and / or the target unclaimed consensus protocol requests for the target interference request Yi stored locally, as the target unclaimed consensus protocol request. Further, as shown in step 4 of Figure 7, the second service node can execute a process to resolve the logical timestamp of the target interference request based on the target unclaimed consensus protocol request, thereby forming a resolution on the logical timestamp of the target interference request.

[0113] In this embodiment, multiple service nodes resolve the logical timestamp of a target masterless consensus protocol request without distinguishing whether the request involves an interfering request resolution process. If multiple service nodes wait for the logical timestamp of an interfering request to be resolved and a timeout occurs, for the target interfering request whose logical timestamp has not been resolved at the timeout, the logical timestamp resolution process of the target interfering request can be determined based on the target masterless consensus protocol request of the target interfering request currently existing in the multiple service nodes. Other service nodes then take over the logical timestamp resolution process of the target interfering request Yi from that stage, forming a resolution for the logical timestamp of the target interfering request, thus achieving disaster recovery of the masterless replication state machine. Since the logical timestamp resolution process of the target interfering request abandons the traditional one-hop fast path optimization scheme, it is not necessary to distinguish which method the logical timestamp of the target interfering request is resolved during disaster recovery, simplifying the disaster recovery process and helping to improve disaster recovery efficiency (i.e., disaster recovery efficiency).

[0114] Specifically, as shown in step 6 of Figure 9, if the target unclaimed consensus protocol request includes a resolution request for the target interference request Yi, and this resolution request includes a resolution of the logical timestamp of the target interference request Yi, then the second service node can broadcast the resolution request for the target interference request Yi to form a resolution of the logical timestamp of the target interference request Yi with other service nodes. Of course, the resolution request may also include the interference request set D0 of the target interference request Yi. Correspondingly, the second service node, by broadcasting the resolution request for the target interference request Yi, can also form a resolution of the interference request set D0 of the target interference request Yi with other service nodes.

[0115] If the target unclaimed consensus protocol request includes an acceptance request for the target interference request Yi, but does not include a resolution request for the target interference request Yi, it means that the logical timestamp of the target interference request Yi forms a resolution. In this case, the second service node can broadcast the acceptance request for the target interference request Yi to form a resolution on the logical timestamp of the target interference request Yi with other service nodes.

[0116] However, for the target unclaimed consensus protocol request, which includes: the acceptance request of the target interference request Yi, but not the resolution request of the target interference request Yi, and also indicates that the set of interference requests of the target interference request Yi has not yet formed a resolution, then as shown in step 8 of Figure 9, the second service node can also collect the set of conflict requests D0 of the target interference request Yi by broadcasting the acceptance request of the target interference request Yi. ′ Regarding the second service node's acceptance request for the target interference request Yi broadcast, it collects the conflict request set D0 of the target interference request Yi. ′ For the specific process, please refer to the aforementioned coordination node 101, which collects the conflict request set C0 of target request X by broadcasting the acceptance request of target request X.′ The relevant content will not be repeated here.

[0117] Furthermore, as shown in step 9 of Figure 9, the second service node can, based on the collected conflict request set D0 of the target interference request Yi, ′ Determine the set of interference requests D0 of the target interference request Yi. Regarding the set of conflict requests D0 collected from the target interference request Yi. ′ For a specific implementation of determining the interference request set D0 of the target interference request Yi, please refer to the aforementioned coordination node 101 based on the collected conflict request set C0 of the target request X. ′ The details regarding the interference request set C0 for the target request X will not be elaborated upon here.

[0118] Further, as shown in step 10 of Figure 9, the second service node can broadcast a resolution request for the target interference request Yi. This resolution request includes: a resolution for the logical timestamp of the target interference request Yi and a resolution for the interference request set D0 of the target interference request Yi. Other service nodes receive the resolution request for the target interference request Yi and obtain the logical timestamp of the target interference request Yi and the resolution for the interference request set D0 from the resolution request for the target interference request Yi, thereby forming a resolution for the logical timestamp of the target interference request Yi and a resolution for the interference request set D0.

[0119] Using the same method, multiple service nodes can form a resolution on the logical timestamp of each target interference request Yi and the resolution on the interference request set D0, thereby obtaining a resolution on the logical timestamp of each interference request in the interference request set C0 of the target request X and a resolution on the interference request set D0.

[0120] Subsequently, as shown in step 5 of Figure 7, multiple service nodes 10 can determine the order in which the target request X is applied to the state machine based on the resolution of the target logical timestamp Tx0 of the target request X and the logical timestamps of each interference request in the interference request set C0. This achieves consistency in the order in which the target request X is applied to the state machine among multiple service nodes, thereby maintaining data consistency among multiple service nodes. This implementation takes into account the influence of the interference request set C0 on the order in which the target request X is applied to the state machine, which helps to improve the accuracy of the order in which the target request X is applied to the state machine.

[0121] In some embodiments, as shown in step 7 of Figure 9, if the target unclaimed consensus protocol request for the target interference request Yi collected by the second service node does not include: the resolution request for the target interference request Yi and the acceptance request for the target interference request Yi, then the second service node broadcasts another resolution request for the target interference request Yi. To distinguish it from the resolution request in the aforementioned target unclaimed consensus protocol, the resolution request in the target unclaimed consensus protocol is defined as the first resolution request, and the resolution request in step 7 of Figure 9 is defined as the second resolution request. The second resolution request includes target resolution information; this target resolution information includes: the logical timestamp of the target interference request Yi is positive infinity, and the set of interference requests for the target interference request Yi is an empty set. Other service nodes receiving such a resolution request can form a consensus based on this target resolution information. The fact that the logical timestamp of the target interference request Yi is positive infinity ensures that the target interference request Yi cannot become an interference request for any other request, thus preventing the target interference request Yi from affecting the order in which other requests are applied to the state machine. For a description of steps 1 and 2 in Figure 9, please refer to the relevant content of steps 1 and 2 in Figure 7 above, which will not be repeated here.

[0122] This disclosed embodiment implements a masterless consensus replication state machine based on logical timestamps. Multiple service nodes can provide read and write access points, eliminating single points of failure in access points and stability. If some service nodes malfunction, other service nodes can proactively take over requests proposed by the malfunctioning service nodes that have not yet reached a resolution.

[0123] On the other hand, the masterless consensus replication state machine mechanism provided in this disclosure supports canary upgrades. A management node (not shown in the figures) can perform recovery upgrades on service instances belonging to multiple service nodes. Specifically, the management node can obtain the canary upgrade ratio and perform traffic control on multiple service nodes based on the ratio. Specifically, the number N of target service nodes to be upgraded can be determined based on the canary upgrade ratio; and during the version upgrade process, the access traffic to these N target service nodes is controlled to be 0, and the access traffic to the remaining service nodes is evenly distributed, thereby achieving load balancing. The canary upgrade ratio is generally less than 50%, ensuring that even if a new version of the service node malfunctions, more than half of the service nodes in the service instance still provide services.

[0124] Next, the services on N target service nodes can be upgraded to a different version, thus achieving a canary rollout. This ensures that even if the new version has anomalies, only a small portion of the access traffic to the service instances is affected, improving the availability of the distributed service system. Afterwards, the management node can control the access traffic to multiple service nodes based on their operational status after the version upgrade. If all N target service nodes are operating normally, access traffic can be evenly distributed across them, achieving load balancing among the service nodes.

[0125] For example, as shown in Figure 10, assuming a service instance has three service nodes A, B, and C, and the canary upgrade ratio is 33%, then one service node can be upgraded, such as service node B. Then, as shown in step 1 of Figure 10, the access traffic to service node B can be controlled to 0, while the access traffic to service nodes A and C can be controlled to 50%, and service node B can be upgraded. After the version upgrade of service node B is successful (i.e., service node B's version is upgraded from version V1 to version V2), the control node can gradually increase the access traffic to service node B until service node B shares the access traffic equally with service nodes A and B, as shown in step 2 of Figure 10, gradually adjusting the access traffic of each service node to approximately 33%, thus achieving load balancing among service nodes A, B, and C.

[0126] In addition to the distributed service system provided in the foregoing embodiments, this disclosure also provides a disaster recovery method in a masterless replication state machine scenario. The disaster recovery method provided in this disclosure is illustrated below.

[0127] Figure 11 is a flowchart illustrating the disaster recovery method provided in this embodiment. This method is applicable to any one of multiple service nodes in a distributed service system. Multiple service nodes independently maintain their state machines; the distributed service system employs a masterless replication state machine mechanism. When any first service node among the multiple service nodes acts as a coordinating node, it reaches a resolution with the replica nodes of the coordinating node through a target masterless consensus protocol, determining the target logical timestamp Tx0 of the target request X and the set of interference requests C0. The target request is the request proposed by the coordinating node; the replica nodes refer to service nodes other than the first service node among the multiple service nodes. As shown in Figure 11, this disaster recovery method mainly includes the following steps:

[0128] 1101. The logical timestamps of the interference requests in the interference request set C0 are used to form a resolution.

[0129] 1102. If, when the waiting time reaches the set time threshold, there is a target interference request Yi in the interference request set C0 whose logical timestamp has not yet formed a resolution, then the target unclaimed consensus protocol request of the target interference request is obtained.

[0130] 1103. Based on the target ownerless consensus protocol request, execute the resolution process of the logical timestamp of the target interference request Yi, so as to form a resolution of the logical timestamp of the target interference request Yo with other service nodes.

[0131] 1104. When the logical timestamps of the interference requests in the interference request set C0 are resolved, the order in which the target request is applied to the state machine is determined based on the resolution of the target logical timestamp and the logical timestamps of the interference requests in the interference request set C0.

[0132] For the concepts of service nodes, target ownerless consensus protocol, coordination nodes and replica nodes, please refer to the relevant content in the foregoing embodiments, which will not be repeated here.

[0133] To maintain consistency across multiple service nodes, each node independently maintains its own state machine. To ensure a consistent sequence of logs across all state machines, it's necessary to determine the consistent order of requests within the logs. In this embodiment, the concept of a logical timestamp is introduced to determine the order of requests in the logs. A logical timestamp is a time mechanism for distinguishing the order of requests; the execution order of requests can be determined by comparing the magnitudes of the logical timestamps. Generally, a larger logical timestamp indicates a later execution of the request.

[0134] In this disclosure, the implementation form of the logical timestamp is not limited. In some embodiments, the logical timestamp may be implemented as a triple, including: a physical timestamp, a sequence number, and a replica identifier.

[0135] The following explains how the logical timestamp relationship is determined. For logical timestamps T1 and T2, if the physical timestamp of T1 is greater than the physical timestamp of T2, it means that the request with logical timestamp T1 arrived later than the request with logical timestamp T2. Therefore, it can be determined that logical timestamp T1 is greater than T2. ​​In this way, the request with logical timestamp T2 will be listed before the request with logical timestamp T1 in the log, allowing the earlier-arriving request to be executed first.

[0136] If the physical timestamp of T1 equals the physical timestamp of T2, and the sequence number of T1 is greater than the sequence number of T2, it means that the request with the logical timestamp of T1 arrived later than the request with the logical timestamp of T2. Therefore, it can be determined that the logical timestamp of T1 is greater than T2. ​​In this way, the request with the logical timestamp of T2 will be placed before the request with the logical timestamp of T1 in the log order, so that the earlier-arriving request will be executed first.

[0137] If the physical timestamp of T1 is equal to the physical timestamp of T2, the sequence number of T1 is greater than the sequence number of T2, and the replica identifier of T1 is greater than the replica identifier of T2, then it means that the request with logical timestamp T1 and the request with logical timestamp T2 are concurrent requests proposed by different service nodes. The execution order of concurrent requests is not limited. Therefore, it can be determined that the logical timestamp T1 is greater than T2 or the logical timestamp T1 is less than T2, which means that the logical timestamps of concurrent requests are different.

[0138] The logical timestamp of a request, which is composed of a physical timestamp, a sequence number, and a replica identifier, can also be called a sequence coordinate. This ensures that no proposed requests with the same logical timestamp will appear in service instances.

[0139] Based on the logical timestamp of the request, in this embodiment of the disclosure, when any service node proposes a request (defined as target request X), the service node, acting as the coordinating node for target request X, can reach a resolution with the replica nodes regarding the target logical timestamp Tx0 of target request X through a target ownerless consensus protocol. Here, replica node 102 refers to a service node other than the coordinating node among multiple service nodes.

[0140] Since there may be interfering requests that affect the final state of the state machine, the coordinating node can also reach a resolution with the replica nodes regarding the set of interfering requests C0 for the target request X through a target-less consensus protocol.

[0141] Specifically, a target-free consensus protocol can be asynchronously used to reach a decision with replica nodes on the target logical timestamp Tx0 of target request X and the set of interfering requests C0 of target request X. In this way, the decision on the target logical timestamp Tx0 and the set of interfering requests C0 of target request X by the coordinating node and replica nodes will not block these service nodes from deciding on the logical timestamps and sets of interfering requests for other requests. The logical timestamp of each request can be occupied in discrete time and space in a non-blocking manner.

[0142] Specifically, the target logical timestamp Tx0 and the set of conflicting requests C0 for target request X can be determined asynchronously by broadcasting pre-acceptance requests and acceptance requests for target request X. ′ A conflicting request to target request X is a request whose operation object is the same as target request X. Such requests may affect the order in which target request X is applied to the state machine; therefore, the set C0 of conflicting requests to target request X is determined. ′ This can provide a reference for subsequent decisions regarding interference requests that truly affect the order in which target request X is applied to the state machine.

[0143] The following describes how to asynchronously broadcast pre-accept and accept requests for target request X, determine the target logical timestamp Tx0, and collect the set of conflicting requests for target request X. Specifically, when proposing target request X, the coordinating node can broadcast a pre-accept request for target request X. The pre-accept request includes: the logical timestamp Tx1 configured by the coordinating node for target request X and the target payload of target request X. The target payload of target request X records the operation object of target request X and the processing content performed by the operation object.

[0144] Accordingly, replica nodes and coordinating nodes can obtain the pre-acceptance request of target request X and persist the pre-acceptance request of target request X. The fact that replica nodes and coordinating nodes have persisted the pre-acceptance request of target request X indicates that the nodes have accepted the pre-acceptance request of target request X. Furthermore, replica nodes and coordinating nodes can determine the set of conflicting requests C1 of target request X based on the target payload.

[0145] Specifically, replica nodes and coordinating nodes can obtain the operation object of target request X from the target payload, and from the requests carried by the acquired target unclaimed consensus protocol request, obtain the set of requests whose operation objects are the same as the operation objects of the target payload, as the conflict request set C1 of target request X. Since conflict requests of target request X may affect the order in which target request X is applied to the state machine, determining the conflict request set C1 of target request X can provide a reference for subsequent resolution of interference requests that truly affect the order in which target request X is applied to the state machine. Among them, the acquired target unclaimed consensus protocol request may include pre-acceptance requests, acceptance requests, and resolution requests.

[0146] If a service node (replica node or coordinator node) does not have any conflicting requests for target request X, then the set C1 of conflicting requests for target request X determined by that service node is an empty set. If a service node (replica node or coordinator node) has conflicting requests for target request X, then the set C1 of conflicting requests for target request X determined by that service node is a non-empty set, which is the set of conflicting requests for target request X.

[0147] After obtaining the conflict request set C1 of target request X, the replica node and the coordinating node can determine the logical timestamp Tx2 of target request X based on the maximum logical timestamp Ty of the requests in their respective conflict request sets C1. Tx2 is greater than Ty. Since determining that the logical timestamp Tx2 of target request X will not be less than the maximum logical timestamp Ty of the conflict requests, it ensures that target request X becomes the maximum logical timestamp of the conflict request set for subsequent target requests X. When a pre-acceptance request for a conflict request Z of target request X is subsequently received, the logical timestamp of conflict request Z determined by this node will be greater than the logical timestamp Tx2 of target request X. The subsequently received conflict request Z of target request X will not be older than target request X on this node; that is, the subsequently received conflict request Z of target request X will not be prioritized before target request X, thus not affecting the order in which target request X is applied to the state machine.

[0148] In some embodiments, if the aforementioned maximum logical timestamp Ty is greater than or equal to the logical timestamp Tx1 carried by the pre-accepted request of the target request X (i.e., Ty ≥ Tx1), then the logical timestamp of the target request X can be updated based on the maximum logical timestamp Ty to obtain the logical timestamp Tx2 of the target request X, where Tx2 > Ty. This ensures that conflicting requests Z subsequently received by the node for the target request X will not precede the target request X, thus not affecting the order in which the target request X is applied to the state machine.

[0149] Based on the triple consisting of the physical timestamp, sequence number, and replica identifier, the physical timestamp of the logical timestamp Tx1 of the target request X can be updated to the physical timestamp in the maximum logical timestamp Ty; the sequence number of the logical timestamp Tx1 of the target request X can be updated to the sequence number in the maximum logical timestamp Ty plus a set value. The set value is a positive integer, typically set to 1, ensuring that the sequence numbers of the target request X and its conflicting requests are consecutive, facilitating log sorting of the target request X and its conflicting requests. Correspondingly, the physical timestamp of the logical timestamp Tx1 of the target request X can also be updated to the replica identifier of this service node to obtain the logical timestamp Tx2 of the target request X. This ensures that the logical timestamp of a subsequent conflicting request Z of the target request X received by this service node will not be smaller than the logical timestamp Tx2 of the target request X on this service node, thus preventing the conflicting request Z from being prioritized before the target request X and avoiding affecting the order in which the target request X is applied to the state machine.

[0150] Accordingly, if the aforementioned maximum logical timestamp Ty is less than the logical timestamp Tx1 carried by the pre-acceptance request of the target request X (i.e., Ty < Tx1), then the logical timestamp Tx1 carried by the pre-acceptance request of the target request X can be determined as the logical timestamp Tx2 of the target request X. Since the logical timestamp Tx1 of the target request X is already the maximum logical timestamp among requests with the same operating object, this ensures that the logical timestamp of the conflicting request Z of the target request X received subsequently by this service node will not be smaller than the logical timestamp Tx2 of the target request X on this service node. Consequently, the conflicting request Z will not be ranked before the target request X, and thus will not affect the order in which the target request X is applied to the state machine.

[0151] For a replica node, after determining the logical timestamp Tx2 of the target request X on this service node, it can return a pre-accept request to the coordinating node. This pre-accept request may include the logical timestamp Tx2 of the target request X determined by this service node and the set of conflicting requests C1 of the target request X.

[0152] Since the consensus protocol uses the majority rule for request processing, to ensure the high availability of the distributed service system and allow the entire system to continue functioning even when some service nodes fail, the majority rule can also be applied when deciding on the target logical timestamp Tx0 of the target request X and the set of interfering requests C0. Based on this, the coordinating node 101 can count the number of pre-acceptance confirmation requests it receives. These pre-acceptance confirmation requests include those generated by the protocol node 101 itself.

[0153] Furthermore, if the number of pre-acceptance confirmation requests received is greater than or equal to a set number R, the coordinating node can determine the target logical timestamp Tx0 of the target request X based on the logical timestamp Tx2 carried by the received pre-acceptance confirmation requests. Generally, the coordinating node 101 can obtain the largest logical timestamp from the logical timestamps Tx2 carried by the received pre-acceptance confirmation requests as the target logical timestamp of the target request X. The largest logical timestamp ensures that the target request X has a unique timestamp that is larger than all previous operations, simplifying the conflict detection and resolution process and reducing the need for additional processing.

[0154] Specifically, the number R is set to be greater than or equal to half of the total number M of the aforementioned multiple service nodes 10, and less than the total number M of the multiple service nodes. That is, M / 2 ≤ R < M. In this way, more than half of the service nodes corresponding to the same service instance participate in resolving the target logical timestamp of the target request X. Even if some service nodes fail, the remaining service nodes can still form a majority and continue to process the request, ensuring the high availability and fault tolerance of the system.

[0155] On the other hand, in a distributed service system, if only a few nodes participate in the decision-making process, multiple different target logical timestamps may be confirmed, leading to data inconsistency. Therefore, having more than half of the nodes participate in the decision-making process for the target logical timestamp of target request X can effectively prevent this from happening.

[0156] In this embodiment, the coordinating node can further determine the conflict request set C2 of the target request X based on the conflict request set C1 carried by the obtained pre-acceptance confirmation requests, when the number of pre-acceptance confirmation requests is greater than or equal to a set R. The conflict request set C2 can be the union of the conflict request sets C1. In this way, the coordinating node 101 can integrate conflict requests from multiple service nodes, providing a more comprehensive basis for subsequently determining the interference requests that truly affect the application of the target request X to the state machine.

[0157] It is worth noting that if the set of conflict requests C1 carried by the pre-acceptance confirmation request obtained by the coordinating node is empty, then the set of conflict requests C2 is also empty. If the set of conflict requests C1 carried by the pre-acceptance confirmation request obtained by the coordinating node is not empty, then the set of conflict requests C2 is also not empty.

[0158] To ensure that multiple service nodes of a service instance reach a consensus on the target logical timestamp of target request X and the set of conflicting requests C2 of target request X, the coordinating node can also broadcast an accept request for target request X. The accept request includes the target logical timestamp of target request X and the set of conflicting requests C2 of target request X.

[0159] Accordingly, replica nodes can receive and persistently store acceptance requests for use in accepting such requests. Since the target logical timestamp is determined by the coordinating node based on the logical timestamp carried in the pre-acceptance confirmation request (e.g., the largest logical timestamp among those carried in the pre-acceptance confirmation request), replica nodes and coordinating nodes may also receive conflicting requests for target request X with logical timestamps less than the target logical timestamp Tx0 after issuing the pre-acceptance confirmation request. To ensure the comprehensiveness of the subsequently resolved set of interfering requests C0 for target request X, replica nodes and coordinating nodes can also obtain target conflicting requests Y1 with logical timestamps less than the target logical timestamp from the locally stored conflicting requests for target requests. Target conflicting request Y1 may or may not exist, depending on whether the replica node or coordinating node receives conflicting requests for target request X with logical timestamps less than the target logical timestamp Tx0 after issuing the pre-acceptance confirmation request. If target conflicting request Y1 exists, the union of target conflicting request Y1 and conflicting request set C2 can be used to determine the conflicting request set C3 for target request X. Furthermore, replica node 102 can return an AcceptOK request to the coordinating node. The AcceptOK request includes the conflict request set C3 of the target request X. The fifth conflict request set C3 can be either empty or non-empty.

[0160] Accordingly, the coordinating node can obtain the acceptance confirmation request; and collect the set of conflict requests C3 carried by the obtained acceptance confirmation request as the set of conflict requests C0′ of the target request X.

[0161] Specifically, if the number of received acceptance confirmation requests is greater than or equal to a set number R, the union of the conflict request sets C3 carried by the received acceptance confirmation requests is determined as the conflict request set C0′ of the target request X. In this way, more than half of the service nodes corresponding to the same service instance participate in resolving the conflict request set C0′ of the target request X. Even if some service nodes fail, the remaining service nodes can still form a majority and continue to process the request, ensuring the system's high availability and fault tolerance.

[0162] On the other hand, in a distributed service system, if only a few nodes participate in the decision-making process, multiple different conflict request sets C0′ may be confirmed, which may lead to data inconsistency. Therefore, having more than half of the nodes participate in the decision-making process for the conflict request set C0′ of the target request X can effectively prevent this from happening.

[0163] Furthermore, the coordinating node can determine the interfering request set C0 of the target request X based on the collected conflicting request set C0′. The interfering request set C0 can be either empty or non-empty. If all conflicting request sets C3 carried by the acceptance confirmation requests obtained by the coordinating node are empty, then the interfering request set C0 is empty. If any conflicting request set C3 carried by the acceptance confirmation requests obtained by the coordinating node is non-empty, then the interfering request set C0 is non-empty.

[0164] Specifically, the union of the conflict request set C3 carried by the obtained acceptance confirmation request can be determined as the interference request set C0 of the target request X. Furthermore, the coordinating node can broadcast a resolution request for the target request X to form a resolution with the replica node regarding the target logical timestamp Tx0 and the interference request set C0.

[0165] Specifically, the coordinating node can broadcast a resolution request for the target request X, which includes the target logical timestamp Tx0 and the interference request set C0, in order to form a resolution with the replica node regarding the target logical timestamp Tx0 and the interference request set C0.

[0166] Through the above process, the coordinating node, via the target ownerless consensus protocol, reaches a resolution with the replica node regarding the target logical timestamp Tx0 and the interference request set C0. This interference request set C0 can be empty or non-empty, depending on whether the protocol node and replica node have received requests that conflict with the target request X.

[0167] In this embodiment of the disclosure, when resolving the logical timestamp of the request and the set of interference requests, the resolution process for whether a request contains interference requests is no longer differentiated. A unified target-less consensus protocol is adopted for processing, that is, a two-hop slow path is used to resolve the logical timestamp of the request and the set of interference requests, abandoning the traditional one-hop fast path optimization. The resolution of the logical timestamp of the request provided in this embodiment of the disclosure can provide basic support for simplifying disaster recovery. This part will be described in the following embodiments and will not be repeated here.

[0168] After multiple service nodes reach a resolution on the target logical timestamp Tx0 of the target request X and the set of interference requests C0 of the target request X, in the embodiment where the first set of interference requests for the target request X is empty, since there are no interference requests for the target request X, the coordinating node and the replica node can directly apply the target request X to the state machine sequence.

[0169] In embodiments where the interference request set C0 is a non-empty set, since the interference request set C0 of the target request X affects the order in which the target request X is applied to the state machine, for any service node, in step 1101, it is possible to wait for the logical timestamps of each interference request in the interference request set C0 of the target request X to form a resolution; and after the logical timestamps of each interference request in the interference request set C0 of the target request X form a resolution, the order in which the target request X is applied to the state machine is determined based on the target logical timestamp Tx0 of the target request X and the resolution of the logical timestamps of each interference request in the interference request set C0. This achieves consistency in the order in which the target request X is applied to the state machine among multiple service nodes, thereby maintaining data consistency among multiple service nodes. This implementation takes into account the influence of the interference request set C0 on the order in which the target request X is applied to the state machine, which helps to improve the accuracy of the order in which the target request X is applied to the state machine.

[0170] Specifically, for any service node, the relationship between the target logical timestamp of target request X and the logical timestamps of each interfering request of target request X can be determined. Specifically, the logical timestamp includes: physical timestamp, sequence number, and replica identifier. Correspondingly, for any two logical timestamps among the target logical timestamp of target request X and the logical timestamps of each interfering request of target request X, defined as the first logical timestamp T1 and the second logical timestamp T2, the relationship between the first logical timestamp T1 and the second logical timestamp T2 can be determined. For specific implementation methods of determining the first logical timestamp T1 and the second logical timestamp T2, please refer to the relevant content of the foregoing embodiments, which will not be repeated here. Using the same method, the relationship between the target logical timestamp of target request X and the logical timestamps of each interfering request of target request X can be determined. Furthermore, the order in which target request X is applied to the state machine can be determined based on the relationship between the target logical timestamp of target request X and the logical timestamps of each interfering request of target request X. In this embodiment, the order in which target request X is applied to the state machine precedes interference requests whose logical timestamp resolution is greater than the target logical timestamp Tx0, and follows interference requests whose logical timestamp resolution is less than the target logical timestamp Tx0. That is, the order in which requests are applied to the state machine is inversely proportional to the size of their logical timestamps; requests with larger logical timestamps are applied to the state machine later. The order in which interference requests of target request X are applied to the state machine is determined by the resolution of the logical timestamp of the interference request and the resolutions of the logical timestamps of each interference request in the interference request set. In this embodiment, determining the order in which requests are applied to the state machine based on the relationship between the logical timestamps of the requests simplifies the logic for determining the order and improves the efficiency of determining the order.

[0171] However, in practical applications, during the process of waiting for the interference requests in the interference request set C0 of the target request X to reach a decision, the coordinating node proposing the interference request Yi may malfunction, causing the coordinating node and replica nodes to time out and enter the disaster recovery mode. The disaster recovery (i.e., disaster recovery) process provided by the embodiments of this disclosure is described below as an example.

[0172] Any service node waits for the logical timestamps of the interference requests in the interference request set C0 of the target request X to form a resolution. In step 1102, if, after the waiting time reaches a set time threshold, there is still a target interference request Yi in the interference request set C0 whose logical timestamp has not formed a resolution, then the node enters the failover recovery mode. Specifically, for any service node, if it receives a resolution request for interference request Yi, it determines that the logical timestamp of interference request Yi has formed a resolution; if, after the waiting time reaches the set time threshold, it has not received a resolution request for interference request Yi, it determines that the logical timestamp of interference request Yi has not formed a resolution, thus identifying interference request Yi as the target interference request Yi, and the service node enters the failover recovery mode.

[0173] In this embodiment, regardless of whether an interference request exists, the logical timestamp of the request is resolved through the target unclaimed consensus protocol. The resolution process for the logical timestamp of the target interference request Yi is also completed by the target unclaimed consensus protocol. Therefore, based on the target unclaimed consensus protocol requests for the target interference request Yi currently existing on multiple service nodes, it can be determined which stage the logical timestamp resolution process for the target interference request Yi has reached. Other service nodes then take over the resolution process for the logical timestamp of the target interference request Yi from that stage, forming a resolution for the logical timestamp of the target interference request Yi. Based on this, in step 1103, any service node (defined as the second service node) can obtain the target unclaimed consensus protocol request for the target interference request Yi after entering disaster recovery mode. The target unclaimed consensus protocol request includes one or more of the following: a pre-acceptance request, an acceptance request, and a resolution request. "Multiple" refers to two or more types (including two). Of course, there may also be no target unclaimed consensus protocol request for the target interference request Yi. The second service node and the aforementioned first service node can be the same service node or different service nodes.

[0174] In some embodiments, if the second service node determines that the logical timestamp wait of the interference request for target request X has timed out, it may broadcast a recovery request for target interference request Yi. This recovery request may include the identifier of target interference request Yi. Other service nodes (service nodes other than the second service node) may receive the recovery request for target interference request Yi. Upon receiving the recovery request for target interference request Yi, the second service node and other service nodes may reject the pre-acceptance request and acceptance request for target interference request Yi sent by other service nodes (excluding the second service node). This discards the original decision process for the logical timestamp of target interference request Yi. If the old pre-acceptance request or acceptance request for target interference request Yi is still accepted at this time, it may lead to a conflict between the old and new states in the logical timestamp decision process of target interference request Yi, disrupting consistency. Rejecting the pre-acceptance request and acceptance request for target interference request Yi sent by other service nodes (excluding the second service node) ensures that the original decision process for the logical timestamp of target interference request Yi can be safely discarded, maintaining strong consistency of the system.

[0175] When the second service node and other service nodes receive a recovery request for the target interference request Yi, they also retrieve the target unclaimed consensus protocol request for the target interference request Yi from their local storage, and then return the target unclaimed consensus protocol request for the target interference request Yi to the second service node. The second service node can collect the target unclaimed consensus protocol requests for the target interference request Yi returned by other service nodes and / or the target unclaimed consensus protocol requests for the target interference request Yi stored locally, as the target unclaimed consensus protocol request. Further, in step 1103, a decision process for the logical timestamp of the target interference request can be executed according to the target unclaimed consensus protocol request to form a decision on the logical timestamp of the target interference request. Using the same method, the logical timestamps of all target interference requests that have not formed a decision when the waiting timeout occurs can be determined.

[0176] In this embodiment, multiple service nodes resolve the logical timestamp of a target masterless consensus protocol request without distinguishing whether the request involves an interfering request resolution process. If multiple service nodes wait for the logical timestamp of an interfering request to be resolved and a timeout occurs, for the target interfering request whose logical timestamp has not been resolved at the timeout, the logical timestamp resolution process of the target interfering request can be determined based on the target masterless consensus protocol request of the target interfering request currently existing in the multiple service nodes. Other service nodes then take over the logical timestamp resolution process of the target interfering request Yi from that stage, forming a resolution for the logical timestamp of the target interfering request, thus achieving disaster recovery of the masterless replication state machine. Since the logical timestamp resolution process of the target interfering request abandons the traditional one-hop fast path optimization scheme, it is not necessary to distinguish which method the logical timestamp of the target interfering request is resolved during disaster recovery, simplifying the disaster recovery process and helping to improve disaster recovery efficiency (i.e., disaster recovery efficiency).

[0177] Because the ownerless replication state machine mechanism provided in this disclosure simplifies the disaster recovery process, it makes it possible to implement the ownerless replication state machine mechanism in engineering. In other words, the ownerless replication state machine mechanism provided in this disclosure is easy to implement in engineering.

[0178] Specifically, if the target unclaimed consensus protocol request includes a resolution request for the target interference request Yi, and this resolution request includes a resolution of the logical timestamp of the target interference request Yi, then the second service node can broadcast the resolution request for the target interference request Yi to form a resolution of the logical timestamp of the target interference request Yi with other service nodes. Of course, the resolution request may also include the interference request set D0 of the target interference request Yi. Accordingly, the second service node, by broadcasting the resolution request for the target interference request Yi, can also form a resolution of the interference request set D0 of the target interference request Yi with other service nodes.

[0179] If the target unclaimed consensus protocol request includes an acceptance request for the target interference request Yi, but does not include a resolution request for the target interference request Yi, it means that the logical timestamp of the target interference request Yi forms a resolution. In this case, the second service node can broadcast the acceptance request for the target interference request Yi to form a resolution on the logical timestamp of the target interference request Yi with other service nodes.

[0180] However, for the target unclaimed consensus protocol request, which includes an acceptance request for the target interference request Yi but excludes a resolution request for the target interference request Yi, and further indicates that the set of interference requests for the target interference request Yi has not yet reached a resolution, the second service node can also collect the conflict request set D0′ of the target interference request Yi by broadcasting the acceptance request for the target interference request Yi. The specific process by which the second service node collects the conflict request set D0′ of the target interference request Yi by broadcasting the acceptance request for the target interference request Yi can be found in the aforementioned content regarding the coordination node 101 collecting the conflict request set C0′ of the target request X by broadcasting the acceptance request for the target request X, and will not be repeated here.

[0181] Furthermore, the second service node can determine the interference request set D0 of the target interference request Yi based on the collected conflict request set D0′ of the target interference request Yi. For a detailed implementation of determining the interference request set D0 of the target interference request Yi based on the collected conflict request set D0′ of the target interference request Yi, please refer to the aforementioned content regarding the coordination node determining the interference request set C0 of the target request X based on the collected conflict request set C0′ of the target request X, which will not be repeated here.

[0182] Furthermore, the second service node can broadcast a resolution request for the target interference request Yi, which includes a resolution for the logical timestamp of the target interference request Yi and a resolution for the interference request set D0 of the target interference request Yi. Other service nodes receive the resolution request for the target interference request Yi and obtain the logical timestamp of the target interference request Yi and the resolution for the interference request set D0 from the resolution request for the target interference request Yi, thereby forming a resolution for the logical timestamp of the target interference request Yi and a resolution for the interference request set D0.

[0183] Using the same method, multiple service nodes can form a resolution on the logical timestamp of each target interference request Yi and the resolution on the interference request set D0, thereby obtaining a resolution on the logical timestamp of each interference request in the interference request set C0 of the target request X and a resolution on the interference request set D0.

[0184] Subsequently, in step 1104, the order in which the target request X is applied to the state machine is determined based on the resolution of the target logical timestamp Tx0 of the target request X and the logical timestamps of each interference request in the interference request set C0. This achieves consistency in the order in which the target request X is applied to the state machine across multiple service nodes, thereby maintaining data consistency among multiple service nodes. This implementation takes into account the influence of the interference request set C0 on the order in which the target request X is applied to the state machine, helping to improve the accuracy of the order in which the target request X is applied to the state machine.

[0185] In some embodiments, if the target unclaimed consensus protocol request for the target interference request Yi collected by the second service node does not include: a resolution request for the target interference request Yi and an acceptance request for the target interference request Yi, then the second service node broadcasts another resolution request for the target interference request Yi. To distinguish it from the resolution request in the aforementioned target unclaimed consensus protocol, the resolution request in the target unclaimed consensus protocol is defined as the first resolution request, and the resolution request in this embodiment is defined as the second resolution request. The second resolution request includes target resolution information; this target resolution information includes: the logical timestamp of the target interference request Yi is positive infinity, and the set of interference requests for the target interference request Yi is an empty set. Other service nodes receiving such a resolution request can form a consensus based on this target resolution information. The fact that the logical timestamp of the target interference request Yi is positive infinity ensures that the target interference request Yi cannot become an interference request for any other request, thus preventing the target interference request Yi from affecting the order in which other requests are applied to the state machine.

[0186] This disclosed embodiment implements a masterless consensus replication state machine based on logical timestamps. Multiple service nodes can provide read and write access points, eliminating single points of failure in access points and stability. If some service nodes malfunction, other service nodes can proactively take over requests proposed by the malfunctioning service nodes that have not yet reached a resolution.

[0187] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 1101 and 1102 can be device A; or the execution subject of step 1101 can be device A, and the execution subject of step 1102 can be device B; and so on.

[0188] Furthermore, some processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 1101, 1102, etc., are merely used to distinguish different operations and do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel.

[0189] Accordingly, this disclosure also provides a computer-readable storage medium storing computer instructions, which, when executed by one or more processors, cause one or more processors to perform the steps in the disaster recovery methods provided in the foregoing embodiments.

[0190] Computer-readable storage media include volatile or non-volatile or a combination thereof, and may be removable or non-removable. Examples of computer-readable storage media include, but are not limited to, phase-change random access 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 (EPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital video disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transfer medium.

[0191] This disclosure also includes a computer program product comprising a computer program that, when executed by one or more processors, causes the one or more processors to perform the steps in the disaster recovery methods provided in the foregoing embodiments.

[0192] In this disclosure, the specific implementation form of the computer program product is not limited. In some embodiments, the computer program product may be implemented as an application (APP), a mini-program, a computer-side client, a program module, a plug-in, an installation package, a software development kit (SDK), an image file of an optical disc (such as an ISO file), a plug-in, or software in the form of Software as a Service (SaaS), etc., but is not limited thereto.

[0193] It should be understood that each or a combination of the above-described method flow can be implemented by computer programs or instructions. Furthermore, these computer programs or instructions can be applied to the processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device, enabling the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to function as an apparatus for implementing the corresponding functions in the above-described method embodiments.

[0194] Figure 12 is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. As shown in Figure 12, the electronic device includes a memory 12a and a processor 12b. The memory 12a is used to store computer programs and can be configured to store various other data to support operation on a computing platform. Examples of such data include instructions for any application or method operating on the electronic device, data structures, contact data, phonebook data, messages, pictures, videos, etc.

[0195] The processor 12b is coupled to the memory 12a and is used to execute a computer program to perform the steps in the disaster recovery methods provided in the foregoing embodiments. Specific implementation details of each step can be found in the relevant descriptions of the foregoing embodiments, and will not be repeated here.

[0196] In some alternative embodiments, as shown in FIG12, the electronic device may further include optional components such as a communication component 12c, a power supply component 12d, a display component 12e, and an audio component 12f. FIG12 only schematically shows some components and does not mean that the electronic device must include all the components shown in FIG12, nor does it mean that the electronic device can only include the components shown in FIG12.

[0197] Furthermore, the components within the dashed boxes in Figure 12 are optional, not mandatory, and their specific requirements depend on the product form of the electronic device. The electronic device in this embodiment can be a desktop computer, laptop computer, mobile phone, or IoT device; it can also be a traditional server, cloud server, or server cluster, or other server equipment.

[0198] In embodiments of this disclosure, the memory is used to store computer programs and can be configured to store various other data to support operation on its host device. The processor can execute the computer programs stored in the memory to implement corresponding control logic. The memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), electrically erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0199] In this embodiment of the disclosure, the processor can be any hardware processing device capable of executing the above-described method logic. Optionally, the processor can be a central processing unit (CPU), a graphics processing unit (GPU), or a microcontroller unit (MCU); it can also be a programmable device such as a field-programmable gate array (FPGA), a programmable array logic (PAL), a general array logic (GAL), or a complex programmable logic device (CPLD); or it can be an advanced RISC machine (ARM) or a system on chip (SoC), etc., but is not limited thereto.

[0200] In this embodiment of the disclosure, the communication component is configured to facilitate wired or wireless communication between its host device and other devices. The device hosting the communication component can access wireless networks based on communication standards, such as 2G or 3G, 4G, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.

[0201] In embodiments of this disclosure, the display component may include a liquid crystal display (LCD) and a touch panel (TP). If the display component includes a touch panel, the display component may be implemented as a touchscreen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0202] In embodiments of this disclosure, a power supply component is configured to provide power to various components of the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply component resides.

[0203] In embodiments of this disclosure, the audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals. For example, in devices with voice interaction capabilities, voice interaction with a user can be achieved through the audio component.

[0204] It should be noted that the terms "first" and "second" in this article are used to distinguish different messages, devices, modules, etc., and do not represent a chronological order, nor do they limit "first" and "second" to different types.

[0205] 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 process, method, article, or apparatus. Unless otherwise specified, 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 the aforementioned element.

[0206] The above description is merely an embodiment of this disclosure and is not intended to limit the scope of this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of the claims of this disclosure.

Claims

1. A distributed service system, wherein, include: Multiple service nodes; Each of the multiple service nodes independently maintains its state machine; the distributed service system adopts a masterless replication state machine mechanism. Among the plurality of service nodes, the coordinating node is used to resolve, through the target ownerless consensus protocol, the target logical timestamp of the target request and the first set of interference requests with the replica nodes; the coordinating node is the service node that proposes the target request. The replica node refers to the service node other than the coordinating node among the plurality of service nodes; The replica node and either the coordinating node are used to wait for the logical timestamps of the interference requests in the first interference request set to form a resolution. And, if the waiting time reaches a set time threshold, for target interference requests in the first interference request set where the logical timestamp has not been resolved, obtain the target masterless consensus protocol request of the target interference request; and, according to the target masterless consensus protocol request, execute the resolution process of the logical timestamp of the target interference request to form a resolution of the logical timestamp of the target interference request with other services. Furthermore, in the case where a resolution is reached on the logical timestamps of the interference requests in the first set of interference requests, the order in which the target request is applied to the state machine is determined based on the resolution of the target logical timestamp and the logical timestamps of the interference requests in the first set of interference requests.

2. The system according to claim 1, wherein, The coordination node is specifically used to perform the following operations asynchronously: By broadcasting pre-acceptance requests and acceptance requests for the target request, the target logical timestamp is determined and the set of conflicting requests for the target request is collected. Based on the collected set of conflicting requests for the target request, a first set of interfering requests for the target request is determined, and a first resolution request for the target request is broadcast. The first resolution request includes the target logical timestamp and the first set of interfering requests, so as to form a resolution with the replica node regarding the target logical timestamp and the first set of interfering requests.

3. A disaster recovery method applicable to any one of multiple service nodes in a distributed service system, wherein, The multiple service nodes independently maintain state machines; the distributed service system adopts a masterless replication state machine mechanism; wherein, among the multiple service nodes, the coordinating node proposing the target request, through a target masterless consensus protocol, forms a resolution with the replica nodes regarding the target logical timestamp of the target request and the first set of interfering requests; the replica nodes refer to service nodes other than the coordinating node among the multiple service nodes; the method includes: Wait for the logical timestamps of the interference requests in the first set of interference requests to form a resolution; If the waiting time reaches the set time threshold, and there is a target interference request in the first interference request set whose logical timestamp has not yet formed a resolution, then the target masterless consensus protocol request of the target interference request is obtained. According to the target ownerless consensus protocol request, execute the resolution process of the logical timestamp of the target interference request, so as to form a resolution of the logical timestamp of the target interference request with other service nodes; When a resolution is reached based on the logical timestamps of the interference requests in the first set of interference requests, the order in which the target request is applied to the state machine is determined according to the resolution of the target logical timestamp and the logical timestamps of the interference requests in the first set of interference requests.

4. The method according to claim 3, wherein, The step of executing the decision process for the logical timestamp of the target interference request based on the target unclaimed consensus protocol request, in order to form a decision on the logical timestamp of the target interference request with other services, includes: If the target unclaimed consensus protocol request includes a first resolution request for the target interference request or a first acceptance request for the target interference request, then by broadcasting the first resolution request or the first acceptance request, a resolution on the logical timestamp of the target interference request is formed with other service nodes.

5. The method according to claim 4, wherein, The target ownerless consensus protocol request includes the first resolution request; The first resolution request includes: a resolution of the second set of interference requests for the target interference request; the method further includes: By broadcasting the first resolution request, a resolution is formed with the other service nodes to create the second interference request set; the second interference request set is used to determine the order in which the target interference request is applied to the state machine.

6. The method according to claim 4, wherein, The target ownerless consensus protocol request includes the first acceptance request but does not include the first resolution request; The resolution of the logical timestamp of the target interference request, formed by broadcasting the first accept request and other service nodes, includes: By broadcasting the first accept request, a set of target conflict requests for the target interference request is collected; the set of target conflict requests is: a set of requests for resolutions where the operation object of the payload is the same as the operation object of the target interference request and the logical timestamp is less than the logical timestamp. Based on the target conflict request set, a second interference request set for the target interference request is determined; the second interference request set is used to determine the order in which the target interference requests are applied to the state machine. Broadcast the first resolution request, which includes: the resolution of the logical timestamp and the second set of interference requests, so as to form a resolution of the logical timestamp of the target interference request and the second set of interference requests with the other service nodes.

7. The method according to claim 6, wherein, The first acceptance request includes: a first conflict request set of the target interference request; the first conflict request set is: a set of requests whose operation object of the payload is the same as the operation object of the target interference request; The first acceptance request is broadcast to collect the target conflict request set of the target interference request; The first acceptance request is broadcast so that, if the other service nodes and any of the service nodes locally record a resolution that the logical timestamp of the target interference request is less than the logical timestamp, they can update the logical timestamp of the target interference request to the resolution of the logical timestamp and return a first acceptance confirmation request; the first acceptance confirmation request includes a second conflict request set; the second conflict request set is the set of conflict requests of the target interference request in which the resolution of the logical timestamp is less than the logical timestamp; If the number of first acceptance confirmation requests obtained is greater than or equal to a set number, the target conflict request set is determined based on the second conflict request set carried by the obtained acceptance confirmation requests; the set number is greater than or equal to half of the total number of the plurality of service nodes, and less than the total number. The step of determining the second interference request set of the target interference request based on the target conflict request set includes: The union of the target conflict request sets is determined to be the second interference request set of the target interference requests.

8. The method according to any one of claims 3-7, wherein, The acquisition of the target unclaimed consensus protocol request for the target interference request includes: Broadcast a recovery request in response to the target interference request, so that the other service nodes can return the target unclaimed consensus protocol request to the target interference request based on the recovery request; The target unclaimed consensus protocol request is obtained from the other service nodes and / or from the target unclaimed consensus protocol request stored by any of the service nodes.

9. The method according to claim 8, wherein, Also includes: Upon receiving the recovery request, the pre-acceptance request for the target interference request and the acceptance request for the target interference request sent by the other service nodes are rejected; wherein, upon receiving the recovery request, the other service nodes reject the pre-acceptance request for the target interference request and the acceptance request for the target interference request sent by the other service nodes.

10. The method according to claim 4 or 6, wherein, Also includes: If the target ownerless consensus protocol request does not include the first resolution request and the first acceptance request, then broadcast the second resolution request of the target interference request; The second resolution request includes the target resolution information; The target resolution information includes: the logical timestamp of the target interference request is positive infinity, and the interference request set of the target interference request is empty.

11. The method according to any one of claims 3-10, wherein, The step of determining the order in which the target request is applied to the state machine based on the resolution of the target logical timestamp and the logical timestamps of the interference requests in the first interference request set includes: Determine the size relationship between the target logical timestamp and the logical timestamp corresponding to the first set of interference requests; the logical timestamp corresponding to the first set of interference requests is: the logical timestamp of the interference request in the first set of interference requests; Based on the size relationship, the target request and the interference requests in the first interference request set are sorted to determine the order in which the target request is applied to the state machine.

12. The method according to claim 11, wherein, The logical timestamp includes: a physical timestamp, a sequence number, and a replica identifier; determining the size relationship between the target logical timestamp and the logical timestamp corresponding to the first interference request set includes: Regarding the resolution of the first logical timestamp and the second logical timestamp in the resolution of the target logical timestamp and the logical timestamp corresponding to the first interference request set, if the physical timestamp of the first logical timestamp is greater than the physical timestamp of the second logical timestamp, then it is determined that the first logical timestamp is greater than the second logical timestamp. or, If the physical timestamp of the first logical timestamp is equal to the physical timestamp of the second logical timestamp, and the sequence number of the first logical timestamp is greater than the second logical timestamp, then it is determined that the first logical timestamp is greater than the second logical timestamp. or, If the physical timestamp of the first logical timestamp is equal to the physical timestamp of the second logical timestamp, and the sequence number of the first logical timestamp is equal to the second logical timestamp, and the replica identifier of the first logical timestamp is greater than the second logical timestamp, then it is determined that the first logical timestamp is greater than the second logical timestamp.

13. The method according to any one of claims 3-12, wherein, The service node is the coordinating node; the method further includes: Through the target ownerless consensus protocol, a resolution is formed with the replica node to establish the target logical timestamp and the first set of interference requests.

14. The method according to claim 13, wherein, The resolution to form the target logical timestamp and the first set of interference requests with the replica node through the target ownerless consensus protocol includes asynchronously executing the following steps: By broadcasting a second pre-acceptance request and a second accept request for the target request, the target logical timestamp is determined and a set of conflicting requests for the target request is collected; Based on the collected set of conflicting requests of the target request, a first set of interfering requests of the target request is determined; Broadcast a third resolution request for the target request, the third resolution request including the target logical timestamp and the first set of interference requests, to form a resolution with the replica node regarding the target logical timestamp and the first set of interference requests.

15. The method according to claim 14, wherein, The step of determining the target logical timestamp and collecting the set of conflicting requests for the target request by broadcasting a second pre-acceptance request and a second accept request for the target request includes asynchronously performing the following steps: Broadcast the second pre-acceptance request; the second pre-acceptance request includes a third logical timestamp configured for the target request and the target payload of the target request, so that the replica node and the coordinating node can determine the third set of conflicting requests of the target request based on the target payload, and return the second pre-acceptance confirmation request of the target request; The pre-acceptance confirmation request includes the fourth logical timestamp of the target request and the third set of conflicting requests; The fourth logical timestamp is determined based on the maximum logical timestamp of the requests in the third conflict request set and the third logical timestamp; and the fourth logical timestamp is greater than the maximum logical timestamp; If the number of the second pre-acceptance confirmation requests obtained is greater than or equal to the set number, the target logical timestamp of the target request is determined according to the second logical timestamp carried by the second pre-acceptance confirmation requests. Based on the third set of conflicting requests carried by the obtained pre-acceptance confirmation request, determine the fourth set of conflicting requests for the target request; The second acceptance request of the target request is broadcast, the second acceptance request including the target logical timestamp and the fourth conflict request set, so that the replica node can return a second acceptance confirmation request; the second acceptance confirmation request includes a fifth conflict request set; the fifth conflict request set is the set of conflict requests of the target request whose logical timestamp is less than the target logical timestamp; as well as, If the number of second acceptance confirmation requests obtained is greater than or equal to the set number, the fifth set of conflict requests carried by the obtained second acceptance confirmation requests is collected as the set of conflict requests for the target request. The set number is greater than or equal to half of the total number of the multiple service nodes, but less than the total number; The step of determining the first set of interfering requests for the target request based on the collected set of conflicting requests for the target request includes: The union of the conflicting request sets of the target request is determined to be the first interference request set.

16. The method according to claim 15, wherein, The step of determining the third conflict request set of the target request based on the target payload includes: Based on the target payload, from the requests carried by the acquired target ownerless consensus protocol requests, a set of requests whose operation objects are the same as the operation objects of the target payload is obtained, which is used as the third conflict request set.

17. The method according to claim 15 or 16, wherein, Determining the fourth logical timestamp of the target request based on the largest logical timestamp of the requests in the third conflict request set includes: If the maximum logical timestamp is greater than or equal to the first logical timestamp, then the logical timestamp of the target request is updated based on the maximum logical timestamp to obtain the fourth logical timestamp of the target request. Alternatively, if the maximum logical timestamp is less than the first logical timestamp, then the third logical timestamp of the target request is determined to be the fourth logical timestamp.

18. The method according to claim 17, wherein, The logical timestamp includes: physical timestamp, serial number, and replica identifier; The step of updating the logical timestamp of the target request based on the maximum logical timestamp to obtain the fourth logical timestamp of the target request includes: Update the physical timestamp of the third logical timestamp to the physical timestamp of the largest logical timestamp; Update the sequence number of the third logical timestamp to the sequence number of the largest logical timestamp plus a set value; Update the replica identifier of the third logical timestamp to the replica identifier of this service node.

19. An electronic device, wherein, include: A memory and a processor; wherein the memory is used to store computer programs; The processor is coupled to the memory for executing the computer program to perform the steps of the method according to any one of claims 3-18.

20. A computer-readable storage medium storing computer instructions, wherein, When the computer instructions are executed by one or more processors, the one or more processors are caused to perform the steps of the method according to any one of claims 3-18.

21. A computer program product, wherein, Includes a computer program that, when executed by one or more processors, causes the one or more processors to perform the steps of the method according to any one of claims 3-18.

Images