Computer-implemented method of distributed management of locks, apparatus for distributed management of locks and computer program product

Abstract

A computer-implemented method of distributed management of locks includes: receiving, by a plurality of servers, a plurality of concurrent requests; performing lock preemption on the distributed lock using a synchronization mechanism; only one server uses a synchronization mechanism to obtain the distributed lock; updating the lock value of the distributed lock by only one server; and executing the business logic. Lock preemption is performed on the distributed lock by the respective server, including comparing a current memory value of the distributed lock to an expected value. The method further comprises the steps that if the current memory value is matched with the expected value, only one server modifies the current memory value into an updated value; writing the updated value into a memory of the distributed lock; and if the execution of the service logic fails, recovering the memory value of the distributed lock to the current memory value.

Description

Technical Field

[0001] The present invention relates to data processing technology, and in particular to a computer-implemented method for distributed management of locks, a device for distributed management of locks, and a computer program product. Background Art

[0002] In a distributed computing environment, where multiple servers or processes need to coordinate their activities, the concept of locks plays a vital role. Locks are synchronization mechanisms that restrict access to shared resources, allowing only one entity to access a shared resource at a time. Distributed lock management becomes increasingly important when multiple servers or processes contend for shared resources simultaneously. Summary of the invention

[0003] On the one hand, the present disclosure provides a computer-implemented method for distributed management of locks, comprising: receiving multiple concurrent requests by multiple servers; performing lock preemption on the distributed lock by the multiple servers using a synchronization mechanism; acquiring the distributed lock by only one of the multiple servers using the synchronization mechanism; updating the lock value of the distributed lock by the only one server; and executing business logic; wherein, performing lock preemption on the distributed lock by a corresponding server among the multiple servers includes comparing the current memory value of the distributed lock with an expected value; wherein the method further comprises: if the current memory value matches the expected value, modifying the current memory value to an updated value by the only one server; writing the updated value to the memory of the distributed lock by the only one server; and if the execution of the business logic fails, restoring the memory value of the distributed lock to the current memory value by the only one server; and recording the operation of restoring the memory value by the only one server.

[0004] Optionally, the corresponding server among the multiple servers performs lock preemption on the distributed lock, further comprising: if the current memory value of the distributed lock does not match the expected value, keeping the current memory value unchanged.

[0005] Optionally, the corresponding server among the multiple servers performs lock preemption on the distributed lock, and also includes providing a CPU instruction by the processor, and the CPU instruction automatically compares the current memory value of the distributed lock with the expected value, and updates the current memory value if the comparison is successful.

[0006] Optionally, the method further includes: after restoring the memory value of the distributed lock to the current memory value, releasing the distributed lock.

[0007] Optionally, the method also includes: using Redis as the underlying data storage and coordination mechanism for the distributed lock; wherein each distributed lock is represented by a specific key-value pair in Redis, wherein the key represents a lock identifier and the value represents a lock state or value; applying a compare and exchange principle to the Redis key-value pair representing the distributed lock; and when the corresponding server attempts to preempt the lock, the corresponding server performs a compare and exchange operation on the lock value stored in Redis.

[0008] Optionally, the method further includes: utilizing Lua scripts to perform automatic operations and business logic on Redis data.

[0009] Optionally, the method further includes: recording, by the only one server, an operation of restoring the memory value.

[0010] On the other hand, the present disclosure provides a device for distributed management of locks, comprising: a data storage and coordination mechanism for distributed locks; and multiple servers; wherein the multiple servers are configured to: receive multiple concurrent requests; and use a synchronization mechanism to perform lock preemption on the distributed lock; wherein only one of the multiple servers is configured to: use the synchronization mechanism to acquire the distributed lock; update the lock value of the distributed lock; and execute business logic; wherein the corresponding server among the multiple servers is configured to: compare the current memory value of the distributed lock with the expected value; wherein the only one of the multiple servers is configured to: if the current memory value matches the expected value, modify the current memory value to an updated value; write the updated value to the memory of the distributed lock; and if the execution of the business logic fails, restore the memory value of the distributed lock to the current memory value.

[0011] Optionally, the corresponding server among the multiple servers is configured to: if the current memory value of the distributed lock does not match the expected value, keep the current memory value unchanged.

[0012] Optionally, the corresponding server among the plurality of servers is configured to provide a CPU instruction, which automatically compares the current memory value of the distributed lock with the expected value, and updates the current memory value if the comparison is successful.

[0013] Optionally, the only one server among the multiple servers is configured to release the distributed lock after restoring the memory value of the distributed lock to the current memory value.

[0014] Optionally, the data storage and coordination mechanism for the distributed lock is Redis; wherein each distributed lock is represented by a specific key-value pair in Redis, wherein the key represents a lock identifier and the value represents a lock state or value; a compare and exchange principle is applied to the Redis key-value pair representing the distributed lock; and when the corresponding server attempts to preempt the lock, the corresponding server is configured to perform a compare and exchange operation on the lock value stored in Redis.

[0015] Optionally, the multiple servers are configured to utilize Lua scripts to perform automatic operations and business logic on Redis data.

[0016] Optionally, the only one server among the plurality of servers is further configured to record an operation of restoring the memory value.

