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 distributed systems. When the lock client detects a to-be-processed task, acquiring corresponding lock object information; the lock object information comprises a lock number, locker identification information, a lock version number and a version number of a lock lease period. The version number of the lock lease period is determined based on the monotonous clock value of the monotonous clock, and the problem of double writing of the same resource by double controllers is solved. The lock server comprises a master server and a slave server, the collating group adopts a copy mode, and each lock server has a corresponding copy used for recording a lock state. When the lock client operates a certain lock instance, the lock client only needs to communicate with the main server to initiate the lock operation request to the main server, the main server can execute the corresponding operation in combination with the lock state recorded in the arrangement group and feed back the lock operation result to the lock client, a new distributed cluster does not need to be introduced in the whole implementation process, and the operation and maintenance complexity is effectively reduced.

Description

Technical Field

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

[0002] Currently, distributed lock implementations can be mainly categorized into three types: implementations based on remote dictionary services (Redis), implementations based on distributed coordination service frameworks (ZooKeeper), and non-open-source implementations.

[0003] These locks typically use the system clock as their time reference. When a lock expiration time is set, if there is a synchronization or jump in the system clock, or if the lock client and server are on different servers and there is a system clock deviation, the lock expiration time may be earlier or later than expected for the client. It is impossible to design business processes with precise expiration times. Especially in scenarios that require strict and precise time boundaries, such as split-brain processing, the inaccuracy of the expiration time may lead to serious consequences such as data inconsistency problems and split-brain double-write problems.

[0004] In current distributed lock implementations, lock clients need to communicate with multiple nodes in the cluster that maintain the lock state. Typically, a majority of nodes must succeed in their lock requests for the lock to be successful, and the lock request itself is a multi-stage transaction request. With this design, lock performance is difficult to guarantee, especially in unstable environments such as network fluctuations or packet loss, which can easily lead to continuous lock acquisition failures. Furthermore, when using these lock services, it is necessary to maintain a ZooKeeper or Redis cluster, significantly increasing operational complexity and costs.

[0005] It is evident that improving the accuracy of lock management and reducing operational complexity are problems that need to be addressed by those skilled in the art. Summary of the Invention

[0006] The purpose of this application is to provide a method, apparatus, electronic device, and storage medium for distributed lock management, which can improve the accuracy of lock management and reduce the complexity of operation and maintenance.

[0007] This application provides a method for distributed lock management, applicable to lock clients, the method including:

[0008] Upon detecting a pending task, the corresponding lock object information is obtained; the lock object information includes the lock number, lock acquirer identification information, lock version number, and lock lease period version number; the lock lease period version number is determined based on the monotonic clock value of the lock client;

[0009] Based on the task type and lock object information of the task to be processed, a lock operation request is sent to the main server of the lock service so that the main server can perform the lock operation and determine the lock operation result according to the lock operation request and the lock status recorded in the placement group, and then send the lock operation result back to the lock client.

[0010] Obtain the lock operation result from the main server and execute the corresponding receipt operation.

[0011] On the one hand, based on the task type of the task to be processed and the lock object information, a lock operation request is initiated to the main server of the lock service, including:

[0012] If the task type to be processed is a locking task, a locking request carrying lock object information is sent to the main server, and the local monotonic clock value is recorded.

[0013] If the task type to be processed is a renewal task, a renewal request carrying lock object information is sent to the main server, and the local monotonic clock value is recorded.

[0014] If the task type to be processed is an unlocking task, send an unlocking request carrying lock object information to the main server.

[0015] On the one hand, when the lock operation request is a lock acquisition request, the lock operation result returned by the main server is obtained, and a corresponding receipt operation is executed, including:

[0016] If the lock operation results in successful locking, record the lock lease expiration time based on the monotonic clock value recorded when the lock request was sent and the lock validity period; start the lease refresh scheduled task and send a successful locking response message to the business component;

[0017] If the lock operation results in the lock being preempted or the lock being refused, a lock acquisition failure response message should be sent to the business component.

[0018] If the lock operation result is "service busy", wait for the set time and then re-initiate the lock request;

[0019] If the lock operation results in a request timeout, set the client lease timeout flag based on the lock acquirer's identifier information and send a lock acquisition failure response message to the business component.

[0020] If the lock operation results in an internal service error, a lock acquisition failure response message is sent to the business component.

[0021] On the one hand, when the lock operation request is a renewal request, the lock operation result fed back by the main server is obtained, and a corresponding receipt operation is executed, including:

[0022] If the lock operation results in a successful renewal, the lock lease expiration time is updated based on the monotonic clock value recorded when the renewal request was sent and the renewal validity period, and the next renewal event is registered.

[0023] If the lock operation results in the lock being preempted, stop the lease refresh scheduled task; send a preempted lock response message to the business component and initiate an unlock request;

[0024] If the lock operation result is "service busy", wait for the set time and then re-initiate the renewal request;

[0025] If the lock operation results in a request timeout or an internal service error, register the next renewal event, and if the local lease times out, send a response message to the business component that the lock has expired.

[0026] If the lock operation results in a refusal to renew the lease, stop the lease refresh scheduled task and send a response message to the business component indicating that the lock has expired.

[0027] On the one hand, when the lock operation request is an unlock request, the lock operation result fed back by the main server is obtained, and a corresponding receipt operation is executed, including:

[0028] If the lock operation results in successful unlocking, a successful unlocking response message is sent to the business component.

[0029] If the lock operation result is "service busy", wait for the set time and then re-initiate the unlock request;

[0030] If the lock operation results in a request timeout, set a client timeout flag for the lease and report a timeout error code to the business component;

[0031] If the lock operation results in an internal service error, an internal error code is sent back to the business component.

[0032] This application also provides a method for distributed lock management, applicable to the main server, the method including:

[0033] Receive lock operation requests initiated by lock clients, which carry lock object information; wherein, lock object information includes lock number, locker identification information, lock version number, and lock lease period version number; the lock lease period version number is determined based on the monotonic clock value of the lock client;

[0034] Based on the lock operation request and the lock status recorded in the reset group, execute the lock operation and determine the lock operation result;

[0035] The lock operation results are fed back to the lock client so that the client can execute a acknowledgment operation that matches the lock operation results.

[0036] On the one hand, before executing the lock operation and determining the lock operation result based on the lock operation request and the lock state recorded in the reset group, it also includes:

[0037] Determine whether the lock acquirer identifier information carried in the lock operation request is the same as the lock acquirer identifier information of the current lock;

[0038] If the lock acquirer identifier information carried in the lock operation request is different from the lock acquirer identifier information of the current lock, determine whether the lock version number carried in the lock operation request is greater than the lock version number of the current lock.

[0039] If the locker identifier information carried in the lock operation request is different from the locker identifier information of the current lock and the lock version number carried in the lock operation request is greater than the lock version number of the current lock, then perform the operation steps of executing the lock operation and determining the lock operation result according to the lock operation request and the lock status recorded in the placement group.

[0040] If the lock acquirer identifier information carried in the lock operation request is the same as the lock acquirer identifier information of the current lock, determine whether the lock version number carried in the lock operation request is greater than the lock version number of the current lock, or whether the lock version number carried in the lock operation request is equal to the lock version number of the current lock and whether the version number of the lock lease period carried in the lock operation request is greater than or equal to the version number of the lock lease period of the current lock.

