Distributed lock service system and method, device, storage medium, and program product

Abstract

Embodiments of the present disclosure provide a distributed lock service system and method, a device, a storage medium, and a program product. In the embodiments of the present disclosure, for an active-active scenario in which a plurality of service nodes independently provide a distributed lock service, a client node concurrently contends for distributed locks maintained by the service nodes to obtain a distributed lock required for accessing a mutually exclusive resource, and when more than half of the service nodes return a lock contention success message, the client node is deemed to have obtained the distributed lock required for accessing the mutually exclusive resource, thereby implementing the distributed lock services in the active-active scenario. In this distributed lock service mode, even if one or some of the service nodes are unavailable, as long as the client node receives the lock contention success messages returned from more than half of the service nodes, that is, as long as the client node can renew the lease of the distributed lock with more than half of the service nodes, the client node can obtain the distributed lock required for accessing the mutually exclusive resource, and continue using the distributed service system, thereby improving the availability of the distributed lock services.

Description

Distributed lock service systems, methods, devices, storage media, and program products

[0001] This disclosure claims priority to Chinese Patent Application No. 202410918188.1, filed with the China Patent Office on July 9, 2024, entitled “Distributed Lock Service System, 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 lock service system, method, device, storage medium and program product. Background Technology

[0003] Distributed locks are widely used in distributed application systems to solve data consistency problems. Taking a distributed storage system as an example, a partition-based scheduling architecture is employed, where user storage space is divided into several partitions, and data read and write services are provided to the outside world at the partition level. Mutual exclusion access to partition resources is the cornerstone of data consistency in a storage system, and distributed locks can guarantee mutual exclusion access to partition resources.

[0004] Distributed lock services can be provided by a consensus-based distributed lock service system. This system includes multiple service nodes capable of providing distributed lock services. A master node is selected from these nodes based on the consensus protocol. The master node provides distributed lock services to clients requesting distributed locks and ensures mutual exclusion of distributed locks among different clients. Clients can access partitioned resources after acquiring a distributed lock, guaranteeing mutually exclusive access to those resources. However, current distributed lock service systems face the challenge of further improving availability. Summary of the Invention

[0005] This disclosure provides a distributed lock service system, method, device, storage medium, and program product to improve the availability of distributed lock services.

[0006] This disclosure provides a distributed lock service system, including: at least one client node that applies for a distributed lock and multiple service nodes that independently provide distributed lock services;

[0007] Any client node is used to concurrently send lock acquisition request messages to the multiple service nodes, and if the number of first service nodes among the multiple service nodes exceeds a set number, it determines that it has acquired the distributed lock required to access the mutual exclusion resource, and accesses the mutual exclusion resource within the lifetime of the distributed lock;

[0008] Wherein, the first service node is the service node that returns the lock acquisition success message; the set number is greater than or equal to half of the total number of the plurality of service nodes, and less than or equal to the total number of the plurality of service nodes.

[0009] This disclosure also provides a distributed lock service method, including:

[0010] Concurrently send lock acquisition request messages to multiple service nodes; each of the multiple service nodes independently provides distributed lock services;

[0011] If the number of first service nodes among the plurality of service nodes exceeds a set number, a distributed lock required to access the mutually exclusive resource is determined; wherein, the first service node is the service node that returns the lock acquisition success message; the set number is greater than or equal to half of the total number of the plurality of service nodes, and less than or equal to the total number of the plurality of service nodes.

[0012] Access the mutex resource within the lifetime of the distributed lock required to access the mutex resource.

[0013] This disclosure also provides a computing device, including: a memory and a processor; wherein the memory is used to store computer programs;

[0014] The processor is coupled to the memory and is used to execute the computer program to perform the steps in the aforementioned distributed lock service method.

[0015] 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 distributed lock service method.

[0016] 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 distributed lock service method.

[0017] In this embodiment, for a multi-active scenario where multiple service nodes independently provide distributed lock services, client nodes concurrently preempt the distributed locks maintained by each service node to acquire the distributed lock required to access mutually exclusive resources. Only when more than half of the service nodes return a successful lock acquisition message can the client node acquire the distributed lock required to access the mutually exclusive resources, thus realizing a distributed lock service in a multi-active scenario. This distributed lock service method ensures that even if one or more service nodes are unavailable, as long as the client node receives successful lock acquisition messages from more than half of the service nodes (i.e., as long as the client node can renew the distributed lock lease with more than half of the service nodes), it can acquire the distributed lock required to access the mutually exclusive resources and continue using the distributed service system, thereby improving the availability of the distributed lock service. Attached Figure Description

[0018] 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:

[0019] Figure 1 is a schematic diagram of the structure of the distributed lock service system provided in an embodiment of this disclosure;

[0020] Figure 2 is a schematic diagram of the lifetime setting of the distributed lock provided in an embodiment of this disclosure;

[0021] Figure 3 is a schematic diagram of the start time of the lifetime of the distributed lock provided in the embodiments of this disclosure;

[0022] Figure 4 is a schematic diagram illustrating the effect of client node managing the lifecycle of a distributed lock according to an embodiment of this disclosure.

[0023] Figure 5 is a flowchart illustrating the distributed lock service method provided in an embodiment of this disclosure;

[0024] Figure 6 is a flowchart illustrating another distributed lock service method provided in an embodiment of this disclosure;

[0025] Figure 7 is a schematic diagram of the structure of the computing device provided in an embodiment of this disclosure. Detailed Implementation

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

[0027] It should be noted that 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, data stored, data displayed, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0028] The following is an explanation of the terms and concepts used in this disclosure.

[0029] Distributed lock: A control mechanism in a distributed system that allows different processes to access a shared resource mutually exclusively, thereby ensuring the consistency of the entire system at the data level.

[0030] Master selection: High availability is a common requirement in distributed systems, and it is usually achieved by using a "one master and multiple slaves" approach. That is, multiple servers compete for the same distributed lock. The server that successfully acquires the lock becomes the master node and provides services to the outside world. The server that fails to acquire the lock becomes a slave node. By periodically retrying to acquire the lock, once the master node fails, a slave node immediately takes over and ensures the continuity of services.

[0031] 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, etc.

[0032] Active-active: A disaster recovery concept relative to primary-backup. Primary-backup disaster recovery means that the primary data center handles service access, while the backup data center only performs real-time backups of the primary data center's data, configurations, or application services. When the primary data center fails, there is a failover process, and then the backup data center takes over access. Active-active, on the other hand, means that multiple data centers simultaneously handle service abandonment for users, inherently possessing the ability to tolerate the failure of one data center.

[0033] Currently, most distributed lock service systems are based on consensus protocols to achieve strong consistency and fault tolerance. These consensus protocols are typically strong-master consensus protocols, which require leader election to resolve request conflicts; that is, a master node (Leader) is required to resolve request conflicts. Therefore, the master node in a distributed lock service system can become a single point of failure and a bottleneck to stability. The inventors of this disclosure have repeatedly discovered problems where the entire distributed lock service system becomes unusable due to the master node appearing to be dead (i.e., in a state of being dead but not completely dead).

[0034] To improve the availability of distributed lock services, this disclosure proposes the concept of multi-active locks. Multi-active locks refer to multiple service nodes independently providing distributed lock services simultaneously. These service nodes operate independently, with equal roles and no master-slave distinction. Specifically, in a multi-active scenario where multiple service nodes independently provide distributed lock services, client nodes concurrently preempt the distributed locks maintained by each service node to acquire the distributed lock required to access mutually exclusive resources. Only when more than half of the service nodes return a successful lock acquisition message can the client node acquire the distributed lock required to access the mutually exclusive resource, thus realizing a multi-active distributed lock service. Even if one or more service nodes are unavailable, as long as the client node receives successful lock acquisition messages from more than half of the service nodes (i.e., as long as the client node can renew the distributed lock lease with more than half of the service nodes), it can acquire the distributed lock required to access the mutually exclusive resource and continue using the distributed service system, thereby improving the availability of the distributed lock service.

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

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