[0017] On the other hand, the present disclosure provides a computer program product, comprising a non-temporary tangible computer-readable medium having computer-readable instructions thereon, wherein the computer-readable instructions are executable by one or more processors to cause the one or more processors to: cause multiple servers to receive multiple concurrent requests; cause the multiple servers to perform lock preemption on a distributed lock using a synchronization mechanism; cause only one of the multiple servers to acquire the distributed lock using the synchronization mechanism; cause the only one server to update the lock value of the distributed lock; and cause the only one server to execute business logic; wherein the computer-readable instructions are executable by the processor to cause the processor to: cause the corresponding server of the multiple servers to compare the current memory value of the distributed lock with an expected value; wherein the computer-readable instructions are executable by the processor to cause the processor to: if the current memory value matches the expected value, cause the only one server to modify the current memory value to an updated value; cause the only one server to write the updated value to the memory of the distributed lock; and if the execution of the business logic fails, cause the only one server to restore the memory value of the distributed lock to the current memory value.

[0018] Optionally, the computer-readable instructions are executable by one or more processors to cause the one or more processors to execute: if the current memory value of the distributed lock does not match the expected value, causing the corresponding server among the multiple servers to keep the current memory value unchanged.

[0019] Optionally, the computer-readable instructions are executable by one or more processors to cause the one or more processors to perform: providing CPU instructions that automatically compare the current memory value of the distributed lock with the expected value, and update the current memory value if the comparison is successful.

[0020] Optionally, the computer-readable instructions are executable by one or more processors to cause the one or more processors to execute: after restoring the memory value of the distributed lock to the current memory value, releasing the distributed lock.

[0021] Optionally, the computer program product includes: Redis as the underlying data storage and coordination mechanism for the distributed lock; wherein each distributed lock is represented by a specific key-value pair in Redis, wherein the key represents a lock identifier and the value represents a lock state or value; a compare and exchange principle is applied to the Redis key-value pair representing the distributed lock; and when the corresponding server attempts to seize the lock, the corresponding server performs a compare and exchange operation on the lock value stored in Redis.

[0022] Optionally, the non-transitory tangible computer-readable medium having computer-readable instructions includes: a Lua script for performing automated operations and business logic on Redis data.

[0023] Optionally, the computer readable instructions are executable by a processor to cause the processor to further execute: causing the only one server to record an operation of restoring the memory value. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] According to various disclosed embodiments, the following drawings are examples only for illustration purposes and are not intended to limit the scope of the present invention.

[0025] Figure 1 The implementation of a distributed lock in some embodiments according to the present disclosure is shown.

[0026] Figure 2 An implementation of a compare and swap execution process in some embodiments according to the present disclosure is shown.

[0027] Figure 3 A computer-implemented method for distributed management of locks according to some embodiments of the present disclosure is shown.

[0028] Figure 4 is a flow chart illustrating a computer-implemented method of distributed management of locks in accordance with some embodiments of the present disclosure.

[0029] Figure 5 A computer-implemented method for distributed management of locks according to some embodiments of the present disclosure is shown.

[0030] Figure 6 is a flow chart illustrating a computer-implemented method of distributed management of locks in accordance with some embodiments of the present disclosure.

[0031] Figure 7 is a flow chart illustrating a computer-implemented method of distributed management of locks in accordance with some embodiments of the present disclosure.

[0032] Figure 8 is a flow chart illustrating a computer-implemented method of distributed management of locks in accordance with some embodiments of the present disclosure. DETAILED DESCRIPTION

[0033] The present disclosure will now be described in more detail with reference to the following examples. It should be noted that the following description of some of the embodiments presented herein is for illustration and description purposes only. It is not intended to be exhaustive or limited to the precise form disclosed.

[0034] The present disclosure provides, among other things, a computer-implemented method for distributed management of locks, an apparatus for distributed management of locks, and a computer program product, which substantially eliminate one or more problems caused by limitations and disadvantages of the prior art. In one aspect, the present disclosure provides a computer-implemented method for distributed management of locks. In some embodiments, the method includes: receiving multiple concurrent requests by multiple servers; performing lock preemption on distributed locks by multiple servers using a synchronization mechanism; acquiring distributed locks by only one of the multiple servers using a synchronization mechanism; updating the lock value of the distributed lock by only one server; and executing business logic. Optionally, performing lock preemption on the distributed lock by a corresponding server among the multiple servers includes: comparing the current memory value of the distributed lock with the expected value. Optionally, the method also includes: if the current memory value matches the expected value, modifying the current memory value to the updated value by only one server; writing the updated value to the memory of the distributed lock by only one server; if the execution of the business logic fails, restoring the memory value of the distributed lock to the current memory value by only one server; and recording the operation of restoring the memory value by only one server.

[0035] In the case of a single-machine deployment of a monolithic application, if you need to synchronize access to shared variables in a multi-threaded manner, you can use concurrency-related features for mutual exclusion control. However, in the case of multi-instance deployment, where multiple threads and processes of a distributed system are distributed on different machines, the concurrency control lock strategy used in the original single-machine deployment becomes invalid. Distributed locks are needed to solve this problem. Distributed locks are a mechanism used to achieve mutual exclusion in a distributed system, which ensures that only one node or process can access a shared resource at any given time. In a distributed system, multiple nodes or processes may try to access the same resource at the same time, and distributed locks ensure that only one of them can acquire a lock on the resource, thereby ensuring mutual exclusion. Distributed locks have several advantages.

