Distributed lock management method and device, electronic equipment and storage medium

Abstract

The invention discloses a distributed lock management method and device, electronic equipment and a storage medium, and relates to the technical field of storage, the management method comprises the following steps: in response to lease overdue of a client, judging whether a server works normally or not; in response to normal work of the server, releasing a distributed lock held by the overdue client, and recording session information of the overdue client into a preset database to prohibit the overdue client from executing lock recovery; and in response to restarting of the server, notifying the metadata server to enter a delay period, determining a target client of which the lock state is not recovered after the delay period is ended, controlling the metadata server to clear lock information of a distributed lock held by the target client, and recording session information of the target client into a preset database, the technical problem that the unconditionally trusted client recovers the lock request after the server is restarted is solved, and the technical effect of guaranteeing the data consistency and reliability of the distributed file system in a fault scene is achieved.

Description

Technical Field

[0001] This application relates to the field of storage technology, and in particular to a distributed lock management method, apparatus, electronic device and storage medium. Background Technology

[0002] Network File System (NFS) is a widely used network file system protocol that can be used to share file data between different devices. While a device is using the NFS protocol, it may hold some exclusive or shared resources.

[0003] To ensure the continuity and security of file services, the NFS protocol stipulates that during server failure recovery, a grace period must first be entered. During this grace period, the client and server re-establish the NFS protocol session, and the client re-requests the resources it held before the server failure. However, because the server has lost information after the restart, it cannot determine which client to trust, and if multiple clients hold locks, it is prone to incorrectly restoring the lock state. Summary of the Invention

[0004] This application provides a distributed lock management method, apparatus, electronic device, and storage medium to at least address the problem of the lack of trusted client verification in related technologies.

[0005] In a first aspect, this application provides a distributed lock management method, comprising: a server receiving lock requests from multiple clients, allocating distributed locks to clients and setting leases, and controlling a metadata server to store lock information of clients and their allocated distributed locks; in response to a client's lease expiring, determining whether the server is functioning normally; in response to the server functioning normally, releasing the distributed lock held by the expired client and recording the session information of the expired client in a preset database to prevent the expired client from performing lock recovery; in response to a server restart, notifying the metadata server to enter a delay period, identifying the target client whose lock state has not been recovered after the delay period, controlling the metadata server to clear the lock information of the distributed lock held by the target client, and recording the session information of the target client in the preset database.

[0006] Secondly, this application also provides a distributed lock management device, comprising: an allocation module, configured to receive lock requests from multiple clients, allocate distributed locks to clients and set leases, and control a metadata server to store lock information of clients and their allocated distributed locks; a judgment module, configured to determine whether the server is working normally in response to the lease expiration of a target client; a first processing module, configured to release the distributed lock held by the expired client in response to the server working normally, and record the session information of the expired client in a preset database to prevent the expired client from performing lock recovery; and a second processing module, configured to notify the metadata server to enter a delay period in response to a server restart, identify the target client whose lock state has not been recovered after the delay period ends, control the metadata server to clear the lock information of the distributed lock held by the target client, and record the session information of the target client in the preset database.

[0007] Thirdly, this application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of the distributed lock management method in the following embodiments: the server receives lock requests from multiple clients, allocates distributed locks to the clients and sets leases, and controls the metadata server to store lock information of the clients and the distributed locks they are allocated; in response to a client's lease expiring, it determines whether the server is working normally; in response to the server working normally, it releases the distributed lock held by the expired client and records the session information of the expired client in a preset database to prevent the expired client from performing lock recovery; in response to a server restart, it notifies the metadata server to enter a delay period, and after the delay period ends, it identifies the target client whose lock state has not been recovered, controls the metadata server to clear the lock information of the distributed lock held by the target client, and records the session information of the target client in the preset database.

[0008] Fourthly, this application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the distributed lock management method in the following embodiments: the server receives lock requests from multiple clients, allocates distributed locks to clients and sets leases, and controls the metadata server to store lock information of clients and their allocated distributed locks; in response to a client's lease expiring, it determines whether the server is working normally; in response to the server working normally, it releases the distributed lock held by the expired client and records the session information of the expired client in a preset database to prevent the expired client from performing lock recovery; in response to a server restart, it notifies the metadata server to enter a delay period, and after the delay period ends, it identifies the target client whose lock state has not been recovered, controls the metadata server to clear the lock information of the distributed lock held by the target client, and records the session information of the target client in the preset database.