[0037] Figure 1 is a schematic diagram of the structure of the distributed lock service system provided in an embodiment of this disclosure. As shown in Figure 1, the distributed lock service system includes at least one client node 10 and multiple service nodes 20. "Multiple" refers to two or more.

[0038] In this embodiment, service node 20 can provide distributed lock services to ensure the consistency of backend resources. Service node 20 can be a node providing distributed lock services in a self-developed distributed lock service system, or it can be a node providing distributed lock services in an existing distributed lock service system. For example, service node 20 can be a Kubernetes Etcd node or an Apache ZooKeeper node. The Kubernetes Etcd node is a node providing distributed lock services in the Kubernetes system. The Apache ZooKeeper node is an open-source distributed coordination service that provides distributed lock services to applications through a tree-structured data model. In addition to ensuring resource consistency, service node 20 can also have other service functions, such as storage transaction processing.

[0039] Service node 20 can be implemented as a device, apparatus, virtual machine (VM), container, or software module that provides distributed lock services. The device providing distributed lock services can be a single server device or a cloud-based server array. Alternatively, the device providing distributed lock services can also refer to other computing devices with corresponding service capabilities, such as computers or other terminal devices (running service programs). In this embodiment, service node 20 can be deployed in the cloud, such as a central cloud. Of course, service node 20 can also be deployed on the same physical machine as the backend mutually exclusive resource 30.

[0040] In this embodiment, the mutually exclusive resource 30 refers to a shared resource provided by the distributed system. Each service node 20 corresponds one-to-one with a mutually exclusive resource 30. The mutually exclusive resources 30 back each other up and jointly provide relevant services to users. The distributed system can be a distributed storage system or a distributed computing system, etc. Accordingly, the mutually exclusive resource 30 can be a stored data resource, such as data stored in the form of object storage, block storage, or file storage; or the mutually exclusive resource 30 can also be a code resource that provides computing or data processing services, etc.

[0041] In this embodiment, multiple service nodes 20 operate independently and do not communicate with each other. Each service node 20 independently provides distributed lock services. The multiple service nodes 20 work independently, have equal identities, and there is no master-slave distinction. The multiple service nodes 20 independently providing distributed lock services constitute a multi-active lock, which can be understood as multiple service nodes 20 providing distributed lock services in a "multi-active" mode.

[0042] In this embodiment, client node 10 refers to the node that deploys the client corresponding to the distributed lock service. It can be a device, apparatus, VM, container, or software module that deploys the client corresponding to the distributed lock service. Generally, there are multiple client nodes 10, and each client node 10 can request a distributed lock. Multiple client nodes 10 can maintain the mutual exclusion of the distributed lock service by preempting the distributed lock maintained by service node 20. Only the client node 10 that acquires the distributed lock has the right to access the mutually exclusive resource 30, thereby maintaining the consistency of the mutually exclusive resource 30 in the backend distributed system.

[0043] Specifically, client node 10 can concurrently send lock acquisition request messages to multiple service nodes 20. For any service node 20, if the service node 20 determines that client node 10 has acquired the distributed lock it maintains, it returns a lock acquisition success message to client node 10 (see step 2 in Figure 1).

[0044] In this embodiment, the specific implementation method of the service node 20 maintaining the distributed lock is not limited. In some embodiments, the service node 20 may maintain lease information to maintain the distributed lock. In this embodiment, the specific implementation form of the lease information is not limited. Optionally, the lease information may be implemented as resource information. The resource information may be in the form of files, key-value pairs (KV), keys, or timestamp information, but is not limited to these.

[0045] Specifically, as shown in step 1 of Figure 1, a client node can concurrently send lock-grabbing request messages to multiple service nodes 20 to preempt the distributed locks maintained by each service node 20. This lock-grabbing request message includes operation-related information related to the lease information. The service node 20 receives the lock-grabbing request message and determines the holding rights of the client node based on it. Specifically, determining the holding rights of the client node refers to whether the client node 10 has the right to hold the distributed locks maintained by the service nodes.

[0046] Furthermore, service node 20 can return a lock acquisition result adapted to the client node's held permissions to client node 10. Client node 10 can then determine whether it has successfully acquired the distributed lock maintained by service node 20 based on the acquisition result. If the acquisition result indicates that client node 10 successfully acquired the lock, then the client node has confirmed that it has acquired the distributed lock maintained by the service node. If the acquisition result indicates that client node 10 failed to acquire the lock, then the client node 10 has confirmed that it has not acquired the distributed lock maintained by the service node.

[0047] The following example illustrates the process by which client node 10 preempts the distributed lock maintained by service node 20, using a specific embodiment as an example.

[0048] In some embodiments, client node 10 can preempt the distributed lock maintained by service node 20 by creating or updating resource information. Accordingly, the operation-related information of the lease information included in the lock preemption request message may include: request information for creating or updating resources.

[0049] The following example illustrates how client node 10 creates and updates resource information, demonstrating the specific implementation of client node 10 preempting the distributed lock maintained by the service node and how service node 20 determines the holding rights of client node 10 based on the preemption request.

[0050] In some embodiments, client node 10 can preempt the distributed lock maintained by service node 20 by creating resource information. Accordingly, the lock preemption request message can be implemented as a resource creation request, which may include request information for the resource to be created. This request information may include: the name of the target resource and its lifetime. The lifetime of the target resource refers to the effective duration of the target resource, which can be a set duration, and its specific value can be flexibly set according to the actual application scenario. For example, if the target resource is a file, the request information for the resource to be created may include: the file name and the file's lifetime. As another example, if the target resource is a key-value pair (KV), the request information for the resource to be created may include: the KV name and its lifetime.

[0051] In this embodiment, service node 20 receives the lock acquisition request message; obtains the request information for the resource to be created from the lock acquisition request message; and determines whether the target resource requested by the request information for the resource to be created exists. Specifically, service node 20 can query the name of the stored resource; if the name of the target resource is not found, it is determined that the client node has the right to hold the lock. Correspondingly, if the name of the target resource is found, it is determined whether the name of the stored target resource has expired; if the resource name contained in the request information for creating the resource has expired, it is determined that the client node 10 has the right to hold the distributed lock maintained by service node 20. Correspondingly, if the name of the stored target resource has expired, it is determined that the client node 10 does not have the right to hold the distributed lock maintained by service node 20.

[0052] Furthermore, service node 20 can generate a lock acquisition result adapted to the holding permissions of client node 10. For example, for client node 10 that has holding rights to the distributed lock maintained by service node 20, the adapted lock acquisition result can be a lock acquisition success message. For client nodes that do not have holding rights to the distributed lock maintained by service node 20, the adapted lock acquisition result can be a lock acquisition failure message, and so on.

[0053] In other embodiments, client node 10 can preempt the distributed lock maintained by service node 20 by updating resource information. Accordingly, the lock preemption request message can be implemented as a resource update request, which may include request information about the resource to be updated. This request information may include: the name of the resource to be updated and the value (LV1) of the resource stored by the client node. For example, if the resource to be updated is a file, the request information may include: the filename and the content (LV1) of that file stored by the client node. As another example, if the resource to be updated is a key-value pair (KV), the request information may include: the name of the key and the value (LV1) stored by the client node.