[0036] Figure 1 The implementation of a distributed lock in some embodiments of the present disclosure is shown. Figure 1 , making multiple concurrent requests to acquire the lock. Figure 1 In the example shown, multiple concurrent requests are made using the SETNX command in Redis to acquire a lock. Redis (Remote Dictionary Server) is an open source memory-based data structure storage that is widely used as a distributed cache, message broker, and database. The SETNX ("Set if Not Exists") command is a command commonly found in key-value stores including Redis that allows the value of a key to be set when the key does not yet exist in the database. It provides a way to perform an automatic operation that creates a key-value pair only when the key does not yet exist. The SETNX command takes two arguments: key and value. It attempts to set the value of the key to a given value only when the specified key does not exist. If the key already exists, the command is invalid and returns a result indicating that the key has not been set. The purpose of SETNX is to provide an idempotent operation for creating a key, ensuring that the creation of a key-value pair is performed automatically without the risk of overwriting existing data. If the key does not exist, the command sets the value of the key to the specified value and returns a result indicating a successful operation (e.g., 1 or "OK"). If the key already exists, the command has no effect; the value of the key remains unchanged, and a result indicating the failure of the operation (e.g., 0 or a null value) is returned.

[0037] In the context of a database or key-value store such as Redis, a "key" refers to a unique identifier used to access or reference a specific data or value stored in the database. In a key-value store, data is organized in a simple key-value format, where each value is associated with a unique key. The key serves as an identifier or handle that allows the corresponding value to be retrieved or manipulated. For example, in Redis, which is a popular memory-based data structure store, data can be stored using key-value pairs. The key can be a string, and the value can be any supported data type, such as a string, a number, a list, a set, or even more complex data structures such as hashes or ordered sets. You can use the key to perform various operations, such as retrieving a value, updating a value, or deleting a key-value pair. Keys in a database or key-value store are generally used to provide efficient and fast access to data. They should be unique within the scope of the database or the specific data structure used to allow fast retrieval and manipulation of the associated values.

[0038] When a process or node acquires a key associated with a distributed lock, it effectively gains the ability to acquire and hold the lock, thereby granting exclusive access to a shared resource or critical section. In a distributed lock mechanism, a lock is typically associated with a specific key or identifier. Acquiring a key means that the process or node has obtained the necessary permission or authorization to acquire the corresponding distributed lock. Once a lock is acquired by holding the associated key, it means that the process or node has obtained exclusive access to the shared resource, and other processes or nodes attempting to acquire the same lock (using the same key) will be blocked or denied access until the lock is released. Granting a key means granting the acquisition of a distributed lock, allowing the key holder to control and regulate access to shared resources in a distributed system.

[0039] Refer again Figure 1 , if the key does not exist, the SETNX command is used to set the key (for acquiring the lock). Only one request successfully sets the key and acquires the lock, while the other requests fail to acquire the lock.

[0040] For requests that successfully acquire the lock, the Redis EXPIRE command is used to set the timeout for the lock. This ensures that if the request does not manually remove the lock, the lock will be automatically released after a certain duration.

[0041] The request then continues to the server interface to perform the desired operation. If the request to the server interface succeeds and returns the expected result, the request can return the result to the caller. If the request to the server interface times out or fails to execute, indicating a failure, the request should delete the lock using the DEL command in Redis to release the lock, and then return a failure response to the caller.

[0042] The inventors of the present disclosure have discovered that Figure 1 The approach depicted in , with two steps (SETNX and EXPIRE), lacks automation. For example, if the service is down, the lock may encounter problems. The term "automatically" refers to an operation or sequence of operations that is guaranteed to occur indivisibly and without interference from concurrent operations. An automatic operation is one that appears to occur instantaneously, as if it were a single, uninterruptible step, even in the presence of concurrent access or interruptions from other threads or processes. The concept of automation is closely related to the ideas of consistency and correctness in concurrent or parallel execution. It ensures that a sequence of operations or critical sections of code are executed in a way that maintains integrity, avoids race conditions, and maintains the desired state or properties of the system. When an operation is executed automatically, it means that it either completes successfully as a whole or has no effect at all. There are no partial or intermediate states that are visible to other threads or processes. This property is critical to maintaining data integrity, preventing data corruption, and ensuring predictable and correct behavior in concurrent systems.

[0043] The inventor of the present disclosure has found that the method of using SETNX and EXPIRE as separate operations may result in a situation where a lock is created but not properly released if the requesting process exits unexpectedly or crashes. This may result in a deadlock, in which subsequent requests cannot acquire the lock, causing the lock to persist indefinitely.

[0044] The inventors of the present disclosure have also discovered that if request A acquires a lock, but its business operation takes longer than the lock timeout, request B may acquire the lock and start its own business logic. When request A is finally completed and attempts to release the lock, it will inadvertently release the lock held by request B, which destroys the integrity of the distributed lock mechanism.

