Distributed lock processing method, device, storage medium, and system

Abstract

The present disclosure provides a distributed lock processing method, a device, a storage medium, and a system. The method comprises: a client sequentially acquires a first session lease from a first service cluster, sends, on the basis of the first session lease, to the first service cluster a first request for creating a lock, acquires a second session lease from a second service cluster, and sends, on the basis of the second session lease, to the second service cluster a second request for creating a lock; the first service cluster and the second service cluster respectively create locks for the client when determining that no other client is occupying the locks, and send lock creation success messages to the client; and then, upon receiving the lock creation success messages sent by the two service clusters, the client determines that the client itself has acquired the locks. The high robustness of the locks is achieved by improving the complexity of a lock contention stage, thereby maintaining the high availability of a distributed lock service when the entire single service cluster is unavailable.

Description

[0001] Distributed Lock Processing Method, Device, Storage Medium, and System This disclosure claims priority to Chinese Patent Application No. 202410095739.9, filed with the Patent Office of China on January 23, 2024, entitled "Distributed Lock Processing Method, Device, Storage Medium, and System," the entire contents of which are incorporated herein by reference. Technical Field This disclosure relates to the field of cloud computing technology, and more particularly to a distributed lock processing method, device, storage medium, and system.

[0002] ZooKeeper is an open-source distributed coordination service that has been widely used in many large-scale distributed systems. For example, the ZooKeeper service system can be used in distributed lock service scenarios. A ZooKeeper service system consists of multiple nodes (znodes) and can tolerate the simultaneous failure of some nodes. For example, a system consisting of five nodes can tolerate the simultaneous failure of two nodes. However, some software-level failures can cause the entire ZooKeeper service system to become unavailable. For example, the following situations: (1) The master node (Leader node) is stuck (i.e., it suddenly gets stuck during operation and does not continue to run subsequent codes), but the heartbeat mechanism between it and the slave node (Follower node) is still running normally. At this time, the slave node will think that the master node is still normal and will not trigger a new round of master node election process, causing the service system to be continuously unavailable at this time; (2) Assuming that the service system contains 3 nodes, and assuming that the hard disk of the machine where one of the slave nodes is located fails and is unavailable, a deadlock occurs when the other master node Leader exits (for example, the transaction ID is exhausted, the heartbeat timeout between the slave node and the master node, etc.). At this time, two of the three nodes have software failures, which will cause the entire service system to be unavailable. Therefore, in application scenarios using ZooKeeper service systems, such as distributed lock service application scenarios, it is necessary to ensure the high availability of distributed lock services. SUMMARY OF THE INVENTION The present disclosure provides a distributed lock processing method, device, storage medium and system to improve the high availability of distributed lock services.In a first aspect, embodiments of the present disclosure provide a distributed lock processing system, comprising: a first service cluster and a second service cluster providing distributed lock services, and a client using the distributed lock services; the client, configured to sequentially obtain a first session lease from the first service cluster and a second session lease from the second service cluster, send a first request to create a lock to the first service cluster using the first session lease, and send a second request to create a lock to the second service cluster using the second session lease; and determine that the lock has been acquired upon receiving lock creation success messages respectively sent by the first and second service clusters, wherein the first and second session leases are each bound to a set validity period; the first service cluster, configured to create a lock for the client in response to the first request and send a lock creation success message to the client when determining that no other client is occupying the lock; and the second service cluster, configured to create a lock for the client in response to the second request and send a lock creation success message to the client when determining that no other client is occupying the lock. In a second aspect, embodiments of the present disclosure provide a distributed lock processing method, applied to a client using a distributed lock service. The method includes: obtaining a first session lease from a first service cluster, and sending a first lock creation request to the first service cluster using the first session lease; obtaining a second session lease from a second service cluster, and sending a second lock creation request to the second service cluster using the second session lease, wherein both the first service cluster and the second service cluster provide distributed lock services, and the first session lease and the second session lease are respectively bound to a set validity period; and upon receiving a lock creation success message from the first service cluster and a lock creation success message from the second service cluster, determining that the lock has been acquired. In a third aspect, embodiments of the present disclosure provide a distributed lock processing device, applied to a client using a distributed lock service. The device includes: a first creation module, configured to obtain a first session lease from a first service cluster, and send a first lock creation request to the first service cluster using the first session lease; a second creation module, configured to obtain a second session lease from a second service cluster, and send a second lock creation request to the second service cluster using the second session lease, wherein both the first service cluster and the second service cluster provide distributed lock services, and the first session lease and the second session lease are respectively bound to a set validity period; and a determination module, configured to determine that the lock has been acquired upon receiving a lock creation success message from the first service cluster and a lock creation success message from the second service cluster.In a fourth aspect, embodiments of the present disclosure provide an electronic device comprising: a memory, a processor, and a communication interface; wherein the memory stores executable code, and when the processor executes the executable code, the processor is enabled to implement at least the distributed lock processing method described in the second aspect. In a fifth aspect, embodiments of the present disclosure provide a non-transitory machine-readable storage medium, wherein the non-transitory machine-readable storage medium stores executable code, and when the processor of the electronic device executes the executable code, the processor is enabled to implement at least the distributed lock processing method described in the second aspect. In a sixth aspect, embodiments of the present disclosure provide a computer program product, comprising a computer program, and when the processor executes the computer program, the processor is enabled to implement at least the distributed lock processing method described in the second aspect. The distributed lock processing system provided in embodiments of the present disclosure includes at least a first service cluster and a second service cluster that provide distributed lock services, and also includes a client that uses the distributed lock service. The process for creating a lock (i.e., acquiring a lock) for a client group is as follows: The client sequentially obtains a first session lease from the first service cluster and a second session lease from the second service cluster. Using the first session lease, the client sends a first request to create a lock to the first service cluster, and then a second request to create a lock to the second service cluster using the second session lease. In response to the first request, the first service cluster creates a lock for the client if it determines that no other client is holding the lock, and sends a lock creation success message to the client. Similarly, in response to the second request, the second service cluster creates a lock for the client if it determines that no other client is holding the lock, and sends a lock creation success message to the client. Only after receiving both lock creation success messages can the client confirm that it has successfully acquired the lock. As can be seen, each service cluster maintains a lock. A client can only be considered to have successfully acquired the lock if it has acquired locks from both service clusters in sequence. In other words, if a client fails to create a lock in a service cluster, it means that another client is currently holding the lock provided by that service cluster, and the client ultimately fails to acquire the lock. This increases the complexity of the lock grabbing phase in exchange for greater lock robustness, ensuring high availability of the distributed lock service even when a single service cluster is unavailable. BRIEF DESCRIPTION OF THE DRAWINGS To more clearly illustrate the technical solutions in the embodiments of the present disclosure, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below represent some embodiments of the present disclosure. Those skilled in the art can derive other drawings based on these drawings without inventive effort.Figure 1 is a schematic diagram of a lock grabbing process of a traditional distributed lock provided by an embodiment of the present disclosure; Figure 2 is a schematic diagram of a dual lock mechanism provided by an embodiment of the present disclosure; Figure 3 is a schematic diagram of a hardware execution environment of a distributed lock processing system provided by an embodiment of the present disclosure; Figure 4 is a schematic diagram of a cloud computing environment of a distributed lock processing system provided by an embodiment of the present disclosure; Figure 5 is a schematic diagram of the execution process of a distributed lock processing method provided by an embodiment of the present disclosure; Figure 6 is a schematic diagram of a client seeing a server that has not successfully grabbed the master under a dual lock mechanism provided by an embodiment of the present disclosure; Figure 7 is a schematic diagram of the timing design of a session lease under a primary-secondary lock mechanism provided by an embodiment of the present disclosure; Figure 8 is a schematic diagram of a heartbeat delayed response scenario provided by an embodiment of the present disclosure; Figure 9 is a flow chart of a distributed lock processing method provided by an embodiment of the present disclosure; Figure 10 is a structural schematic diagram of a distributed lock processing device provided by an embodiment of the present disclosure; Figure 11 is a structural schematic diagram of an electronic device provided by an embodiment of the present disclosure. DETAILED DESCRIPTION To further clarify the objectives, technical solutions, and advantages of the embodiments of the present disclosure, the technical solutions of the embodiments of the present disclosure will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the described embodiments represent only a portion of the embodiments of the present disclosure, and are not exhaustive. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present disclosure without inventive effort are within the scope of protection of the present disclosure. 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, stored data, and displayed data, etc.) involved in the embodiments of the present disclosure are all authorized by the user or fully authorized by all parties. The collection, use, and processing of the relevant data must comply with the relevant laws, regulations, and standards of the relevant region, and corresponding operation portals are provided for users to choose to authorize or reject. The following detailed description of some embodiments of the present disclosure is provided in conjunction with the accompanying drawings. The following embodiments and features may be combined unless there is a conflict between them. Furthermore, the sequence of steps in the following method embodiments is provided for illustrative purposes only and is not a strict limitation. Let's first explain the terms and concepts used in the embodiments of this disclosure: Distributed lock: A mechanism used in a distributed system for mutually exclusive access to shared resources. It ensures that only one client can obtain ownership of the lock at any given time, thereby guaranteeing the correctness of concurrent operations. Session lease: The session agreement between a client and a distributed lock service.When a client acquires a lock, it creates a session lease. The validity period of the session lease determines the validity period of the lock. Ephemeral nodes: Nodes representing distributed locks in a ZooKeeper service cluster. The lifecycle of an ephemeral node is bound to the session lease. When the client session holding the lock times out or is terminated, the ephemeral node is automatically deleted. Distributed lock availability: If the entire cluster providing the distributed lock service becomes unavailable, session leases will quickly expire, causing clients that have already acquired the lock to enter the lock loss logic and re-acquire the lock. Due to the cluster unavailability, lock acquisition attempts will continue to fail, leaving the client unavailable. The entire cluster can be unavailable if a majority of its nodes are unavailable. For example, if a ZooKeeper service cluster contains three ZooKeeper nodes (znodes), and at least two of them are unavailable, the entire ZooKeeper cluster becomes unavailable. Service discovery: Service discovery is the process of automatically discovering and identifying available service instances in a distributed system so that other services or clients can interact with them. Currently, distributed lock services based on distributed ZooKeeper clusters are widely used. Common ZooKeeper clusters are often deployed with three or five nodes. When a majority of these nodes become unavailable, the entire ZooKeeper cluster becomes unavailable, and thus cannot provide distributed lock services properly. The distributed lock processing solution provided in the present disclosure aims to improve the high availability of distributed lock services. The following briefly describes the traditional distributed lock acquisition (i.e., lock creation) and related maintenance processes, using Figure 1. Distributed locks have two basic properties: ownership and validity. As shown in Figure 1, taking a ZooKeeper distributed lock as an example, assume that client 1 and client 2 compete for the same lock in the same ZooKeeper cluster (ZooKeeper cluster 1 in Figure 1). Each client creates a session lease: client 1's session lease is represented as Iease1, and client 2's session lease is represented as Iease2. A lock is a temporary node whose lifetime is bound to the session lease.For ease of understanding, this embodiment names this lock "abc." Assume that the lock creation process is as follows: 1. Client 1 first establishes a communication connection (e.g., a TCP (Transmission Control Protocol) connection) with ZooKeeper cluster 1. ZooKeeper cluster 1 creates session-layer identification information for client 1, namely, a session lease (leasel), binds the corresponding validity period, and feeds it back to client 1. Afterwards, client 1 and ZooKeeper cluster 1 perform heartbeat maintenance based on the heartbeat mechanism. 2. Client 1 sends a lock creation request to ZooKeeper cluster 1, using "leasel" as the owner identifier. Assume that ZooKeeper cluster 1 discovers that lock abc is not occupied by another client. Then, ZooKeeper cluster 1 creates a temporary node corresponding to lock abc and associates it with client 1's session lease, leasing, indicating that client 1 has successfully acquired the lock. The lease is valid for the duration corresponding to leasing. ZooKeeper cluster 1 then sends a message confirming the lock creation success to client 1, confirming that client 1 has successfully acquired the lock. Furthermore, while client 1 is creating the lock, client 2 is also creating a lock. As shown in Figure 1: 1. Client 2 establishes a TCP connection with ZooKeeper cluster 1. ZooKeeper cluster 1 creates a session-layer identifier for client 2, namely, a session lease (leasing2), binds it to the lease, and sends it back to client 2. Client 2 and ZooKeeper cluster 1 then maintain heartbeats based on the heartbeat mechanism. 2. Client 2 sends a lock creation request to ZooKeeper cluster 1, using Iease2 as the owner. Since ZooKeeper cluster 1 detects that lock abc is currently held by client 1, it sends a message to client 2, indicating that the lock creation failed. Client 2 then determines that it has failed to acquire the lock. This means that only one client can acquire the lock at a time, thus satisfying the mutual exclusivity requirement of distributed locks.Furthermore, when the heartbeat of a client session holding a lock stops, its session lease will time out within a predetermined period, automatically releasing the lock it holds. Other surviving clients can then successfully seize the lock, ensuring lock survivability. For example, in the embodiment shown in Figure 1, if the heartbeat between client 1 and ZooKeeper cluster 1 stops at some point after successfully acquiring the lock (for example, it cannot send heartbeat packets to the ZooKeeper cluster at the configured heartbeat interval), the timer will start from the last received heartbeat response message. When the timer reaches the validity period corresponding to I easel, client 1's I easel will time out, and lock abc will be actively released. ZooKeeper cluster 1 will then delete I easel and its associated lock abc. As shown in Figure 1: 3. Assume that the heartbeat between client 2 and ZooKeeper cluster 1 is functioning normally. Client 2 is attempting to create a lock using its own Iease2. Therefore, when ZooKeeper cluster 1 receives client 2's request to create a lock, since no other client currently holds lock abc, it allocates lock abc to client 2. A temporary node for lock abc is created and associated with client 2's Iease2, with a validity period equal to that of Iease2. This process involves the renewal of the lease. For example, after client 1 establishes a TCP connection with ZooKeeper cluster 1 and is assigned lease1, it can send heartbeat packets to ZooKeeper cluster 1 at a set interval. Upon receiving the heartbeat packets, ZooKeeper cluster 1 responds with a corresponding response message, confirming that the communication connection between client 1 and ZooKeeper cluster 1 is functioning properly. Assume that the validity period of the I easel received by client 1 from ZooKeeper cluster 1 is 20 seconds. After receiving the message from ZooKeeper cluster 1 that the lock has been successfully created, client 1 starts counting the validity period. Assume that the starting point of the timing is time T1.When client 1 sends the next heartbeat packet to ZooKeeper cluster 1 and receives a corresponding response (assuming this is T2), the timer is reset to T2, effectively renewing I easel. If client 1 subsequently does not send any more heartbeat packets or receive any corresponding response messages, a 20-second countdown begins at T2, marking I easel's expiration. In the example shown in Figure 1, the ownership and validity of distributed locks are both represented by the session lease, meaning the two are coupled together. This creates an availability issue: if ZooKeeper cluster 1, which provides the distributed lock service, becomes unavailable as a whole, the session lease will quickly expire. Clients that have seized ownership of the lock will quickly enter the lock-losing logic, triggering a retry. Because ZooKeeper cluster 1 is unavailable, lock acquisition attempts by various clients will continue to fail, leaving them unavailable.