[0054] In this embodiment, service node 20 receives the lock acquisition request message; obtains the request information of the resource to be updated from the lock acquisition request message; determines whether the value LV2 of the resource to be updated stored by the service node itself is the same as the value LV1 of the resource to be updated carried in the lock acquisition request; if LV2 is the same as LV1, it is determined that the client node has the right to hold the distributed lock maintained by service node 20. Conversely, if LV2 is different from LV1, it is determined that the client node does not have the right to hold the distributed lock maintained by service node 20.

[0055] Furthermore, service node 20 can generate a lock acquisition result adapted to the lock holding permissions of client node 10. For example, for a client node with lock holding rights, the adapted lock acquisition result could be a lock acquisition success message. For a client node without lock holding rights, the adapted lock acquisition result could be a lock acquisition failure message, and so on. Furthermore, service node 20 can return the lock acquisition result to client node 10. If the lock acquisition result indicates that client node 10 successfully acquired the lock, then the client node determines that it has acquired the distributed lock maintained by the service node and updates the value of the resource to be updated to LV2.

[0056] The foregoing embodiments merely provide illustrative examples of how a service node determines whether a client node has successfully acquired the lock, but do not constitute a limitation.

[0057] Furthermore, client node 10 can count the number of service nodes that return a successful lock acquisition message. In this embodiment, for ease of description and distinction, for the same client node, the service node that returns a successful lock acquisition message to that client node is defined as the first service node; the service node that does not return a successful lock acquisition message to that client node is defined as the second service node. Not returning a successful lock acquisition message includes: returning a failed lock acquisition message to the client node and not returning any message, etc.

[0058] To maintain the mutual exclusion of the distributed lock and ensure that the mutually exclusive resource is accessed by only one client node at a time, this embodiment introduces the "majority" principle. This means that a number M is set, greater than half the total number N of the multiple service nodes 20, and less than or equal to the total number N of the multiple service nodes, i.e., 1 / 2N < M ≤ N. Accordingly, if more than M service nodes return a successful lock acquisition message, the client node 10 can determine that it has acquired the distributed lock required to access the mutually exclusive resource (see step 3 in Figure 1). Thus, the client node 10 can access the mutually exclusive resource for the lifetime of the distributed lock. The lifetime of the distributed lock refers to the time from when the distributed lock becomes effective to when it expires.

[0059] The setting of the quantity M is greater than or equal to half of the total number N of multiple service nodes 20, which can ensure that only one client node 10 can acquire the distributed lock required to access the mutually exclusive resource at the same time. That is, only one client node 10 has the right to access the mutually exclusive resource at the same time, which can maintain the mutual exclusion of the distributed lock.

[0060] In this embodiment of the disclosure, the specific value of the lifetime of the distributed lock corresponding to the mutex resource acquired by the client node 10 is not limited. In some embodiments, the lifetime of the distributed lock corresponding to the mutex resource can be set to a fixed duration, the value of which can be flexibly set according to the application scenario. Specifically, it can be set according to the time required for the client node 10 to access the mutex resource, and the fixed duration can be greater than or equal to the time required for the client node 10 to access the mutex resource.

[0061] To ensure the validity of the distributed lock, in some embodiments of this disclosure, for any client node 10, when the client node 10 acquires the distributed lock required to access the mutually exclusive resource, the validity period of the distributed lock maintained by the first service node 20, which returns a successful lock acquisition message, can be obtained. The validity period of the distributed lock refers to the remaining lifetime of the distributed lock, that is, the time from the current time until the distributed lock expires. The validity period of the distributed lock is less than or equal to the lifetime of the distributed lock.

[0062] Furthermore, based on the validity period of the distributed lock maintained by the first service node 20, the lifespan of the distributed lock required for client node 10 to access the mutex resource can be set. During the lifespan of the distributed lock required for accessing the mutex resource, the number of first service nodes 20 maintaining valid distributed locks exceeds the aforementioned set number M. Specifically, by ensuring that the number of first service nodes 20 maintaining valid distributed locks exceeds the aforementioned set number M during the lifespan of the distributed lock required for client node 10 to access the mutex resource, it can ensure that, on the one hand, more than the set number M of service nodes 20 maintain valid distributed locks, thereby ensuring the validity of the distributed lock required for client node 10 to access the mutex resource; on the other hand, it guarantees that only one client node 10 can acquire the distributed lock required to access the mutex resource at any given time, i.e., only one client node 10 has the right to access the mutex resource at any given time, thus maintaining the mutual exclusion of the distributed lock.

[0063] In this embodiment, the specific implementation of setting the lifetime of the distributed lock required for the client node 10 to access the mutually exclusive resource based on the validity period of the distributed lock maintained by the first service node 20 is not limited. As long as it can be guaranteed that the number of first service nodes 20 with the distributed lock in validity period during the lifetime of the distributed lock required to access the mutually exclusive resource exceeds the aforementioned set number M, it can be implemented.

[0064] In some embodiments, the validity period of the distributed lock maintained by the first service node 20 can be calculated at a set quantile. The set quantile is greater than or equal to the median. Specifically, the validity periods of the distributed locks maintained by the first service node can be arranged in ascending order, and the validity period located at the set quantile from the sorted validity period sequence is the value of the validity period of the distributed lock maintained by the first service node at the set quantile. For example, if the set quantile is the median, and the number of first service nodes is odd, the validity period located at the median (i.e., the middle one) from the sorted validity period sequence is the value of the validity period of the distributed lock maintained by the first service node at the median. If the number of first service nodes is even, the average of the two middle validity periods from the sorted validity period sequence is the value of the validity period of the distributed lock maintained by the first service node at the median. It should be noted that the set quantile remains unchanged over time, but the value of the validity period of the distributed lock maintained by the first service node at the set quantile will change.

[0065] Furthermore, the lifetime of the distributed lock required by client node 10 to access the mutex resource can be set to the value of the validity period of the distributed lock maintained by the first service node 20 at a set quantile. The set quantile is greater than or equal to the median, thus ensuring that more than a set number M service nodes of the multiple service nodes 20 maintain valid distributed locks, thereby ensuring the validity of the distributed lock required by client node 10 to access the mutex resource.

[0066] For example, as shown in Figure 2, there are a total of 3 service nodes, with a set quantity M = 1.5. The first service node 20 consists of two service nodes, one on the left and one on the right. The validity period of the distributed lock maintained by the first service node 20 is shown as the rectangle filled with diagonal lines in Figure 2, where a longer rectangle indicates a longer validity period. The set quantile is the median. The calculated validity periods of the three distributed locks maintained by the first service nodes 20 are shown as the dashed lines in Figure 2. Therefore, the lifetime of the distributed lock required by client node 10 to access the mutex resource can be set to the median of the validity periods of the distributed locks maintained by the first service nodes 20. As can be seen from Figure 2, within the lifetime of the distributed lock required by client node 10 to access the mutex resource, there are always two service nodes maintaining a valid distributed lock. This ensures that more than the set quantity (M = 1.5) of service nodes 20 maintain valid distributed locks, thus ensuring the validity of the distributed lock required by client node 10 to access the mutex resource.