[0045] Figure 2 The implementation of the compare and swap execution process in some embodiments of the present disclosure is shown. Compare and swap (CAS) is a concurrency control technique used in parallel and distributed computing to implement automatic and non-blocking operations on shared variables or memory locations. The CAS operation allows the current value of a variable to be automatically compared with the expected value, and if they match, the variable is updated to the new value. CAS is a basic building block for implementing synchronization primitives such as locks, automatic operations, and optimistic concurrency control mechanisms. During the execution of compare and swap, the current value of the variable is compared with the expected value. If the comparison is successful (the value matches), the operation proceeds to the next step. Otherwise, it means that the value has changed in the meantime and the operation fails. If the comparison is successful, the variable is updated to the new expected value. The operation returns a result indicating whether the update is successful. It usually returns a Boolean value indicating success or failure.

[0046] CAS operations are designed to be executed automatically without blocking other operations. They provide a way to achieve synchronization and consistency in a concurrent environment without using traditional locks or blocking mechanisms. The inventors of the present disclosure have found that CAS is particularly useful in situations where multiple threads or processes can access and modify shared variables at the same time. By using CAS, race conditions and inconsistencies caused by concurrent updates can be avoided or properly handled.

[0047] Reference Figure 2, once the current value of the memory location ("memory value V") is read, in some embodiments, the process includes: comparing the memory value V with the expected value A. If the comparison is successful (the value matches), in some embodiments, the process includes: modifying the memory value V to the updated value B, and writing the updated value B to the memory location. The CAS operation returns a result indicating whether the exchange is successful. Typically, it returns a Boolean value indicating success or failure. If the comparison fails (the value does not match), in some embodiments, the process includes: returning the current value stored at the memory location because it does not match the expected value A. During the CAS process, if the memory value V matches the expected value A, the updated value B is placed at the memory location. If the memory value V does not match the expected value A, the value at the memory location is not modified.

[0048] The inventors of the present disclosure have discovered that the ABA problem exists in the CAS process. Specifically, the ABA problem in CAS is the following situation: a memory location or shared variable undergoes a series of changes and eventually obtains the same value it originally had, resulting in potential inconsistency or unexpected behavior when using CAS. The ABA problem may occur when multiple threads or processes attempt to perform a CAS operation on the same memory location at the same time. For example, thread T1 reads the current value of a memory location and obtains the value "A". At the same time, thread T2 interrupts thread T1 and performs a series of operations so that the memory location changes from "A" to "B" and then back to "A". Subsequently, thread T1 resumes execution and performs a CAS operation, comparing the current value ("A") with the matching expected value ("A"). Therefore, thread T1 assumes that no other thread has modified the memory location and continues to update it to the new value. In this case, thread T1 successfully performs a CAS operation, even if the storage unit has been modified during this period. This situation may lead to unexpected behavior and inconsistency because thread T1 is unaware of the intermediate changes that have occurred.

[0049] Figure 3 A computer-implemented method for distributed management of locks according to some embodiments of the present disclosure is shown. Figure 4 is a flow chart illustrating a computer-implemented method for distributed management of locks according to some embodiments of the present disclosure. Figure 3 and Figure 4 In some embodiments, the method includes: receiving multiple concurrent requests by multiple servers; performing lock preemption on distributed locks by multiple servers using the compare and exchange principle; acquiring the distributed lock by only one server among the multiple servers using the compare and exchange principle; and performing an insert operation into the database by only one server.

[0050] like Figure 3As shown, in some embodiments, the plurality of servers include N servers, including server 1, server 2, ..., server n, ..., server (N-1), and server N. Each server is treated as a service, and a distributed lock mechanism combined with a comparison and exchange principle is utilized to ensure that only one server acquires the lock at a time. Once the server has acquired the lock, it performs an insert operation into the database. The inventors of the present disclosure have found that the method helps prevent conflicts and ensures that only one server / service can perform an insert operation at any given time. When a server holds a lock and performs an insert operation, other servers attempting to acquire the lock will be blocked or denied access. They will keep retrying until the lock becomes available. Once the server completes the insert operation and releases the lock, another server / service can acquire the lock and perform its own insert operation.

[0051] Lock preemption refers to the ability of another server or service to interrupt or preempt the lock ownership of a server or service. For example, lock preemption can mean that if a server has already acquired a lock, it can be preempted or interrupted by another server with a higher priority or in a more critical state. When a server attempts to acquire a lock, it checks whether any other server currently holds the lock. If the lock is already held by another server / service, the acquiring server evaluates its priority or urgency compared to the current lock holder. If the acquiring server has a higher priority, it preempts the lock ownership from the current lock owner and enters the critical section (a specific part of a program or code that must be executed automatically or in a mutually exclusive manner). Lock ownership is transferred from the current lock holder to the acquiring server. The preempted server is notified that it has lost the lock and should release any resources related to the critical section that it holds. The preempted server can then retry acquiring the lock at a later time or based on a predefined retry mechanism.