[0009] This application addresses the technical problem of unconditionally trusting client lock recovery requests after a server restart, thus preventing lock state recovery errors. By promptly releasing expired locks from clients during normal server operation and adding their session information to the database for blacklisting, and by notifying the metadata server to enter a delay period upon server restart and clearing the lock information of unrecovered target clients after the delay, and also blacklisting them, only clients in a normal state can recover their locks. This avoids lock state recovery errors caused by the server's inability to determine client identity after a restart. Therefore, it achieves the technical effect of ensuring data consistency and reliability of the distributed file system under fault scenarios. Attached Figure Description

[0010] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A flowchart illustrating a distributed lock management method provided in an embodiment of this application;

[0012] Figure 2 A flowchart illustrating a distributed lock management process provided in an embodiment of this application;

[0013] Figure 3 A structural block diagram of a distributed lock management device provided in an embodiment of this application;

[0014] Figure 4 This is an internal structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0015] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0016] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0017] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0018] Early distributed file lock implementations primarily relied on NFSv3 (Network File System) and NLM (Network Lock Manager) to control concurrent access to shared files in a distributed environment and prevent conflicts caused by multiple clients modifying files simultaneously. NFSv3 itself does not maintain state information; it manages file locks in a distributed environment by integrating NLM. Clients send lock requests to the NLM server, which is responsible for maintaining the file's lock state, thus preventing conflicts caused by multiple clients modifying files simultaneously. However, this combination of a stateless file system protocol and a network lock manager is prone to lock loss or deadlocks in failure scenarios (such as network disconnection or server restart), failing to meet the requirements of high-reliability scenarios.

[0019] As a stateful file system protocol, NFSv4 integrates file locking functionality into the protocol itself. The server tracks the client's file locking and opening status information. The client and server manage these states through a lease mechanism, and the client needs to periodically renew its lease with the server to maintain the validity of the state. NFSv4 file locking introduces a lease and recovery lock mechanism to solve the problem of lock state recovery in the event of server or client failures.

[0020] The lease mechanism employs leased locks, each with the same lease period. Client read and write operations refresh the lease period, and the server releases the lock upon expiration. During the grace period after a server restart, clients can create sessions, but locking requests are restricted; the lock state can only be re-established through a recovery request.

[0021] While NFSv4's lease and restore lock mechanisms can mitigate server-side and client-side anomalies and ensure data consistency to some extent, problems still exist in complex scenarios. For example, when multiple clients hold locks, if the first client experiences a network failure, the server cannot communicate with it. After the lease expires, the server releases the first client's lock and authorizes it to the second client. At this point, the lock state information on the server has been updated to show that the second client holds the lock. When the server restarts and enters a delay period, both the first and second clients may restore their respective lock states through the restore lock mechanism. Since the server loses all previous state information after restarting, it cannot determine which client should be trusted and will unconditionally assign new lock states to both clients based on the received restore request, thus posing a risk of restore errors.

[0022] To address the aforementioned issues, this application proposes to perform trust verification on the client, blacklist untrusted clients, and prohibit them from performing lock recovery operations.

[0023] The specific application environment architecture or specific hardware architecture on which the execution of the distributed lock management method depends is described here.

[0024] The distributed lock management method in this application is primarily applied to an architecture based on Ganesha+Ceph. In this architecture, Ganesh (Network File Service Unit) acts as the NFS (Network File System) server, responsible for handling client file operation requests, including lock acquisition and management. Ceph is a distributed storage system that provides highly reliable and high-performance storage services for storing file data and metadata. The Metadata Server (MDS) is used to manage file system metadata in Ceph, including file lock information, client session information, etc.

[0025] The embodiments of this application provide a distributed lock management method, and the method is described in detail in conjunction with the execution flow of the distributed lock management method.

[0026] In one embodiment, such as Figure 1 As shown, a distributed lock management method is provided, including the following steps:

[0027] S1: The server receives lock requests from multiple clients, allocates distributed locks to the clients and sets leases, and controls the metadata server to store lock information between the clients and the distributed locks they are allocated.