[0067] Based on the above method, which determines the lifetime of the distributed lock required to access the mutex resource, it is also necessary to determine the start time of the distributed lock's lifetime. To prevent two or more client nodes from successfully acquiring the lock, client nodes can be made aware of the expiration of the distributed lock before the server node. This prior awareness of the expiration of the distributed lock by client nodes maintains the mutual exclusion of the distributed lock and prevents two or more client nodes from successfully acquiring the lock. This is mainly because if the service node learns of the expired distributed lock before the client node, the following problem may occur: Suppose the first client node acquires the distributed lock required to access the mutex resource. If the distributed lock maintained by the service node has expired, but the first client node is unaware of this, the first client node will not attempt to acquire the lock again and will believe that it still holds the distributed lock required to access the mutex resource. If another client node (defined as the second client node) attempts to acquire the lock (the distributed lock required to access the mutex resource), and the distributed lock maintained by the service node has expired, the second client node may successfully acquire the lock. This results in two client nodes (i.e., the first client node and the second client node) both believing that they hold the distributed lock required to access the mutex resource, making it impossible to maintain the mutual exclusion of the distributed lock.

[0068] To ensure that client nodes are aware of the expiration of the distributed lock required to access mutually exclusive resources before service nodes, this embodiment proposes a method for client nodes and service nodes to negotiate the lifetime of the distributed lock required to access mutually exclusive resources based on a "causal order," that is, client nodes and service nodes negotiate the lease according to a "causal order." Here, "causal order" refers to the time sequence in which the client node sends the lock-grabbing request message and the service node receives the lock-grabbing request message from the client node. "Causal order" refers to the time sequence in which the client node sends the lock-grabbing request message and the service node receives it; the client node sends the lock-grabbing request message earlier than the service node receives it.

[0069] Specifically, as shown in Figure 3, client node 10 can start timing the lifetime of the distributed lock provided by service node 20 before sending a lock-grabbing request message to service node 20; while service node 20 starts timing the lifetime of the distributed lock it maintains upon receiving the lock-grabbing request message. Since client node 10 sends the lock-grabbing request message earlier than the service node receives the lock-grabbing request message from client node 20, this is an objectively existing causal event, unaffected by the clock information of client node 10 and service node 20. Therefore, it can be ensured that client node 10 knows that the distributed lock maintained by service node 20 has expired before service node 20, which helps maintain the mutual exclusion of distributed locks.

[0070] The following illustration, using Figure 4 as an example, demonstrates the effect of client node 10 managing the distributed lock required for accessing mutually exclusive resources from a spatiotemporal perspective. In Figure 4, the distributed lock refers to the distributed lock required for accessing mutually exclusive resources, and the space refers to the space corresponding to the service nodes. Figure 4 only illustrates three service nodes, but this is not a limitation. Each valid lifetime of the distributed lock required for accessing mutually exclusive resources can be represented by a rectangle spanning multiple service nodes. When a client node 10 acquires the distributed lock required for accessing mutually exclusive resources, the rectangle may span multiple service nodes at the same time. Figure 4 only illustrates two service nodes spanning the same time, but this is not a limitation. Within the lifetime of the distributed lock required for accessing mutually exclusive resources acquired by client node 10, the distributed locks maintained by the service nodes acquired at different times may be different. That is, within the lifetime of the distributed lock required for accessing mutually exclusive resources acquired by client node 10, the rectangle may span different service nodes at different times, but the rectangles must intersect in terms of temporal maintenance. Once the lock is lost, it means that the rectangle seen by the next client node that acquires the distributed lock required to access the mutually exclusive resource will not overlap with the rectangle last seen by the previous client node in time, thus ensuring the mutual exclusion of the distributed lock.

[0071] Furthermore, client node 10, having acquired the distributed lock required to access the mutex resource, can access the mutex resource for the duration of the distributed lock (see step 4 in Figure 1). Client node 10 can synchronously perform the same access operation on the mutex resources corresponding to each service node 20, thereby ensuring the consistency of the mutex resource. For example, if the mutex resource is stored data, client node 10 can synchronously perform data writing, data reading, data deletion, or data modification operations on the data resources corresponding to multiple service nodes 20. As another example, if the mutex resource is code providing computing services, client node 10 can call, delete, modify, or update the code corresponding to multiple service nodes 20.

[0072] In this embodiment, for a multi-active scenario where multiple service nodes independently provide distributed lock services, client nodes concurrently preempt the distributed locks maintained by each service node to acquire the distributed lock required to access mutually exclusive resources. Only when more than half of the service nodes return a successful lock acquisition message can the client node acquire the distributed lock needed to access the mutually exclusive resources, thus realizing a distributed lock service in a multi-active scenario. This distributed lock service method ensures that even if one or more service nodes are unavailable, as long as the client node receives successful lock acquisition messages from more than half of the service nodes (i.e., as long as the client node can renew the distributed lock lease with more than half of the service nodes), it can acquire the distributed lock needed to access the mutually exclusive resources and continue using the distributed service system, thereby improving the availability of the distributed lock service.

[0073] It is worth noting that, in this embodiment, client node 10 can periodically send lock acquisition request messages concurrently to multiple service nodes 20 according to a set lock acquisition period. Alternatively, client node 10 can send lock acquisition request messages concurrently to multiple service nodes 20 when it needs to access mutually exclusive resources. Of course, client node 10 can also monitor the holding status of the distributed lock required to access mutually exclusive resources, and send lock acquisition request messages concurrently to multiple service nodes 20 when the distributed lock required to access mutually exclusive resources is not held. The holding status of the distributed lock is divided into an idle state and a held state, where the idle state means that the distributed lock is not held by any client node.

[0074] Optionally, client node 10 can monitor the number K of service nodes 20 whose distributed locks are valid. If the number K is less than the aforementioned set number M, it is determined that the distributed lock required to access the mutually exclusive resource is not held, that is, the distributed lock required to access the mutually exclusive resource is idle.

[0075] In this embodiment, the specific implementation of the number K of service nodes 20 monitored and maintained by the client node that are valid is not limited. In some embodiments, the client node may send a validity period query request to the service node 20. This validity period query request is used to request the service node 20 to query whether the distributed lock it maintains is valid. Accordingly, the service node 20 receives the validity period query request, and in response to the validity period query request, reads the validity period of the distributed lock it maintains, and returns a query result reflecting whether it is valid to the client node 10. If the query result reflects that the distributed lock maintained by the service node 20 is valid, the client node can determine that the distributed lock maintained by the service node 20 is valid; if the query result reflects that the distributed lock maintained by the service node is not valid, the client node can determine that the distributed lock maintained by the service node 20 is not valid, that is, the distributed lock maintained by the service node 20 has expired.

[0076] In other embodiments, for instances where a client node preempts the distributed lock maintained by the service node 20 by updating resource information, the client node can also monitor whether the value LV2 of the resource to be updated stored by the service node 20 has been updated; if the value LV2 of the resource to be updated stored by the service node 20 has not been updated for a set period of time, it is determined that the distributed lock maintained by the service node 20 is not valid, that is, the distributed lock maintained by the service node 20 has expired.

[0077] Furthermore, client node 10 can count the number K of service nodes whose distributed locks are valid; if K < M, then it is determined that the distributed lock required to access the mutually exclusive resource is in an idle state, that is, the distributed lock is not held.

[0078] Furthermore, if the client node 10 detects that the distributed lock for accessing the mutex resource is not held, it can concurrently send lock-grabbing request messages to multiple service nodes 20 to preempt the distributed lock maintained by the multiple service nodes 20. In some embodiments, if the client node 10 detects that the distributed lock for accessing the mutex resource is not held, it can wait for a random period of time before executing the operation of concurrently sending lock-grabbing request messages to multiple service nodes 20.

[0079] In this implementation, the waiting time for each client node is random, starting from the moment it is determined that the distributed lock is not held. Because the waiting time for each client node is random, randomness is introduced. During this random waiting process, it is possible that only one client node can simultaneously acquire the distributed lock required to access the mutually exclusive resource. In this case, one client node will hold the distributed lock, maintaining the mutual exclusion of the distributed lock. This embodiment trades time for the eventual availability of the distributed lock service system, thus helping to improve the availability of the distributed lock service.