[0052] Figure 5 A computer-implemented method for distributed management of locks according to some embodiments of the present disclosure is shown. Figure 6 is a flow chart illustrating a computer-implemented method for distributed management of locks according to some embodiments of the present disclosure. Figure 5 and Figure 6 In some embodiments, the method includes: receiving multiple concurrent requests by multiple servers; performing lock preemption on the distributed lock by the multiple servers using the comparison and exchange principle; acquiring the distributed lock by only one server among the multiple servers using the comparison and exchange principle; updating the lock value of the distributed lock by only one server; and executing business logic.

[0053] In some embodiments, a corresponding server among a plurality of servers uses a comparison and exchange principle to perform lock preemption on a distributed lock, including: comparing a current memory value of the distributed lock with an expected value. In some embodiments, the method further includes: if the current memory value matches the expected value, only one of the plurality of servers modifies the current memory value to an updated value; and only one of the plurality of servers writes the updated value to the memory of the distributed lock. Optionally, a corresponding server among the plurality of servers uses a comparison and exchange principle to perform lock preemption on a distributed lock, further including: if the current memory value does not match the expected value, keeping the current memory value of the distributed lock unchanged. In some embodiments, the operation involves a CPU instruction that automatically compares the current memory value of the distributed lock with the expected value, and updates the current memory value if the comparison is successful. The processor typically provides built-in support for automatic operations (including comparison and exchange) through dedicated CPU instructions. These instructions ensure that the operation is performed automatically, meaning that the operation is indivisible and cannot be interrupted by other threads or processes.

[0054] In some embodiments, the method further includes: if the execution of the business logic fails, the memory value of the distributed lock is restored to the current memory value ("its old value") by only one of the multiple servers; and the operation of restoring the memory value is recorded by only one of the multiple servers. By recording the operation of restoring the memory value, relevant information about the operation can be stored in a log or audit trail. Optionally, the relevant information includes details such as timestamps, lock identifiers, old values, and any other relevant information you want to track for auditing or debugging purposes. Various appropriate algorithms can be used to restore the memory value. Examples of appropriate algorithms include rollback mechanisms, undo operations, or transaction processing methods to ensure that any modifications made during unsuccessful execution of the business logic are reliably and efficiently restored.

[0055] In some embodiments, the method further includes: after restoring the memory value of the distributed lock to the current memory value, releasing the distributed lock. Releasing the distributed lock allows other processes or threads to acquire it.

[0056] Various suitable data storage and coordination mechanisms may be implemented in the present disclosure. Examples of suitable data storage and coordination mechanisms include Zookeeper, Kafka, etcd, Consul, DynamoDB, Cosmo DB, and Redis.

[0057] In some embodiments, the method further includes: utilizing Redis as the underlying data storage and coordination mechanism for distributed locks. For example, Redis is used as a storage medium for maintaining the state of distributed locks, and provides the necessary capabilities for concurrent access control, automatic operation, and logging. Each distributed lock is represented by a specific key-value pair in Redis, where the key represents a lock identifier and the value represents a lock state or value.

[0058] In some embodiments, the CAS principle is applied to Redis key-value pairs representing distributed locks. When the corresponding server attempts to seize the lock, it performs a CAS operation on the lock value stored in Redis. This operation compares the current value with the expected value and updates the value if the comparison is successful, thereby ensuring exclusive lock acquisition.

[0059] In some embodiments, in the case of business logic failure or other abnormal situations, the method can use Redis commands or transactions to restore the memory value of the distributed lock in Redis. This ensures that the lock value is restored to its previous state, thereby maintaining data consistency.

[0060] In some embodiments, Redis provides features for logging and auditing operations. In some embodiments, the method can utilize Redis's logging mechanism to log relevant lock management operations (including lock value recovery). This enables tracking, analysis, and auditing of lock-related activities.

[0061] The inventors of the present disclosure have found that by combining CAS principles to utilize Redis, the method benefits from Redis's efficient data storage and retrieval capabilities, concurrent access control, and logging features. Redis provides a robust foundation for implementing distributed lock management, ensuring scalability, data consistency, and operational transparency.

[0062] Various suitable scripting languages ​​may be implemented in the present disclosure. Examples of suitable scripting languages ​​include JavaScript, Python, Ruby, Perl, PHP, Go, and Lua.

[0063] In some embodiments, the method further includes: using Lua scripts to perform automatic operations and business logic on Redis data. Redis provides scripting capabilities through the Lua programming language. Lua scripts can be executed within Redis, allowing complex operations to be performed on Redis data in an automatic manner. The inventors of the present disclosure have found that Lua scripts can be used to implement a CAS-based lock preemption mechanism within Redis. Lua scripts can perform a comparison of the current lock value with the expected value, and update the value if the comparison is successful, all in automatic operation. The inventors of the present disclosure have found that this ensures that only one server successfully acquires the lock. Lua scripts within Redis provide the flexibility to execute complex business logic in the context of distributed lock management. The inventors of the present disclosure have found that when a Lua script is executed, it is automatically executed and will not be interrupted by other requests. This ensures the automatic execution of multiple consecutive instructions within the Lua script, maintaining the integrity of the task.

[0064] By leveraging Lua scripts to perform automated operations and business logic on Redis data, this method uses Lua scripts to retrieve the current memory value and check if it is not equal to the expected value. If the check passes, the update is allowed to occur. This approach helps avoid the CAS (compare and swap) ABA problem.