[0041] If the lock version number carried in the lock operation request is greater than the lock version number of the current lock, or if the lock version number carried in the lock operation request is equal to the lock version number of the current lock and the version number of the lock lease period carried in the lock operation request is greater than or equal to the version number of the lock lease period of the current lock, then the operation steps of performing the lock operation and determining the lock operation result are executed according to the lock operation request and the lock state recorded in the placement group.

[0042] On the one hand, it also includes:

[0043] When the primary server becomes the new primary server after a master-slave server switch, acquire the lock status;

[0044] If the lock is in the released state, set the remaining lock validity period recorded locally to zero;

[0045] When the lock is in a locked state, adjust the remaining lock validity period recorded locally based on the remaining lock validity period recorded locally and the remaining lock validity period returned from each server; update the lock lease expiration time based on the current monotonic clock value and the adjusted remaining lock validity period.

[0046] On the one hand, based on the remaining lock validity period recorded locally and the remaining lock validity period returned from the server, the remaining lock validity period recorded locally is adjusted, including:

[0047] The minimum of the locally recorded remaining lock validity period and the remaining lock validity period returned from the server is used as the adjusted remaining lock validity period.

[0048] This application also provides a distributed lock management device, applicable to lock clients, the device including an information acquisition unit, an initiation unit, and an execution unit;

[0049] The information acquisition unit is used to acquire the corresponding lock object information when a task to be processed is detected; wherein, the lock object information includes lock number, locker identification information, lock version number and lock lease period version number; the lock lease period version number is determined based on the monotonic clock value of the lock client;

[0050] The initiating unit is used to initiate a lock operation request to the main server of the lock service based on the task type of the task to be processed and the lock object information, so that the main server can execute the lock operation and determine the lock operation result according to the lock operation request and the lock status recorded in the placement group, and then feed back the lock operation result to the lock client.

[0051] The execution unit is used to obtain the lock operation results fed back by the main server and execute the acknowledgment operation that matches the lock operation results.

[0052] This application also provides a distributed lock management device, suitable for the main server, the device including a receiving unit, a determining unit and a feedback unit;

[0053] The receiving unit is used to receive lock operation requests initiated by the lock client, which carry lock object information. The lock object information includes the lock number, locker identification information, lock version number, and lock lease period version number. The lock lease period version number is determined based on the monotonic clock value of the lock client.

[0054] The determining unit is used to perform a lock operation and determine the lock operation result based on the lock operation request and the lock status recorded in the placement group.

[0055] The feedback unit is used to send the lock operation result back to the lock client so that the client can execute an acknowledgment operation that matches the lock operation result.

[0056] This application also provides an electronic device, including:

[0057] Memory, used to store computer programs;

[0058] A processor is used to implement any of the above-described methods of distributed lock management when executing a computer program.

[0059] 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 any of the above-described distributed lock management methods.

[0060] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described distributed lock management methods.

[0061] As can be seen from the above technical solution, when the lock client detects a task to be processed, it obtains the corresponding lock object information. This lock object information includes the lock number, lock acquirer identifier, lock version number, and lock lease period version number. The lock lease period version number is determined based on the monotonic clock value of the lock client. Based on the task type and lock object information, the client initiates a lock operation request to the main lock service. The main server then executes the lock operation and determines the result based on the request and the lock status recorded in the placement group, and sends the result back to the lock client. The client obtains the lock operation result from the main server and executes a corresponding acknowledgment operation. In this technical solution, determining the lock lease period version number based on the monotonic clock value prevents double-write issues to the same resource by the two controllers in scenarios involving clock jumps or inconsistencies between the two controllers, thus achieving precise lock management. The lock server includes a main server and slave servers. The placement group uses a replica mode, with each lock server having its own replica for recording lock status. When a lock client operates on a lock instance, it only needs to communicate with the main server. The main server will combine the lock status recorded in the placement group, execute the corresponding operation, and feed back the lock operation result to the lock client. The entire implementation process does not require the introduction of a new distributed cluster, which effectively reduces the complexity of operation and maintenance. Attached Figure Description

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

[0063] Figure 1 A design architecture diagram of a distributed lock provided in an embodiment of this application;

[0064] Figure 2 A flowchart illustrating a method for distributed lock management applicable to lock clients, provided as an embodiment of this application;

[0065] Figure 3 A schematic diagram illustrating a lock state transition relationship provided in an embodiment of this application;

[0066] Figure 4 A schematic diagram illustrating a locking process for a lock client provided in an embodiment of this application;

[0067] Figure 5 A schematic diagram illustrating a lock client renewal process provided in an embodiment of this application;

[0068] Figure 6 A schematic diagram illustrating a lock client unlocking process provided in an embodiment of this application;

[0069] Figure 7 A flowchart illustrating a method for distributed lock management applicable to a main server, provided as an embodiment of this application;

[0070] Figure 8 A locking process based on a monotonic clock is provided for embodiments of this application;

[0071] Figure 9 A timing diagram for two clients using a single distributed lock instance to perform I / O, provided in an embodiment of this application;

[0072] Figure 10 A schematic diagram of a distributed lock management device suitable for lock clients, provided as an embodiment of this application;

[0073] Figure 11 This is a schematic diagram of a distributed lock management device suitable for a main server, provided as an embodiment of this application. Detailed Implementation

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

[0075] The terms "comprising" and "having," and any variations thereof, in the specification and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may include steps or units not listed.

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

[0077] Given that current distributed locks use system time as the time reference, the potential for time discrepancies between multiple lock servers and between lock servers and clients makes it difficult to accurately determine lock expiration times. This inaccuracy can lead to serious consequences such as data inconsistency and split-brain double-write issues. Furthermore, current distributed lock implementations require maintaining a new distributed cluster, such as a ZooKeeper or Redis cluster, significantly increasing operational complexity and costs.

[0078] Therefore, this application provides a method, apparatus, electronic device, and storage medium for distributed lock management. The distributed lock no longer uses system time but instead uses the monotonic clock value of a monotonic clock. The version number of the lock lease period is determined based on the monotonic clock value, preventing dual-controller writes to the same resource in scenarios involving clock jumps or inconsistencies between dual controllers, thus achieving precise lock management. The lock server includes a master server and slave servers. The placement group adopts a replica mode, with each lock server having its own replica for recording lock states. When a lock client operates on a lock instance, it only needs to communicate with the master server. The master server, based on the lock state recorded in the placement group, executes the corresponding operation and feeds back the lock operation result to the lock client. The entire implementation process does not require the introduction of a new distributed cluster, effectively reducing operational complexity.

[0079] Figure 1 This is a design architecture diagram of a distributed lock provided in an embodiment of this application. Figure 1 The example used is a dual-controller setup consisting of node A and node B. In the distributed lock (PLock) architecture provided in this application, the lowest level is the placement group, which uses a replica mode. Figure 1 This example uses five replicas to store the distributed lock state. The five replicas are stored on five different hard drives. Each replica is bound to a local lock service module, which can be called a "lock server." One of these lock servers is called the master server, and it is bound to the master replica of the placement group. The remaining lock servers can be called slave servers.

[0080] In the design architecture of PLock, a large number of lock instances, or PLock instances, can be managed simultaneously. Each PLock instance is uniquely mapped to a placement group, and multiple PLock instances can run concurrently on a placement group. Each PLock instance has its own corresponding data, and access to that data can be obtained through locking operations. Figure 1The example shown uses one lock client deployed on each node providing business services. In practical applications, lock clients can be divided according to business type and scope. Each node can run several lock clients, and each lock client has access to any Plock instance, enabling it to perform operations such as locking, unlocking, and renewing. When operating on a specific Plock instance, the lock client communicates with the main server of that Plock instance.