[0003] Lock grabbing is a low-frequency operation, so the natural question is whether, in this scenario, the validity period of existing distributed locks remains unchanged, while only new lock grabbing operations are affected. This effectively limits the failure radius of the cluster providing distributed lock services. Based on this approach, the disclosed embodiments offer a solution that increases the difficulty of lock grabbing, thereby relaxing the threshold for maintaining lock validity periods. In other words, increasing the complexity of lock grabbing in exchange for lock robustness. Based on this, the disclosed embodiments provide a highly available distributed lock processing solution based on a primary-secondary lock renewal mechanism, ensuring high lock service availability even when a single ZooKeeper cluster becomes unavailable. By introducing a primary-secondary lock design based on the ZooKeeper cluster, the lock robustness is enhanced by increasing the complexity of the lock grabbing phase. This ZooKeeper cluster is merely an example of a distributed system and is not intended to be limiting. As shown in Figure 2, the distributed lock service service is expanded from one service cluster to at least two, such as ZooKeeper cluster 1 and ZooKeeper cluster 2. Each distributed lock is split into a primary lock and a secondary lock, each maintained independently in two separate ZooKeeper clusters. In practice, the primary and secondary locks are simply used to distinguish the locks in the two clusters; their names can be the same, for example, both are locks abc. To acquire ownership of the lock, a client must sequentially acquire ownership of both the primary and secondary locks. Distributed locks exhibit mutual exclusivity; at most one client can simultaneously hold both locks. The validity period of a distributed lock is the maximum of the validity periods of the corresponding session leases. In other words, if either lock is still within its validity period, the client assumes the lock has been held and can continue to hold the lock. Otherwise, the prerequisite for a client to acquire the distributed lock becomes more stringent: the validity periods of both locks must have expired. The following describes the distributed lock processing solution provided by the present disclosure. FIG3 is a schematic diagram of a hardware execution environment of a distributed lock processing system provided in an embodiment of the present disclosure. As shown in FIG3 , the hardware execution environment of the distributed lock processing system may include a client device 301, a first service cluster 302, and a second service cluster 303. The client device 301 is in communication with the first service cluster 302 and the second service cluster 303.First service cluster 302 and second service cluster 303 are different service clusters that provide the same distributed lock service. Each service cluster may include multiple nodes. For example, first service cluster 302 includes nodes a1, a2, and a3; second service cluster 303 includes nodes b1, b2, and b3. In practical applications, these two service nodes can be specifically implemented as a first ZooKeeper cluster and a second ZooKeeper cluster, each of which includes three ZooKeeper nodes, providing distributed lock services. In this disclosed embodiment, the master and slave roles of the nodes in each ZooKeeper cluster may not be distinguished. In practical applications, first service cluster 302 and second service cluster 303 may be two service clusters composed of cloud servers based on the cloud, and different nodes in the same service cluster may be deployed on different cloud servers. Client device 301 refers to a client that uses the distributed lock service provided by first service cluster 302 and second service cluster 303, and generally refers to any client that uses the distributed lock service. In actual applications, the client device 301 is often a server that provides certain application / content services, such as e-commerce, audio and video, and artificial intelligence services. In actual applications, the nodes included in the first service cluster 302 and the second service cluster 303 may be cloud servers maintained by a cloud service provider, also known as computing nodes. In the cloud computing environment shown in FIG4 , several distributed computing nodes (illustrated as 401-1, 401-2, and so on in FIG4 ) may be included, each of which has processing resources such as computing and storage. In a cloud computing environment, multiple computing nodes may be organized to provide a certain service; of course, a computing node may also provide one or more services, such as service A, service B, service C, and service D illustrated in FIG4 , where service B is, for example, a distributed lock service. In other words, a computing node may include services other than the distributed lock service. The cloud computing environment may provide such services by providing an external service interface, which the client device calls to use the corresponding service.Service interfaces include software development kits (SDKs) and application programming interfaces (APIs). During operation, executing a request from a client device may require invoking one or more services in the cloud computing environment. Executing one or more functions of one service may require invoking one or more functions of another service. As shown in Figure 4 , after receiving a request from a client device, service A can invoke service B, and service B can request service D to execute one or more functions. Each of the first service cluster 302 and the second service cluster 303 can include multiple computing nodes providing distributed lock services. Figure 4 illustrates only one computing node 401-1 providing the distributed lock service. In practice, multiple computing nodes providing the distributed lock service can constitute one service cluster, while another multiple computing nodes providing the same distributed lock service can constitute another service cluster. The distributed lock service described above is deployed based on various virtualization technologies supported by the cloud computing environment, such as virtualization technologies based on virtual machines or containers. Taking container-based virtualization technology as an example, several containers corresponding to a service can be assembled into a container group (pod). For example, Service B (distributed lock service) shown in Figure 4 can be configured with one or more pods. Each pod can include a proxy and one or more containers. The one or more containers in the pod are used to process requests related to one or more corresponding functions of the service. The proxy in the pod is used to control network functions related to the service, such as routing and load balancing.Based on the distributed lock processing system shown in FIG3 , the process by which a client device 301 grabs a lock, i.e., creates a lock, through a first service cluster 302 and a second service cluster 303 is as follows: the client device 301 sequentially obtains a first session lease from the first service cluster and a second session lease from the second service cluster, sends a first request to create a lock to the first service cluster using the first session lease, and sends a second request to create a lock to the second service cluster using the second session lease. Upon receiving lock creation success messages respectively from the first and second service clusters, the client determines that the lock has been acquired. The first and second session leases are each bound to a set validity period. The first service cluster, in response to the first request, creates a lock for the client upon determining that no other client is occupying the lock, and sends a lock creation success message to the client. The second service cluster, in response to the second request, creates a lock for the client upon determining that no other client is occupying the lock, and sends a lock creation success message to the client. The lock loss process is as follows: If the client determines that the target session lease has timed out based on the validity periods of the first and second session leases, it decides to abandon the lock. The target session lease is the later of the first and second session leases that has timed out. The validity periods of the first and second session leases are the same. The lock acquisition and lock loss process described above is illustrated with reference to Figure 5. The lock acquisition process is as follows: 1. Client 1 establishes a TCP connection with ZooKeeper cluster 1. ZooKeeper cluster 1 creates a first session lease (l easel) for client 1, binds the corresponding validity period, and sends it back to client 1. Client 1 and ZooKeeper cluster 1 then perform heartbeat maintenance based on the heartbeat mechanism. Client 1 sends a first request to ZooKeeper cluster 1 to create a lock, using l easel as the owner identifier. Assume that ZooKeeper cluster 1 discovers that its local lock abc is not occupied by another client. It then creates a temporary node corresponding to lock abc and associates it with client 1's session lease, I easel, with a validity period corresponding to I easel. ZooKeeper cluster 1 then sends a message to client 1 confirming the successful lock creation. Next, client 1 establishes a TCP connection with ZooKeeper cluster 2. ZooKeeper cluster 2 creates a second session lease (l ease2) for client 1, binds it to the corresponding validity period, and sends this message back to client 1. Client 1 and ZooKeeper cluster 2 then maintain heartbeat maintenance based on the heartbeat mechanism.Client 1 sends a second lock creation request to ZooKeeper cluster 2, using Iease2 as the owner identifier. Since ZooKeeper cluster 2 detects that its local lock abc is not occupied by another client at this point, it sends a lock creation success message back to client 1. Since client 1 has received lock creation success messages from both ZooKeeper cluster 1 and ZooKeeper cluster 2, it determines that it has successfully acquired the lock. Then, as shown in Figure 5, 3. When the heartbeat between client 1 and ZooKeeper cluster 1 stops / times out at some point after successfully acquiring the lock, and when the timer reaches the validity period of Iease1, ZooKeeper cluster 1 determines that client 1 has lost the lock and deletes the record of client 1's occupation of the local lock abc. However, assuming that the heartbeat between client 1 and ZooKeeper cluster 2 is still normal at this point, ZooKeeper cluster 2's local lock abc is still occupied by client 1. At this point, client 1 still holds lock abc because Iease2 has not yet expired. At the same time: 4. Assume that client 2 establishes a TCP connection with ZooKeeper cluster 1. ZooKeeper cluster 1 creates a third session lease (l ease3) for client 2, binds it to a corresponding validity period, and sends it back to client 2. Client 2 and ZooKeeper cluster 1 then maintain heartbeats based on the heartbeat mechanism. Client 2 sends a lock creation request to ZooKeeper cluster 1 using l ease3 as the owner identifier. ZooKeeper cluster 1 detects that the local lock abc is not occupied by another client. It then creates a temporary node corresponding to lock abc and associates it with client 2's session lease I ease3. ZooKeeper cluster 1 then sends a lock creation success message to client 2. Client 2 then establishes a TCP connection with ZooKeeper cluster 2. ZooKeeper cluster 2 creates a fourth session lease (l ease4) for client 2, binds it to a corresponding validity period, and sends it back to client 2. Client 2 and ZooKeeper cluster 2 then maintain heartbeats based on the heartbeat mechanism.5. Client 2 sends a lock creation request to ZooKeeper cluster 2 using Iease4 as the owner identifier. ZooKeeper cluster 2 discovers that the local lock abc is still occupied by client 1, determines that client 2 has failed to acquire the lock, and sends a lock acquisition failure message to client 2. It is understandable that in the above example, if the heartbeat between client 1 and ZooKeeper cluster 2 also times out, causing the validity period corresponding to Iease2 to expire, client 1 will determine that it has discarded the occupied lock abc. Heartbeat timeout / stoppage refers to situations where the heartbeat mechanism between the client and the ZooKeeper cluster detects a communication anomaly. A heartbeat timeout occurs, for example, when a client sends a heartbeat packet but does not receive a response from the ZooKeeper cluster within a set time. A heartbeat stop occurs, for example, when a client fails to send a heartbeat packet after a set period of time. As can be seen from this, under the dual-lock mechanism of primary and secondary locks (for example, the locks abc locally maintained by two ZooKeeper clusters in the above example—one primary and one secondary) a successful lock acquisition is determined by simultaneously acquiring both locks, which is equivalent to holding the validity periods of both locks simultaneously. Therefore, the so-called primary and secondary locks are effectively equivalent, and swapping the order of acquisition of the primary and secondary locks does not affect the mutual exclusivity of the locks. Based on this primary and secondary lock mechanism, high availability of the distributed lock service can be achieved. This is because, for a client, even if either the primary or secondary lock fails, the session lease of the other lock remains renewed (as long as the heartbeat is normal), preventing the lock from being lost and allowing the client to continue operating. In contrast, if there is only one distributed lock service, if the corresponding service cluster becomes unavailable, the client will lose its only lock (such as in the embodiment shown in Figure 1). The client will need to immediately re-acquire the lock. Because the single service cluster is unavailable, the client will be unable to acquire the lock, and its operation will cease. It should be noted that in this disclosure, the distributed lock processing process is described only at the service cluster level. In practice, using the aforementioned ZooKeeper cluster 1 as an example, it can include multiple nodes. When a client establishes a TCP connection with ZooKeeper cluster 1, it actually establishes a TCP connection with a specific node. Successful lock creation by the client means successful lock creation on that node. However, for clients using the distributed lock service, all nodes in a service cluster can be considered equivalent, without distinction.The solution described in the above embodiments, which does not require distinguishing between the order of acquiring primary and secondary locks (that is, a default lock acquisition order from two service clusters can be sufficient, either first acquiring the lock from the first service cluster and then from the second service cluster, or first acquiring the lock from the second service cluster and then from the first service cluster), is applicable to scenarios where different clients using a distributed lock service have equal roles, such as when each client is a storage node with the same role in a distributed storage system. However, in master election and service discovery scenarios, it is necessary to distinguish between the order of acquiring primary and secondary locks. Master election and service discovery scenarios involve multiple clients using a distributed lock service determining master and slave roles through lock acquisition. The client that successfully acquires the lock is designated as the primary client, while the other clients are designated as backup clients. Furthermore, the primary client that successfully acquires the lock registers its service address (e.g., IP (Internet Protocol) address) with the service cluster providing the distributed lock service, making it easier for accessed clients to discover the service address they need to access. At this time, the client using the distributed lock service can be represented as a server (i.e., an application server, such as an e-commerce server, audio and video server, etc.), and the one accessing the application server can be represented as a client (i.e., an application client). Therefore, the master selection is to determine the master server and the backup server among multiple servers. oIn a master election and service discovery scenario, after a server successfully seizes master status through a distributed lock, it needs to register its service address with a service cluster (such as a ZooKeeper cluster) providing distributed lock services to facilitate client access. Therefore, in an alternative embodiment, the server can simultaneously write its service address to the service cluster while seizing the lock, thereby completing both the lock seizure and service address registration logic. In this application scenario, using the dual lock mechanism described above, if the service address is registered through the master lock, in some scenarios, the client may see the service address registered by the backup server that failed to seize master status, even though the backup server has not yet started operating. The above scenario is illustrated below with reference to FIG6 . In FIG6 , assume that server 1 successfully acquires locks from ZooKeeper cluster 1 and ZooKeeper cluster 2, respectively, through steps 1 and 2 illustrated in the figure (the specific process is described in the embodiment shown in FIG5 and is not repeated here). Furthermore, assume that the lock acquired from ZooKeeper cluster 1 is called the primary lock, and the lock acquired from ZooKeeper cluster 2 is called the secondary lock. In reality, the primary and secondary locks are the same lock stored in both server clusters: for example, lock abc in the example above. Furthermore, upon acquiring the primary lock, server 1 registers its service address with ZooKeeper cluster 1. As shown in FIG6 , the client can query server 1's service address through ZooKeeper cluster 1. After server 1 acquires both the primary and secondary locks, it begins working. After a while, as shown in Figure 6 , a heartbeat timeout occurs between server 1 and ZooKeeper cluster 1. This means the primary lock maintains its heartbeat for a timeout. Server 2 then acquires the primary lock from ZooKeeper cluster 1 and registers its service address with ZooKeeper cluster 1. At this point, because server 1 still maintains the session lease for the secondary lock, meaning the secondary lock is still valid, server 2 fails to seize the secondary lock from ZooKeeper cluster 2 (see the relevant description in the embodiment shown in Figure 5 , which will not be repeated here).That is to say, server 1 is still occupying the lock at this time, so what the client should see in ZooKeeper cluster 1 is the service address of the currently working server 1. However, because server? successfully grabs the master lock in ZooKeeper cluster 1 and registers its service address in ZooKeeper cluster 1, ZooKeeper cluster 1 believes that server? is now the master server and replaces the previously registered service address of server 1 with the service address of server?. At this time, what the client sees from ZooKeeper cluster 1 is the service address of server?, which creates an inconsistent master selection problem: the master server that should be selected is server 1, but the service address is actually registered by the backup server 2. To address the aforementioned inconsistent master selection issue in master election and service discovery scenarios, compared to the previous embodiment in which the first and second service clusters do not distinguish between primary and secondary locks, the first service cluster is set as the primary service cluster by default, providing the primary lock, while the second service cluster is set as the secondary service cluster, providing the secondary lock. By default, servers preempt the primary lock first and then the secondary lock. After successfully preempting the primary lock, they register their service address with the primary service cluster (i.e., the first service cluster). This disclosed embodiment provides the following solution to inconsistent master selection: the default preemption order of primary and secondary locks is swapped, so that a server can only preempt the primary lock after it has acquired ownership of the secondary lock. Specifically, the second service cluster is configured as the service cluster that provides the service address registration service (unlike the previous embodiment, the locks it provides are referred to as primary locks here), while the first service cluster is configured as the service cluster that provides the secondary lock. In practice, since primary and secondary locks are simply names that distinguish the same lock located in different service clusters, they can also be collectively referred to as the primary lock and the secondary lock. Therefore, the solution is essentially this: the server first grabs the lock (secondary lock) provided by the first service cluster, which doesn't offer service address registration. It then grabs the lock (primary lock) provided by the second service cluster, which does offer service address registration. After successfully grabbing the primary lock, the server registers its service address with the second service cluster. For each server, the service cluster configured to provide service address registration by default is the second service cluster. Therefore, upon receiving a lock creation success message from the second service cluster, the client (server) using the distributed lock service registers its service address with the second service cluster. This allows the server's access objects (clients) to obtain the server's service address from the second service cluster.Using the aforementioned approach to solving the leader election consistency problem, let's continue with the lock grabbing scenario illustrated in Figure 6, where servers 1 and 2 are competing for the master lock. Server 1 first successfully grabs the lock from ZooKeeper cluster 1, then attempts to grab the lock from ZooKeeper cluster 2. If it also succeeds in grabbing the lock from ZooKeeper cluster 2, it registers its service address with ZooKeeper cluster 2. At this point, the client sees server 1's service address through ZooKeeper cluster 2. Later, suppose server 1 releases the lock it grabbed from ZooKeeper cluster 1 (for example, due to a heartbeat stop or timeout), but still holds the lock it grabbed from ZooKeeper cluster 2. Server 2 successfully grabs the lock from ZooKeeper cluster 1, but when it attempts to grab the lock from ZooKeeper cluster 2, it fails to grab the master lock because server 1 is already holding the lock. Consequently, the client still sees the service address of server 1, which holds the lock, from ZooKeeper cluster 2. It's worth noting that if the secondary lock is preempted first, to ensure that the session lease for the secondary lock remains valid when the primary lock is successfully preempted, the remaining validity period of the secondary lock can be ensured to be greater than the time required to preempt the primary lock before attempting to preempt the primary lock, allowing for a successful primary lock preemption message to be returned. In extreme cases, if the server discovers that the session lease for the secondary lock has expired after receiving a successful primary lock preemption message from the second service cluster, it must proactively release the primary lock and begin preempting the secondary lock. This ensures that the client resolves to the service address of the true primary server. The above embodiment describes a distributed lock processing system that includes only two service clusters: the first and second service clusters providing distributed lock services. In practice, to further improve the high availability of distributed lock services, the number of service clusters providing distributed lock services can be expanded from two to more, such as three or five. In other words, in addition to the first and second service clusters, the distributed lock processing system also includes at least one other service cluster providing distributed lock services. In this case, the client using the distributed lock service is not sure that it has acquired the lock until it receives lock creation success messages from at least a target number of service clusters, where the target number is greater than half the number of service clusters.At this point, the security and activity of the extended distributed lock are mainly reflected in the following aspects: Security of the distributed lock: When the same client seizes the lock resources of the majority, it is considered that the lock is seized successfully. If the majority renewal timeout occurs, it is considered that the lock is lost. The majority refers to more than half of the service clusters in the entire service cluster. For example, if there are 3 service clusters in total, the majority refers to at least 2 of them. For example, if there are 5 service clusters in total, the majority refers to at least 3 of them. Activity of the distributed lock: (1) There is no deadlock, and the lock resources of the service cluster will automatically expire and be recycled; each client seizes the lock resources of each service cluster in a fixed order. If the preemption fails, it will skip seizing the lock resources of the next service cluster. Each failed lock seizure requires a longer backoff time than the successful seizure of the majority lock, so that the client that has successfully seized the lock resource can first compete for the subsequent lock resources. (2) The failure of a single service cluster does not affect the availability of the entire distributed lock. In the aforementioned embodiments, the session lease serves as an identifier for clients using the distributed lock service at the session layer. It is also bound to a validity period; upon expiration, the occupied lock is released. This involves the design of a timekeeping mechanism for the session lease validity period. Traditional distributed lock solutions, such as the Redrock algorithm of RedIS, employ absolute timekeeping based on physical clocks, such as Network Time Protocol (NTP). Physical clock drift may occur, specifically between the service cluster providing the distributed lock service and the client using it. This clock drift can destroy the mutual exclusivity of the lock. It should be noted that both the service cluster and the client need to time the validity period of the same session lease. For example, if a client's session lease has a validity period of 20 seconds, both the client and the service cluster need to time the validity period of this session lease. For example, if the service cluster's physical clock drifts forward (to a certain point in the future, meaning time is running too fast), the service cluster may believe that its session lease has expired prematurely (i.e., the lock has timed out prematurely). However, the client's session lease has not yet expired, so it believes it still holds the lock. At this point, another client attempts to grab the lock from the service cluster. Since the service cluster already considers the previous client's session lease to have expired, it assigns the lock to the other client. This results in the lock being held by two clients simultaneously, breaking the lock's mutual exclusivity.For example, if the client's physical clock drifts backward (to a certain point in the past, i.e., time has slowed down), the client may believe it still holds the lock (its session lease has not expired), but the service cluster has already determined that it has lost the lock (its session lease has expired). Similarly, multiple clients may simultaneously hold the lock, breaking the mutual exclusivity of the lock. In both of these examples, the client's session lease expires after the service cluster's session lease, resulting in a break in the mutual exclusivity of the lock. To overcome the impact of the physical clock timing on the mutual exclusivity of the lock, the primary and secondary lock design provided in the embodiments of the present disclosure does not rely on the physical clock, but instead relies on the consistency of clock frequencies (over a short period of time). In other words, the elapsed time on any two machines can be considered the same. Based on this assumption, under the aforementioned primary-secondary lock mechanism, session leases on both the client and each service cluster are monotonically relative, rather than absolute. This ensures accurate session lease maintenance and ensures that client session leases expire before service cluster session leases. If a client believes its own session lease has expired, but the service cluster's session lease has not, and the client releases the lock, the service cluster will consider the client still holding the lock and reject other clients' lock creation requests (i.e., lock grabbing requests). This means that only one client holds the lock at a time, preventing mutual exclusivity. In practice, both the service cluster and the client can use CPU (Central Processing Unit) ticks as a relative timekeeping mechanism to time the validity of session leases. In fact, Monotonic Time (monotonic time) can be determined according to the CPU tick, and the timing of the validity period of the session lease is achieved by counting Monotonic Time. The method of determining Monotonic Time according to the CPU tick can be implemented by referring to the existing related technologies.Continuing with the above embodiment, for the client, the client uses the moment it receives the lock creation success message from the first service cluster as the first timing start point, and counts the validity period of the first session lease according to the CPU tick period. Furthermore, the client uses the moment it receives the lock creation success message from the second service cluster as the second timing start point, and counts the validity period of the second session lease according to the CPU tick period. For the first and second service clusters, the first service cluster resets the third timing start point of the locally maintained validity period of the first session lease at the moment it receives the initial heartbeat packet from the client, counts the validity period of the locally maintained first session lease according to the CPU tick period, and deletes the lock and the first session lease upon determining that the locally maintained first session lease has timed out. Similarly, the second service cluster resets the fourth timing start point of the locally maintained second session lease at the moment it receives the initial heartbeat packet from the client, counts the validity period of the locally maintained second session lease according to the CPU tick period, and deletes the lock and the second session lease upon determining that the locally maintained second session lease has timed out. It is understood that after receiving a lock creation success message from the first service cluster, the client sends an initial heartbeat packet (the initial heartbeat packet sent to the first service cluster) to the first service cluster. Upon receiving the initial heartbeat packet, the first service cluster restarts the validity period of its first session lease. Similarly, after receiving a lock creation success message from the second service cluster, the client sends an initial heartbeat packet (the initial heartbeat packet sent to the second service cluster) to the second service cluster. Upon receiving the initial heartbeat packet, the second service cluster restarts the validity period of its second session lease. The initial time for the validity period of the first and second session leases of the first and second service clusters, respectively, is the time when the first service cluster creates the first session lease and the time when the second service cluster creates the second session lease. Furthermore, the client only releases the lock and proceeds to the next lock acquisition logic when its own timing determines that both the first and second session leases have expired. In addition, it should be noted that, from a first timing start point, the client sends heartbeat packets to the first service cluster at a set time interval. If a response message fed back by the first service cluster is received, the first timing start point is reset to the time when the response message is received. And, from a second timing start point, the client sends heartbeat packets to the second service cluster at a set time interval. If a response message fed back by the second service cluster is received, the second timing start point is reset to the time when the response message is received.It is understandable that resetting the first and second timer starting points is equivalent to restarting the corresponding session lease validity period from the new starting point, effectively achieving a session lease renewal. Of course, the normal transmission and reception of the next heartbeat packet and response message will also cause the timer starting point to be reset again. Similarly, when the first and second service clusters are timing the validity periods of the first and second session leases locally, each time they receive a heartbeat packet from the client and return a corresponding response message, they will also reset the local third and fourth timer starting points. The following describes the timing mechanism for the session lease validity period with reference to FIG7 . As shown in Figure 7, when the validity period of the session lease on the client side is the same as the validity period of the same session lease on the service cluster side, under the aforementioned primary-secondary lock mechanism, the client starts counting the validity period of the first session lease (denoted as I easel in the figure) from the time it receives the lock creation success message from ZooKeeper cluster 1 (this time is the first timing starting point), and starts counting the validity period of the second session lease (denoted as I ease2 in the figure) from the time it receives the lock creation success message from ZooKeeper cluster 2 (this time is the second timing starting point). After receiving the initial heartbeat packet sent by the client, ZooKeeper cluster 1 and ZooKeeper cluster 2 both begin timing out their respective I easel and I ease2 validity periods (corresponding to the third and fourth timing starting points in the figure, respectively). Therefore, the timing starting points of the client and ZooKeeper clusters 1 and 2 are guaranteed to be sequential due to causality (the client sends the initial heartbeat packet after receiving the lock creation success message). Furthermore, through monotonic relative time timing (i.e., CPU tick timing), it is guaranteed that if the client no longer initiates renewal (i.e., cannot send and receive heartbeat packets normally), the client's session lease will always time out before the validity period of the service cluster's session lease. For example, as shown in Figure 7: Assume that the client does not send the next heartbeat packet after sending the initial heartbeat packet to ZooKeeper cluster 1 and ZooKeeper cluster 2 respectively, then when the validity period of I easel measured from the first timing starting point reaches time T1, the client determines that the validity period of I easel has timed out. When the validity period of I ease2 measured from the second timing starting point reaches time T1', the client determines that the validity period of I ease2 has timed out.Because ZooKeeper cluster 1 no longer receives heartbeat packets, Iease1 is determined to have timed out when the validity period of Iease1, which has been timed since the third timing start, reaches time T2. Similarly, because ZooKeeper cluster 2 no longer receives heartbeat packets, Iease2 is determined to have timed out when the validity period of Iease2, which has been timed since the fourth timing start, reaches time T3. Furthermore, T1 is earlier than T2, and T1' is earlier than T3. Thus, based on the relative time timing method, the client session lease expires earlier than the corresponding service cluster session lease, resulting in a timeout. The above embodiments all assume that the validity period of a session lease on the client and each service cluster is equal. However, in actual applications, network latency between the client and the first or second service clusters can sometimes be significant. In extreme cases, for example, when a client sends a heartbeat packet to the first service cluster, the first service cluster may delay responding by the duration of the first session lease. In this case, the client may believe it still holds the lock (because it received the response message within the lease's duration, indicating a successful renewal), but the first service cluster may determine that the client has lost the lock (because the lease's duration has expired). As shown in Figure 8, the client sends a heartbeat packet to ZooKeeper cluster 1 at time T1. Assuming the network latency is negligible, ZooKeeper cluster 1 receives the heartbeat packet at time T1. Subsequently, assuming the client receives a response message from ZooKeeper cluster 1 at time T2, after a delay of twice the lease's duration, the client determines that the lease's renewal is successful. The client then sends another heartbeat packet to ZooKeeper cluster 1. At this point, as shown in Figure 8, ZooKeeper cluster 1 begins timing at time T1. When it reaches time T2, which is equal to twice the validity period of the I easel, ZooKeeper cluster 1 determines that the client's I easel is invalid. It then disconnects the client, preventing it from receiving the "next heartbeat packet." This causes the client's subsequent I easel renewal attempts to fail, resulting in lock loss. To avoid this situation, the first service cluster can ensure that the validity period of the locally maintained first session lease is at least twice the validity period of the client-maintained first session lease. Similarly, the second service cluster can ensure that the validity period of the locally maintained second session lease is at least twice the validity period of the client-maintained second session lease.That is, for the client's first session lease (for example, 1 ease1), the first service cluster notifies the client that the first session lease is valid for, for example, 20 seconds, but the first service cluster locally records the first session lease as valid for 40 seconds (a double-time scenario). Similarly, for the client's second session lease (for example, 1 ease2), the second service cluster notifies the client that the second session lease is valid for, for example, 20 seconds, but the second service cluster locally records the second session lease as valid for 40 seconds (a double-time scenario). In this example, even if the first service cluster sends a heartbeat packet response message to the client only after half of the 40-second validity period of the first session lease has passed (reaching 20 seconds), the first service cluster determines that the client still holds the lock because the 40-second validity period has not yet expired, which matches the situation where the client's first session lease has been successfully renewed. In summary, with the primary-secondary lock design, the session lease validity period is determined not by the physical clock but by trusted relative time. This prevents physical clock drift from causing the client's session lease to expire later than the service cluster's session lease. Furthermore, by setting the service cluster's session lease validity period to at least twice that of the client's session lease, the impact of network latency on client session lease renewal can be reduced. Figure 9 is a flowchart of a distributed lock processing method provided by an embodiment of the present disclosure. This method can be executed by a client using the distributed lock service in the aforementioned embodiments. As shown in Figure 9, the method includes the following steps:

[0004] 901. A client obtains a first session lease from a first service cluster, and sends a first request for creating a lock to the first service cluster using the first session lease.

[0005] 902. The client obtains a second session lease from the second service cluster and sends a second request to create a lock to the second service cluster using the second session lease. Both the first service cluster and the second service cluster provide distributed lock services. The first session lease and the second session lease are respectively bound to a set validity period.

[0006] 903. If the client receives a lock creation success message sent by the first service cluster and a lock creation success message sent by the second service cluster, the client determines that the lock has been acquired. In an optional embodiment, the method further includes: if the client determines, based on the validity periods of the first session lease and the second session lease, that the target session lease has timed out, then determining to discard the lock, where the target session lease is the session lease that has timed out later than the first session lease or the second session lease. In an optional embodiment, regarding the timing of the session lease validity period, the client uses the moment of receipt of the lock creation success message sent by the first service cluster as a first timing starting point, and counts the validity period of the first session lease according to the CPU tick period. Furthermore, uses the moment of receipt of the lock creation success message sent by the second service cluster as a second timing starting point, and counts the validity period of the second session lease according to the CPU tick period. In an optional embodiment, in a master election and service discovery scenario, the second service cluster is configured to provide a service address registration service. Thus, when a client first creates a lock (i.e., grabs the lock) from the first service cluster and then creates a lock from the second service cluster, upon receiving a lock creation success message from the second service cluster, the client registers the service address with the second service cluster, allowing the client's access object to obtain the client's service address from the second service cluster. The following describes in detail the distributed lock processing apparatus of one or more embodiments of the present disclosure. Those skilled in the art will appreciate that these apparatuses can be constructed using commercially available hardware components and configured according to the steps taught in this solution. Figure 10 is a schematic diagram of the structure of a distributed lock processing apparatus provided by an embodiment of the present disclosure, which is applied to a client using a distributed lock service. As shown in Figure 10, the apparatus includes a first creation module 11, a second creation module 12, and a determination module 13. The first creation module 11 is configured to obtain a first session lease from the first service cluster and send a first request to create a lock to the first service cluster using the first session lease. A second creation module 12 is configured to obtain a second session lease from a second service cluster and send a second lock creation request to the second service cluster using the second session lease. Both the first and second service clusters provide distributed lock services, and the first and second session leases are each bound to a set validity period. A determination module 13 is configured to determine that the lock has been acquired upon receiving a lock creation success message from the first service cluster and a lock creation success message from the second service cluster. The apparatus shown in FIG10 can execute the steps performed by the client in the aforementioned embodiment. The detailed execution process and technical effects are described in the aforementioned embodiment and are not further elaborated here.In one possible design, the structure of the distributed lock processing device shown in FIG. 10 can be implemented as an electronic device. As shown in FIG. 11 , the electronic device may include: a processor 21, a memory 22, and a communication interface 23. Memory 22 stores executable code. When executed by processor 21, processor 21 can at least implement the distributed lock processing method provided in the aforementioned embodiments. Furthermore, embodiments of the present disclosure provide a non-transitory machine-readable storage medium storing executable code. When executed by a processor of an electronic device, the processor can at least implement the distributed lock processing method provided in the aforementioned embodiments. Embodiments of the present disclosure provide a computer program product including a computer program. When executed by a processor, the computer program can at least implement the distributed lock processing method provided in the aforementioned embodiments. The device embodiments described above are merely illustrative. The network elements described as separate components may or may not be physically separate. Some or all of these modules can be selected to achieve the objectives of the present embodiments according to actual needs. Persons of ordinary skill in the art can understand and implement the present embodiments without inventive effort. Through the description of the above embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by adding the necessary general hardware platform, or of course, by a combination of hardware and software. Based on this understanding, the essence of the above technical solutions, or the portion that contributes to the prior art, can be embodied in the form of a computer product. The present disclosure can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM (Compact Disk Read-Only Memory), optical storage, etc.) containing computer-usable program code. Finally, it should be noted that the above embodiments are merely illustrative of the technical solutions of the present disclosure, and are not intended to limit them. Although the present disclosure has been described in detail with reference to the aforementioned embodiments, those skilled in the art will understand that the technical solutions described in the aforementioned embodiments may be modified, or some of the technical features thereof may be replaced by equivalents. Such modifications or replacements do not deviate from the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present disclosure.