[0065] In some embodiments, the Lua script evaluates the conditions and performs the necessary operations to determine whether the lock can be acquired. If the conditions are met and the lock is successfully acquired, the Lua script returns a result of 1, indicating that the lock is successfully acquired and the memory value is updated (returning "true"). If the Lua script returns a result other than 1, it means that the lock has been acquired by another instance and the current request is unsuccessful in acquiring the lock. In this case, the method directly returns "false" to indicate that the lock acquisition failed. By combining this logic in the Lua script, the method ensures that only one instance can successfully acquire the lock and update the memory value, and other instances are notified of unsuccessful attempts.

[0066] In one example, the method includes: executing a data insertion function at a specific time (e.g., at dawn) every day. For example, the method takes two parameters: a first parameter "curr", which is used to obtain the current date when the execution is triggered; a second parameter "old", which is used to retrieve the original memory value of the lock. Using the CAS principle, if the value provided as the first parameter is not equal to the value of the second parameter, it means that the lock has not been acquired by another thread. The current thread can successfully acquire the lock and continue to execute the business logic. In the event of an error or exception during the execution of the business logic, the method also includes: restoring the value of the lock to the old value and recording the operation. By restoring the lock value to its previous state, the method ensures the integrity of the lock and maintains consistency in the event of a failure or error during the execution of the business logic.

[0067] Figure 7 is a flow chart illustrating a computer-implemented method for distributed management of locks according to some embodiments of the present disclosure. Figure 7 In some embodiments, the method includes: receiving multiple concurrent requests by multiple servers; performing lock preemption on a distributed lock by the multiple servers using a synchronization mechanism; acquiring the distributed lock by only one server among the multiple servers using a synchronization mechanism; updating the lock value of the distributed lock by only one server; and executing business logic.

[0068] A synchronization mechanism is a technique for coordinating and controlling concurrent access to shared resources, ensuring that multiple threads or processes can safely access and manipulate resources without conflicts or data corruption. It helps maintain data integrity and order in a multithreaded or distributed environment. Various appropriate synchronization mechanisms can be implemented in the present disclosure. Examples of appropriate synchronization mechanisms include locking, signaling, barriers, automatic operations, and read-write locks.

[0069] Figure 8 is a flow chart illustrating a computer-implemented method for distributed management of locks according to some embodiments of the present disclosure. Figure 8 In some embodiments, the method includes: receiving multiple concurrent requests by multiple servers; performing lock preemption on a distributed lock by the multiple servers using automatic operations; acquiring the distributed lock by only one of the multiple servers using automatic operations; updating the lock value of the distributed lock by only one server; and executing business logic. Automatic operations are invisible and uninterruptible low-level operations performed on shared memory. These low-level operations ensure that the order of operations occurs automatically, meaning that they are executed as a single uninterruptible unit without interference from other threads or processes. Automatic operations provide consistency and isolation guarantees when multiple threads or processes access shared resources.

[0070] Compare and Swap (CAS) is a specific type of automatic operation that compares the value of a memory location with an expected value and, if the comparison succeeds, swaps it with the new value. CAS is often used as a building block to implement synchronization mechanisms and is an example of an automatic operation. Automatic operations cover a wider range of operations such as automatic read, automatic write, automatic increment, automatic decrement, automatic addition, automatic subtraction, etc. These operations are designed to be guaranteed automatic and provide synchronization semantics at a lower level than high-level synchronization mechanisms. They are usually implemented using hardware support or specific instructions provided by the processor architecture.

[0071] On the other hand, the present disclosure provides a device for distributed management of locks. In some embodiments, the device includes: a data storage and coordination mechanism for distributed locks; and multiple servers. Optionally, the multiple servers are configured to: receive multiple concurrent requests; and perform lock preemption on the distributed lock using a synchronization mechanism. Optionally, only one of the multiple servers is configured to: use a synchronization mechanism to acquire a distributed lock; update the lock value of the distributed lock; and execute business logic. Optionally, the corresponding server of the multiple servers is configured to compare the current memory value of the distributed lock with the expected value. Optionally, only one of the multiple servers is configured to: if the current memory value matches the expected value, modify the current memory value to the updated value; write the updated value to the memory of the distributed lock; if the execution of the business logic fails, restore the memory value of the distributed lock to the current memory value; and record the operation of restoring the memory value.

[0072] In some embodiments, a corresponding server of the plurality of servers is configured to keep the current memory value of the distributed lock unchanged if the current memory value does not match the expected value.

[0073] In some embodiments, a corresponding server of the plurality of servers is configured to provide CPU instructions that automatically compare a current memory value of the distributed lock with an expected value and update the current memory value if the comparison is successful.

[0074] In some embodiments, only one server among the plurality of servers is configured to release the distributed lock after restoring the memory value of the distributed lock to the current memory value.

[0075] In some embodiments, the data storage and coordination mechanism for distributed locks is Redis. Optionally, each distributed lock is represented by a specific key-value pair in Redis, where the key represents a lock identifier and the value represents a lock state or value. Optionally, the compare and swap principle is applied to the Redis key-value pairs representing the distributed locks. Optionally, when the corresponding server attempts to seize the lock, the corresponding server is configured to perform a compare and swap operation on the lock value stored in Redis.