[0028] In an optional implementation, the server receives lock requests from multiple clients, allocates distributed locks to the clients, and sets leases, including: the server establishing sessions with multiple clients and assigning identification information to each client, the identification information being used to uniquely identify the client in the session; receiving file access requests sent by clients carrying identification information, and determining the target file requested by the client based on the file access request; obtaining the file handle of the target file and returning it to the client; receiving a first locking request sent by the client based on the file handle, allocating a distributed lock to the target file, and establishing a lease.

[0029] Each communication between the client and server establishes a session, generating a unique client ID as identification information. This identification information is used to uniquely identify the client during the session, and subsequent operations will also use this client ID as a unique identifier. Each client's client ID is represented by an 8-byte 64-bit number, and each client's client ID has a lease function. That is, if the client does not perform any status request operations, such as locking, unlocking, or closing, within the lease validity period on the server, the client ID will become invalid.

[0030] Specifically, the client sends a file access request carrying identification information to the server. Upon receiving the request, the server parses the identification information to identify the corresponding client, determines the target file the client wants to access, and obtains the file handle of the target file. This handle is the necessary credential for accessing the file, and is then returned to the client. When the client sends its first locking request to the server based on the obtained file handle, the server allocates a distributed lock for the target file, ensuring that only one client can perform a specific operation on the target file at a time. Simultaneously, a lease is set for this lock, specifying the duration for which the client can hold the lock. During the lease period, the client can normally hold and use the lock.

[0031] Based on the above steps, by assigning unique identification information to each client, exclusive access to files in a distributed environment is ensured, preventing multiple clients from simultaneously performing conflicting operations on the same file. The lease mechanism sets a time limit for lock holding, ensuring that clients use the lock within the specified time, avoiding permanent lock occupation, and improving resource utilization.

[0032] In an optional implementation, a first locking request sent by a client is received, the first locking request carrying lease information and at least one target file corresponding to the lease information; conflict type configuration information is obtained to determine whether there is a conflict between the distributed locks; based on the conflict type configuration information, it is determined whether to lock the target file; if there is no conflict, the target file is locked; if there is a conflict, the target file is not locked; after successful locking, the lease status of all locks is checked periodically; if there is a lock waiting to be renewed that is in a timeout state, and there are threads that have not timed out sharing the lock waiting to be renewed, then a request is sent to the middle of the distributed locks. The system sends lock renewal requests to the distributed lock middleware to update the lock state of locks to be renewed; it retrieves a pre-configured linked list; it treats each element in the linked list as a bucket and stores lease information in the buckets according to their expiration times; when a lock renewal request is received, it retrieves the lease information of the lock corresponding to the renewal request from the bucket in the linked list and moves it to a new bucket to update the lock lease information; it stores the lease information of multiple locks with expiration times within a preset range in the same bucket in the linked list; it periodically checks whether the lease information in the buckets of the linked list has expired, and if it has expired, it releases all locks corresponding to the lease information in the entire bucket.

[0033] Specifically, the lease information refers to the lock's timeout period, which can be represented using a random, non-repeating string. The lease information can be stored in a pre-defined linked list in order of expiration time; updating the position of each element in the linked list updates the lock's lease information.

[0034] By pre-configuring the conflict types between different locks, such as allowing read locks to be non-conflicting, write locks to be conflicting, and read locks to be conflicting, the system determines whether to send a lock request based on the configured conflict type during locking. This allows non-conflicting distributed locks to be used simultaneously, reducing unnecessary conflicts and contention during locking and effectively reducing lock granularity. Furthermore, a single lock request can support a lease locking multiple target files simultaneously, reducing network transmissions and data volume, saving network bandwidth, and facilitating flexible configuration for batch locking to achieve various locking strategies, such as acquiring all locks or acquiring as many locks as possible.

[0035] S2 responds to the existence of client lease expiration and determines whether the server is working properly.

[0036] In an optional implementation, the method further includes: assigning state information to the client based on the client's identification information and the number of session requests, so that the client carries the state information when requesting the server; periodically checking the lease status of each client; extending the client's lease for a preset duration in response to receiving a read / write request from the client within the lease period; and determining that the client's lease has expired in response to not receiving a read / write request from the client within the lease period.