[0080] To enhance the robustness of the distributed lock, if client node 10 determines that it has acquired the distributed lock required to access the mutex resource, it can also attempt to acquire the distributed lock maintained by the remaining service node (i.e., the second service node) to increase the number of first service nodes that return a successful lock acquisition message, thereby enhancing the robustness of the distributed lock required to access the mutex resource.

[0081] However, the distributed lock maintained by the second service node that client node 10 failed to acquire may be held by other client nodes 10. If a client node 10 that acquires the distributed lock required to access the mutex resource wants to increase the number of distributed locks it holds maintained by service nodes, other client nodes need to release the distributed locks they acquired. Therefore, for other client nodes 10 that failed to acquire the distributed lock required to access the mutex resource, they can release the distributed lock maintained by the service node that acquired the lock if it is determined that they did not acquire the required distributed lock. Specifically, for other client nodes 10, if the number of service nodes returning a successful lock acquisition message to them is less than a set number M, it can be determined that they failed to acquire the distributed lock required to access the mutex resource, and the distributed lock maintained by the service node that returned the successful lock acquisition message to them can be released.

[0082] Accordingly, for a client node 10 that has acquired the distributed lock required to access the mutex resource, it can continue to send a lock acquisition request message to the second service node among the multiple service nodes 20, thereby increasing the number of service nodes that return a lock acquisition success message. When a client node 10 acquires the distributed lock required to access the mutex resource, the more distributed locks maintained by the service nodes, the stronger the robustness of the distributed lock required to access the mutex resource.

[0083] In practical applications, some service nodes may malfunction, or communication between service nodes and client nodes may fail, affecting the robustness of the distributed lock required to access mutually exclusive resources. It is necessary to ensure that the number of service nodes in a normal state among those that client node 10 can acquire the maintained distributed lock from exceeds a set number M, thereby reducing the probability of client node 10 losing the distributed lock required to access the mutually exclusive resource. Based on this, a target number X can be set, where X is greater than the aforementioned set number M. This ensures that the number of service nodes in a normal state among those that client node 10 can acquire the maintained distributed lock from exceeds the set number M.

[0084] Based on the foregoing analysis, client node 10 can monitor the health status of the aforementioned first service node to ensure that client node 10 is in a normal state. Specifically, client node 10 can monitor the health status of the first service node that returned a successful lock acquisition message based on heartbeat messages between it and the service node. For example, client node 10 can periodically send heartbeat messages to the first service node according to a set heartbeat cycle; if it receives a response message from the first service node within a set time period, it determines that the first service node is in a normal state; if it does not receive a response message from the first service node within a set time period, it determines that the first service node is in an abnormal state.

[0085] Furthermore, client node 10 can count the number Q of service nodes in the first service node that are in a normal state; and when the number Q of service nodes in the first service node that are in a normal state reaches the set target number X, it continues to send lock acquisition request messages to the second service node to increase the number of service nodes that return lock acquisition success messages.

[0086] For details on how service node 20 determines whether client node 10 has acquired the distributed lock maintained by service node 20 based on the lock acquisition request message, please refer to the relevant content of the aforementioned embodiments, which will not be repeated here.

[0087] If the second service node 20 determines that the client node 10 has successfully acquired the distributed lock it maintains, it returns a lock acquisition success message to the client node 10. For the client node 10, upon receiving the lock acquisition success message from the second service node, the number of service nodes that returned the message can be increased; and the lifetime of the distributed lock required for the client node to access the mutually exclusive resource can be updated based on the validity period of the distributed lock maintained by the first service node and the validity period of the distributed lock maintained by the second service node that returned the lock acquisition success message. Furthermore, the number of service nodes maintaining valid distributed locks must exceed a set number M within the lifetime of the distributed lock required for the client node to access the mutually exclusive resource. This ensures that, on the one hand, more than the set number M of service nodes 20 maintain valid distributed locks, thereby ensuring the validity of the distributed lock required for the client node 10 to access the mutually exclusive resource; on the other hand, it guarantees that only one client node 10 acquires the distributed lock required to access the mutually exclusive resource at any given time, meaning only one client node 10 has the right to access the mutually exclusive resource at any given time, thus maintaining the mutual exclusion of the distributed lock.

[0088] Regarding the specific implementation method of updating the lifetime of the distributed lock required by the client node to access the mutually exclusive resource based on the validity period of the distributed lock maintained by the first service node and the validity period of the distributed lock maintained by the second service node that returned the lock acquisition success message, please refer to the relevant content on setting the lifetime of the distributed lock required by the client node to access the mutually exclusive resource based on the validity period of the distributed lock maintained by the first service node 20, which will not be repeated here.

[0089] The foregoing embodiments have described in detail the implementation of how client node 10 acquires the distributed lock required to access a mutex resource. Of course, client node 10 may also fail to acquire the distributed lock required to access the mutex resource, i.e., the number of first service nodes returning a successful lock acquisition message to client node 10 is less than the aforementioned set number M. Accordingly, if the number of first service nodes returning a successful lock acquisition message is less than the aforementioned set number M, client node 10 can determine that it has not acquired the distributed lock required to access the mutex resource and release the distributed lock maintained by the first service node that returned the successful lock acquisition message, so that other client nodes 10 that have acquired the distributed lock required to access the mutex resource can continue to apply for the distributed locks maintained by these service nodes, thereby enhancing the robustness of the distributed lock required to access the mutex resource.

[0090] In addition to the distributed lock service system provided in the foregoing embodiments, this disclosure also provides a distributed lock service method. The distributed lock service method provided in this disclosure is described below with reference to the accompanying drawings.

[0091] Figure 5 is a flowchart illustrating the distributed lock service method provided in this embodiment of the present disclosure. As shown in Figure 5, the method mainly includes:

[0092] 501. Concurrently send lock acquisition request messages to multiple service nodes; each service node independently provides distributed lock services.

[0093] 502. When the number of first service nodes among multiple service nodes exceeds a set number, determine the distributed lock required to access the mutually exclusive resource; wherein, the first service node is the service node that returns a successful lock acquisition message; the set number is greater than or equal to half of the total number of multiple service nodes, and less than or equal to the total number of multiple service nodes.

[0094] 503. Access the mutex resource within the lifetime of the distributed lock required to access the mutex resource.

[0095] For a description of the service nodes and mutually exclusive resources, please refer to the relevant content in the foregoing system embodiments, which will not be repeated here. The distributed lock service method provided in this disclosure is applicable to client nodes corresponding to the distributed lock service, and client nodes can apply for distributed locks. Multiple client nodes can maintain the mutual exclusion of the distributed lock service by preempting the distributed lock maintained by the service node. Only the client node that acquires the distributed lock has the right to access the mutually exclusive resources, thereby maintaining the consistency of mutually exclusive resources in the backend distributed system.

[0096] Specifically, as shown in step 501, lock acquisition request messages are sent concurrently to multiple service nodes. For any service node, if the service node can determine whether the client node has acquired the distributed lock it maintains based on the lock acquisition request message, and if it determines that the client node has acquired the distributed lock it maintains, then a lock acquisition success message is returned to the client node. For the specific implementation of the service node responding to the lock acquisition request message and determining whether the client node has acquired the distributed lock it maintains, please refer to the relevant content of the aforementioned system embodiment, which will not be repeated here.