[0081] When lock-related locking, unlocking, and renewal operations are performed on the primary replica, strong consistency operations are performed on the other replicas. The changed lock state data is stored on each disk according to the consistency strategy of the placement group. At the same time, the lock state is updated in the memory of each lock server.

[0082] When a failure occurs, the primary server and the primary replica of the reset group may become unavailable. In this case, a primary replica switch will be performed, and one of the remaining healthy replicas will become the new primary replica. The lock service corresponding to it maintains the lock state before the failure in its memory. The client communicates with the new primary server, and the lock state is continued.

[0083] Next, a method for distributed lock management provided by an embodiment of this application will be described in detail. Figure 2 A flowchart illustrating a method for distributed lock management applicable to lock clients, provided in this application embodiment, is included.

[0084] S201: If a task to be processed is detected, obtain the corresponding lock object information.

[0085] The lock object information may include the lock number, locker identifier (Locker_id), lock version number (Epoch), and lock lease period version number (Interval); the lock lease period version number is determined based on the monotonic clock value of the lock client.

[0086] The lock number can be the lock instance number (lock ID) or the resource number protected by the lock (resource ID).

[0087] The locker identification information can be the locker's ID information, which is the lock client's ID information.

[0088] The version number can only be increased, not regressed.

[0089] In practical applications, the version number of the lock lease period for the lock client can be directly adopted using the monotonic clock value of the lock client, that is, the monotonic clock value of the lock client can be used as the version number of the lock lease period.

[0090] S202: Based on the task type of the task to be processed and the lock object information, initiate a lock operation request to the main server of the lock service, so that the main server can perform the lock operation and determine the lock operation result according to the lock operation request and the lock status recorded in the placement group, and then feed back the lock operation result to the lock client.

[0091] There are various types of tasks to be processed, including locking, renewal, and unlocking.

[0092] When the task type to be processed is a locking task, the lock client sends a locking request carrying lock object information to the main server and records the local monotonic clock value.

[0093] When the task type to be processed is a renewal task, the lock client sends a renewal request carrying lock object information to the main server and records the local monotonic clock value.

[0094] When a lock operation request is initiated, a monotonic clock value is recorded. The purpose of this is to add the recorded monotonic clock value to the lock validity period after the lock is successfully acquired or renewed, thereby determining the lock lease expiration time. For example, if the recorded monotonic clock value is 100 milliseconds and the lock validity period is 400 milliseconds, then the lock lease expiration time is 500 milliseconds.

[0095] When the task type to be processed is an unlocking task, the lock client sends an unlocking request carrying lock object information to the main server.

[0096] The lock client sends a lock operation request to the main server. The main server will determine the lock state to switch to based on the lock operation request and the lock states recorded in the placement group.

[0097] The lock state recorded in the placement group refers to the current state of the lock.

[0098] To enable switching between different lock states, a state machine is associated with each Plock instance. The lock states maintained by the state machine are divided into stable and unstable states. The stable states include the unlocked state (UnLocked) and the locked state (Locked), while the unstable states include the unlocking state (UnLocking) and the locking state (Locking).

[0099] The main server sends the lock operation result back to the lock client based on the lock state switching result.

[0100] S203: Obtain the lock operation result from the main server and execute the acknowledgment operation that matches the lock operation result.

[0101] Each lock operation request has multiple possible lock operation results. After receiving the lock operation result from the main server, the lock client can execute a matching receipt operation based on the lock operation result.

[0102] For example, if the main server reports a successful lock operation result for a lock request, the lock client needs to record the lock lease expiration time based on the monotonic clock value recorded when the lock request was sent and the lock validity period; start a lease refresh scheduled task; and send a successful lock response message to the business component.

[0103] As can be seen from the above technical solution, when the lock client detects a task to be processed, it obtains the corresponding lock object information. This lock object information includes the lock number, lock acquirer identifier, lock version number, and lock lease period version number. The lock lease period version number is determined based on the monotonic clock value of the lock client. Based on the task type and lock object information, the client initiates a lock operation request to the main lock service. The main server then executes the lock operation and determines the result based on the request and the lock status recorded in the placement group, and sends the result back to the lock client. The client obtains the lock operation result from the main server and executes a corresponding acknowledgment operation. In this technical solution, determining the lock lease period version number based on the monotonic clock value prevents double-write issues to the same resource by the two controllers in scenarios involving clock jumps or inconsistencies between the two controllers, thus achieving precise lock management. The lock server includes a main server and slave servers. The placement group uses a replica mode, with each lock server having its own replica for recording lock status. When a lock client operates on a lock instance, it only needs to communicate with the main server. The main server will combine the lock status recorded in the placement group, execute the corresponding operation, and feed back the lock operation result to the lock client. The entire implementation process does not require the introduction of a new distributed cluster, which effectively reduces the complexity of operation and maintenance.

[0104] In this embodiment, the distributed lock corresponds to multiple different lock states, which can be described using a lock state machine. A lock state machine is a mechanism used to describe and manage the set of lock states, state triggering conditions, and state transition rules of a PLock instance in a lock service. The lock state machine specifies how a PLock instance, starting from its initial state, switches to other lock states under different operations or events, and the operations allowed to be executed in each lock state.

[0105] Figure 3This diagram illustrates a lock state transition relationship provided in an embodiment of this application. In the initial state, the lock state machine resets the lock state based on disk data. Upon receiving a ResetLocked event, the lock switches to the locked state. The locked state is persistent, indicating that the lock is currently held by a lock client.

[0106] When a ResetUnlocked event is received, the lock is switched to the UnLocked state. UnLocked is a persistent state, indicating that the lock is currently available and can be locked.

[0107] In the Unlocked state, if a lock request event (ELock) or a lock lease renewal request event (ETTLRefresh) is received, the lock can switch to the Locking state if these events meet the monotonicity requirement. Locking indicates that the lock is in progress. Simultaneously, the lock state machine determines the next state to be Locked based on the current lock state. If so, it serializes the Locked state into binary data and submits it to the placement group for asynchronous persistence. After the placement group completes recording the lock state, it triggers the Lock Information Completed Storage event (ESaveCommitted), at which point the lock state switches to the Locked state.

[0108] In the Locked state, if an unlock request event (EUnlock) is received and the monotonicity requirement is met, the system switches to the Unlocking state. Unlocking indicates that the unlock request is still being processed.

[0109] In the Unlocked state, if a lock information storage completion event (ESaveCommited) is received, it will switch to the unlocking state (Unlocking).

[0110] In this embodiment, each Plock instance is associated with a state machine. Lock states are divided into stable and unstable states. Stable states include Unlocked and Locked, while unstable states include Unlocking and Locking. The unstable state design is primarily to support asynchronous programming. During asynchronous persistent I / O, the lock state is unstable; based on the persistence result, the lock switches to a stable state. Persistent lock states are all stable, meaning that the lock state after fault recovery will be one of the two stable states.

[0111] Taking a locking request as an example, when a lock client sends a locking request, the main server posts an ELock event to the state machine associated with the Plock instance. For instance, if the state machine determines that the next state is Locked based on the current state, it serializes the Locked state into binary data and submits it to the placement group for asynchronous persistence. At the same time, the lock's memory state is switched to the Locking state. After the placement group completes distributed persistence, it drives the state machine to transition to the Locked state by posting an ESaveCommitted persistence completion event.