[0076] In some embodiments, multiple servers are configured to utilize Lua scripts to perform automated operations and business logic on Redis data.

[0077] On the other hand, the present disclosure provides a computer program product, including a non-transitory tangible computer-readable medium having computer-readable instructions thereon. In some embodiments, the computer-readable instructions can be executed by one or more processors to cause the one or more processors to perform: causing multiple servers to receive multiple concurrent requests; causing multiple servers to perform lock preemption on distributed locks using a synchronization mechanism; causing only one server among the multiple servers to acquire a distributed lock using a synchronization mechanism; causing only one server to update a lock value of a distributed lock; and causing only one server to execute business logic.

[0078] In some embodiments, the computer readable instructions are executable by a processor to cause the processor to cause a corresponding server of the plurality of servers to compare a current memory value of the distributed lock with an expected value.

[0079] In some embodiments, computer-readable instructions are executable by a processor to cause the processor to perform: if the current memory value matches the expected value, causing only one server to modify the current memory value to the updated value; causing only one server to write the updated value to the memory of the distributed lock; if the execution of the business logic fails, causing only one server to restore the memory value of the distributed lock to the current memory value; and causing only one server to record the operation of restoring the memory value.

[0080] In some embodiments, the computer readable instructions are executable by one or more processors to cause the one or more processors to: if the current memory value does not match the expected value, cause a corresponding server among the plurality of servers to maintain the current memory value of the distributed lock unchanged.

[0081] In some embodiments, the computer readable instructions are executable by one or more processors to cause the one or more processors to perform: providing CPU instructions that automatically compare a current memory value of a distributed lock with an expected value and update the current memory value if the comparison is successful.

[0082] In some embodiments, the computer readable instructions are executable by one or more processors to cause the one or more processors to perform: after restoring the memory value of the distributed lock to the current memory value, releasing the distributed lock.

[0083] In some embodiments, the computer program product includes Redis as the underlying data storage and coordination mechanism for distributed locks. Optionally, each distributed lock is represented by a specific key-value pair in Redis, where the key represents the lock identifier and the value represents the lock state or value. Optionally, the compare and swap principle is applied to the Redis key-value pairs representing the distributed locks. Optionally, when the corresponding server attempts to seize the lock, it performs a compare and swap operation on the lock value stored in Redis.

[0084] In some embodiments, a non-transitory tangible computer-readable medium having computer-readable instructions includes a Lua script for performing automated operations and business logic on Redis data.

[0085] For the purpose of illustration and description, the above description of the embodiments of the present invention has been given. It is not exhaustive, nor is it intended to limit the present invention to the precise form or exemplary embodiments disclosed. Therefore, the foregoing description should be considered illustrative rather than restrictive. Obviously, many modifications and variations will be apparent to those skilled in the art. The embodiments are selected and described to explain the principles of the present invention and its best mode practical application, so that those skilled in the art can understand the various embodiments of the present invention and the various modifications suitable for the specific use or implementation under consideration. The scope of the present invention is intended to be defined by the appended claims and their equivalents, in which all terms are meant to have the broadest reasonable meaning unless otherwise stated. Therefore, the term "the invention, the present invention" and the like do not necessarily limit the scope of the claims to a specific embodiment, and the reference to the exemplary embodiments of the present invention does not mean a limitation of the present invention, and such a limitation should not be inferred. The present invention is limited only by the spirit and scope of the appended claims. In addition, these claims may involve the use of "first", "second", etc., followed by a noun or element. These terms should be understood as nomenclature and should not be interpreted as limiting the number of elements modified by these nomenclatures unless a specific number has been given. Any advantages and benefits described may not apply to all embodiments of the present invention. It should be understood that those skilled in the art may make changes to the described embodiments without departing from the scope of the invention as defined by the appended claims. In addition, none of the elements and assemblies in this disclosure are intended to be dedicated to the public, regardless of whether the element or assembly is explicitly described in the appended claims.

Claims

1. A computer-implemented method for distributed management of locks, include: Multiple concurrent requests are received by multiple servers; The multiple servers use a synchronization mechanism to perform lock preemption on the distributed lock; Acquiring the distributed lock by only one server among the plurality of servers using the synchronization mechanism; Updating the lock value of the distributed lock by the only one server; as well as Execute business logic; wherein, performing lock preemption on the distributed lock by a corresponding server among the plurality of servers comprises comparing a current memory value of the distributed lock with an expected value; Wherein, the method further comprises: If the current memory value matches the expected value, modifying the current memory value to an updated value by the only one server; Writing the updated value into the memory of the distributed lock by the only one server; and If the execution of the business logic fails, the only one server restores the memory value of the distributed lock to the current memory value; and An operation of restoring the memory value is recorded by the only one server.

2. The method according to claim 1, in, The corresponding server among the multiple servers performs lock preemption on the distributed lock, and further includes: if the current memory value of the distributed lock does not match the expected value, keeping the current memory value unchanged.

3. The method according to claim 1, in, The corresponding server among the multiple servers performs lock preemption on the distributed lock, and also includes providing a CPU instruction by a processor, wherein the CPU instruction automatically compares the current memory value of the distributed lock with the expected value, and updates the current memory value if the comparison is successful.