Claims

Claims 1. A distributed lock processing system, wherein, Including: A first service cluster and a second service cluster that provide a distributed lock service, and a client that uses the distributed lock service; the client is used to sequentially obtain a first session lease from the first service cluster, obtain a second session lease from the second service cluster, send a first request to create a lock to the first service cluster with the first session lease, send a second request to create a lock to the second service cluster with the second session lease, and determine that the lock is acquired when receiving the lock creation success messages sent by the first service cluster and the second service cluster respectively. The first session lease and the second session lease are respectively bound to a set validity period. The first service cluster is used to, in response to the first request, create a lock for the client when determining that no other client occupies the lock, and send a lock creation success message to the client. The second service cluster is used to, in response to the second request, create a lock for the client when determining that no other client occupies the lock, and send a lock creation success message to the client.

2. The system according to claim 1, wherein The client is used to determine to discard the lock if it is determined that the target session lease has timed out based on the validity periods of the first session lease and the second session lease, where the target session lease refers to the session lease that times out later among the first session lease and the second session lease.

3. The system according to claim 1 or 2, wherein The client is used to use the moment when it receives the lock creation success message sent by the first service cluster as the first timing start point, time the validity period of the first session lease according to the CPU tick period of the central processing unit (CPU), and use the moment when it receives the lock creation success message sent by the second service cluster as the second timing start point, time the validity period of the second session lease according to the CPU tick period.