[0112] By setting up a state machine, the state transition rules are clearly defined, avoiding "unknown intermediate states" in the lock state and ensuring predictable lock behavior. Abstracting the complex lock state transition logic into a state machine description results in clear logic, facilitating code implementation, debugging, and maintenance, making it particularly suitable for distributed lock scenarios.

[0113] Business components can operate on specific lock IDs (or resource IDs) through the lock client. The operations are mainly divided into three types: locking, renewing, and unlocking.

[0114] Figure 4 This diagram illustrates a locking process for a lock client according to an embodiment of this application. The lock client determines the lock ID, using it as the locker identifier (Locker_id), and uses an auto-incrementing Epoch version number, taking a monotonic clock value as the lock lease period version number (Interval). After completing data preparation, the lock client sends a locking request to the main server, carrying {lock ID, Locker_id, Epoch, Interval}. The main server performs relevant operations and determines the unlocking result based on the locking request sent by the lock client and the lock status recorded in the placement group.

[0115] The lock operation result returned by the main server may be of various types, including successful locking (OK), lock preemption or refusal to lock, service busy, request timeout, or internal service error.

[0116] If the lock operation results in a successful lock acquisition, the lock client can record the lock lease expiration time based on the monotonic clock value recorded when sending the lock request and the lock validity period; start a lease refresh scheduled task; and send a successful lock acquisition response message to the business component.

[0117] If the lock operation results in the lock being preempted or the lock being refused, the lock client can send a response message to the business component indicating that the lock acquisition failed.

[0118] If the lock operation results in "service busy", the lock client can wait for a set time and then re-initiate the lock request.

[0119] If the lock operation results in a request timeout, the lock client can set a client lease timeout flag based on the lock acquirer's identifier information and send a lock acquisition failure response message to the business component. By setting the client lease timeout flag, it blocks any future return results (Reply).

[0120] If the lock operation results in an internal service error, the lock client can send a response message indicating that the lock acquisition failed to the business component.

[0121] In practical applications, lock clients can send response messages to business components by calling upper-level callback functions. Figure 4 Taking the call to the upper-level callback function as an example, when the lock is successfully acquired, the upper-level callback function is called to inform that the lock acquisition was successful; when the lock is preempted or the acquisition is refused, the upper-level callback function is called to inform that the lock acquisition failed; when the request times out, the upper-level callback function is called to inform that the lock acquisition failed; when an internal service error occurs, the upper-level callback function is called to inform that the lock acquisition failed.

[0122] Figure 5 This diagram illustrates a lock client renewal process provided in an embodiment of this application. When the lock client receives a timed task triggering renewal, it performs data preparation, including determining the lock ID, using the lock client ID as the Locker_id, using an auto-incrementing Epoch version number, and taking a monotonic clock value as the Interval. After completing the data preparation, the lock client sends a renewal request to the main server, carrying {lock ID, Locker_id, Epoch, Interval}. Since the data preparation is the same as the data preparation in the locking process, Figure 5 The data preparation process has been omitted.

[0123] For a renewal request, the main server may return several lock operation results, including renewal successful (OK), lock preempted, service busy, request timeout or internal service error, renewal refused, etc.

[0124] If the lock operation results in a successful renewal, the lock client can update the lock lease expiration time and register the next renewal event based on the monotonic clock value and renewal validity period recorded when sending the renewal request.

[0125] If the lock operation results in the lock being preempted, the lock client can stop the lease refresh scheduled task; send a response message to the business component indicating that the lock has been preempted; and initiate an unlock request, so that the preempting party can acquire the lock as soon as possible.

[0126] If the lock operation results in "service busy", the lock client can ignore the result and wait for the set time before re-initiating the renewal request.

[0127] The duration can be set flexibly; for example, it can be set to 1 second. Figure 5 Taking 1 second as an example, the lock client can register a renewal event after 1 second.

[0128] If the lock operation results in a request timeout or an internal service error, the lock client can register for the next renewal event and, if the local lease times out, send a response message to the business component indicating that the lock has expired.

[0129] In the implementation, the lock client can check the local lock lease expiration time to determine if the lock lease has expired. If the lock lease expiration time is greater than the current monotonic clock value, it means the lock lease has expired. In this case, the lock client can call the upper-level callback function to notify the lock that it has expired and register the next renewal event. If the lock lease has not expired, the next renewal event is registered directly.

[0130] If the lock operation results in a refusal to renew the lease, the lock client can stop the lease refresh scheduled task and send a response message to the business component indicating that the lock has expired.

[0131] In practical applications, lock clients can send response messages to business components by calling upper-level callback functions. Figure 5 Taking the call to the upper-level callback function as an example, when the lock has been preempted, the upper-level callback function is called to notify that it has been preempted; when the request times out or there is an internal error, the upper-level callback function is called to notify that the lock has expired; when renewal is refused, the upper-level callback function is called to notify that the lock has expired.

[0132] Figure 6 This diagram illustrates a lock client unlocking process provided in an embodiment of this application. When the lock client receives a stop-renewal timing task, it performs data preparation, including determining the lock ID, using the lock client ID as the Locker_id, using an auto-incrementing Epoch version number, and taking a monotonic clock value as the Interval. After completing the data preparation, the lock client sends an unlock request to the main server, carrying {lock ID, Locker_id, Epoch, Interval}. Since the data preparation is the same as that in the locking process, Figure 6 The data preparation process has been omitted.

[0133] For unlock requests, the main server may return several lock operation results, including unlock successful (OK), service busy, request timeout, internal service error, etc.

[0134] If the lock operation results in a successful unlock, the lock client can send a successful unlock response message to the business component.

[0135] If the lock operation results in "service busy", the lock client can wait for a set time and then re-initiate the unlock request.

[0136] Figure 6 Taking 1 second as an example, the lock client can wait 1 second and then retry the unlock request.

[0137] If the lock operation results in a request timeout, the lock client can set a client timeout flag for the lease and send a timeout error code (ETIMEOUT) to the business component.

[0138] By setting a client timeout flag for the lease, you can prevent future replies from returning.

[0139] If the lock operation results in an internal service error, the lock client can report the internal error code to the business component.

[0140] In practical applications, lock clients can send response messages to business components by calling upper-level callback functions. Figure 6 Taking the call to the upper-level callback function as an example, when unlocking is successful, the upper-level callback function is called to notify that unlocking was successful; when the request times out, the upper-level callback function is called to return the error code -ETIMEOUT; when an internal service error occurs, the upper-level callback function is called to pass through the error code.

[0141] The above Figures 4 to 6 This paper describes the operation process of locking, renewing, and unlocking by the lock client. Following this process design ensures the overall operation of the distributed lock and provides services to upper-layer business logic.

[0142] Figure 7 A flowchart illustrating a method for distributed lock management applicable to a main server, provided in this application embodiment, is included. The method comprises:

[0143] S701: Receive lock operation requests initiated by lock clients, which carry lock object information.

[0144] The lock object information may include the lock number, the locker's identification information, the lock version number, and the lock lease period version number; the lock lease period version number is determined based on the monotonic clock value of the lock client.

[0145] S702: Based on the lock operation request and the lock status recorded in the reset group, perform the lock operation and determine the lock operation result.

[0146] After receiving a lock operation request, the main server posts the corresponding event to the state machine associated with the Plocked instance. The state machine then determines the next lock state based on the current lock state, serializes the next lock state into binary data, submits it to the placement group for storage, and simultaneously switches the lock state to the corresponding unstable state. After the placement group completes storage, it posts a completion event, driving the state machine to transition to the stable state.