[0037] When a client successfully acquires a lock, the server returns a state ID to the client as status information, used to identify the lock or a group of locks. This state ID is composed of the client ID and the cumulative number of requests associated with that client ID session. Each state ID identifies an open file, and each state ID is associated with a specific lock holder and a specific file. Furthermore, at most one state ID can be associated with a specific lock holder and file. A lock holder cannot open the same file multiple times, and locking, reading, writing, and file truncation operations all require a state ID.

[0038] A lease is an agreement between the server and the client to ensure that the client can hold and use the distributed lock normally for a specified period. The server sets a lease for each lock, typically in time units, such as 15 seconds or 30 seconds. Once a client successfully acquires the lock, it has the right to use it, and other clients cannot perform conflicting operations on the file during this period. If a client fails to send a renewal request within the lease's validity period, the server determines that the client's lease has expired, assuming the client may have encountered an abnormal situation, such as network failure or crash. In this case, the server will take appropriate measures, such as releasing the lock, so that other clients can acquire the lock and continue operating on the file.

[0039] Based on the above steps, the lease mechanism ensures the stability of the system and the efficient use of resources, avoiding the waste or blockage of the entire system's resources due to the abnormality of a single client.

[0040] S3, in response to the server working normally, releases the distributed lock held by the expired client and records the session information of the expired client in the preset database to prevent the expired client from performing lock recovery.

[0041] In an optional implementation, the session information of the expired client is recorded in a preset database, including: pre-establishing a database of a distributed file system on the server, the database being used to store a distributed lock blacklist; wherein, the distributed lock blacklist is used to prohibit the client from sending a recovery request; in response to the existence of a client's lease expiration and the server working normally, the session information of the expired client is added to the distributed lock blacklist; wherein, the session information includes identification information.

[0042] Specifically, the server pre-establishes a distributed file system database to store a distributed lock blacklist. This blacklisted clients are prohibited from sending recovery requests, preventing them from restoring the lock state after their leases expire. When the server detects an expired client's lease and is functioning normally, it adds the expired client's identifier to the distributed lock blacklist, thereby identifying and prohibiting the expired client from performing lock recovery operations, ensuring the normal operation of the system and normal access for other clients.

[0043] Based on the above steps, untrusted clients are added to the database and blacklisted to prevent them from performing lock recovery. This effectively avoids data inconsistencies or other conflicts caused by expired clients reacquiring the lock, thus maintaining the order and efficiency of distributed lock management.

[0044] S4, in response to a server restart, notifies the metadata server to enter a delay period. After the delay period ends, it identifies the target client that has not recovered its lock state, controls the metadata server to clear the lock information of the distributed lock held by the target client, and records the target client's session information in a preset database.

[0045] In an optional implementation, the metadata server is notified to enter a delay period. After the delay period ends, the target client whose lock state has not been restored is identified, including: in response to receiving a restoration request from the client during the delay period, matching the identification information carried in the restoration request with a preset database to determine whether the identification information exists in the distributed lock blacklist; in response to the absence of identification information in the distributed lock blacklist, allowing the client to perform lock restoration; receiving a release request returned by the metadata server; controlling the metadata server to release the distributed lock and lease held by the client, and returning a first response message to the metadata server, wherein the first response message is used to instruct the metadata server to delete the distributed lock; generating new identification information and status information for the client, and receiving a second locking request sent by the client based on the new status information, wherein the second locking request is used to instruct the client to restore the lock state of the distributed lock held by the client; in response to the presence of identification information in the distributed lock blacklist, designating the client as the target client, and returning an error message to the target client, wherein the error message is used to instruct the target client not to perform lock restoration.

[0046] The process of recovering from a server failure or client failure during the establishment of a communication connection and data transmission between the server and client can be collectively referred to as the file system failure recovery delay period. This period is to give the client a buffer time to restore the previous lock state. The client can send a recovery request during the delay period to attempt to re-establish the session and lock state with the server. In this embodiment, the server's failure recovery process can be preferred as the delay period. During this period, client requests such as creating identification information sessions will be processed normally, but locking requests are restricted; only recovery requests are allowed.