[0097] For client nodes, the number of service nodes that return a successful lock acquisition message can be counted. In this embodiment, for ease of description and distinction, for the same client node, the service node that returns a successful lock acquisition message to that client node is defined as the first service node; the service node that does not return a successful lock acquisition message to that client node is defined as the second service node. Not returning a successful lock acquisition message includes: returning a failed lock acquisition message to the client node and not returning any message, etc.

[0098] To maintain the mutual exclusion of the distributed lock and ensure that the mutually exclusive resource is accessed by only one client node at a time, this embodiment introduces the "majority" principle. This means setting a number M that is greater than half the total number of service nodes N, and less than or equal to the total number of service nodes N (i.e., 1 / 2N < M ≤ N). Accordingly, as shown in step 502, if more than M service nodes return a successful lock acquisition message, it is determined that the client node has acquired the distributed lock required to access the mutually exclusive resource. Thus, the client node can access the mutually exclusive resource for the lifetime of the distributed lock. The lifetime of the distributed lock refers to the time from when the distributed lock becomes effective to when it expires.

[0099] Setting the quantity M to be greater than or equal to half of the total number N of multiple service nodes ensures that only one client node can acquire the distributed lock required to access the mutually exclusive resource at any given time. That is, only one client node 10 has the right to access the mutually exclusive resource at any given time, which can maintain the mutual exclusion of the distributed lock.

[0100] In this embodiment of the disclosure, the specific value of the lifetime of the distributed lock corresponding to the mutex resource acquired by the client node is not limited. In some embodiments, the lifetime of the distributed lock corresponding to the mutex resource can be set to a fixed duration, the value of which can be flexibly set according to the application scenario. Specifically, it can be set according to the time required for the client node to access the mutex resource, and the fixed duration can be greater than or equal to the time required for the client node to access the mutex resource.

[0101] To ensure the validity of the distributed lock, in some embodiments of this disclosure, for any client node, when the client acquires the distributed lock required to access the mutually exclusive resource, the validity period of the distributed lock maintained by the first service node that returned a successful lock acquisition message can be obtained. The validity period of the distributed lock refers to the remaining lifetime of the distributed lock, that is, the time from the current time until the distributed lock expires. The validity period of the distributed lock is less than or equal to the lifetime of the distributed lock.

[0102] Furthermore, based on the validity period of the distributed lock maintained by the first service node, the lifespan of the distributed lock required for client nodes to access mutually exclusive resources can be set. Within the lifespan of the distributed lock required for accessing mutually exclusive resources, the number of first service nodes maintaining valid distributed locks exceeds the aforementioned set number M. Specifically, ensuring that the number of first service nodes maintaining valid distributed locks within the lifespan of the distributed lock required for client nodes to access mutually exclusive resources exceeds the aforementioned set number M ensures, on the one hand, that more than the set number M of service nodes maintain valid distributed locks, thus ensuring the validity of the distributed lock required for client nodes to access mutually exclusive resources; on the other hand, it guarantees that only one client node can acquire the distributed lock required to access the mutually exclusive resource at any given time, i.e., only one client node has the right to access the mutually exclusive resource at any given time, thus maintaining the mutual exclusion of the distributed lock.

[0103] In this embodiment, the specific implementation of setting the lifetime of the distributed lock required for a client node to access a mutually exclusive resource based on the validity period of the distributed lock maintained by the first service node is not limited. As long as it can be guaranteed that the number of first service nodes whose distributed locks are valid during the lifetime of the distributed lock required to access the mutually exclusive resource exceeds the aforementioned set number M, it can be implemented.

[0104] In some embodiments, the validity period of the distributed lock maintained by the first service node can be calculated at a set quantile. The set quantile is greater than or equal to the median. Specifically, the validity periods of the distributed locks maintained by the first service node can be arranged in ascending order, and the validity period located at the set quantile from the sorted validity period sequence is taken as the value of the validity period of the distributed lock maintained by the first service node at the set quantile. For example, if the set quantile is the median, and the number of first service nodes is odd, the validity period located at the median (i.e., the middle one) from the sorted validity period sequence is taken as the value of the validity period of the distributed lock maintained by the first service node at the median. If the number of first service nodes is even, the average of the two middle validity periods from the sorted validity period sequence is taken as the value of the validity period of the distributed lock maintained by the first service node at the median.

[0105] Furthermore, the lifetime of the distributed lock required for client nodes to access mutually exclusive resources can be set to a value at a set quantile of the validity period of the distributed lock maintained by the first service node. This set quantile is greater than or equal to the median, ensuring that more than a set number M service nodes maintain valid distributed locks, thereby ensuring the validity of the distributed lock required for client nodes to access mutually exclusive resources.

[0106] Based on the above method, which determines the lifetime of the distributed lock required to access the mutex resource, it is also necessary to determine the start time of the distributed lock's lifetime. To prevent two or more client nodes from successfully acquiring the lock, client nodes can be made aware of the expiration of the distributed lock before the server node. This prior awareness of the expiration of the distributed lock by client nodes maintains the mutual exclusion of the distributed lock and prevents two or more client nodes from successfully acquiring the lock.

[0107] To ensure that client nodes learn of the expiration of the distributed lock required to access mutually exclusive resources before service nodes, this embodiment proposes a method for client nodes and service nodes to negotiate the lifetime of the distributed lock required to access mutually exclusive resources based on a "causal order".

[0108] Specifically, a client node can start timing the lifetime of the distributed lock provided by the service node before sending a lock-grabbing request message to the service node; conversely, the service node starts timing the lifetime of the distributed lock it maintains upon receiving the lock-grabbing request message. Since the client node sends the lock-grabbing request message earlier than the service node receives it, this is an objectively existing causal event, unaffected by the clock information of the client and service nodes themselves. Therefore, it ensures that the client node learns of the expiration of the distributed lock maintained by the service node before the service node, which helps maintain the mutual exclusion of distributed locks.

[0109] Furthermore, in step 503, a client node that acquires the distributed lock required to access a mutex resource can access the mutex resource for the lifetime of the distributed lock.

[0110] In this embodiment, for a multi-active scenario where multiple service nodes independently provide distributed lock services, client nodes concurrently preempt the distributed locks maintained by each service node to acquire the distributed lock required to access mutually exclusive resources. Only when more than half of the service nodes return a successful lock acquisition message can the client node acquire the distributed lock needed to access the mutually exclusive resources, thus realizing a distributed lock service in a multi-active scenario. This distributed lock service method ensures that even if one or more service nodes are unavailable, as long as the client node receives successful lock acquisition messages from more than half of the service nodes (i.e., as long as the client node can renew the distributed lock lease with more than half of the service nodes), it can acquire the distributed lock needed to access the mutually exclusive resources and continue using the distributed service system, thereby improving the availability of the distributed lock service.

[0111] It is worth noting that in this embodiment, the client node can periodically and concurrently send lock acquisition request messages to multiple service nodes according to a set lock acquisition period. Alternatively, the client node can concurrently send lock acquisition request messages to multiple service nodes when it needs to access the mutex resource. Of course, the client node can also monitor the holding status of the distributed lock required to access the mutex resource, and concurrently send lock acquisition request messages to multiple service nodes when the distributed lock required to access the mutex resource is not held. The holding status of the distributed lock is divided into an idle state and a held state, where the idle state means that the distributed lock is not held by any client node.

[0112] Optionally, the number K of service nodes whose distributed locks are valid can be monitored and maintained. If this number K is less than the aforementioned set number M, it is determined that the distributed lock required to access the mutually exclusive resource is not held, that is, the distributed lock required to access the mutually exclusive resource is idle.