[0147] Taking a locking request as an example, when a lock client sends a locking request, the lock service posts an ELock event to the Plock instance state machine. For instance, if the state machine determines that the next state is Locked based on the current state, it serializes the Locked state into binary data and submits it to the placement group for asynchronous persistence. At the same time, the lock's memory state is switched to the Locking state. After the placement group completes distributed persistence, it drives the state machine to transition to the Locked stable state by posting an ESaveCommitted persistence completion event.

[0148] S703: Feedback the lock operation result to the lock client so that the client can execute a acknowledgment operation that matches the lock operation result.

[0149] The above Figures 4 to 6 The specific forms of lock operation results under different lock operation requests are listed in the document, and will not be repeated here.

[0150] As can be seen from the above technical solution, the main server receives lock operation requests initiated by the lock client, carrying lock object information. This lock object information includes the lock number, lock acquirer identifier, lock version number, and lock lease period version number; the lock lease period version number is determined based on the monotonic clock value of the lock client. Based on the lock operation request and the lock status recorded in the placement group, the main server executes the lock operation and determines the lock operation result. The lock operation result is then fed back to the lock client so that the client can execute a corresponding acknowledgment operation. In this technical solution, determining the lock lease period version number based on the monotonic clock value prevents the problem of dual-controller writes to the same resource in scenarios involving clock jumps or inconsistencies between dual controller clocks, thus achieving precise lock management. The lock server includes a main server and slave servers. The placement group adopts a replica mode, with each lock server having its own replica for recording lock status. When a lock client operates on a lock instance, it only needs to communicate with the main server. The main server will combine the lock status recorded in the placement group, execute the corresponding operation, and feed back the lock operation result to the lock client. The entire implementation process does not require the introduction of a new distributed cluster, which effectively reduces the complexity of operation and maintenance.

[0151] Each lock operation request (lock, unlock, renewal) carries Locker_id, Epoch, and Interval information. When the lock request arrives at the main server, its monotonicity is checked. For ease of description, lock operation requests can be simply referred to as lock requests.

[0152] The main server will determine whether the lock acquirer identifier information carried in the lock operation request is the same as the lock acquirer identifier information of the current lock.

[0153] If the lock acquirer identifier information carried in the lock operation request is different from the lock acquirer identifier information of the current lock, determine whether the lock version number carried in the lock operation request is greater than the lock version number of the current lock.

[0154] If the lock acquirer identifier information carried in the lock operation request is different from the lock acquirer identifier information of the current lock, and the lock version number carried in the lock operation request is greater than the lock version number of the current lock, it means that the lock operation request satisfies monotonicity. In this case, the operation steps of performing the lock operation and determining the lock operation result can be executed according to the lock operation request and the lock state recorded in the placement group.

[0155] If the lock acquirer identifier information carried in the lock operation request is the same as the lock acquirer identifier information of the current lock, determine whether the lock version number carried in the lock operation request is greater than the lock version number of the current lock, or whether the lock version number carried in the lock operation request is equal to the lock version number of the current lock and whether the version number of the lock lease period carried in the lock operation request is greater than or equal to the version number of the lock lease period of the current lock.

[0156] If the lock version number carried in the lock operation request is greater than the lock version number of the current lock, or if the lock version number carried in the lock operation request is equal to the lock version number of the current lock and the version number of the lock lease period carried in the lock operation request is greater than or equal to the version number of the lock lease period of the current lock, it indicates that the lock operation request satisfies monotonicity. In this case, the operation steps of performing the lock operation and determining the lock operation result can be executed based on the lock operation request and the lock state recorded in the placement group.

[0157] In practical implementation, the monotonicity of a lock request is determined by whether it meets one of the following two conditions: The lock request is said to be monotonic if it meets neither condition.

[0158] Below, && represents logical AND, || represents logical OR, and ! represents logical NOT.

[0159] Condition 1: If the lock acquirer remains unchanged, the lock request has a larger Epoch, or the Epochs are the same and the Intervals are the same or larger.

[0160] (Lock request Locker == Current lock Locker) && (

[0162] (Lock request Epoch > Current lock Epoch) ||

[0163] ((lock request Epoch == current lock Epoch) && (lock request Interval >= current lock Interval))

[0164] ).

[0165] Condition 2: When the lock acquirer changes, the lock request Epoch is larger.

[0166] (Lock request Locker != Current lock Locker) && (Lock request Epoch > Current lock Epoch).

[0167] In this embodiment, the monotonicity determination ensures the consistency of lock state transitions, avoids lock conflicts and data corruption, and maintains the legality and validity of the lock.

[0168] Traditional solutions that use the local system clock as the time reference will cause the following problems.

[0169] Scenario a: The clock of the distributed lock master node is ahead of the client clock. From the perspective of the client business module (PlogFS) instance, the distributed lock master node will experience early lock expiration. The new PLogFS instance will be able to acquire the lock in advance, resulting in overlapping distributed lock lease periods and causing inconsistency issues due to dual data writes.

[0170] Scenario b: The clock of the distributed lock master node lags behind the client clock, which will prolong the failover time of node failure. From the perspective of the client PlogFS instance, the distributed lock master node will experience delayed lock expiration, and the new PlogFS instance will have to wait for more extra time to acquire the lock. When a failure occurs, switching PlogFS instances will cause longer business interruption time.

[0171] Scenario c: The clock of the distributed lock slave node is lagging behind that of the master node, which will prolong the failover time of node failure. From the perspective of the client PlogFS instance, the distributed lock slave node will experience delayed lock expiration. If a master-slave switch occurs within the master's lock validity period, the new PlogFS instance will have to wait for an additional time to acquire the lock due to the delayed expiration of the lock slave node (new master).

[0172] Scenario d: The clock of the distributed lock slave node is ahead of that of the master node. From the perspective of the client PlogFS instance, the distributed lock slave node will experience the early expiration of the distributed lock. If a master-slave switch occurs within the validity period of the lock slave node, the new PlogFS instance will successfully acquire the lock in advance, resulting in overlapping PlogFS lease periods and data inconsistency issues due to dual writes.

[0173] To address the four risks caused by clock inconsistency (a, b, c, and d), the improvement measure is to adopt the PlogFS lock time-to-live (TTL) mechanism, which does not use the system clock but instead uses a monotonic clock. Nodes do not transmit absolute time but only relative time.

[0174] The monotonic clock value is taken from the number of milliseconds that have passed since the computer started. It is calculated based on factors such as the CPU clock speed and is not affected by the system clock. It always increases monotonically and is reset to zero after the computer restarts.

[0175] Figure 8 This application provides a locking process based on a monotonic clock. Figure 8 This example uses a distributed lock client, a distributed lock service master node, and a distributed lock service slave node. The distributed lock service master node is the primary server, and the distributed lock service slave node is the secondary server. Each of the lock client, master node, and slave node has its own monotonic clock. When a distributed lock client initiates a lock request, it records its own monotonic clock value, denoted as monotonic clock T1. When initiating a lock request, it includes the lock's expiration date. Figure 8 The example given is a lock validity period TTL=x.

[0176] When the master node of the lock service receives a lock request, it records its own monotonic clock value, which is denoted as monotonic clock T2. The TTL is persisted as x, and the lock lease expiration time is recorded in memory as T2 + TTL. Then, it sends a lock subop carrying the lock validity period to other lock service slave nodes.