4. The system according to claim 3, wherein The client is used to send a heartbeat packet to the first service cluster at a set time interval starting from the first timing start point, and reset the first timing start point to the moment when the response message is received if the response message feedback by the first service cluster is received; and send a heartbeat packet to the second service cluster at a set time interval starting from the second timing start point, and reset the second timing start point to the moment when the response message is received if the response message feedback by the second service cluster is received.

5. The system according to any one of claims 1-4, wherein The first service cluster is used to determine that the validity period of the first session lease maintained locally is at least twice the validity period of the first session lease maintained by the client; the second service cluster is used to determine that the validity period of the second session lease maintained locally is at least twice the validity period of the second session lease maintained by the client.

6. The system according to claim 5, wherein, The first service cluster is used to reset the third timing start point of the validity period of the first session lease maintained locally at the moment when the start heartbeat packet sent by the client is received, time the validity period of the first session lease maintained locally according to the CPU tick period, and delete the lock and the first session lease when it is determined that the first session lease maintained locally has timed out; The second service cluster is used to reset the fourth timing start point of the validity period of the second session lease maintained locally at the moment when the start heartbeat packet sent by the client is received, and time the validity period of the second session lease maintained locally according to the CPU tick period, and delete the lock and the second session lease when it is determined that the second session lease maintained locally has timed out.