[0113] Furthermore, if it is detected that the distributed lock for accessing a mutex resource is not held, lock acquisition request messages can be sent concurrently to multiple service nodes to preempt the distributed lock maintained by multiple service nodes. In some embodiments, if it is detected that the distributed lock for accessing a mutex resource is not held, the operation of sending lock acquisition request messages concurrently to multiple service nodes can be performed after waiting for a random period of time.

[0114] In this implementation, the waiting time for each client node is random, starting from the moment it is determined that the distributed lock is not held. Because the waiting time for each client node is random, randomness is introduced. During this random waiting process, it is possible that only one client node can simultaneously acquire the distributed lock required to access the mutually exclusive resource. In this case, one client node will hold the distributed lock, maintaining the mutual exclusion of the distributed lock. This embodiment trades time for the eventual availability of the distributed lock service system, thus helping to improve the availability of the distributed lock service.

[0115] To enhance the robustness of distributed locks, if a client node determines that it has acquired the distributed lock required to access a mutex resource, it can also attempt to acquire the distributed lock maintained by the remaining service nodes (i.e., the second service nodes). This increases the number of first service nodes that return a successful lock acquisition message, thereby enhancing the robustness of the distributed lock required to access the mutex resource.

[0116] However, the distributed lock maintained by the second service node that a client node failed to acquire may be held by other client nodes. For a client node that successfully acquires the distributed lock required to access the mutex resource to increase the number of distributed locks it holds maintained by a service node, other client nodes must release the distributed locks they acquired. Therefore, for other client nodes that failed to acquire the distributed lock required to access the mutex resource, they can release the distributed lock maintained by the service node that acquired it, provided that they were determined not to have acquired the required distributed lock. Specifically, for other client nodes, if the number of service nodes returning a successful lock acquisition message to them is less than a set number M, it can be determined that they failed to acquire the distributed lock required to access the mutex resource, and the distributed lock maintained by the service node that returned the successful lock acquisition message to them can be released.

[0117] Accordingly, for a client node that acquires the distributed lock required to access a mutex resource, it can continue to send a lock-acquiring request message to a second service node among multiple service nodes, thereby increasing the number of service nodes returning a lock-acquiring success message. When a client node acquires the distributed lock required to access a mutex resource, the more distributed locks maintained by the service nodes it holds, the stronger the robustness of the distributed lock required to access the mutex resource.

[0118] In practical applications, some service nodes may malfunction, or communication between service nodes and client nodes may fail, affecting the robustness of the distributed lock required to access mutually exclusive resources. It is necessary to ensure that the number of service nodes in a normal state among those that a client node can acquire the maintained distributed lock from exceeds a set number M, thereby reducing the probability of a client node losing the distributed lock required to access mutually exclusive resources. Based on this, a target number X can be set, where X is greater than the aforementioned set number M. This ensures that the number of service nodes in a normal state among those that a client node can acquire the maintained distributed lock from is not less than the target number X, thus ensuring that the number of service nodes in a normal state among those that a client node can acquire the maintained distributed lock from exceeds the set number M.

[0119] Based on the foregoing analysis, the client node can monitor the health status of the first service node to ensure it is in a normal state. Specifically, the client node can monitor the health status of the first service node that returned a successful lock acquisition message based on heartbeat messages between the client node and the service node. For example, the client node can periodically send heartbeat messages to the first service node according to a set heartbeat cycle; if it receives a response message from the first service node within a set time period, it determines that the first service node is in a normal state; if it does not receive a response message from the first service node within a set time period, it determines that the first service node is in an abnormal state.

[0120] Furthermore, the client node can count the number Q of service nodes in the first service node that are in a normal state; and when the number Q of service nodes in the first service node that are in a normal state reaches the set target number X, it continues to send lock acquisition request messages to the second service node to increase the number of service nodes that return lock acquisition success messages.

[0121] For details on how the service node determines whether the client node has successfully acquired the distributed lock maintained by the service node based on the lock acquisition request message, please refer to the relevant content in the foregoing embodiments, which will not be repeated here.

[0122] If the second service node determines that the client node has successfully acquired the distributed lock it maintains, it returns a lock acquisition success message to the client node 10. For the client node, upon receiving the lock acquisition success message from the second service node, it can increase the number of service nodes that returned the message; and it can update the lifetime of the distributed lock required for the client node to access the mutually exclusive resource based on the validity period of the distributed lock maintained by the first service node and the validity period of the distributed lock maintained by the second service node that returned the lock acquisition success message. Furthermore, the number of service nodes maintaining valid distributed locks must exceed a set number M within the lifetime of the distributed lock required for the client node to access the mutually exclusive resource. This ensures that, on the one hand, more than the set number M of service nodes maintain valid distributed locks, thus ensuring the validity of the distributed lock required for the client node to access the mutually exclusive resource; on the other hand, it guarantees that only one client node can acquire the distributed lock required to access the mutually exclusive resource at any given time, maintaining the mutual exclusion of the distributed lock.

[0123] The specific implementation method for updating the lifetime of the distributed lock required by the client node to access the mutually exclusive resource based on the validity period of the distributed lock maintained by the first service node and the validity period of the distributed lock maintained by the second service node that returned the lock acquisition success message can be found in the aforementioned content on setting the lifetime of the distributed lock required by the client node to access the mutually exclusive resource based on the validity period of the distributed lock maintained by the first service node, and will not be repeated here.

[0124] The foregoing embodiments have described in detail the implementation of a distributed lock required for a client node to access a mutex resource. However, a client node may also fail to acquire the distributed lock required for accessing the mutex resource, i.e., the number of first service nodes returning a successful lock acquisition message to that client node is less than the aforementioned set number M. Accordingly, if the number of first service nodes returning successful lock acquisition messages is less than the aforementioned set number M, the client node can determine that it has not acquired the distributed lock required for accessing the mutex resource and release the distributed lock maintained by the first service node that returned the successful lock acquisition message. This allows other client nodes that have acquired the distributed lock required for accessing the mutex resource to continue requesting the distributed locks maintained by these service nodes, thereby enhancing the robustness of the distributed lock required for accessing the mutex resource.

[0125] The distributed lock service method provided in this disclosure will be described below with reference to the specific embodiment shown in Figure 6. This distributed lock service method is applicable to any client node requesting a distributed lock service. As shown in Figure 6, the method mainly includes:

[0126] S1. Initialize and start the session with the service node.

[0127] S2. Read from the memory information whether the distributed lock required to access the mutually exclusive resource is held. If it is held, proceed to steps S8 and S10-S12; if not, proceed to step S3.

[0128] S3. Obtain the holding information of distributed locks maintained by multiple service nodes.

[0129] S4. If you hold a distributed lock maintained by one or more service nodes, release the distributed lock maintained by those service nodes.

[0130] S5. Monitor whether the distributed lock required to access the mutually exclusive resource is idle, i.e., whether it is in an unheld state. If the distributed lock is not held, proceed to step S6; if the distributed lock is held, proceed to step S9.

[0131] S6. Concurrently send lock acquisition request messages to multiple service nodes.

[0132] S7. If the number of first service nodes among multiple service nodes exceeds a set number M, determine the distributed lock required to access the mutually exclusive resource; wherein, the first service node is the service node that returns a lock acquisition success message; M is greater than or equal to half of the total number of multiple service nodes and less than or equal to the total number of multiple service nodes.

[0133] S8. Access the mutex resource within the lifetime of the distributed lock required to access the mutex resource.

[0134] S9. After waiting for a fixed period of time, return to step S2.

[0135] S10, The background thread traverses the distributed lock maintained by multiple service nodes.

[0136] S11. Determine whether the service node currently being traversed holds the distributed lock maintained by it; for service nodes that hold the distributed lock maintained by it, execute step S12; for service nodes that do not hold the distributed lock maintained by it, execute step S13.