[0177] When a lock service slave node receives a lock sub-operation, it records its own monotonic clock value, denoted as monotonic clock T3, persists the TTL=x, and records the lock lease expiration time in memory as T3+TTL. After recording the lock lease expiration time, it sends a sub-operation reply to the lock service master node.

[0178] After receiving subop replies from all lock service slave nodes, the lock service master node sends a lock reply to the distributed lock client, indicating the locking operation result. Taking a successful lock acquisition as an example, upon receiving the lock reply, the lock client records the lock lease expiration time as T1 + TTL and enters the ready state to renew the lease periodically. Once the lock is successfully acquired, it begins providing services to the business components.

[0179] In this embodiment of the application, a monotonic clock value is used as the time basis, and the lease time windows of the lock client will not overlap.

[0180] If a master-slave switch occurs in the lock service, assuming the slave node has not been restarted, the additional time for the client to acquire the lock is the latency of one request. Therefore, the client can acquire the lock by retrying at most once.

[0181] Figure 9 This application provides a timing diagram for two clients using a single distributed lock instance for I / O, as illustrated in an embodiment. Figure 9 Client 1's states include unlocked, successfully locked, and expired. In the unlocked state, business operations are not possible; in the successfully locked state, business operations are possible; and in the expired state, business operations are not possible. Client 2's states range from unlocked to successfully locked. In a distributed lock, "master" refers to the master node, and "slave" refers to the slave node.

[0182] Figure 9 Taking the locking process of client 1 and the locking process of client 1 when the lock expires as examples, we analyze the timing of client 1 and client 2 using a distributed lock instance for IO from the timeline perspective. Figure 9 The example given is a request latency of 50ms between nodes and a TTL of 800ms.

[0183] If a master-slave switch occurs in the lock service, and the slave node restarts first and then becomes the master node, the slave node's lock lease will be restored from its persistent state. After becoming the new master node, the lock expiration time can only be calculated from the current monotonic clock plus the TTL, which is equivalent to indirectly extending the TTL validity period. Although there is no lease overlap issue, the service interruption time will be longer. In the worst case, the new lock client needs to wait for an additional TTL cycle before it can acquire the lock.

[0184] To address this issue, this application employs the following design: During master-slave failover, each replica in the placement group first performs a Plock pre-loading operation, loading the distributed lock state recorded on the local disk into memory, known as probe information. If a Plock record already exists in memory, the probe information is updated using the lock expiration time recorded in memory. This operation ensures that for lock replicas that have not been restarted, their expiration times remain unchanged from the state before the master-slave failover; for restarted lock replicas, which do not have Plock information records in memory, the expiration time of the memory probe information record will be the longest, i.e., one TTL period.

[0185] In this embodiment, when the primary server is the new primary server after a master-slave server switch, the lock state is acquired. If the lock state is "lock released," the locally recorded remaining lock validity period is set to zero. If the lock state is "locked," the locally recorded remaining lock validity period is adjusted based on the locally recorded remaining lock validity period and the remaining lock validity period returned by each slave server. The lock lease expiration time is updated based on the current monotonic clock value and the adjusted remaining lock validity period. The primary server can be referred to as the master node, and the slave servers can be referred to as slave nodes.

[0186] In practice, the minimum of the locally recorded remaining lock validity period and the remaining lock validity period returned from the server can be used as the adjusted remaining lock validity period.

[0187] For example, during master-slave failover, the master node sends a query to all slave nodes requesting the distributed lock instance status: {lock ID, epoch, lock status, remaining TTL}. The slave node's query response includes its own replica's {lock ID, epoch, lock status, remaining TTL}.

[0188] When the master node updates, probe information with a larger epoch is overwritten with probe information with a smaller epoch. If the epochs are the same: if the master node lock is in an Unlocked state, the remaining lock validity period in the master node probe record is set to 0. If it is in a Locked state, the remaining TTL in the local probe record is set to MIN(the remaining TTL in the local record and the remaining TTL returned by the replica).

[0189] After receiving the receipts for all copies, the remaining TTL length of each lock in the local probe information was corrected.

[0190] When the master-slave switchover negotiation phase of the reset group is about to be completed, if the lock epoch in the previously negotiated probe information is larger than that recorded on the master node's disk, it means that this lock needs to be repaired later. Here, the memory plock expiration time is first restored according to the negotiated minimum TTL remaining length. If the negotiated lock epoch is the same as that recorded on the master node's disk, the TTL expiration time of the plock in memory is corrected to the current monotonic clock value plus the negotiated minimum TTL remaining length.

[0191] According to this application, during master-slave failover, each replica first performs a Plock preload operation, loading the distributed lock state recorded on the local disk into memory. After the master-slave failover is complete, if the lock state of the new master node is already locked, the minimum value of the remaining lock validity period recorded locally and the remaining lock validity period returned by each slave server is used as the adjusted remaining lock validity period, ensuring that the lock expiration time is not lost.

[0192] In a dual-controller architecture, if all replicas in a placement group fail and restart, the lock expiration monotonic clock timestamps recorded in the memory of all lock replicas are lost. This causes the final negotiation result of the distributed lock remaining expiration time to be one TTL cycle, and the lock client still needs to wait for one TTL cycle when re-acquiring the lock. To solve this problem, this application improves the disk mapping algorithm of the placement group, so that in any placement group of 5 replicas, 2 are distributed on two different disks on controller A, and 3 replicas are distributed on three different disks on controller B. In this way, when a single controller fails and restarts, a shorter distributed lock expiration time can still be negotiated from the replicas of the surviving controller. It is equivalent to the distributed lock expiration timer on the server side not being interrupted.

[0193] By negotiating the lock expiration time, the lock waiting time is optimized to the greatest extent in single-disk, dual-disk, and single-controller failure scenarios, ensuring optimal business continuity.

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

[0195] Figure 10 This is a schematic diagram of a distributed lock management device for lock clients provided in an embodiment of this application. The device includes an information acquisition unit 101, an initiation unit 102, and an execution unit 103.

[0196] The information acquisition unit 101 is used to acquire the corresponding lock object information when a task to be processed is detected; wherein, the lock object information includes lock number, locker identification information, lock version number and lock lease period version number; the lock lease period version number is determined based on the monotonic clock value of the lock client;

[0197] The initiating unit 102 is used to initiate a lock operation request to the main server of the lock service based on the task type of the task to be processed and the lock object information, so that the main server can perform the lock operation and determine the lock operation result according to the lock operation request and the lock status recorded in the placement group, and then feed back the lock operation result to the lock client.

[0198] The execution unit 103 is used to obtain the lock operation result fed back by the main server and execute the acknowledgment operation that matches the lock operation result.

[0199] In some embodiments, the initiating unit is configured to initiate a locking request carrying lock object information to the main server and record the local monotonic clock value when the task type of the task to be processed is a locking task; to initiate a renewal request carrying lock object information to the main server and record the local monotonic clock value when the task type of the task to be processed is a renewal task; and to initiate an unlock request carrying lock object information to the main server when the task type of the task to be processed is an unlock task.

[0200] In some embodiments, when the lock operation request is a lock acquisition request, the execution unit is configured to, when the lock operation result is a successful lock acquisition, record the lock lease expiration time based on the monotonic clock value recorded when the lock acquisition request was sent and the lock validity period; start a lease refresh timer task; and send a successful lock acquisition response message back to the business component.

