Distributed lock processing method and device, electronic equipment and storage medium
By delaying queue management of distributed lock identification information and consumption time information, unified management of locking and lock renewal of different threads is achieved, and the problem of high resource consumption in the existing technology is solved, and the reliability and resources of the system are improved. Utilization efficiency.
Patent Information
- Application Number
- CN202411147922.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-20
- Publication Date
- 2024-12-27
AI Technical Summary
In the prior art, additional threads or processes are required for each distributed lock monitoring and renewal, resulting in an increase in resource consumption, especially in high concurrency scenarios.
By managing the identification information and consumption time information of distributed locks by delay queues, unified management of locking and lock renewal of different threads is achieved, and the caller dog thread or process is avoided to create separate watchdog threads or processes for each lock.
It reduces the consumption of system resources, ensures that the lock renewal operation is executed immediately when the lock expires, reduces the risk of unlocking the lock in advance due to the long task execution time, and improves the system's reliability and resource utilization efficiency.
Smart Images
Figure CN119201483A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of computer technology, and in particular to a distributed lock processing method, device, electronic device and storage medium. Background Art
[0002] In distributed systems, data consistency and concurrency control are key challenges in building robust applications. Distributed locks are widely used to coordinate operations between multiple services or nodes as an effective means of solving concurrency problems. Among them, traditional distributed lock implementations usually require setting lock expiration times to prevent deadlocks, and rely on additional threads or processes to monitor and renew these locks.
[0003] However, in the prior art, a watchdog thread or process needs to be created separately for each lock to monitor and renew, which increases system resource consumption. Especially in high concurrency scenarios, the more watchdog threads or processes are used to monitor distributed locks, the more resource consumption will be. Summary of the invention
[0004] The embodiments of the present application provide a distributed lock processing method, device, electronic device and storage medium to solve the problem in the prior art that a corresponding thread or process needs to be created for the monitoring and renewal of each distributed lock, resulting in large resource overhead.
[0005] In a first aspect, an embodiment of the present application provides a distributed lock processing method, the method comprising:
[0006] Obtaining a lock request of a first thread, wherein the lock request carries identification information of the first thread;
[0007] When the lock identification information corresponding to the identification information of the first thread does not exist in the delay queue, add a distributed lock to the first thread, and add the target information of the first thread to the delay queue, wherein the target information includes the identification information of the first thread, the identification information of the distributed lock held by the first thread, and the consumption time information;
[0008] When the time indicated by the consumption time information arrives, it is detected whether the business corresponding to the first thread has been executed. If it has not been executed, the distributed lock of the first thread is renewed, and the consumption time information of the first thread in the delay queue is updated.
[0009] Optionally, adding a distributed lock to the first thread includes:
[0010] Generate first version information;
[0011] The remote dictionary service Redis is called to add a distributed lock to the first thread, and the identification information of the distributed lock held by the first thread and the first version information are stored in Redis.
[0012] Optionally, the method further comprises:
[0013] When lock identification information corresponding to the identification information of the first thread exists in the delay queue, second version information of the distributed lock held by the first thread is generated, and the first version information of the distributed lock held by the first thread stored in Redis is kept unchanged.
[0014] Optionally, the method further comprises:
[0015] Obtaining a lock release request of the first thread, wherein the lock release request carries lock identification information and third version information;
[0016] If the lock identification information carried in the release request exists in Redis, and the version information corresponding to the lock identification information is the same as the third version information, the lock identification information carried in the release request in Redis and the version information corresponding to the lock identification information are deleted, and the target information of the first thread in the delay queue is discarded.
[0017] Optionally, the method further comprises:
[0018] If the lock identification information carried in the release request exists in Redis, and the version information corresponding to the lock identification information is different from the third version information, the lock identification information carried in the release request in Redis and the version information corresponding to the lock identification information are retained, and the target information of the first thread in the delay queue is retained.
[0019] Optionally, updating the consumption time information of the first thread in the delay queue includes:
[0020] The consumption time information is updated according to the duration of the distributed lock renewal for the first thread.
[0021] Optionally, when the time indicated by the consumption time information arrives, detecting whether the business corresponding to the first thread is completed, and if it is not completed, renewing the distributed lock of the first thread, and updating the consumption time information of the first thread in the delay queue, including:
[0022] Through the consumption thread, when the time indicated by the consumption time information arrives, it is detected whether the business corresponding to the first thread has been executed. If it has not been completed, the distributed lock of the first thread is renewed, and the consumption time information of the first thread in the delay queue is updated.
[0023] In a second aspect, an embodiment of the present application provides a distributed lock processing device, the device comprising:
[0024] A first acquisition module, configured to acquire a lock request of a first thread, wherein the lock request carries identification information of the first thread;
[0025] A locking module, configured to add a distributed lock to the first thread when the lock identification information corresponding to the identification information of the first thread does not exist in the delay queue, and add the target information of the first thread to the delay queue, wherein the target information includes the identification information of the first thread, the identification information of the distributed lock held by the first thread, and the consumption time information;
[0026] A renewal module is used to detect whether the business corresponding to the first thread has been executed when the time indicated by the consumption time information arrives, and if it has not been completed, renew the distributed lock of the first thread and update the consumption time information of the first thread in the delay queue.
[0027] In a third aspect, an embodiment of the present application provides an electronic device, including a memory, a transceiver, and a processor:
[0028] A memory for storing a computer program; a transceiver for sending and receiving data under the control of the processor; and a processor for reading the computer program in the memory and executing the distributed lock processing method described in the first aspect above.
[0029] In a fourth aspect, an embodiment of the present application provides a readable storage medium, on which a program or instruction is stored, and when the program or instruction is executed by a processor, the distributed lock processing method described in the first aspect is implemented.
[0030] In an embodiment of the present application, a lock request of the first thread can be obtained, and the lock request carries the identification information of the first thread. Therefore, when the lock identification information corresponding to the identification information of the first thread does not exist in the delay queue, a distributed lock is added to the first thread, and the target information of the first thread is added to the delay queue. The target information includes the identification information of the first thread, the identification information of the distributed lock held by the first thread, and the consumption time information. Therefore, when the time indicated by the consumption time information arrives, it is detected whether the business of the first thread is completed. If not, the distributed lock of the first thread is renewed, and the consumption time information of the first thread in the delay queue is updated.
[0031] It can be seen that in an embodiment of the present application, the identification information of the thread to which the distributed lock is added and the identification information of the distributed lock held by the thread can be saved through a delay queue; that is, if the identification information of a thread and its corresponding lock identification information exist in the delay queue, it means that the thread already holds the distributed lock; if the identification information of a thread and its corresponding lock identification information do not exist in the delay queue, it means that the thread does not hold the distributed lock; and, by setting the consumption time information of each distributed lock in the delay queue, the time for the next determination whether to renew the lock is indicated; in this way, the embodiment of the present application realizes unified management of locking and lock renewal of different threads through a delay queue. Therefore, in an embodiment of the present application, there is no need to create a watchdog thread or process for each lock separately, thereby reducing resource consumption. BRIEF DESCRIPTION OF THE DRAWINGS
[0032] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the description of the embodiments of the present application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.
[0033] Figure 1 A flowchart of a distributed lock processing method provided in an embodiment of the present application;
[0034] Figure 2 A flowchart of a specific implementation of the distributed lock processing method of an embodiment of the present application;
[0035] Figure 3 A structural block diagram of a distributed lock processing device provided in an embodiment of the present application;
[0036] Figure 4 A structural block diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0037] In the embodiments of the present application, the term "and / or" describes the association relationship of the associated objects, indicating that three relationships may exist. For example, A and / or B may represent: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the associated objects before and after are in an "or" relationship.
[0038] In the embodiments of the present application, the term "plurality" refers to two or more than two, and other quantifiers are similar.
[0039] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.
[0040] The embodiments of the present application provide a distributed lock processing method, device, electronic device and storage medium to solve the problem in the prior art that a corresponding thread or process needs to be created for the monitoring and renewal of each distributed lock, resulting in large resource overhead.
[0041] Among them, the method and the device are based on the same application concept. Since the method and the device solve the problem in a similar principle, the implementation of the device and the method can refer to each other, and the repeated parts will not be repeated.
[0042] See also Figure 1 , an embodiment of the present application provides a distributed lock processing method, which may include the following steps 101 to 103:
[0043] Step 101: Obtain a lock request from a first thread.
[0044] The lock request carries identification information of the first thread.
[0045] In addition, the first thread may include one or more threads for executing services; if the first thread includes multiple threads, in the embodiment of the present application, steps 101 to 103 need to be executed for each of the multiple threads.
[0046] In addition, the identification information of the first thread may include an ID of the first thread.
[0047] Step 102: When the lock identification information corresponding to the identification information of the first thread does not exist in the delay queue, a distributed lock is added to the first thread, and the target information of the first thread is added to the delay queue.
[0048] The target information includes identification information of the first thread, identification information of the distributed lock held by the first thread, and consumption time information; the identification information of the distributed lock may include the name of the distributed lock.
[0049] It can be seen that in the embodiment of the present application, the above target information of the thread holding the distributed lock is stored in the delay queue; and the thread that does not hold the distributed lock does not have the corresponding target information in the delay queue; therefore, by whether there is target information belonging to a certain thread in the delay queue, it can be determined whether the thread currently holds the distributed lock. If the distributed lock is not currently held, the thread can be locked according to the lock request of the thread.
[0050] In addition, the consumption time information is used to indicate the next time to determine whether the distributed lock needs to be renewed. That is, when the time indicated by the consumption time information arrives, it is necessary to determine whether the business of the thread corresponding to the consumption time information has been completed. If not, the distributed lock of the first thread needs to be renewed.
[0051] It can be seen that in the embodiment of the present application, the locking of different threads is uniformly managed through the delay queue, and the time when the distributed lock executes the renewal operation is indicated by the consumption time information. In this way, the distributed locks of different threads are uniformly managed through the delay queue, and there is no need to create a separate monitoring thread or process for each distributed lock, thereby saving resource consumption.
[0052] In addition, it should be noted that the delay queue is a mechanism that allows messages to be stored in the queue for a period of time before being processed by the consumer. It can consume data according to a specified time node.
[0053] Step 103: When the time indicated by the consumption time information arrives, detect whether the business corresponding to the first thread has been executed. If not, renew the distributed lock of the first thread and update the consumption time information of the first thread in the delay queue.
[0054] Among them, the consumption time information is used to indicate the next time to determine whether the distributed lock needs to be renewed. Therefore, when the time indicated by the consumption time information arrives, it can be detected whether the business of the first thread is completed. If not, the distributed lock of the first thread needs to be renewed.
[0055] It should be noted that before the business corresponding to the first thread is executed, the first thread needs to continue to occupy the distributed lock added for it, that is, the distributed lock of the first thread needs to exist all the time during the execution of the business corresponding to the first thread. In this way, even if the time indicated by the consumption time information corresponding to the first thread has arrived, the business of the first thread has not been completed, then the distributed lock of the first thread needs to be renewed to avoid the distributed lock being released prematurely and affecting the normal execution of the business.
[0056] It can be understood that if the time indicated by the consumption time information corresponding to the first thread has arrived, but the business of the first thread has not been completed, the distributed lock of the first thread needs to be renewed; at the same time, the consumption time information needs to be updated so that when the updated consumption time information arrives, it can be further detected whether the business of the first thread has been completed. If it has not been completed, the distributed lock of the first thread can be renewed again, and the consumption time information can be updated again; until the business of the first thread is completed.
[0057] It can be seen from the above steps 101 to 103 that in an embodiment of the present application, a lock request of the first thread can be obtained, and the lock request carries the identification information of the first thread. Therefore, when the lock identification information corresponding to the identification information of the first thread does not exist in the delay queue, a distributed lock is added to the first thread, and the target information of the first thread is added to the delay queue. The target information includes the identification information of the first thread, the identification information of the distributed lock held by the first thread, and the consumption time information. Therefore, when the time indicated by the consumption time information arrives, it is detected whether the business of the first thread is executed. If not, the distributed lock of the first thread is renewed, and the consumption time information of the first thread in the delay queue is updated.
[0058] It can be seen that in an embodiment of the present application, the identification information of the thread to which the distributed lock is added and the identification information of the distributed lock held by the thread can be saved through a delay queue; that is, if the identification information of a thread and its corresponding lock identification information exist in the delay queue, it means that the thread already holds the distributed lock; if the identification information of a thread and its corresponding lock identification information do not exist in the delay queue, it means that the thread does not hold the distributed lock; and, by setting the consumption time information of each distributed lock in the delay queue, the time for the next determination whether to renew the lock is indicated; in this way, the embodiment of the present application realizes unified management of locking and lock renewal of different threads through a delay queue. Therefore, in an embodiment of the present application, there is no need to create a watchdog thread or process for each lock separately, thereby reducing resource consumption.
[0059] In addition, in the prior art, the polling check method of the gatedog thread created separately for each lock may cause the lock to be renewed in an untimely manner, increasing the risk of premature release of the lock. In addition, maintaining the lock state and counter increases the complexity and maintenance cost of the system. In the embodiment of the present application, through the above-mentioned consumption time information, it can be ensured that the lock renewal operation is executed immediately when the lock expires, thereby reducing the risk of premature release of the lock due to excessive task execution time.
[0060] Optionally, in the above step 102, adding a distributed lock to the first thread includes:
[0061] Generate first version information;
[0062] The remote dictionary service Redis is called to add a distributed lock to the first thread, and the identification information of the distributed lock held by the first thread and the first version information are stored in Redis.
[0063] It can be seen from this that in an embodiment of the present application, when a distributed lock needs to be added to the first thread, version information of a distributed lock can be generated, and Redis can be called to add a distributed lock to the first thread, thereby storing the identification information and the version information of the distributed lock held by the first thread in Redis.
[0064] Among them, the identification information of the distributed lock (such as the lock name) can be used as a key, and the version information can be put into Redis as a value; that is, in Redis, the lock identification information and the version information are stored as a key-value pair.
[0065] Optionally, the method further comprises:
[0066] When lock identification information corresponding to the identification information of the first thread exists in the delay queue, second version information of the distributed lock held by the first thread is generated, and the first version information of the distributed lock held by the first thread stored in Redis is kept unchanged.
[0067] If the lock request of the first thread is obtained, but the lock identification information corresponding to the identification information of the first thread exists in the delay queue, it means that the first thread holds the distributed lock and needs to re-enter. In the embodiment of the present application, when the first thread re-enters the distributed lock, a version information can be re-generated for the distributed lock, but the version information of the distributed lock in Redis is not updated.
[0068] In addition, in the prior art, the lock reentry is realized by maintaining a counter, which not only increases the system complexity, but also may introduce thread competition and synchronization problems. However, the embodiment of the present application determines the reentry state of the lock by checking the target information in the delay queue, thereby realizing a concise and efficient reentry mechanism, avoiding the complexity introduced by maintaining a counter in the traditional method.
[0069] In addition, to facilitate understanding of the reentry scenario described here, the following example is given:
[0070] As a first example, in the order processing business, since order processing may involve multiple sub-processes and nested calls, a reentrant lock is needed to ensure that the lock can be continuously held in the recursive call to avoid data inconsistency;
[0071] As a second example, in the payment process of a shopping mall, a distributed lock of the order is acquired when a user tries to pay for an order for the first time; if the payment fails due to network anomalies or other reasons, the user may try to pay again. At this time, the use of a reentrant lock can ensure that the lock can continue to be held when paying again, avoiding data conflicts caused by concurrent payments.
[0072] It can be seen that when the business corresponding to the first thread involves the main process and multiple sub-processes, each sub-process will be called during the execution of the main process. Among them, a lock request will be generated when the main process starts to execute, so as to add a distributed lock to the first thread; thereafter, when a sub-process is called, a lock request can also be generated, but at this time the first thread already holds the distributed lock. In this case, it belongs to the re-entry scenario of the distributed lock. At this time, there is no need to add a distributed lock to the first thread, and only a new version information needs to be generated for the distributed lock.
[0073] It can be seen that in an embodiment of the present application, in a nested call scenario, when each sub-process re-enters the distributed lock, a new version information can be generated for each sub-process to distinguish the version information of the distributed lock corresponding to the main process.
[0074] Optionally, the method further comprises:
[0075] Obtaining a lock release request of the first thread, wherein the lock release request carries lock identification information and third version information;
[0076] If the lock identification information carried in the release request exists in Redis, and the version information corresponding to the lock identification information is the same as the third version information, the lock identification information carried in the release request in Redis and the version information corresponding to the lock identification information are deleted, and the target information of the first thread in the delay queue is discarded.
[0077] Optionally, the method further comprises:
[0078] If the lock identification information carried in the release request exists in Redis, and the version information corresponding to the lock identification information is different from the third version information, the lock identification information carried in the release request in Redis and the version information corresponding to the lock identification information are retained, and the target information of the first thread in the delay queue is retained.
[0079] It should be noted that, after the target process involved in the business corresponding to the first thread is executed, a lock release request for the first thread can be generated, and the third version information carried in the lock release request is the version information corresponding to the target process; the target process is one of the processes involved in the business corresponding to the first thread; when the business corresponding to the first thread involves a main process, the target process is the main process; when the business corresponding to the first thread involves a main process and multiple sub-processes nested in the main process, the target process is the main process or one of the sub-processes.
[0080] It can be seen that in the embodiment of the present application, if the lock release request of the first thread is obtained, the lock identification information and the third version information carried in the lock release request can be searched in Redis, and then when found, the lock identification information carried in the release request in Redis and the version information corresponding to the lock identification information are deleted, and the target information of the first thread in the delay queue is discarded to realize the release of the distributed lock held by the first thread. If the lock identification information carried in the release request exists in Redis, but the version information corresponding to the lock identification information is different from the third version information, the release operation is not performed on the distributed lock held by the first thread.
[0081] In addition, as described above, the business corresponding to the first thread may involve one main process (ie, a non-nested calling scenario) or one main process and multiple sub-processes (ie, a nested calling scenario).
[0082] Among them, for non-nested call scenarios:
[0083] When the business corresponding to the first thread involves a main process, when the main process is executed, a distributed lock will be allocated to the first thread, and a distributed lock version information will be obtained, and the version information of the distributed lock will be recorded in Redis; wherein, when the business is executed (that is, the main process of the business is executed), a lock release request of the first thread can be generated, and the lock release request carries the identification information and version information of the distributed lock held by the first thread; and, in this scenario, the version information of the distributed lock held by the first thread stored in Redis is the same as the version information in the lock release request; therefore, in this scenario, after obtaining the lock release request of the first thread, the distributed lock held by the first thread can be released.
[0084] For nested call scenarios:
[0085] When the business corresponding to the first thread involves a main process and multiple sub-processes, as described above, when the main process is executed, a distributed lock will be allocated to the first thread, and a distributed lock version information corresponding to the main process will be obtained, wherein the version information of the distributed lock corresponding to the main process will be recorded in Redis; and, when each sub-process re-enters the distributed lock, a new version information can be generated for each sub-process to distinguish the version information of the distributed lock corresponding to the main process, but after the version information corresponding to the sub-process is obtained, it is not updated to Redis.
[0086] That is, in the nested call scenario, the main process and each sub-process correspond to different version information of the same distributed lock. However, the version information corresponding to the main process is stored in Redis, while the version information corresponding to the sub-process is not stored in Redis. Therefore, in the nested call scenario, the lock release request of the first thread generated after the sub-process is executed carries the version information corresponding to the sub-process. However, the version information in Redis is the version information corresponding to the main process, and the two are not the same. Therefore, the lock release request generated when the sub-process is executed will not trigger the release of the distributed lock held by the first thread. However, the lock release request of the first thread generated after the main process is executed carries the version information corresponding to the main process, and the version information in Redis is the version information corresponding to the main process. Therefore, the lock release request generated when the main process is executed can trigger the release of the distributed lock held by the first thread.
[0087] In summary, in the embodiment of the present application, in the reentry scenario, new version information is generated for the distributed lock held by the first thread, but the version information of the distributed lock in Redis is not updated, so that the distributed lock of the first thread can be released only when the main process is executed, and the distributed lock held by the first thread is avoided when the sub-process is executed. It can be seen that in the embodiment of the present application, in the reentry scenario, it is not necessary to maintain the lock state and counter in Redis for the reentry lock, thereby reducing resource consumption.
[0088] Optionally, updating the consumption time information of the first thread in the delay queue includes:
[0089] The consumption time information is updated according to the duration of the distributed lock renewal for the first thread.
[0090] It can be seen that in the embodiment of the present application, the consumption time information of the first thread in the delay queue can be updated according to the duration of the renewal of the distributed lock of the first thread. Exemplarily, the duration indicated by the updated consumption time information is half of the renewal duration. For example, this time the distributed lock of the first thread is renewed for 5s, and the duration indicated by the updated consumption time information is 2.5s, that is, after 2.5s, it is detected whether the business of the first duration has been executed. If it has not been executed, the distributed lock of the first thread will continue to be renewed, and the consumption time information will be updated again.
[0091] Optionally, when the time indicated by the consumption time information arrives, detecting whether the business corresponding to the first thread is completed, and if it is not completed, renewing the distributed lock of the first thread, and updating the consumption time information of the first thread in the delay queue, including:
[0092] Through the consumption thread, when the time indicated by the consumption time information arrives, it is detected whether the business corresponding to the first thread has been executed. If it has not been completed, the distributed lock of the first thread is renewed, and the consumption time information of the first thread in the delay queue is updated.
[0093] It can be seen that in the embodiment of the present application, a consumption thread can be set to monitor whether the time indicated by the consumption time information in the delay queue has arrived, so as to detect whether the business corresponding to the first thread has been completed when it arrives, and then renew and update the consumption time information if it has not been completed. It can be seen that the embodiment of the present application concentrates the renewal logic in one consumption thread, thereby reducing the structural and management complexity of the system and reducing maintenance costs.
[0094] In summary, the specific implementation of the distributed lock processing method of the embodiment of the present application can be as follows: Figure 2 As shown, the specific steps from the first step to the eighth step are as follows:
[0095] Step 1: Set up a delay queue (DelayQueue) globally and set up a consumer thread (DelayConsumeThread) to consume messages from the delay queue.
[0096] Step 2: Get a lock request, that is, get the lock request of the current thread corresponding to the business that needs to be executed, where the lock request carries the ID of the current thread;
[0097] Step 3: Determine whether the current thread has been locked based on the delay queue;
[0098] That is, by judging whether the message of the current thread and the lock name is put into the delay queue, if it is put into the delay queue, it means that the current thread already holds the lock, otherwise the current thread does not hold the lock;
[0099] Step 4: If the current thread already holds the lock, a new version number is returned directly;
[0100] Step 5: If the current thread does not hold the lock, a new version number is generated, and the lock name is combined with Redis to perform a lock operation, that is, the lock name is used as the key and the version number is used as the value to be put into Redis; if the lock is successful, a message body is constructed including the thread ID, lock name, and the next consumption time of the message, and the message body is put into the delay queue, and the generated version number is returned; if the lock fails, invalid (null) is returned.
[0101] For example, the lock name is: LOCK_TEST_INVENTORY;
[0102] The version number returned is: 585cb14c-5bd6-4481-840d-f27d68eca7b6.
[0103] Step 6: Execute the business process of the current thread;
[0104] Step 7: The consumer thread monitors the consumption time in the delay queue, thereby executing the renewal operation and the consumption time update operation. That is, when the consumption time of the consumer thread in the delay queue arrives, it determines whether the business of the current thread has been completed. If not, it renews and calculates the next consumption time. Based on the calculated next consumption time, the consumption time of the current thread in the delay queue is updated.
[0105] Step 8: After the business process is executed, the unlocking operation is performed. That is, after the overall business of the current thread is executed, a lock release request is generated. The lock release request carries the name of the lock held by the current thread and the version number obtained in the fifth step. The lock name and version number in the lock release request recorded in Redis are deleted, and the message body of the current thread in the delay queue is discarded to release the lock.
[0106] It should be noted that after the fourth step above, that is, after the current thread reenters the lock it already holds, if the business process related to this reentry is completed, a lock release request can be generated, and the lock release request includes the lock name held by the current thread and the version number obtained during this reentry. However, the lock name held by the current thread and the version number when it first enters the lock (i.e., locks) recorded in Redis are different from the version number in the lock release request, so the lock release request will not trigger the release of the lock held by the current thread. Therefore, the current thread will release the lock it holds only after the business process related to the first lock entry is completed.
[0107] In summary, the embodiments of the present application have the following advantages:
[0108] 1. High reliability: By setting the expiration time of the lock, you can effectively prevent deadlock problems caused by system anomalies and ensure the robustness of the distributed system. In addition, by using the delay queue to automatically renew the lock, even if the business processing time exceeds the preset expiration time, you can ensure that the lock continues to be valid and reduce the risk of lock failure. Or, even in the case of high load or network delay, you can ensure that the lock is renewed in time, avoiding business interruption caused by lock failure.
[0109] 2. High availability: The reentrant design of the distributed lock allows the same thread to acquire the same lock multiple times while holding the lock, which improves the concurrent processing capability of the system and reduces the competition pressure between threads. In addition, whether it is a reentry can be determined by judging whether the lock and the thread ID have been placed in the delay queue. There is no need to manage the Redis count, which reduces the risk of system errors and simplifies the reentry process design. In addition, there is no need to operate Redis again when reentering, and the logic is completely implemented in memory.
[0110] 3. Flexibility: You can flexibly configure the lock expiration time and renewal frequency according to actual business needs to meet the performance requirements in different scenarios. In addition, through the delay queue service, you can easily implement complex lock management logic and support more advanced lock strategies and functions.
[0111] 4. Resource optimization: The lock expiration time can be reset at a reasonable time interval, avoiding the waste of Redis resources due to frequent renewal. In addition, when the thread holding the lock completes the business processing and releases the lock, the renewal operation can be stopped, thereby reducing unnecessary system overhead.
[0112] In summary, the embodiments of the present application improve the reliability, availability, flexibility and ease of use of the distributed system by realizing automatic renewal and reentrant optimization of distributed locks, and optimize the utilization efficiency of system resources, providing strong support for high concurrency, high performance and stable operation of the distributed system.
[0113] The above introduces the distributed lock processing method provided by the embodiment of the present application. The following will introduce the distributed lock processing device provided by the embodiment of the present application in conjunction with the accompanying drawings.
[0114] See also Figure 3 , the embodiment of the present application further provides a distributed lock processing device, the device comprising:
[0115] A first acquisition module 301 is used to acquire a lock request of a first thread, wherein the lock request carries identification information of the first thread;
[0116] The locking module 302 is used to add a distributed lock to the first thread when the lock identification information corresponding to the identification information of the first thread does not exist in the delay queue, and add the target information of the first thread to the delay queue, wherein the target information includes the identification information of the first thread, the identification information of the distributed lock held by the first thread, and the consumption time information;
[0117] The renewal module 303 is used to detect whether the business corresponding to the first thread has been executed when the time indicated by the consumption time information arrives, and if it has not been completed, renew the distributed lock of the first thread and update the consumption time information of the first thread in the delay queue.
[0118] It can be seen that in an embodiment of the present application, a lock request of the first thread can be obtained, and the lock request carries the identification information of the first thread. Therefore, when the lock identification information corresponding to the identification information of the first thread does not exist in the delay queue, a distributed lock is added to the first thread, and the target information of the first thread is added to the delay queue. The target information includes the identification information of the first thread, the identification information of the distributed lock held by the first thread, and the consumption time information. Therefore, when the time indicated by the consumption time information arrives, it is detected whether the business of the first thread is completed. If not, the distributed lock of the first thread is renewed, and the consumption time information of the first thread in the delay queue is updated.
[0119] It can be seen that in an embodiment of the present application, the identification information of the thread to which the distributed lock is added and the identification information of the distributed lock held by the thread can be saved through a delay queue; that is, if the identification information of a thread and its corresponding lock identification information exist in the delay queue, it means that the thread already holds the distributed lock; if the identification information of a thread and its corresponding lock identification information do not exist in the delay queue, it means that the thread does not hold the distributed lock; and, by setting the consumption time information of each distributed lock in the delay queue, the time for the next determination whether to renew the lock is indicated; in this way, the embodiment of the present application realizes unified management of locking and lock renewal of different threads through a delay queue. Therefore, in an embodiment of the present application, there is no need to create a watchdog thread or process for each lock separately, thereby reducing resource consumption.
[0120] In addition, in the prior art, the polling check method of the gatedog thread created separately for each lock may cause the lock to be renewed in an untimely manner, increasing the risk of premature release of the lock. In addition, maintaining the lock state and counter increases the complexity and maintenance cost of the system. In the embodiment of the present application, through the above-mentioned consumption time information, it can be ensured that the lock renewal operation is executed immediately when the lock expires, thereby reducing the risk of premature release of the lock due to excessive task execution time.
[0121] Optionally, the locking module 302 adds a distributed lock to the first thread, including:
[0122] Generate first version information;
[0123] The remote dictionary service Redis is called to add a distributed lock to the first thread, and the identification information of the distributed lock held by the first thread and the first version information are stored in Redis.
[0124] It can be seen from this that in an embodiment of the present application, when a distributed lock needs to be added to the first thread, version information of a distributed lock can be generated, and Redis can be called to add a distributed lock to the first thread, thereby storing the identification information and the version information of the distributed lock held by the first thread in Redis.
[0125] Among them, the identification information of the distributed lock (such as the lock name) can be used as a key, and the version information can be put into Redis as a value; that is, in Redis, the lock identification information and the version information are stored as a key-value pair.
[0126] Optionally, the device further comprises:
[0127] The first processing module is used to generate second version information of the distributed lock held by the first thread when lock identification information corresponding to the identification information of the first thread exists in the delay queue, and keep the first version information of the distributed lock held by the first thread stored in Redis unchanged.
[0128] If the lock request of the first thread is obtained, but the lock identification information corresponding to the identification information of the first thread exists in the delay queue, it means that the first thread holds the distributed lock and needs to re-enter. In the embodiment of the present application, when the first thread re-enters the distributed lock, a version information can be re-generated for the distributed lock, but the version information of the distributed lock in Redis is not updated.
[0129] In addition, in the prior art, the lock reentry is realized by maintaining a counter, which not only increases the system complexity, but also may introduce thread competition and synchronization problems. However, the embodiment of the present application determines the reentry state of the lock by checking the target information in the delay queue, thereby realizing a concise and efficient reentry mechanism, avoiding the complexity introduced by maintaining a counter in the traditional method.
[0130] In addition, to facilitate understanding of the reentry scenario described here, the following example is given:
[0131] As a first example, in the order processing business, since order processing may involve multiple sub-processes and nested calls, a reentrant lock is needed to ensure that the lock can be continuously held in the recursive call to avoid data inconsistency;
[0132] As a second example, in the payment process of a shopping mall, a distributed lock of the order is acquired when a user tries to pay for an order for the first time; if the payment fails due to network anomalies or other reasons, the user may try to pay again. At this time, the use of a reentrant lock can ensure that the lock can continue to be held when paying again, avoiding data conflicts caused by concurrent payments.
[0133] It can be seen that when the business corresponding to the first thread involves the main process and multiple sub-processes, each sub-process will be called during the execution of the main process. Among them, a lock request will be generated when the main process starts to execute, so as to add a distributed lock to the first thread; thereafter, when a sub-process is called, a lock request can also be generated, but at this time the first thread already holds the distributed lock. In this case, it belongs to the re-entry scenario of the distributed lock. At this time, there is no need to add a distributed lock to the first thread, and only a new version information needs to be generated for the distributed lock.
[0134] It can be seen that in an embodiment of the present application, in a nested call scenario, when each sub-process re-enters the distributed lock, a new version information can be generated for each sub-process to distinguish the version information of the distributed lock corresponding to the main process.
[0135] Optionally, the device further comprises:
[0136] a second acquisition module, configured to acquire a lock release request of the first thread, wherein the lock release request carries lock identification information and third version information;
[0137] A release module is used to delete the lock identification information carried in the release request and the version information corresponding to the lock identification information in Redis, and discard the target information of the first thread in the delay queue when the lock identification information carried in the release request exists in Redis and the version information corresponding to the lock identification information is the same as the third version information.
[0138] Optionally, the device further comprises:
[0139] The second processing module is used to retain the lock identification information carried in the release request and the version information corresponding to the lock identification information in Redis, and retain the target information of the first thread in the delay queue when the lock identification information carried in the release request exists in Redis and the version information corresponding to the lock identification information is different from the third version information.
[0140] It should be noted that, after the target process involved in the business corresponding to the first thread is executed, a lock release request for the first thread can be generated, and the third version information carried in the lock release request is the version information corresponding to the target process; the target process is one of the processes involved in the business corresponding to the first thread; when the business corresponding to the first thread involves a main process, the target process is the main process; when the business corresponding to the first thread involves a main process and multiple sub-processes nested in the main process, the target process is the main process or one of the sub-processes.
[0141] It can be seen that in the embodiment of the present application, if the lock release request of the first thread is obtained, the lock identification information and the third version information carried in the lock release request can be searched in Redis, and then when found, the lock identification information carried in the release request in Redis and the version information corresponding to the lock identification information are deleted, and the target information of the first thread in the delay queue is discarded to realize the release of the distributed lock held by the first thread. If the lock identification information carried in the release request exists in Redis, but the version information corresponding to the lock identification information is different from the third version information, the release operation is not performed on the distributed lock held by the first thread.
[0142] In addition, as described above, the business corresponding to the first thread may involve one main process (ie, a non-nested call scenario) or one main process and multiple sub-processes (ie, a nested call scenario).
[0143] Among them, for non-nested call scenarios:
[0144] When the business corresponding to the first thread involves a main process, when the main process is executed, a distributed lock will be allocated to the first thread, and a distributed lock version information will be obtained, and the version information of the distributed lock will be recorded in Redis; wherein, when the business is executed (that is, the main process of the business is executed), a lock release request of the first thread can be generated, and the lock release request carries the identification information and version information of the distributed lock held by the first thread; and, in this scenario, the version information of the distributed lock held by the first thread stored in Redis is the same as the version information in the lock release request; therefore, in this scenario, after obtaining the lock release request of the first thread, the distributed lock held by the first thread can be released.
[0145] For nested call scenarios:
[0146] When the business corresponding to the first thread involves a main process and multiple sub-processes, as described above, when the main process is executed, a distributed lock will be allocated to the first thread, and a distributed lock version information corresponding to the main process will be obtained, wherein the version information of the distributed lock corresponding to the main process will be recorded in Redis; and, when each sub-process re-enters the distributed lock, a new version information can be generated for each sub-process to distinguish the version information of the distributed lock corresponding to the main process, but after the version information corresponding to the sub-process is obtained, it is not updated to Redis.
[0147] That is, in the nested call scenario, the main process and each sub-process correspond to different version information of the same distributed lock. However, the version information corresponding to the main process is stored in Redis, while the version information corresponding to the sub-process is not stored in Redis. Therefore, in the nested call scenario, the lock release request of the first thread generated after the sub-process is executed carries the version information corresponding to the sub-process. However, the version information in Redis is the version information corresponding to the main process, and the two are not the same. Therefore, the lock release request generated when the sub-process is executed will not trigger the release of the distributed lock held by the first thread. However, the lock release request of the first thread generated after the main process is executed carries the version information corresponding to the main process, and the version information in Redis is the version information corresponding to the main process. Therefore, the lock release request generated when the main process is executed can trigger the release of the distributed lock held by the first thread.
[0148] In summary, in the embodiment of the present application, in the reentry scenario, new version information is generated for the distributed lock held by the first thread, but the version information of the distributed lock in Redis is not updated, so that the distributed lock of the first thread can be released only when the main process is executed, and the distributed lock held by the first thread is avoided when the sub-process is executed. It can be seen that in the embodiment of the present application, in the reentry scenario, it is not necessary to maintain the lock state and counter in Redis for the reentry lock, thereby reducing resource consumption.
[0149] Optionally, the renewal module 303 updates the consumption time information of the first thread in the delay queue, including:
[0150] The consumption time information is updated according to the duration of the distributed lock renewal for the first thread.
[0151] It can be seen that in the embodiment of the present application, the consumption time information of the first thread in the delay queue can be updated according to the duration of the renewal of the distributed lock of the first thread. Exemplarily, the duration indicated by the updated consumption time information is half of the renewal duration. For example, this time the distributed lock of the first thread is renewed for 5s, and the duration indicated by the updated consumption time information is 2.5s, that is, after 2.5s, it is detected whether the business of the first duration has been executed. If it has not been executed, the distributed lock of the first thread will continue to be renewed, and the consumption time information will be updated again.
[0152] Optionally, the renewal module 303 is specifically used for:
[0153] Through the consumption thread, when the time indicated by the consumption time information arrives, it is detected whether the business corresponding to the first thread has been executed. If it has not been completed, the distributed lock of the first thread is renewed, and the consumption time information of the first thread in the delay queue is updated.
[0154] It can be seen that in the embodiment of the present application, a consumption thread can be set to monitor whether the time indicated by the consumption time information in the delay queue has arrived, so as to detect whether the business corresponding to the first thread has been completed when it arrives, and then renew and update the consumption time information if it has not been completed. It can be seen that the embodiment of the present application concentrates the renewal logic in one consumption thread, thereby reducing the structural and management complexity of the system and reducing maintenance costs.
[0155] It should be noted that the division of units in the embodiments of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation. In addition, each functional unit in each embodiment of the present application may be integrated into a processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.
[0156] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a processor-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) or a processor (processor) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), disk or optical disk and other media that can store program codes.
[0157] It should be noted here that the above-mentioned device provided in the embodiment of the present application can implement all the method steps implemented in the above-mentioned method embodiment, and can achieve the same technical effect. The parts and beneficial effects of this embodiment that are the same as those in the method embodiment will not be described in detail here.
[0158] The embodiment of the present application also provides an electronic device, such as Figure 4 As shown, the electronic device includes a memory 420, a transceiver 410, and a processor 400;
[0159] Memory 420, used for storing computer programs;
[0160] The transceiver 410 is used to receive and send data under the control of the processor 400;
[0161] The processor 400 is used to read the computer program in the memory 420 and execute the distributed lock processing method described in the first aspect.
[0162] Among them, Figure 4In the embodiment, the bus architecture may include any number of interconnected buses and bridges, specifically linking various circuits of one or more processors represented by processor 400 and memory represented by memory 420. The bus architecture may also link various other circuits such as peripherals, voltage regulators, and power management circuits, which are well known in the art and are therefore not further described herein. The bus interface provides an interface. The transceiver 410 may be a plurality of components, namely, a transmitter and a receiver, providing a unit for communicating with various other devices on a transmission medium, which may include a wireless channel, a wired channel, an optical cable, and other transmission media. The processor 400 is responsible for managing the bus architecture and general processing, and the memory 420 may store data used by the processor 400 when performing operations.
[0163] The processor 400 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or a complex programmable logic device (CPLD). The processor 400 may also adopt a multi-core architecture.
[0164] It should be noted here that the above-mentioned device provided in the embodiment of the present application can implement all the method steps implemented in the above-mentioned method embodiment, and can achieve the same technical effect. The parts and beneficial effects of this embodiment that are the same as those in the method embodiment will not be described in detail here.
[0165] An embodiment of the present application further provides a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the distributed lock processing method described in the first aspect above is implemented.
[0166] The computer-readable storage medium can be any available medium or data storage device that can be accessed by the processor, including but not limited to magnetic storage (such as floppy disks, hard disks, magnetic tapes, magneto-optical disks (Magnet-Optica, MO)), etc.), optical storage (such as Compact Disk (CD), Digital Versatile Disc (DVD), Blu-ray Disc (BD), Holographic Versatile Disc (HVD), etc.), and semiconductor memory (such as Read-Only Memory (ROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read Only Memory (EEPROM), non-volatile memory (NAND FLASH), solid-state drive (Solid State Disk or Solid State Drive, SSD)), etc.
[0167] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage and optical storage, etc.) that contain computer-usable program code.
[0168] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer executable instructions. These computer executable instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.
[0169] These processor executable instructions may also be stored in a processor readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the processor readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.
[0170] These processor-executable instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.
[0171] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.
Claims
1. A distributed lock processing method, characterized in that: The method comprises: Obtaining a lock request of a first thread, wherein the lock request carries identification information of the first thread; When the lock identification information corresponding to the identification information of the first thread does not exist in the delay queue, add a distributed lock to the first thread, and add the target information of the first thread to the delay queue, wherein the target information includes the identification information of the first thread, the identification information of the distributed lock held by the first thread, and the consumption time information; When the time indicated by the consumption time information arrives, it is detected whether the business corresponding to the first thread has been executed. If it has not been executed, the distributed lock of the first thread is renewed, and the consumption time information of the first thread in the delay queue is updated.
2. The method according to claim 1, characterized in that: Adding a distributed lock to the first thread includes: Generate first version information; The remote dictionary service Redis is called to add a distributed lock to the first thread, and the identification information of the distributed lock held by the first thread and the first version information are stored in Redis.
3. The method according to claim 2, characterized in that The method further comprises: When lock identification information corresponding to the identification information of the first thread exists in the delay queue, second version information of the distributed lock held by the first thread is generated, and the first version information of the distributed lock held by the first thread stored in Redis is kept unchanged.
4. The method according to claim 2 or 3, characterized in that: The method further comprises: Obtaining a lock release request of the first thread, wherein the lock release request carries lock identification information and third version information; If the lock identification information carried in the release request exists in Redis, and the version information corresponding to the lock identification information is the same as the third version information, the lock identification information carried in the release request in Redis and the version information corresponding to the lock identification information are deleted, and the target information of the first thread in the delay queue is discarded.
5. The method according to claim 4, characterized in that The method further comprises: If the lock identification information carried in the release request exists in Redis, and the version information corresponding to the lock identification information is different from the third version information, the lock identification information carried in the release request in Redis and the version information corresponding to the lock identification information are retained, and the target information of the first thread in the delay queue is retained.
6. The method according to claim 1, characterized in that The updating of the consumption time information of the first thread in the delay queue includes: The consumption time information is updated according to the duration of the distributed lock renewal for the first thread.
7. The method according to claim 1, characterized in that When the time indicated by the consumption time information arrives, detecting whether the business corresponding to the first thread is completed, and if it is not completed, renewing the distributed lock of the first thread, and updating the consumption time information of the first thread in the delay queue, including: Through the consumption thread, when the time indicated by the consumption time information arrives, it is detected whether the business corresponding to the first thread has been executed. If it has not been completed, the distributed lock of the first thread is renewed, and the consumption time information of the first thread in the delay queue is updated.
8. A distributed lock processing device, characterized in that: The device comprises: A first acquisition module, configured to acquire a lock request of a first thread, wherein the lock request carries identification information of the first thread; A locking module, configured to add a distributed lock to the first thread when the lock identification information corresponding to the identification information of the first thread does not exist in the delay queue, and add the target information of the first thread to the delay queue, wherein the target information includes the identification information of the first thread, the identification information of the distributed lock held by the first thread, and the consumption time information; A renewal module is used to detect whether the business corresponding to the first thread has been executed when the time indicated by the consumption time information arrives, and if it has not been completed, renew the distributed lock of the first thread and update the consumption time information of the first thread in the delay queue.
9. An electronic device, characterized in that: Including memory, transceiver, processor: A memory for storing a computer program; a transceiver for sending and receiving data under the control of the processor; and a processor for reading the computer program in the memory and executing the distributed lock processing method according to any one of claims 1 to 7.
10. A readable storage medium, characterized in that: The readable storage medium stores a program or an instruction, and when the program or the instruction is executed by the processor, the distributed lock processing method according to any one of claims 1 to 7 is implemented.