[0047] Specifically, the client sends a client ID with each request. The server needs to query the database of the distributed file system to see if the client ID in the request has been blacklisted. If the query finds the client ID, it means that the client has been blacklisted, and the server will reply with the NFS4ERR_EXPIRED error code, and the client will not attempt to recover the lock. If the server replies with the NFS4ERR_BADSESSION error code, the client will attempt to recover the lock.

[0048] For example, when client A and client B simultaneously hold a distributed lock on a target file, and both clients recover their networks at the same time, both clients will send a session request. Normally, if both clients respond with NFS4ERR_BADSESSION, they will re-establish a session and recover the lock. However, a blacklist check is added. The clientid field in the recovery request is checked. If the client is in the blacklist, it needs to respond with NFS4ERR_EXPIRED. In this case, client A will reconnect to the session but will not send a reconnection request, thus ensuring that only client B recovers the lock state.

[0049] Specifically, by comparing the client's identification information with the distributed lock blacklist, the server can identify which clients should not reacquire the lock due to lease expiration or other abnormal situations. This prevents abnormal clients from reacquiring the lock, avoiding potential data conflicts and inconsistencies. For trusted clients, the server generates new identification and status information, allowing them to restore the lock state and ensuring that the client can continue its unfinished operations, while maintaining the continuity and reliability of the system.

[0050] In an optional implementation, after returning the error information to the target client, the method further includes: performing a re-verification on the target client to determine whether the working state of the target client has returned to normal; and in response to the target client returning to normal, removing the original session information of the target client from the distributed lock blacklist.

[0051] Specifically, when a client discovers it has been blacklisted, if the client itself is functioning normally, and the lease expired due to a temporary network issue, or if the related fault has been fixed, the server, after returning an error message to the target client, will initiate a re-verification mechanism to determine if the target client's working status has returned to normal. This can be done by sending a heartbeat signal or requesting a simple task to verify its responsiveness. If the verification passes, it means the client has returned to normal working status and is now trustworthy. Therefore, its client ID can be removed from the blacklist, allowing it to establish new sessions and acquire lock resources normally.

[0052] Based on the above steps, the system can dynamically respond to changes in the client's state, ensuring that once the client's problem is resolved, it can regain access to and operation of the distributed lock, thus not affecting its subsequent normal operation.

[0053] In an optional implementation, controlling the metadata server to clear the lock information of the distributed lock held by the target client includes: in response to receiving a release request for a lock to be released held by the target client, checking whether there is any state information of the lock to be released locally on the server; in response to not having any, returning a release success message; in response to having any, clearing the thread holding the lock to be released and the state information of the lock to be released, and determining whether the lock to be released is occupied by another thread after clearing; in response to no other thread occupying the lock to be released, returning a second response message to the metadata server, wherein the second response message is used to instruct the metadata server to delete the lock to be released; in response to other threads occupying the lock to be released, feeding back a lock release success message.

[0054] Specifically, when the server receives a release request for a lock to be released, it first checks locally whether the lock's status information exists. If the status information does not exist, it means the release operation has been completed locally, and the server directly returns a release success message to the client. If the server finds a lock status information to be released, it performs a clearing operation, removing the thread and status information corresponding to the lock to be released. After clearing, it further checks whether the lock to be released is held by another thread. If no other thread holds the lock, the server instructs the metadata server to delete the corresponding lock record to ensure that the lock information is synchronously cleared in all storage locations. If another thread holds the lock to be released, to avoid affecting other normally running threads, the server directly reports a lock release success message without performing any further forced clearing operations on the lock.

[0055] Based on the above steps, the release process of distributed locks can be effectively managed, ensuring the correct reclamation of lock resources and the consistency of system state.

[0056] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0057] Embodiments of this application also provide a distributed lock management device, including an allocation module, a judgment module, a first processing module, and a second processing module, wherein: the allocation module is used to receive lock requests from multiple clients, allocate distributed locks to clients and set leases, and control the metadata server to store lock information of clients and their allocated distributed locks; the judgment module is used to determine whether the server is working normally in response to the expiration of the lease of a target client; the first processing module is used to release the distributed lock held by the expired client in response to the server working normally, and record the session information of the expired client in a preset database to prevent the expired client from performing lock recovery; the second processing module is used to notify the metadata server to enter a delay period in response to a server restart, identify the target client whose lock state has not been recovered after the delay period ends, control the metadata server to clear the lock information of the distributed lock held by the target client, and record the session information of the target client in the preset database.