[0201] If the lock operation results in the lock being preempted or the lock being refused, a lock acquisition failure response message should be sent to the business component.

[0202] If the lock operation result is "service busy", wait for the set time and then re-initiate the lock request;

[0203] If the lock operation results in a request timeout, set the client lease timeout flag based on the lock acquirer's identifier information and send a lock acquisition failure response message to the business component.

[0204] If the lock operation results in an internal service error, a lock acquisition failure response message is sent to the business component.

[0205] In some embodiments, when the lock operation request is a renewal request, the execution unit is configured to update the lock lease expiration time and register the next renewal event based on the monotonic clock value recorded when the renewal request was sent and the renewal validity period, if the lock operation result is a successful renewal.

[0206] If the lock operation results in the lock being preempted, stop the lease refresh scheduled task; send a preempted lock response message to the business component and initiate an unlock request;

[0207] If the lock operation result is "service busy", wait for the set time and then re-initiate the renewal request;

[0208] If the lock operation results in a request timeout or an internal service error, register the next renewal event, and if the local lease times out, send a response message to the business component that the lock has expired.

[0209] If the lock operation results in a refusal to renew the lease, stop the lease refresh scheduled task and send a response message to the business component indicating that the lock has expired.

[0210] In some embodiments, when the lock operation request is an unlock request, the execution unit is configured to send a response message indicating successful unlocking to the business component when the lock operation result is successful unlocking.

[0211] If the lock operation result is "service busy", wait for the set time and then re-initiate the unlock request;

[0212] If the lock operation results in a request timeout, set a client timeout flag for the lease and report a timeout error code to the business component;

[0213] If the lock operation results in an internal service error, an internal error code is sent back to the business component.

[0214] Figure 10 For a description of the features in the corresponding embodiments, please refer to Figure 2 The relevant descriptions of the corresponding embodiments will not be repeated here.

[0215] As can be seen from the above technical solution, when the lock client detects a task to be processed, it obtains the corresponding lock object information. This lock object information includes the lock number, lock acquirer identifier, lock version number, and lock lease period version number. The lock lease period version number is determined based on the monotonic clock value of the lock client. Based on the task type and lock object information, the client initiates a lock operation request to the main lock service. The main server then executes the lock operation and determines the result based on the request and the lock status recorded in the placement group, and sends the result back to the lock client. The client obtains the lock operation result from the main server and executes a corresponding acknowledgment operation. In this technical solution, determining the lock lease period version number based on the monotonic clock value prevents double-write issues to the same resource by the two controllers in scenarios involving clock jumps or inconsistencies between the two controllers, thus achieving precise lock management. The lock server includes a main server and slave servers. The placement group uses a replica mode, with each lock server having its own replica for recording lock status. When a lock client operates on a lock instance, it only needs to communicate with the main server. The main server will combine the lock status recorded in the placement group, execute the corresponding operation, and feed back the lock operation result to the lock client. The entire implementation process does not require the introduction of a new distributed cluster, which effectively reduces the complexity of operation and maintenance.

[0216] Figure 11 This is a schematic diagram of a distributed lock management device suitable for a main server, provided for an embodiment of this application. The device includes a receiving unit 111, a determining unit 112, and a feedback unit 113.

[0217] The receiving unit 111 is used to receive a lock operation request initiated by the lock client, which carries lock object information; wherein, the lock object information includes lock number, locker identification information, lock version number and lock lease period version number; the lock lease period version number is determined based on the monotonic clock value of the lock client;

[0218] The determining unit 112 is used to perform a lock operation and determine the lock operation result based on the lock operation request and the lock status recorded in the placement group;

[0219] Feedback unit 113 is used to provide feedback on the lock operation result to the lock client so that the client can execute an acknowledgment operation that matches the lock operation result.

[0220] In some embodiments, the system further includes a first determination unit, a second determination unit, a first triggering unit, a third determination unit, and a second triggering unit;

[0221] The first judgment unit is used to determine whether the locker identification information carried in the lock operation request is the same as the locker identification information of the current lock;

[0222] The second judgment unit is used to determine whether the lock version number carried in the lock operation request is greater than the lock version number of the current lock when the locker identifier information carried in the lock operation request is different from the locker identifier information of the current lock.

[0223] The first triggering unit is used to trigger the determining unit to perform the operation steps of performing a lock operation and determining the lock operation result based on the lock operation request and the lock status recorded in the placement group when the lock operator identification information carried in the lock operation request is different from the lock operator identification information of the current lock and the lock version number carried in the lock operation request is greater than the lock version number of the current lock.

[0224] The third judgment unit is used to determine whether the lock version number carried in the lock operation request is greater than the lock version number of the current lock, or whether the lock version number carried in the lock operation request is equal to the lock version number of the current lock and whether the version number of the lock lease period carried in the lock operation request is greater than or equal to the version number of the lock lease period of the current lock, when the lock operator identification information carried in the lock operation request is the same as the lock operator identification information of the current lock.

[0225] The second triggering unit is used to trigger the determining unit to perform the operation steps of executing the lock operation and determining the lock operation result based on the lock operation request and the lock status recorded in the placement group when the lock version number carried in the lock operation request is greater than the lock version number of the current lock, or the lock version number carried in the lock operation request is equal to the lock version number of the current lock and the version number of the lock lease period carried in the lock operation request is greater than or equal to the version number of the lock lease period of the current lock.

[0226] In some embodiments, the system further includes a lock state acquisition unit, a setting unit, an adjustment unit, and an update unit;

[0227] The lock state acquisition unit is used to acquire the lock state when the master server becomes the new master server after the master-slave server switch is performed;

[0228] The setting unit is used to set the remaining lock validity period recorded locally to zero when the lock state is the lock released state.

[0229] The adjustment unit is used to adjust the remaining lock validity period recorded locally, based on the remaining lock validity period recorded locally and the remaining lock validity period returned from the server, when the lock status is locked.

[0230] The update unit is used to update the lock lease expiration time based on the current monotonic clock value and the adjusted remaining lock validity period.

[0231] In some embodiments, the adjustment unit is used to take the minimum value of the locally recorded remaining lock validity period length and the remaining lock validity period length returned from the server as the adjusted remaining lock validity period length.

[0232] Without introducing a new distributed cluster, the existing distributed cluster storage capacity is utilized to achieve distributed storage, retrieval, negotiation during failures, and state repair capabilities for distributed lock states.

[0233] Figure 11 For a description of the features in the corresponding embodiments, please refer to Figure 7 The relevant descriptions of the corresponding embodiments will not be repeated here.

[0234] As can be seen from the above technical solution, the main server receives lock operation requests initiated by the lock client, carrying lock object information. This lock object information includes the lock number, lock acquirer identifier, lock version number, and lock lease period version number; the lock lease period version number is determined based on the monotonic clock value of the lock client. Based on the lock operation request and the lock status recorded in the placement group, the main server executes the lock operation and determines the lock operation result. The lock operation result is then fed back to the lock client so that the client can execute a corresponding acknowledgment operation. In this technical solution, determining the lock lease period version number based on the monotonic clock value prevents the problem of dual-controller writes to the same resource in scenarios involving clock jumps or inconsistencies between dual controller clocks, thus achieving precise lock management. The lock server includes a main server and slave servers. The placement group adopts a replica mode, with each lock server having its own replica for recording lock status. When a lock client operates on a lock instance, it only needs to communicate with the main server. The main server will combine the lock status recorded in the placement group, execute the corresponding operation, and feed back the lock operation result to the lock client. The entire implementation process does not require the introduction of a new distributed cluster, which effectively reduces the complexity of operation and maintenance.