4. The method according to claim 1, further comprising: include: After restoring the memory value of the distributed lock to the current memory value, releasing the distributed lock.

5. The method according to claim 1, further comprising: include: Utilizing Redis as the underlying data storage and coordination mechanism for the distributed lock; Wherein, each distributed lock is represented by a specific key-value pair in Redis, wherein the key represents a lock identifier and the value represents a lock state or value; applying a compare and swap principle to the Redis key-value pair representing the distributed lock; and When the corresponding server attempts to seize the lock, the corresponding server performs a compare and swap operation on the lock value stored in Redis.

6. The method according to claim 1, further comprising: include: Use Lua scripts to perform automatic operations and business logic on Redis data.

7. The method according to claim 1, further comprising: include: An operation of restoring the memory value is recorded by the only one server.

8. A device for distributed management of locks, include: Data storage and coordination mechanisms for distributed locks; as well as Multiple servers; Wherein, the multiple servers are configured as: Receive multiple concurrent requests; and Use synchronization mechanism to perform lock preemption on distributed locks; Wherein, only one server among the multiple servers is configured as: Using the synchronization mechanism to acquire the distributed lock; Updating the lock value of the distributed lock; and Execute business logic; Wherein, a corresponding server among the plurality of servers is configured to: compare a current memory value of the distributed lock with an expected value; Wherein, the only one server among the multiple servers is configured as: If the current memory value matches the expected value, modifying the current memory value to an updated value; Writing the updated value into the memory of the distributed lock; and If the execution of the business logic fails, the memory value of the distributed lock is restored to the current memory value.

9. The device according to claim 8, in, The corresponding server among the multiple servers is configured to: if the current memory value of the distributed lock does not match the expected value, keep the current memory value unchanged.

10. The device according to claim 8, in, The corresponding server of the plurality of servers is configured to provide CPU instructions that automatically compare the current memory value of the distributed lock with the expected value and update the current memory value if the comparison is successful.

11. The device according to claim 8, in, The only one server among the plurality of servers is configured to release the distributed lock after restoring the memory value of the distributed lock to the current memory value.

12. The device according to claim 8, in, The data storage and coordination mechanism for the distributed lock is Redis; Wherein, each distributed lock is represented by a specific key-value pair in Redis, wherein the key represents a lock identifier and the value represents a lock state or value; A compare and swap principle is applied to the Redis key-value pair representing the distributed lock; and When the corresponding server attempts to seize the lock, the corresponding server is configured to perform a compare and swap operation on the lock value stored in Redis.

13. The device according to claim 8, in, The multiple servers are configured to utilize Lua scripts to perform automatic operations and business logic on Redis data.

14. The device according to claim 8, in, The only one of the plurality of servers is further configured to log an operation of restoring the memory value.

15. A computer program product comprising a non-transitory tangible computer-readable medium having computer-readable instructions thereon, in, The computer readable instructions are executable by one or more processors to cause the one or more processors to: Enable multiple servers to receive multiple concurrent requests; Enable the multiple servers to perform lock preemption on the distributed lock using a synchronization mechanism; Enable only one server among the multiple servers to acquire the distributed lock using the synchronization mechanism; causing the only one server to update the lock value of the distributed lock; and enabling the only one server to execute the business logic; The computer readable instructions are executable by a processor to cause the processor to perform: causing a corresponding server among the plurality of servers to compare a current memory value of the distributed lock with an expected value; The computer readable instructions are executable by a processor to cause the processor to perform: If the current memory value matches the expected value, causing the only one server to modify the current memory value to an updated value; causing the only one server to write the updated value into the memory of the distributed lock; and If the execution of the business logic fails, the only one server is enabled to restore the memory value of the distributed lock to the current memory value.

16. The computer program product according to claim 15, in, The computer-readable instructions are executable by one or more processors to cause the one or more processors to execute: if the current memory value of the distributed lock does not match the expected value, causing the corresponding server among the plurality of servers to keep the current memory value unchanged.

17. The computer program product according to claim 15, in, The computer readable instructions are executable by one or more processors to cause the one or more processors to perform: providing CPU instructions that automatically compare the current memory value of the distributed lock with the expected value, and update the current memory value if the comparison is successful.

18. The computer program product according to claim 15, in, The computer-readable instructions are executable by one or more processors to cause the one or more processors to perform: after restoring the memory value of the distributed lock to the current memory value, releasing the distributed lock.

19. The computer program product according to claim 15, include: Redis as the underlying data storage and coordination mechanism for the distributed lock; Wherein, each distributed lock is represented by a specific key-value pair in Redis, wherein the key represents a lock identifier and the value represents a lock state or value; A compare and swap principle is applied to the Redis key-value pair representing the distributed lock; and When the corresponding server attempts to seize the lock, the corresponding server performs a compare and swap operation on the lock value stored in Redis.

20. The computer program product according to claim 15, in, The non-transitory tangible computer-readable medium having computer-readable instructions includes: Lua scripts for performing automated operations and business logic on Redis data.

21. The computer program product according to claim 15, in, The computer readable instructions are executable by a processor to cause the processor to further perform: causing the only one server to record an operation of restoring the memory value.

Images