[0058] In one embodiment, the allocation module is further configured to establish sessions with multiple clients and allocate identification information to each client, the identification information being used to uniquely identify the client in the session; receive file access requests carrying identification information sent by clients and determine the target file requested by the client based on the file access requests; obtain the file handle of the target file and return it to the client; receive the first locking request sent by the client based on the file handle, allocate a distributed lock for the target file, and establish a lease.

[0059] In one embodiment, the management device further includes a checking module, configured to allocate status information to clients based on the client's identification information and the number of client session requests, so that the client carries the status information when requesting the server; periodically check the lease status of each client; extend the client's lease for a preset duration in response to receiving a read / write request from the client within the lease period; and determine that the client's lease has expired in response to not receiving a read / write request from the client within the lease period.

[0060] In one embodiment, the first processing module is further configured to pre-establish a database of the distributed file system on the server, the database being used to store a distributed lock blacklist; wherein, the distributed lock blacklist is used to prohibit clients from sending recovery requests; in response to a client's lease expiring and the server working normally, the session information of the expired client is added to the distributed lock blacklist; wherein, the session information includes identification information.

[0061] In one embodiment, the second processing module is further configured to: respond to receiving a recovery request from the client during the delay period; match the identification information carried in the recovery request with a preset database to determine whether the identification information exists in the distributed lock blacklist; allow the client to perform lock recovery in response to the absence of identification information in the distributed lock blacklist; receive a release request returned by the metadata server; control the metadata server to release the distributed lock and lease held by the client, and return a first response message to the metadata server, wherein the first response message is used to instruct the metadata server to delete the distributed lock; generate new identification information and status information for the client, and receive a second locking request sent by the client based on the new status information, wherein the second locking request is used to instruct the client to restore the lock status of the distributed lock held by the client; and, in response to the presence of identification information in the distributed lock blacklist, designate the client as the target client and return an error message to the target client, wherein the error message is used to instruct the target client not to perform lock recovery.

[0062] In one embodiment, the management device further includes a verification module for performing a re-verification on the target client to determine whether the working status of the target client has returned to normal; and in response to the target client returning to normal, removing the original session information of the target client from the distributed lock blacklist.

[0063] In one embodiment, the second processing module is further configured to, in response to receiving a release request for a lock to be released held by the target client, check whether there is any status information for the lock to be released locally on the server; in response to the absence of the lock, return a release success message; in response to the presence of the lock, clear the thread holding the lock and the status information of the lock to be released, and determine whether the lock to be released is occupied by another thread after clearing; in response to no other thread occupying the lock to be released, return a second response message to the metadata server, wherein the second response message is used to instruct the metadata server to delete the lock to be released; in response to the presence of another thread occupying the lock to be released, provide feedback on a lock release success message.

[0064] For a description of the features in the embodiments corresponding to the distributed lock management device, please refer to the relevant descriptions in the embodiments corresponding to the distributed lock management method; they will not be repeated here. Each module in the above-mentioned distributed lock management device can be implemented entirely or partially through software, hardware, or a combination thereof. Each module can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0065] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above embodiments of the distributed lock management method.

[0066] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described embodiments of the distributed lock management method when running.

[0067] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0068] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described distributed lock management method embodiments.

[0069] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described distributed lock management method embodiments.

[0070] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0071] The above provides a detailed description of a distributed lock management method, apparatus, electronic device, and storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A distributed lock management method, characterized in that, The distributed lock management method includes: The server receives lock requests from multiple clients, allocates distributed locks to the clients and sets leases, and controls the metadata server to store lock information of the clients and the distributed locks they are allocated; In response to a client's lease expiring, determine whether the server is functioning correctly; In response to the server working normally, the distributed lock held by the expired client is released, and the session information of the expired client is recorded in a preset database to prevent the expired client from performing lock recovery. In response to a server restart, the metadata server is notified to enter a delay period. After the delay period ends, the target client that has not recovered its lock state is identified, and the metadata server is controlled to clear the lock information of the distributed lock held by the target client and record the session information of the target client in the preset database.