[0235] 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-described distributed lock management method embodiments.

[0236] 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 distributed lock management method embodiments at runtime.

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

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

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

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

[0241] The foregoing has provided a detailed description of the method, apparatus, electronic device, computer-readable storage medium, and computer program product for distributed lock management 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 only intended to aid in understanding the method and core ideas of this application. 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 this application.

Claims

1. A method for distributed lock management, characterized in that, Applicable to lock clients, the method includes: Upon detecting a pending task, the corresponding lock object information is obtained; wherein, the lock object information includes lock number, locker identifier information, lock version number, and lock lease period version number; the lock lease period version number is determined based on the monotonic clock value of the lock client; Based on the task type of the task to be processed and the lock object information, a lock operation request is initiated to the main server of the lock service, so that the main server can perform the lock operation and determine the lock operation result according to the lock operation request and the lock status recorded in the placement group, and then feed back the lock operation result to the lock client. Obtain the lock operation result fed back by the main server, and execute the receipt operation that matches the lock operation result.

2. The method for managing distributed locks according to claim 1, characterized in that, Based on the task type of the task to be processed and the lock object information, a lock operation request is initiated to the main server of the lock service, including: If the task type of the task to be processed is a locking task, a locking request carrying the lock object information is sent to the main server, and the local monotonic clock value is recorded. If the task type of the pending task is a renewal task, a renewal request carrying the lock object information is sent to the main server, and the local monotonic clock value is recorded. If the task type of the task to be processed is an unlocking task, an unlocking request carrying the lock object information is sent to the main server.

3. The method for managing distributed locks according to claim 1, characterized in that, If the lock operation request is a lock acquisition request, obtain the lock operation result returned by the main server, and execute a receipt operation matching the lock operation result, including: If the lock operation result is successful, record the lock lease expiration time based on the monotonic clock value recorded when the lock request was sent and the lock validity period; start the lease refresh timer task and send a successful lock response message to the business component; If the lock operation results in the lock being preempted or the locking being refused, a lock acquisition failure response message is sent to the business component. If the lock operation result is "service busy", wait for a set time and then re-initiate the lock request; If the lock operation results in a request timeout, the client lease timeout flag is set according to the locker identifier information, and a lock failure response message is sent back to the business component. If the lock operation results in an internal service error, a lock acquisition failure response message is sent to the business component.

4. The method for managing distributed locks according to claim 1, characterized in that, If the lock operation request is a renewal request, obtain the lock operation result returned by the main server, and execute a receipt operation matching the lock operation result, including: If the lock operation results in a successful renewal, the lock lease expiration time is updated based on the monotonic clock value recorded when the renewal request was sent and the renewal validity period, and the next renewal event is registered. If the lock operation results in the lock being preempted, stop the lease refresh scheduled task; send a preempted lock response message to the business component and initiate an unlock request; If the lock operation result is "service busy", wait for the set time and then re-initiate the renewal request; If the lock operation results in a request timeout or an internal service error, register the next renewal event and, if the local lease times out, send a response message to the business component that the lock has expired. If the lock operation results in a refusal to renew the lease, the lease refresh scheduled task is stopped, and a response message indicating that the lock has expired is sent to the business component.

5. The method for managing distributed locks according to claim 1, characterized in that, If the lock operation request is an unlock request, obtain the lock operation result returned by the main server, and execute the receipt operation matching the lock operation result, including: If the lock operation results in successful unlocking, a successful unlocking response message is sent to the business component. If the lock operation result is "service busy", wait for the set time and then re-initiate the unlock request; If the lock operation results in a request timeout, set a client timeout flag for the lease and send a timeout error code to the business component. If the lock operation results in an internal service error, an internal error code is sent back to the business component.

6. A method for distributed lock management, characterized in that, Applicable to the main server, the method includes: Receive a lock operation request initiated by a lock client, carrying lock object information; wherein, the lock object information includes lock number, locker identification information, lock version number, and lock lease period version number; the lock lease period version number is determined based on the monotonic clock value of the lock client; Based on the lock operation request and the lock status recorded in the reset group, perform the lock operation and determine the lock operation result; The lock operation result is fed back to the lock client so that the client can execute an acknowledgment operation that matches the lock operation result.

7. The method for managing distributed locks according to claim 6, characterized in that, Before performing the lock operation and determining the lock operation result based on the lock operation request and the lock state recorded in the reset group, the process also includes: Determine whether the locker identifier information carried in the lock operation request is the same as the locker identifier information of the current lock; If the locker identifier information carried in the lock operation request is different from the locker identifier information of the current lock, determine whether the lock version number carried in the lock operation request is greater than the lock version number of the current lock; If the locker identifier information carried in the lock operation request is different from the locker identifier information of the current lock and the lock version number carried in the lock operation request is greater than the lock version number of the current lock, then the operation steps of performing a lock operation and determining the lock operation result are executed according to the lock operation request and the lock status recorded in the placement group. If the locker identifier information carried in the lock operation request is the same as the locker identifier information of the current lock, determine whether the lock version number carried in the lock operation request is greater than the lock version number of the current lock, or whether the lock version number carried in the lock operation request is equal to the lock version number of the current lock and whether the version number of the lock lease period carried in the lock operation request is greater than or equal to the version number of the lock lease period of the current lock. If the lock version number carried in the lock operation request is greater than the lock version number of the current lock, or if the lock version number carried in the lock operation request is equal to the lock version number of the current lock and the version number of the lock lease period carried in the lock operation request is greater than or equal to the version number of the lock lease period of the current lock, then the operation steps of performing a lock operation and determining the lock operation result are executed according to the lock operation request and the lock status recorded in the reset group.

8. The method for managing distributed locks according to claim 6, characterized in that, Also includes: When the primary server becomes the new primary server after a master-slave server switch, acquire the lock status; If the lock is in the released state, set the remaining lock validity period recorded locally to zero; When the lock is in a locked state, adjust the remaining lock validity period recorded locally based on the remaining lock validity period recorded locally and the remaining lock validity period returned from each server; update the lock lease expiration time based on the current monotonic clock value and the adjusted remaining lock validity period.

9. The method for managing distributed locks according to claim 8, characterized in that, Based on the remaining lock validity period recorded locally and the remaining lock validity periods returned from the server, adjust the remaining lock validity period recorded locally, including: The minimum of the locally recorded remaining lock validity period and the remaining lock validity period returned from the server is used as the adjusted remaining lock validity period.

10. A device for distributed lock management, characterized in that, Applicable to lock clients, the device includes an information acquisition unit, an initiation unit, and an execution unit; The information acquisition unit is used to acquire corresponding lock object information when a task to be processed is detected; wherein, the lock object information includes lock number, locker identification information, lock version number and lock lease period version number; the lock lease period version number is determined based on the monotonic clock value of the lock client; The initiating unit is used to initiate a lock operation request to the main server of the lock service based on the task type of the task to be processed and the lock object information, so that the main server can perform the lock operation and determine the lock operation result according to the lock operation request and the lock status recorded in the placement group, and feed back the lock operation result to the lock client. The execution unit is used to obtain the lock operation result fed back by the main server and execute the acknowledgment operation that matches the lock operation result.

11. An electronic device, characterized in that, include: 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 5 when executing the computer program.

12. 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 5.

Images