[0137] S12. Skip the service node and return to step S10.

[0138] S13. Continue sending lock acquisition request messages to service nodes that do not hold the distributed locks they maintain, in order to increase the number of distributed locks maintained by the service nodes that hold the locks, and return to step S10.

[0139] 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 501 and 502 can be device A; or the execution subject of step 501 can be device A, and the execution subject of step 502 can be device B; and so on.

[0140] 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 501, 502, 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.

[0141] Accordingly, embodiments of this disclosure also provide 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 above-described distributed lock service method.

[0142] 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 distributed lock service method described above. This disclosure does not limit the specific implementation of the computer program product. Optionally, the computer program product may be implemented as an application (APP), a computer-side client, a program module, a plug-in, or an installation package, etc., but is not limited thereto.

[0143] Figure 7 is a schematic diagram of the structure of a computing device provided in an embodiment of this disclosure. As shown in Figure 7, the computing device includes: a memory 70a, a processor 70b, and a communication component 70c. The memory 70a is used to store computer programs.

[0144] The processor 15b is coupled to the memory 70a and the communication component 70c, and is used to execute a computer program to perform the steps in the distributed lock service method 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.

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

[0146] Furthermore, the components within the dashed boxes in Figure 7 are optional, not mandatory, and their specific configuration depends on the form factor of the computing device. The computing 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.

[0147] 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 Programmable Read Only Memory (EPROM), Programmable Read Only Memory (PROM), Read Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

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

[0149] In embodiments of this disclosure, the communication component is configured to facilitate wired or wireless communication between its host device and other devices. The device housing the communication component can access wireless networks based on communication standards, such as Wireless Fidelity (WiFi), 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. In another exemplary embodiment, the communication component may also be implemented based on Near Field Communication (NFC), Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wide Band (UWB), Bluetooth (BT), or other technologies.

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

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

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

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

[0154] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code.

[0155] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more flowchart illustrations and / or one or more block diagrams.

[0156] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0157] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

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

[0159] Memory may include non-persistent storage in computer-readable media, such as random-access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0160] Computer storage media are readable storage media, also known as removable media. Removable and non-removable media can be used to store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient media, such as modulated data signals and carrier waves.

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

[0162] 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 lock service system, wherein, include: At least one client node that requests a distributed lock and multiple service nodes that independently provide distributed lock services; Any client node is used to concurrently send lock acquisition request messages to the multiple service nodes, and if the number of first service nodes among the multiple service nodes exceeds a set number, it determines that it has acquired the distributed lock required to access the mutual exclusion resource, and accesses the mutual exclusion resource within the lifetime of the distributed lock; Wherein, the first service node is the service node that returns the lock acquisition success message; the set number is greater than or equal to half of the total number of the plurality of service nodes, and less than or equal to the total number of the plurality of service nodes.

2. The system according to claim 1, wherein, The client node is also used for: If it is determined that the distributed lock required to access the mutually exclusive resource has been acquired, the validity period of the distributed lock maintained by the first service node is obtained; Based on the validity period of the distributed lock maintained by the first service node, the lifetime of the distributed lock required to access the mutually exclusive resource is set, and within the lifetime of the distributed lock required to access the mutually exclusive resource, the number of first service nodes whose maintained distributed locks are valid exceeds the set number.

3. The system according to claim 1 or 2, wherein, The client node is further configured to: before sending the lock acquisition request message to any service node, start timing the lifetime of the distributed lock maintained by the service node; The service node is also configured to: upon receiving the lock acquisition request message, start timing the lifetime of the distributed lock it maintains.

4. The system according to any one of claims 1-3, wherein, Before concurrently sending lock-grabbing request messages to the multiple service nodes, the client node is also used to: Monitor the holding status of the distributed lock required to access the mutex resource; if it is detected that the distributed lock required to access the mutex resource is not held, after waiting for a random period of time, execute the operation of concurrently sending lock acquisition request messages to the multiple service nodes.

5. A distributed lock service method, wherein, include: Concurrently send lock acquisition request messages to multiple service nodes; Each of the multiple service nodes independently provides distributed lock services; If the number of first service nodes among the plurality of service nodes exceeds a set number, a distributed lock required to access the mutually exclusive resource is determined; wherein, the first service node is the service node that returns the lock acquisition success message; the set number is greater than or equal to half of the total number of the plurality of service nodes, and less than or equal to the total number of the plurality of service nodes. Access the mutex resource within the lifetime of the distributed lock required to access the mutex resource.

6. The method according to claim 5, wherein, Also includes: If it is determined that the distributed lock required to access the mutually exclusive resource has been acquired, the validity period of the distributed lock maintained by the first service node is obtained. Based on the validity period of the distributed lock maintained by the first service node, the lifetime of the distributed lock required to access the mutually exclusive resource is set, and within the lifetime of the distributed lock required to access the mutually exclusive resource, the number of first service nodes whose maintained distributed locks are valid exceeds the set number.

7. The method according to claim 6, wherein, Based on the validity period of the distributed lock maintained by the first service node, the lifetime of the distributed lock required for accessing the mutually exclusive resource is set, and within the lifetime of the distributed lock required for accessing the mutually exclusive resource, the number of first service nodes whose maintained distributed locks are valid exceeds the set number, including: Calculate the validity period of the distributed lock maintained by the first service node at a set quantile; the set quantile is greater than or equal to the median; The lifetime of the distributed lock is set to the value of the validity period of the distributed lock maintained by the first service node at a set quantile.

8. The method according to any one of claims 5-7, wherein, Also includes: Before sending the lock acquisition request message to any service node, the lifetime of the distributed lock maintained by any service node is started; wherein, upon receiving the lock acquisition request message, any service node starts the lifetime of the distributed lock it maintains.

9. The method according to any one of claims 5-8, wherein, Also includes: If it is determined that the distributed lock required to access the mutually exclusive resource has been acquired, continue to send lock acquisition request messages to the second service node to increase the number of service nodes that return the lock acquisition success message; The second service node refers to the service node among the plurality of service nodes that did not return the lock acquisition success message.

10. The method according to claim 9, wherein, Also includes: Upon receiving a successful lock acquisition message from the second service node, increase the number of service nodes that returned the successful lock acquisition message; Based on the validity period of the distributed lock maintained by the first service node and the validity period of the distributed lock maintained by the second service node that returned a successful lock acquisition message, the lifetime of the distributed lock required for the client node to access the mutex resource is updated, and within the lifetime of the distributed lock required for the client node to access the mutex resource, the number of service nodes whose distributed locks are valid exceeds the set number.

11. The method according to claim 9 or 10, wherein, The step of continuing to send lock acquisition request messages to the second service node to increase the number of service nodes returning the lock acquisition success message includes: If the number of service nodes in the first service node that are in a normal state reaches the target number, continue to send lock acquisition request messages to the second service node to increase the number of service nodes that return the lock acquisition success message; the target number is greater than the set number.

12. The method according to any one of claims 5-11, wherein, Also includes: If the number of the first service nodes is less than the set number, it is determined that the distributed lock required to access the mutually exclusive resource has not been acquired, and the distributed lock maintained by the first service node is released.

13. The method according to any one of claims 5-12, wherein, The method further includes: Monitor the holding status of the distributed lock required to access the mutually exclusive resource; If it is detected that the distributed lock required to access the mutually exclusive resource is not held, after waiting for a random period of time, the operation of concurrently sending lock acquisition request messages to the multiple service nodes is executed.

14. A computing 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 5-13.

15. 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 5-13.

16. 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 5-13.

Images