2. The distributed lock management method according to claim 1, characterized in that, The server receives lock requests from multiple clients, allocates distributed locks to the clients, and sets leases, including: The server establishes sessions with multiple clients and assigns identification information to each client, the identification information being used to identify the client in the session; Receive a file access request sent by the client carrying the identification information, and determine the target file that the client requests to access based on the file access request; Obtain the file handle of the target file and return it to the client; The system receives the first locking request sent by the client based on the file handle, allocates a distributed lock for the target file, and establishes a lease.

3. The distributed lock management method according to claim 2, characterized in that, The distributed lock management method further includes: allocating state information to the client based on the client's identification information and the number of session requests of the client, so that the client carries the state information when requesting the server; Regularly check the lease status of each client; In response to receiving a read / write request from the client within the lease period, the lease of the client is extended for a preset duration; in response to not receiving a read / write request from the client within the lease period, the lease of the client is determined to have expired.

4. The distributed lock management method according to claim 1, characterized in that, The step of recording the session information of the overdue client into a preset database includes: A pre-established database for a distributed file system is created on the server. This pre-established database is used to store a distributed lock blacklist. The distributed lock blacklist is used to prevent clients from sending recovery requests. In response to a client's lease expiring while the server is functioning normally, the session information of the expired client is added to the distributed lock blacklist; wherein, the session information includes identification information.

5. The distributed lock management method according to claim 1, characterized in that, The notification metadata server enters a delay period, and after the delay period ends, it identifies the target clients that have not restored the lock state, including: In response to receiving a recovery request from the client during the delay period, the identification information carried in the recovery request is matched with a preset database to determine whether the identification information exists in the distributed lock blacklist; In response to the fact that the identifier information is not in the distributed lock blacklist, the client is allowed to perform lock recovery; Receive the release request returned by the metadata server; The metadata server is controlled to release the distributed lock and lease held by the client, and a first response message is returned to the metadata server, wherein the first response message is used to instruct the metadata server to delete the distributed lock; Generate new identification information and status information for the client, and receive a second locking request sent by the client based on the new status information, wherein the second locking request is used to indicate the restoration of the lock state of the distributed lock held by the client; In response to the presence of the identification information in the distributed lock blacklist, the client is designated as the target client, and an error message is returned to the target client, wherein the error message is used to instruct the target client not to execute the recovery lock.

6. The distributed lock management method according to claim 5, characterized in that, After returning the error message to the target client, the method further includes: Perform a re-verification on the target client to determine whether the target client's working status has returned to normal. In response to the target client returning to normal, the original session information of the target client is removed from the distributed lock blacklist.

7. The distributed lock management method according to claim 5, characterized in that, The step of controlling the metadata server to clear the lock information of the distributed lock held by the target client includes: In response to receiving a release request for a lock to be released held by the target client, check whether the server locally has the status information of the lock to be released; If the item does not exist, return a message indicating successful release. In response to the existence of the lock, the thread to be released and the state information of the lock to be released are cleared, and it is determined whether the lock to be released is occupied by other threads after the clearing. In response to the absence of any other thread holding the lock to be released, a second response message is returned to the metadata server, wherein the second response message is used to instruct the metadata server to delete the lock to be released; If another thread is holding the lock to be released, a message indicating that the lock was successfully released is sent.

8. A distributed lock management device, characterized in that, The distributed lock management device includes: The allocation module is used to receive lock requests from multiple clients, allocate distributed locks to the clients and set leases, and control the metadata server to store the lock information of the clients and the distributed locks they are allocated. The judgment module is used to determine whether the server is working properly in response to the lease expiration of the target client. The first processing module is used to release the distributed lock held by the expired client in response to the server working normally, and record the session information of the expired client in a preset database to prevent the expired client from performing lock recovery; The second processing module is used to respond to the server restart, notify the metadata server to enter a delay period, determine the target client that has not recovered the lock state after the delay period ends, control the metadata server to clear the lock information of the distributed lock held by the target client, and record the session information of the target client in the preset database.

9. An electronic device, characterized in that, The electronic device includes: Memory, used to store computer programs; A processor, configured to implement the steps of the distributed lock management method as described in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the distributed lock management method as described in any one of claims 1 to 7.

Images