7. The system according to any one of claims 1-6, wherein, The second service cluster is configured to provide a service address registration service; The client is used to register the service address with the second service cluster when receiving the lock creation success message sent by the second service cluster, so that the access object of the client can obtain the service address of the client from the second service cluster.

8. The system according to any one of claims 1-6, wherein, The system further includes at least one other service cluster that provides the distributed lock service; the client is used to determine that it has obtained the lock when receiving the lock creation success messages sent by at least the target number of service clusters after sending the lock creation request to each service cluster, and the target number is greater than half of the number of service clusters.

9. A distributed lock processing method, wherein Applied to a client using a distributed lock service, it includes: obtaining a first session lease from the first service cluster and sending a first request for creating a lock to the first service cluster with the first session lease; obtaining a second session lease from the second service cluster and sending a second request for creating a lock to the second service cluster with the second session lease. Both the first service cluster and the second service cluster provide a distributed lock service, and the first session lease and the second session lease are respectively bound to a set validity period; if receiving the lock creation success message sent by the first service cluster and the lock creation success message sent by the second service cluster, then determine that it has obtained the lock.

10. The method according to claim 9, wherein, The method further includes: if it is determined that the target session lease has timed out based on the validity periods of the first session lease and the second session lease, then determine to discard the lock, where the target session lease refers to the session lease that times out later among the first session lease and the second session lease.

11. The method according to claim 10, wherein, The method further includes: using the moment when the lock creation success message sent by the first service cluster is received as the first timing start point, and timing the validity period of the first session lease according to the central processing unit (CPU) tick period; using the moment when the lock creation success message sent by the second service cluster is received as the second timing start point, and timing the validity period of the second session lease according to the CPU tick period.

12. The method according to any one of claims 9 - 11, wherein The second service cluster is configured to provide a service address registration service; the method further includes: when receiving a successful lock creation message sent by the second service cluster, registering the service address with the second service cluster, so that the access object of the client can obtain the service address of the client from the second service cluster.

13. An electronic device, wherein, including: a memory, a processor, and a communication interface; wherein, on the memory, there is stored executable code, which, when executed by the processor, causes the processor to execute the distributed lock processing method according to any one of claims 9 to 12.

14. A non-transitory machine-readable storage medium, wherein, The non-transitory machine-readable storage medium stores executable code, which, when executed by the processor of an electronic device, causes the processor to execute the distributed lock processing method according to any one of claims 9 to 12.

15. A computer program product includes a computer program, which, when executed by a processor, implements the method according to any one of claims 9 to 12.

Images