Distributed lock control method and device, equipment, medium and product

Abstract

The invention provides a distributed lock control method and device, equipment, a medium and a product, relates to the technical field of computers, and can consider saving of computing resources and keeping of data consistency. According to the specific technical scheme, a plurality of service threads aiming at a target resource service are obtained; and adding a distributed lock to the target thread, and starting a monitoring thread configured for the distributed lock. And polling the completion condition of the target thread according to the polling interval duration of the monitoring thread, and prolonging the validity period of the distributed lock under the condition that the target thread does not complete service resource processing. And releasing the distributed lock of the target thread and ending the monitoring thread on the basis of the prolonged validity period under the condition that the target thread completes service resource processing. On one hand, the validity period and the polling interval duration are adjusted according to the service load rate to save computing resources, and on the other hand, the validity period of the distributed lock is automatically prolonged to keep data consistency.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of computer, and particularly relate to a control method, device and equipment of distributed lock, medium and product. BACKGROUND

[0002] When multiple processes or nodes need to access the same shared resource (such as a database, cache, file system, etc.), if no lock mechanism is set, problems such as simultaneous reading and writing, data disorder, etc. may occur.

[0003] In the traditional way, the process is added to the distributed lock mechanism, and a fixed expiration time is set for the distributed lock. The setting of the fixed expiration time depends on human experience. If the fixed expiration time is set too long, in the case of the end of the business, the distributed lock has not expired, and a deadlock phenomenon will occur, occupying system computing resources. If the fixed expiration time is set too short, in the case of the end of the business, the distributed lock has expired, which will cause the problem of data inconsistency. SUMMARY

[0004] Embodiments of the present application provide a control method, device and equipment of distributed lock, medium and product, which can balance saving computing resources and maintaining data consistency.

[0005] In a first aspect, a control method of distributed lock is provided, the method comprising: The service load condition of the service end is acquired, and the service load condition includes a service load rate of the service end. The service load rate provides a basis for subsequent extension of the validity period according to the service load rate. In each service thread, a target thread that successfully occupies a service resource in the target resource service is screened, and a thread that needs to occupy a resource is determined, so as to avoid occupying the service resource by multiple threads at the same time and maintain data consistency. A distributed lock is added to the target thread, and a monitoring thread configured for the distributed lock is started; the distributed lock is used to prevent service threads other than the target thread from processing the service resource, so as to avoid processing the service resource by service threads other than the target thread and avoid data inconsistency. The completion of the target thread is polled according to a polling interval of the monitoring thread, and in a case where the target thread does not complete processing of the service resource, the validity period of the distributed lock is extended, wherein the extension time of the validity period of the distributed lock is in a positive correlation with the service load rate, the polling interval is in a positive correlation with the service load rate, and the polling interval is less than or equal to the extension time. In a case where the target thread is not completed, the validity period of the distributed lock is automatically extended, so as to ensure that the distributed lock remains valid before the service ends, and data consistency is maintained. Because the service load rate is in a positive correlation with the extension time of the validity period of the distributed lock and the polling interval, first, compared with setting a fixed validity period for the distributed lock, the extension time of the distributed lock is dynamically adjusted by the polling interval, and the extension time is relatively short each time. In a case where the service ends, the distributed lock can be invalidated in a timely manner, and a deadlock phenomenon is less likely to occur, and system computing resources can be saved. Second, in a case where the service load rate is high, the extension time and the polling interval are relatively long, the polling frequency of the monitoring thread is reduced, the occupation of system resources is reduced, and system computing resources are saved. Moreover, the polling time and the extension time can be dynamically adjusted based on the actual situation of the service load rate, so as to save computing resources consumed by the distributed lock as much as possible while ensuring normal operation of other services of the system. In a case where the service load rate is low, the extension time and the polling interval are relatively short, and the validity period after extension is also relatively short, which helps to improve the release speed of the distributed lock. In a case where the target thread completes processing of the service resource, the distributed lock of the target thread is released based on the validity period after extension, and the monitoring thread is ended, so as to release the distributed lock in a timely manner, avoid a deadlock phenomenon of the distributed lock, avoid frequent calling of the service resource, and save computing resources.

[0006] The method, on one hand, automatically prolongs the validity period of the distributed lock, ensures that the distributed lock remains valid before the end of the service, and maintains data consistency. On the other hand, in the case of high service load rate on the server side, the prolongation time and the polling interval time are correspondingly lengthened, the polling frequency of the monitoring thread is reduced, the occupation of system resources is reduced, and the system computing resources are saved. On the other hand, in the case of low service load rate, the prolongation time and the polling interval time are shortened, and the extended validity period is also shortened, which helps to improve the release speed of the distributed lock, thereby avoiding frequent calling of business resources and saving computing resources.

[0007] In a possible implementation of the first aspect, the obtaining of the plurality of service threads for the target resource service comprises: in response to a configuration operation of an object for the target resource service, obtaining an annotation parameter for the target resource service; obtaining a plurality of base threads for the target resource service; writing an annotation parameter value of the annotation parameter into each of the base threads to obtain a corresponding service thread of each of the base threads, wherein each of the service threads comprises the annotation parameter value and a processing method for each of a plurality of base resources in the target resource service; and the screening of a target thread that successfully occupies a business resource in the target resource service from the service threads comprises: screening a business resource that matches the annotation parameter value from the base resources; and screening a target thread that successfully occupies the business resource from the service threads.

[0008] In the scheme, in response to a configuration operation of an object for a target resource service, an annotation parameter for the target resource service is obtained. A plurality of base threads for the target resource service are obtained. An annotation parameter value of the annotation parameter is written into each of the base threads to obtain a corresponding service thread of each of the base threads, wherein each of the service threads comprises the annotation parameter value and a processing method for each of a plurality of base resources in the target resource service. Through the configuration operation, the annotation parameter value is written into the base thread to obtain the service thread, the business method that needs to use the distributed lock is enhanced, and the distributed lock is introduced into the program in a non-service invasive manner. The developer only needs to configure the custom annotation to conveniently use the distributed lock without needing to care about locking, releasing, exception handling, atomicity of Redis operation, etc. In each of the base resources, a business resource that matches the annotation parameter value is screened. In each of the service threads, a target thread that successfully occupies the business resource is screened. The business resource and the target thread that successfully occupies the business resource are accurately screened without manually selecting the thread, the accuracy of the target thread determination is improved, and the accuracy of the distributed lock control is improved.

[0009] In a possible implementation manner of the first aspect, the obtaining the service load condition of the service end comprises: obtaining an interface call frequency of the target resource service, a hardware utilization rate of the service end, an interface call weight configured for the interface call frequency, and a hardware utilization weight configured for the hardware utilization rate; and determining the service load rate based on a product of the interface call frequency and the interface call weight and a product of the hardware utilization rate and the hardware utilization weight.

[0010] In this scheme, the interface call frequency of the target resource service, the hardware utilization rate of the service end, the interface call weight configured for the interface call frequency, and the hardware utilization weight configured for the hardware utilization rate are obtained. The service load rate is determined based on the product of the interface call frequency and the interface call weight and the product of the hardware utilization rate and the hardware utilization weight. The interface call frequency and the hardware utilization rate are weighted respectively by the weights, the importance of the interface call frequency and the hardware utilization rate is considered, the accuracy of determining the service load rate is improved, and the control accuracy of the distributed lock is further improved. The interface call weight and the hardware utilization weight are configured in combination with the actual situation of the service, and the accuracy of determining the service load rate is further improved.

[0011] In a possible implementation manner of the first aspect, the service load condition further comprises a service load type; the polling interval duration comprises a first interval duration, a second interval duration and a third interval duration, wherein the first interval duration is greater than the second interval duration, and the second interval duration is greater than the third interval duration; and the polling, according to the polling interval duration of the monitoring thread, of the completion condition of the target thread and the extension, in a case where the target thread does not complete the service resource processing, of the validity period of the distributed lock comprises: determining the service load type of the service end; in a case where the service load type is a high load type, polling, according to the first interval duration of the monitoring thread, of the completion condition of the target thread and extending, in a case where the target thread does not complete the service resource processing, of the validity period of the distributed lock; in a case where the service load type is a medium load type, polling, according to the second interval duration of the monitoring thread, of the completion condition of the target thread and extending, in a case where the target thread does not complete the service resource processing, of the validity period of the distributed lock; and in a case where the service load type is a low load type, polling, according to the third interval duration of the monitoring thread, of the completion condition of the target thread and extending, in a case where the target thread does not complete the service resource processing, of the validity period of the distributed lock, wherein the service load rate corresponding to the high load type is greater than the service load rate corresponding to the medium load type, and the service load rate corresponding to the medium load type is greater than the service load rate corresponding to the low load type.

[0012] In the scheme, the service load condition further includes: a service load type; and a polling interval duration including a first interval duration, a second interval duration and a third interval duration, wherein the first interval duration is greater than the second interval duration, and the second interval duration is greater than the third interval duration, and the service load type of the service end is determined. In a case where the service load type is a high load type, the completion of the target thread is polled according to the first interval duration of the monitoring thread, and in a case where the target thread does not complete the service resource processing, the validity period of the distributed lock is extended. In a case of high service load, the system performance consumption is large, a larger time interval is set, the polling frequency of the monitoring thread is reduced, and the consumption of computing resources is reduced. In a case where the service load type is a medium load type, the completion of the target thread is polled according to the second interval duration of the monitoring thread, and in a case where the target thread does not complete the service resource processing, the validity period of the distributed lock is extended. In a case of medium service load, a balanced time interval is taken, and the saving of computing resources and the maintenance of data consistency are balanced. In a case where the service load type is a low load type, the completion of the target thread is polled according to the third interval duration of the monitoring thread, and in a case where the target thread does not complete the service resource processing, the validity period of the distributed lock is extended. The service load rate corresponding to the high load type is greater than the service load rate corresponding to the medium load type, and the service load rate corresponding to the medium load type is greater than the service load rate corresponding to the low load type. In a case of low load type, the system performance consumption is small, a short time interval is set, the expiration time of the lock is more accurate, and the data consistency is maintained.

[0013] In a possible implementation of the first aspect, in the case where the service load type is a high load type, the validity period of the distributed lock is extended according to the first interval duration of the monitoring thread, including: obtaining a service load rate threshold corresponding to the high load type of the service load type; in the case where the service load type is a high load type, updating the first interval duration of the monitoring thread according to the difference between the service load rate and the service load rate threshold to obtain an updated interval duration; and extending the validity period of the distributed lock according to the updated interval duration.

[0014] In the scheme, the service load rate threshold corresponding to the high load type is acquired. In the case that the service load type is the high load type, the first interval length of the monitoring thread is updated according to the difference between the service load rate and the service load rate threshold, to obtain an updated interval length. The validity period of the distributed lock is extended according to the updated interval length. The first interval length of the monitoring thread is updated according to the difference, to obtain the updated interval length, and the updated interval length is longer, so that the polling frequency of the monitoring thread is reduced, and the computing resources are saved. The updated interval length is related to the difference, so that the updated interval length is not set too large, and the long-time occupation of the distributed lock is avoided, and the computing resources are further saved.

[0015] In a possible implementation manner of the first aspect, the control method of the distributed lock further includes: monitoring the target thread based on the monitoring thread to obtain state information of the target thread; and in the case that the state information contains abnormal state information, releasing the distributed lock of the target thread and ending the monitoring thread.

[0016] In the scheme, the target thread is monitored based on the monitoring thread to obtain state information of the target thread. In the case that the state information contains abnormal state information, the distributed lock of the target thread is released and the monitoring thread is ended. In the case of an exception, the monitoring thread is ended in time, which can avoid the occupation of computing resources, and ensure that the resources are completely released. Thread exception can cause serious problems. Ending the process can immediately stop all operations, prevent errors from expanding, and reduce the loss of the server. The distributed lock is released, and the deadlock situation is avoided, and the computing resources are further saved.

[0017] In a second aspect, a control device for a distributed lock is provided, and the device comprises: an acquisition module configured to acquire a plurality of service threads for a target resource service and a service load condition of a server, the service load condition comprising a service load rate of the server; a thread screening module configured to screen, among the service threads, a target thread that successfully occupies a service resource in the target resource service; a thread starting module configured to add a distributed lock to the target thread and start a monitoring thread configured for the distributed lock; the distributed lock is configured to prevent service threads other than the target thread from processing the service resource; a processing module configured to poll a completion condition of the target thread according to a polling interval duration of the monitoring thread, and in a case where the target thread does not complete the processing of the service resource, extend a validity period of the distributed lock, wherein the extension time of the validity period of the distributed lock is in a positive correlation with the service load rate, the polling interval duration is in a positive correlation with the service load rate, and the polling interval duration is less than or equal to the extension time; and a release module configured to release the distributed lock of the target thread and end the monitoring thread based on the extended validity period in a case where the target thread completes the processing of the service resource.

[0018] In a third aspect, a control device for a distributed lock is provided, and the method comprises: a memory and at least one processor. The memory is in communication connection with the processor. The memory is configured to store computer program code, and the computer program code comprises computer instructions. When the processor executes the computer instructions, the electronic device performs the method as described in the first aspect and any possible implementation manner thereof.

[0019] In a fourth aspect, a computer readable storage medium is provided, and the computer readable storage medium stores computer instructions. When the computer instructions are executed by a processor, the method as described in the first aspect and any possible implementation manner thereof is implemented.

[0020] In a fifth aspect, a computer program product is provided, and when the computer program product is run on a computer / executed by a processor of a computer, the method as described in the first aspect and any possible implementation manner thereof is implemented. The computer can be the control device for a distributed lock as described in the third aspect and any possible implementation manner thereof.

[0021] It can be understood that the control device for a distributed lock as described in the second aspect, the control device for a distributed lock as described in the third aspect, the computer readable storage medium as described in the fourth aspect, and the computer program product as described in the fifth aspect can achieve the beneficial effects as described in the first aspect and any possible implementation manner thereof, and thus details are not repeated here. BRIEF DESCRIPTION OF DRAWINGS

[0022] Figure 1 A structural schematic diagram of a distributed lock control system provided in an embodiment of the present application is shown in FIG. 1. Figure 2 A flowchart of a distributed lock control method provided in an embodiment of the present application is shown in FIG. 2. Figure 3 A flowchart of a distributed lock validity period extension method provided in an embodiment of the present application is shown in FIG. 3. Figure 4 A flowchart of a server exclusive distributed lock method provided in an embodiment of the present application is shown in FIG. 4. Figure 5 A structural schematic diagram of a distributed lock control device provided in an embodiment of the present application is shown in FIG. 5. Figure 6 A structural schematic diagram of a distributed lock control device provided in an embodiment of the present application is shown in FIG. 5. DETAILED DESCRIPTION

[0023] Hereinafter, the terms "first" and "second" are used only for the purpose of description, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined with "first" and "second" can explicitly or implicitly include one or more of the features. In the description of the embodiments, the meaning of "a plurality of" is two or more, unless otherwise specified.

[0024] The exemplary embodiments will be described in detail below with reference to the accompanying drawings. In the following description, the same numbers refer to the same or similar elements unless otherwise specified. The embodiments described in the following exemplary embodiments do not represent all the embodiments consistent with the present application. Rather, they are merely examples of devices and methods consistent with some aspects of the present application, as detailed in the appended claims.

[0025] In the technical solutions provided in the embodiments of the present application, the collection, storage, use, processing, transmission, provision and disclosure of information such as financial data or user data, etc. all comply with the relevant legal regulations and do not violate public order and good customs.

[0026] It should be noted that in the embodiments of the present application, some industry existing solutions, components, models, etc. may be mentioned, which should be considered as exemplary, and the purpose is only to illustrate the feasibility of the implementation of the technical solutions of the present application, but does not mean that the applicant has or will necessarily use the solutions.

[0027] The distributed lock control method provided in the embodiments of the present application can be applied to, for example, Figure 1The control system of the distributed lock shown in the figure includes a server 102 and a plurality of terminals 104.

[0028] The server 102 is configured to obtain a plurality of service threads corresponding to a plurality of terminals 102 for a target resource service, and a service load condition of the server, the service load condition including a service load rate of the server. The server 102 is configured to filter a target thread that successfully occupies a service resource in the target resource service from the service threads. The server 102 is configured to add a distributed lock to the target thread, and start a monitoring thread configured for the distributed lock, the distributed lock being configured to prevent service threads other than the target thread from processing the service resource. The server 102 is configured to poll the target thread according to a polling interval of the monitoring thread, and extend a validity period of the distributed lock when the target thread does not complete the service resource processing, wherein the extension time of the validity period of the distributed lock is positively correlated with the service load rate, the polling interval is positively correlated with the service load rate, and the polling interval is less than or equal to the extension time. The server 102 is configured to release the distributed lock of the target thread based on the extended validity period and end the monitoring thread when the target thread completes the service resource processing.

[0029] The terminal 104 is configured to initiate a service request to the server 102, the service request including a service thread. One service request includes at least one service thread.

[0030] The control system of the distributed lock can further include a processing end, the processing end being configured to execute the method steps corresponding to the server 102 and the plurality of terminals 104.

[0031] The server 102 can be a server, which can be implemented by an independent server or a server cluster composed of a plurality of servers. The terminal 104 can be a processor with computing capability.

[0032] When a plurality of processes or nodes need to access the same shared resource (such as a database, a cache, a file system, etc.), if no lock mechanism is set, problems such as simultaneous reading and writing and data disorder may occur.

[0033] In the traditional way, the process is added to the distributed lock mechanism, and a fixed expiration time is set for the distributed lock. The setting of the fixed expiration time depends on human experience. If the fixed expiration time is set too long, in the case of service end, the distributed lock does not expire, and a deadlock phenomenon occurs, occupying system computing resources. If the fixed expiration time is set too short, in the case of service not ending, the distributed lock expires, which may cause data inconsistency.

[0034] A plurality of service threads for a target resource service are acquired. A distributed lock is added to the target thread, and a monitoring thread configured for the distributed lock is started. The completion of the target thread is polled according to a polling interval of the monitoring thread, and the validity period of the distributed lock is extended in the case that the target thread does not complete the service resource processing. In the case that the target thread completes the service resource processing, the distributed lock of the target thread is released based on the extended validity period, and the monitoring thread is ended. On the one hand, the validity period and the polling interval are adjusted according to the service load rate to save computing resources, and on the other hand, the validity period of the distributed lock is automatically extended, thereby maintaining data consistency.

[0035] In one embodiment, as shown in Figure 2 , a distributed lock control method is provided, which can be applied to a server in Figure 1 , or a cloud computing platform, an edge computing device, a chip, a device with computing capability, etc. with data processing capability. The embodiments of the present application do not limit the specific form of the method execution device, and the method is taken as an example of application to a server. The method specifically includes: S201, acquiring a plurality of service threads for a target resource service, and a service load condition of the server, the service load condition including a service load rate of the server.

[0036] In some embodiments, the target resource service can be a specific business type dependent on the target resource. The target resource can be a specific resource in a database, a specific resource in a cache file, or a specific resource in a file system. Specifically, the target resource can be order information, inventory information, etc. in an e-commerce business, or the target resource can be balance information, transfer information, etc. in a financial business. The target resource is characterized by sharing, i.e. multiple nodes or multiple processes can access the same target resource.

[0037] The service thread can be the smallest unit of scheduling operation in the target resource service. The service thread contains a specific processing method for the target resource service. It can be understood that each service thread can process the target resource in the target resource service independently.

[0038] The server can be a server, which can be implemented by an independent server or a server cluster composed of multiple servers.

[0039] The service load condition can be the load condition of the server at the current time or in a preset time period. The load condition can be the workload and resource occupation condition of the server when processing the service thread, mainly including CPU usage, memory occupation, disk I / O usage, network bandwidth information, interface calling condition, etc.

[0040] The service load rate can represent a quantitative service load condition, and the service load rate can include CPU usage, memory usage, disk I / O usage, network bandwidth, interface call frequency, and the like of the server.

[0041] In a possible implementation, the server can obtain the service load condition of the server for the target resource service.

[0042] In a possible implementation, the server can obtain the service load condition of the server for the target resource service.

[0043] In a possible implementation, the server can read the running log and running index of the server (the server) to obtain the service load condition of the server.

[0044] In a possible implementation, the server can obtain the interface call frequency of the target resource service, the hardware utilization rate of the server, the interface call weight configured for the interface call frequency, and the hardware utilization weight configured for the hardware utilization rate. The server can determine the service load rate based on the product of the interface call frequency and the interface call weight, and the product of the hardware utilization rate and the hardware utilization weight.

[0045] S202, in each service thread, a target thread that successfully occupies a business resource in the target resource service is screened.

[0046] In some embodiments, the business resource can be a specific resource in the target resource service. For example, in the case of the target resource service being an e-commerce service, the business resource can be balance information and transfer information involved in the e-commerce service. For another example, in the case of the target resource service being a financial service, the business resource can be balance information and transfer information involved in the financial service. The business resource is usually characterized by sharing.

[0047] The target thread can represent a service thread that successfully occupies the business resource. Other service threads than the target thread can be considered as service threads that fail to occupy the business resource.

[0048] In a possible implementation, the server can screen, in each service thread, a target thread that successfully occupies a business resource in the target resource service. Specifically, the server can determine a respective occupation order of each service thread for the business resource, and the server can determine, as the target thread that successfully occupies the business resource in the target resource service, a service thread ranked first in the occupation order.

[0049] In a possible implementation, the server can further sort the service threads according to respective preemption orders of the service threads corresponding to the service resources, to obtain a preemption order sorting result of the service threads. The server can select one service thread from the top N service threads in the sorting result in a random manner, and determine the service thread as the target thread.

[0050] In a possible implementation, the server can obtain the annotation parameter corresponding to the target resource service in response to a configuration operation of the object on the target resource service. The server can obtain a plurality of base threads corresponding to the target resource service. The server can write the annotation parameter value of the annotation parameter into each base thread respectively, to obtain a service thread corresponding to each base thread, wherein each service thread includes the annotation parameter value and a processing method corresponding to each of a plurality of base resources in the target resource service. The server can filter a service resource matching the annotation parameter value from the base resources. The server can filter the target thread occupying the service resource successfully from the service threads.

[0051] S203, add a distributed lock to the target thread, and start a monitoring thread configured for the distributed lock.

[0052] In some embodiments, the distributed lock is used to prevent service threads other than the target thread from processing the service resource.

[0053] In some embodiments, the distributed lock can be a way of controlling synchronous access to shared resources between distributed systems. The distributed lock can be used to coordinate mutual exclusion of resources by different systems or hosts, prevent data conflicts, and ensure consistency.

[0054] The monitoring thread can be a thread used to monitor the target thread. The monitoring thread can be used to extend the validity time of the distributed lock, and the monitoring thread can also monitor the validity time of the distributed lock at a regular time. Specifically, the monitoring thread can automatically extend the validity time of the distributed lock at a regular time, thereby avoiding expiration of the distributed lock in the case that the service is not completed (the target thread does not complete processing of the service resource), causing other service threads to also process the service resource, and causing inconsistent data.

[0055] In a possible implementation, the server can add a distributed lock to the target thread, and start a monitoring thread configured for the distributed lock.

[0056] The server can write the ID of the distributed lock into a preset thread used for monitoring, to obtain the monitoring thread configured for the distributed lock.

[0057] S204, polling the completion of the target thread according to the polling interval duration of the monitoring thread, and prolonging the validity period of the distributed lock when the target thread does not complete the service resource processing.

[0058] In some embodiments, the polling interval duration can be the interval duration between adjacent start of the monitoring thread. For example, the interval duration between the first start and the second start of a monitoring thread is 5s, and the polling interval duration is 5s.

[0059] The completion of the target thread can represent the processing of the service resource by the target thread. The completion of the target thread includes that the target thread does not complete the processing of the service resource and completes the processing of the service resource. Specifically, the service resource processing not being completed can be that the target thread has not modified the order information or the modification is not completed. The processing of the service resource being completed can be that the modification of the order information by the target thread is completed.

[0060] The validity period of the distributed lock can represent the lock period of the service resource by the target thread. For example, the target thread can process the service resource within the lock period, and other business threads cannot process the service resource, thereby avoiding the risk of data inconsistency and improving data consistency.

[0061] The extension time can represent the time difference between the validity period of the distributed lock and the new validity period after extension. For example, the validity period of the distributed lock is 5s, the new validity period after extension is 7.5s, and the extension time is 2.5s.

[0062] In some embodiments, the extension time of the validity period of the distributed lock is positively correlated with the business load rate, the polling interval duration is positively correlated with the business load rate, and the polling interval duration is less than or equal to the extension time.

[0063] The higher the business load rate, the longer the extension time of the validity period of the distributed lock, and the higher the business load rate, the longer the polling interval duration. On the one hand, when the business load rate of the server is high, the extension time and the polling interval time are correspondingly lengthened, the polling frequency of the monitoring thread is reduced, the occupation of system resources is reduced, and the system computing resources are saved. On the other hand, when the business load rate is low, the extension time and the polling interval time are shortened, and the validity period after extension is also shortened, which helps to improve the release speed of the distributed lock, thereby avoiding frequent calling of the service resource and saving computing resources.

[0064] In some embodiments, the polling interval duration being less than or equal to the extension time can ensure that the distributed lock is still valid when the monitoring thread prolongs the validity period of the distributed lock each time, and the situation that the distributed lock is invalid when the monitoring thread polls can be avoided, thereby avoiding the risk of data inconsistency and ensuring data consistency.

[0065] In a possible implementation, the completion of the target thread is polled according to the polling interval duration of the monitoring thread, and the validity period of the distributed lock is extended in a case where the target thread does not complete the service resource processing.

[0066] In a possible implementation, the server can obtain a polling weight configured for the polling interval duration and a validity period weight configured for the validity period of the distributed lock, where the polling weight is less than or equal to the validity period weight. The server can determine the polling interval duration according to the product of the service load rate and the polling weight. The server can determine the extension time of the validity period of the distributed lock according to the product of the service load rate and the validity period weight.

[0067] In a possible implementation, the service load condition further includes a service load type, and the polling interval duration includes a first interval duration, a second interval duration, and a third interval duration, where the first interval duration is greater than the second interval duration, and the second interval duration is greater than the third interval duration. The server can determine the service load type of the server. In a case where the service load type is a high load type, the server can poll the completion of the target thread according to the first interval duration of the monitoring thread, and extend the validity period of the distributed lock in a case where the target thread does not complete the service resource processing. In a case where the service load type is a medium load type, the server can poll the completion of the target thread according to the second interval duration of the monitoring thread, and extend the validity period of the distributed lock in a case where the target thread does not complete the service resource processing. In a case where the service load type is a low load type, the server can poll the completion of the target thread according to the third interval duration of the monitoring thread, and extend the validity period of the distributed lock in a case where the target thread does not complete the service resource processing. The service load rate corresponding to the high load type is greater than the service load rate corresponding to the medium load type, and the service load rate corresponding to the medium load type is greater than the service load rate corresponding to the low load type.

[0068] S205, in a case where the target thread completes the service resource processing, the distributed lock of the target thread is released and the monitoring thread is ended based on the extended validity period.

[0069] In a possible implementation, in a case where the target thread completes the service resource processing and the extended validity period expires, the server can release the distributed lock of the target thread and end the monitoring thread. This avoids the target thread continuously occupying the distributed lock and the monitoring thread continuously running, avoids the deadlock phenomenon, and saves computing resources.

[0070] The target thread can be caused by a variety of circumstances, such as the business interface exception, in which case the distributed lock of the target thread needs to be released, and the monitoring thread is ended to avoid the continuous occupation of the computing resources. Specifically, the server can monitor the target thread based on the monitoring thread to obtain the state information of the target thread. The server can release the distributed lock of the target thread and end the monitoring thread in the case that the state information contains the abnormal state information.

[0071] In the embodiment, the service load condition of the service end is acquired for the target resource service, and the service load condition includes a service load rate of the service end. The service load rate provides a basis for subsequent extension of the validity period according to the service load rate. In each service thread, a target thread that successfully occupies a service resource in the target resource service is screened, and a thread that needs to occupy a resource is determined, so as to avoid occupying the service resource by multiple threads at the same time and maintain data consistency. A distributed lock is added to the target thread, and a monitoring thread configured for the distributed lock is started; the distributed lock is used to prevent service threads other than the target thread from processing the service resource, so as to avoid processing the service resource by service threads other than the target thread and avoid data inconsistency. The completion of the target thread is polled according to a polling interval of the monitoring thread, and in a case where the target thread does not complete processing of the service resource, the validity period of the distributed lock is extended, wherein the extension time of the validity period of the distributed lock is in a positive correlation with the service load rate, the polling interval is in a positive correlation with the service load rate, and the polling interval is less than or equal to the extension time. In a case where the target thread does not complete the processing, the validity period of the distributed lock is automatically extended, so as to ensure that the distributed lock remains valid before the service ends and maintain data consistency. Since the service load rate is in a positive correlation with the extension time of the validity period of the distributed lock and the polling interval, first, compared with setting a fixed validity period for the distributed lock, the extension time of the distributed lock is dynamically adjusted by the polling interval, the extension time is relatively short each time, the distributed lock can be invalidated in time in a case where the service ends, a deadlock phenomenon is less likely to occur, and system computing resources can be saved. Second, in a case where the service load rate is high, the extension time and the polling interval are relatively long, the polling frequency of the monitoring thread is reduced, the occupation of system resources is reduced, and system computing resources are saved. Moreover, the polling time and the extension time can be dynamically adjusted based on the actual condition of the service load rate, so as to save computing resources consumed by the distributed lock as much as possible while ensuring normal operation of other services of the system. In a case where the service load rate is low, the extension time and the polling interval are relatively short, and the validity period after extension is also relatively short, which helps to improve the release speed of the distributed lock. In a case where the target thread completes processing of the service resource, the distributed lock of the target thread is released and the monitoring thread is ended based on the validity period after extension, the distributed lock is released in time, a deadlock phenomenon of the distributed lock is avoided, frequent calling of the service resource is avoided, and computing resources are saved. The method automatically extends the validity period of the distributed lock, ensures that the distributed lock remains valid before the service ends, and maintains data consistency.On the other hand, in the case of high service load rate of the server, the extension time and the polling interval time are correspondingly lengthened, the polling times of the monitoring thread are reduced, the occupation of system resources is reduced, and the system computing resources are saved. On the other hand, in the case of low service load rate, the extension time and the polling interval time are shortened, and the effective period after the extension is also shortened, which helps to improve the release speed of the distributed lock, thereby avoiding frequent calling of business resources and saving computing resources.

[0072] In one embodiment, the plurality of business threads for the target resource service are obtained, including: in response to a configuration operation of an object on the target resource service, obtaining an annotation parameter for the target resource service. A plurality of basic threads for the target resource service are obtained. The annotation parameter value of the annotation parameter is written into each basic thread respectively to obtain a business thread corresponding to each basic thread respectively, wherein each business thread includes the annotation parameter value and a processing method for each of a plurality of basic resources in the target resource service. In each business thread, a target thread that successfully occupies a business resource in the target resource service is screened, including: in each basic resource, a business resource matching the annotation parameter value is screened. In each business thread, a target thread that successfully occupies a business resource is screened.

[0073] In some embodiments, the object can be a terminal or a server, or a user.

[0074] The configuration operation can be an operation initiated by a terminal or a server on the target resource service.

[0075] The annotation parameter of the target resource service can be a parameter for writing into a code block corresponding to the thread. The code block contains a specific method for processing the target resource by the thread. The code block is a modularized code, which can be separated from the business logic by using a dynamic proxy technology to separate the common logic (such as log, transaction management) across multiple modules, to realize code decoupling and reuse.

[0076] The basic thread can be a thread containing only a processing method corresponding to each of a plurality of basic resources in the target resource service. In order to facilitate subsequent lock processing on the basic thread, the annotation parameter can be written into the basic thread in advance to obtain the business thread.

[0077] In one possible implementation, the server can write the annotation parameter value of the annotation parameter into each basic thread respectively to obtain a business thread corresponding to each basic thread respectively. Specifically, the server can write the annotation parameter and the annotation parameter value on the code interface of the basic thread.

[0078] In some embodiments, the annotation parameter value of the annotation parameter can be a resource ID representing a business resource.

[0079] For example, the annotation parameter can be configured with the resource number that needs to be locked (the resource number is a unique mapping to the real resource). This resource number can exist in the interface request parameter or come from the ThreadLocal object inside the thread.

[0080] In some embodiments, the business resource matching the annotation parameter value can be the business resource corresponding to the resource number targeted by the annotation parameter value. For example, an annotation parameter value of 1 can represent that the business resource to be processed by the business thread is a first type of business resource (e.g., order information), and an annotation parameter value of 2 can represent that the business resource to be processed by the business thread is a second type of business resource (e.g., inventory information).

[0081] In one possible implementation, after the server filters out business resources that match the annotation parameter values ​​from among the basic resources, the server can then filter out target threads that have successfully occupied the business resources from among the business threads.

[0082] In this embodiment, in response to the configuration operation of the object for the target resource business, annotation parameters for the target resource business are obtained. Multiple basic threads for the target resource business are obtained. The annotation parameter values ​​are written into each basic thread, resulting in a corresponding business thread for each basic thread. Each business thread includes the annotation parameter value and a processing method for each of the multiple basic resources in the target resource business. Through the configuration operation, the annotation parameter values ​​are written into the basic threads to obtain business threads, enhancing the business methods that require distributed locks and introducing distributed locks into the program in a non-intrusive manner. Developers only need to configure custom annotations to easily use distributed locks without worrying about locking, releasing locks, exception handling, or the atomicity of Redis operations. Among the basic resources, business resources matching the annotation parameter values ​​are selected. Among the business threads, target threads that have successfully occupied the business resources are selected. Accurately selecting business resources and target threads that have successfully occupied them eliminates the need for manual thread selection, improving the accuracy of target thread determination and the accuracy of distributed lock control.

[0083] In one embodiment, obtaining the server's business load includes: obtaining the interface call frequency of the target resource business, the server's hardware utilization, the interface call weight configured for the interface call frequency, and the hardware utilization weight configured for the hardware utilization. The business load rate is determined based on the product of the interface call frequency and the interface call weight, and the product of the hardware utilization and the hardware utilization weight.

[0084] In some embodiments, the API call frequency for obtaining target resource services can represent the call frequency of the business API, specifically the number of times the business API is called within a preset time period. A higher API call frequency indicates a higher level of business load.

[0085] Server-side hardware utilization can refer to the utilization of various hardware components within the server. Hardware can include CPU, memory, disk, network devices, etc. Hardware utilization can include: CPU utilization, memory utilization, disk utilization, network transmission speed, etc.

[0086] Interface call weight can be a weight configured based on the frequency of interface calls.

[0087] Hardware utilization weights can be weights configured for hardware utilization.

[0088] In one possible implementation, the server can obtain at least one of CPU utilization, memory utilization, disk utilization, and network transfer speed, and then average them to obtain hardware utilization. For example, the server can obtain CPU utilization (80%) and network transfer speed (70%), average them, and obtain hardware utilization of 75%.

[0089] In one possible implementation, the server can respond to an object's weight configuration operation by obtaining a hardware utilization weight configured for hardware utilization and an interface call weight configured for interface call frequency.

[0090] In one possible implementation, the server can also determine the degree of impact of hardware utilization and interface call frequency on the business load, and determine the hardware utilization weight configured for hardware utilization and the interface call weight configured for interface call frequency. The weights and the degree of impact are positively correlated.

[0091] In one possible implementation, the server can also determine the hardware utilization weight configured for hardware utilization and the interface call weight configured for interface call frequency based on the data integrity of both hardware utilization and interface call frequency. Higher data integrity results in higher weights. Determining weights based on the degree of influence or data integrity increases the weight of primary data, avoids interference from secondary data, and maximizes the accuracy of determining business load rates.

[0092] In this embodiment, the interface call frequency of the target resource service, the server's hardware utilization rate, the interface call weight configured for the interface call frequency, and the hardware utilization weight configured for the hardware utilization rate are obtained. The service load rate is determined based on the product of the interface call frequency and the interface call weight, and the product of the hardware utilization rate and the hardware utilization weight. By weighting the interface call frequency and hardware utilization rate separately, the importance of each is considered, improving the accuracy of determining the service load rate and further enhancing the control accuracy of the distributed lock. By configuring the interface call weight and hardware utilization weight, the actual business situation is considered, further improving the accuracy of determining the service load rate.

[0093] In one embodiment, such as Figure 3 The flowchart illustrating the method for extending the validity period of a distributed lock shows that, in S204, the completion status of the target thread is polled according to the polling interval of the monitoring thread. If the target thread has not completed the processing of business resources, the validity period of the distributed lock is extended, specifically including: S301, determine the service load type on the server side.

[0094] In some embodiments, the service load condition further includes: service load type. The polling interval duration includes a first interval duration, a second interval duration, and a third interval duration, wherein the first interval duration is longer than the second interval duration, and the second interval duration is longer than the third interval duration.

[0095] In some embodiments, the service load type can be a classification of the server's service load. Service load types can include high load, medium load, and low load. The service load rate corresponding to the high load type is greater than that corresponding to the medium load type, and the service load rate corresponding to the medium load type is greater than that corresponding to the low load type.

[0096] The first, second, and third interval durations can be the polling intervals of the monitoring threads under high, medium, and low load conditions, respectively.

[0097] In one possible implementation, the server can determine the type of service load based on the service load rate.

[0098] In one possible implementation, the server can obtain a first service load rate range configured for high load type, a second service load rate range configured for medium load type, and a third service load rate range configured for low load type. The lower limit of the first service load rate range is greater than the upper limit of the second service load rate range, and the lower limit of the second service load rate range is greater than the upper limit of the third service load rate range. The server determines the service load type based on the service load rate's position within the first, second, or third service load rate range.

[0099] S302: When the business load type is high load, poll the target thread for completion status according to the first interval of the monitoring thread. If the target thread has not completed the business resource processing, extend the validity period of the distributed lock.

[0100] In some embodiments, the first interval duration can be the polling interval duration corresponding to the monitoring thread under high load conditions.

[0101] The first interval duration can be less than or equal to the extended time.

[0102] In one possible implementation, the server can poll the target thread's completion status at a first interval according to the monitoring thread, and extend the validity period of the distributed lock if the target thread has not completed the processing of business resources.

[0103] In one possible implementation, the server can weight the first interval duration according to a first bias weight set for the first interval duration to obtain the extension time of the distributed lock's validity period. The first interval duration can be less than or equal to the extension time.

[0104] S303: When the business load type is medium load, poll the target thread for completion status according to the second interval of the monitoring thread. If the target thread has not completed the business resource processing, extend the validity period of the distributed lock.

[0105] In some embodiments, the second interval duration can be the polling interval duration corresponding to the monitoring thread under high load conditions.

[0106] The second interval duration can be less than or equal to the extended time.

[0107] In one possible implementation, the server can poll the target thread's completion status at a second interval according to the monitoring thread, and extend the validity period of the distributed lock if the target thread has not completed the processing of business resources.

[0108] In one possible implementation, the server can weight the first interval duration according to a second bias weight set for the second interval duration to obtain the extension time of the distributed lock's validity period. The second interval duration can be less than or equal to the extension time.

[0109] S304: When the business load type is low load, poll the target thread for completion status according to the third interval of the monitoring thread. If the target thread has not completed the business resource processing, extend the validity period of the distributed lock.

[0110] In some embodiments, the third interval duration can be the polling interval duration corresponding to the monitoring thread under high load conditions.

[0111] The third interval duration can be less than or equal to the extended time.

[0112] In one possible implementation, the server can poll the target thread's completion status at a third interval of the monitoring thread, and extend the validity period of the distributed lock if the target thread has not completed the processing of business resources.

[0113] In one possible implementation, the server can weight the third interval duration according to a third bias weight set for the third interval duration to obtain the extension time of the distributed lock's validity period. The third interval duration can be less than or equal to the extension time.

[0114] In this embodiment, the business load situation further includes: business load type; the polling interval includes a first interval, a second interval, and a third interval, wherein the first interval is longer than the second interval, and the second interval is longer than the third interval, thus determining the business load type of the server. When the business load type is high, the completion status of the target thread is polled according to the first interval of the monitoring thread. If the target thread has not completed the business resource processing, the validity period of the distributed lock is extended. Under high business load, system performance consumption is high, so a larger time interval is set, and the polling frequency of the monitoring thread is reduced, thus reducing the consumption of computing resources. When the business load type is medium, the completion status of the target thread is polled according to the second interval of the monitoring thread. If the target thread has not completed the business resource processing, the validity period of the distributed lock is extended. Under medium business load, a balanced time interval is used to balance saving computing resources and maintaining data consistency. When the business load type is low, the completion status of the target thread is polled according to the third interval of the monitoring thread. If the target thread has not completed the processing of business resources, the validity period of the distributed lock is extended. The business load rate corresponding to high load type is greater than that corresponding to medium load type, and the business load rate corresponding to medium load type is greater than that corresponding to low load type. Under low load type, the system performance consumption is small, the short time interval is set, the lock expiration time is more accurate, and data consistency is maintained.

[0115] In one embodiment, when the business load type is high load, the validity period of the distributed lock is extended according to the first interval of the monitoring threads, including: obtaining the business load rate threshold corresponding to the high load type; updating the first interval of the monitoring threads based on the difference between the business load rate and the business load rate threshold when the business load type is high load; and extending the validity period of the distributed lock according to the update interval.

[0116] In some embodiments, the service load rate threshold can be the lower limit of the service load rate range corresponding to a high load type. For example, a service load rate greater than 70% can be considered a high load type, and the service load rate threshold can be 70%.

[0117] The difference between the load factor and the load factor threshold can be a differential value, a ratio, etc. Taking the differential value as an example, the larger the difference between the load factor and the load factor threshold, the closer the server's load factor is to the load limit. To save computing resources, the first interval duration can be further extended to reduce the polling frequency of the monitoring thread.

[0118] The update interval can be the first interval after extending the time period. The difference between the update interval and the first interval can be proportional to the difference between the business load rate and the business load rate threshold.

[0119] In one possible implementation, when the business load type is high load, the server can update the first interval duration of the monitoring thread based on the difference between the business load rate and the business load rate threshold, thus obtaining the update interval duration.

[0120] Specifically, the server can update the first interval duration of the monitoring thread based on the difference or ratio between the business load rate and the business load rate threshold, thus obtaining the update interval duration.

[0121] In one possible implementation, the server can extend the validity period of the distributed lock based on the update interval. The update interval is shorter than the extended validity period.

[0122] In one possible implementation, when the business load type is high, the server can select a fixed duration as the update interval after the update. For example, the update interval can be set to 1 minute. That is, the monitoring thread polls once every 1 minute.

[0123] In this embodiment, the business load rate threshold corresponding to a high-load business load type is obtained. When the business load type is high-load, the first interval duration of the monitoring thread is updated based on the difference between the business load rate and the business load rate threshold, resulting in an update interval duration. The validity period of the distributed lock is extended according to the update interval duration. The update interval duration is increased by updating the first interval duration of the monitoring thread based on the difference, reducing the polling frequency of the monitoring thread and saving computational resources. The update interval duration is related to the difference, ensuring that the update interval duration is not set too large and avoiding prolonged occupation of the distributed lock, further saving computational resources.

[0124] In one embodiment, the distributed lock control method further includes: monitoring the target thread based on a monitoring thread to obtain the target thread's state information. If the state information includes abnormal state information, the distributed lock of the target thread is released and the monitoring thread is terminated.

[0125] In some embodiments, the status information may be information about the target thread's processing of business resources. The status information may include business response time and business processing error rate.

[0126] Abnormal status information can be at least one of the following: a sudden increase in response time or an increase in error rate within a preset time period.

[0127] In some embodiments, response time refers to the time required for the system to process a request and return a result. A sudden increase in response time indicates that the system is processing requests more slowly.

[0128] A sudden increase in response time could be caused by: system resource bottlenecks, code or database issues, or external dependency latency. System resource bottlenecks could be due to high CPU, memory, disk I / O, or network bandwidth usage, leading to decreased processing capacity. Code or database issues could specifically be inefficient database queries, code logic flaws, or database lock contention. External dependency latency could be caused by slow responses from dependent third-party services, dragging down overall performance.

[0129] Error rate refers to the proportion of errors that occur when a system processes a request. An increase in the error rate is a clear abnormal signal, indicating that there is a problem with the system's stability.

[0130] An increase in error rate could be caused by: system defects, resource exhaustion, or external service failures. System defects can indicate bugs in the code that cause some requests to fail. Resource exhaustion can specifically be due to insufficient memory, exceeding connection limits, etc., preventing the system from processing requests correctly. External service failures can specifically be due to the database, API, or other services that the business depends on being unavailable or returning errors.

[0131] In one possible implementation, the abnormal state information includes at least one of the following: a sudden increase in response time or an increase in error rate within a preset time period. The server can monitor the target thread based on the monitoring thread to obtain the target thread's state information. If the state information includes abnormal state information, the distributed lock of the target thread is released and the monitoring thread is terminated.

[0132] In one possible implementation, such as Figure 4 The server-side exclusive distributed lock method shown includes: S401, acquire the distributed lock on the aspect.

[0133] In some embodiments, a distributed lock is acquired in the aspect corresponding to each business thread.

[0134] In some embodiments, the AOP feature of the Spring framework is used to control distributed locks at aspects during the execution of the business application. These aspects are woven into the interfaces that require distributed exclusive locks through annotations. Users only need to develop the business logic itself and do not need to worry about the details of locking and releasing distributed locks.

[0135] Add the `@ControllerDistributedLock` annotation to the code interface. This annotation can be configured with the resource ID that needs to be locked (a unique mapping between the resource ID and the actual resource). This resource ID can exist in the interface request parameters or come from a `ThreadLocal` object within the thread. The resource ID can be a globally unique ID generated using the snowflake algorithm.

[0136] In some embodiments, the Spring framework is an open-source Java platform that provides a comprehensive programming and configuration model for modern Java-based enterprise applications. AOP, or Aspect-Oriented Programming, is a programming paradigm that allows developers to separate cross-cutting concerns from business logic, forming independent aspects, thereby enabling centralized management of these concerns. An aspect can be a block of code that defines a cross-cutting concern. A pointcut can be used to define which join points should be enhanced. Weaving can represent the process of weaving aspect code into the target object.

[0137] S402, failed to acquire resources, exited.

[0138] In some implementations, among the various business threads, the target thread that successfully acquires the target resource is selected. For business threads that fail to acquire the resource, the thread exits.

[0139] If S403 is successfully acquired, the monitoring thread will be started.

[0140] S404, Check if the target thread has completed.

[0141] If the target thread completes, it means that the target thread has finished executing the business logic, that is, the target thread has completed processing the business resources. If the target thread completes, it means that the target thread has not finished executing the business logic, that is, the target thread has not completed processing the business resources.

[0142] S405, extending the lock's validity period.

[0143] In some embodiments, if the target thread has completed, the monitoring thread is terminated. If the target thread has not completed, the monitoring process continues for the specified polling interval and returns S404.

[0144] In some embodiments, a monitoring mechanism to determine whether a business operation is complete is introduced into the distributed lock acquisition scheme to achieve automatic lock renewal. Specifically, the method in this scheme reclaims the right to set the expiration time of the exclusive lock in Redis and takes over the lock's expiration time. When a business thread attempts to acquire the lock, if successful, another monitoring thread is started to poll to determine if the lock exists. If it exists, it indicates that the business operation is underway. The next step is to extend the lock's expiration time via a Redis command, and the monitoring thread goes to sleep, relinquishing CPU resources and waiting for the next poll. The polling interval needs to be set according to whether the business is in a peak or off-peak period. This scheme comprehensively determines the business load by obtaining CPU utilization and the number of business interface accesses within a time period. A longer interval is selected during peak periods, and a shorter interval is selected during off-peak periods. Furthermore, to avoid frequent switching of judgments, if a peak period is determined, no further judgments are made for a fixed one minute, defaulting to high load. Finally, different lock renewal strategies are selected based on different business loads.

[0145] In some embodiments, during the polling process, if the lock exists, the monitoring thread extends its lifetime; otherwise, it indicates that the business process has been completed or an exception has occurred, and the monitoring thread will not renew the lock. In the event of a system crash, the program itself has failed, and the lock monitoring mechanism itself becomes ineffective, preventing the lock from being renewed indefinitely and thus avoiding deadlock.

[0146] S406, executes tasks based on the target thread.

[0147] In some embodiments, business operations are performed based on specific methods in the target thread, that is, business resources are processed according to specific methods.

[0148] S407, release lock on the cut surface.

[0149] In some embodiments, after the business logic is executed by the target thread, the distributed lock of the target thread is released.

[0150] In some embodiments, a relatively short time interval is given to renew the distributed lock, providing a reasonable expiration time to ensure that threads holding the lock do not occupy resources for too long, especially under high load, to avoid intensified resource contention and impact on system performance. Different time interval strategies are set according to different load conditions: 1. Low business load: Low system performance consumption, short time intervals allow for more accurate lock expiration; 2. High business load: High system performance consumption, longer time intervals reduce the polling frequency of monitoring threads, thus reducing consumption; 3. Medium business load: A balanced time interval is used. Specifically, the system's business load can also be comprehensively determined by CPU utilization and access volume statistics on the interface. This solution obtains CPU utilization in real time and assigns it a certain weight, and also assigns a certain weight based on the system's access volume statistics within a fixed time period, comprehensively determining the business load strategy. Different time intervals are used for polling in the lock renewal mechanism.

[0151] In this embodiment, the target thread is monitored by a monitoring thread to obtain its status information. If the status information includes abnormal status information, the distributed lock of the target thread is released and the monitoring thread is terminated. In case of an anomaly, timely termination of the monitoring thread avoids consuming computing resources while ensuring complete resource release; thread anomalies can lead to serious problems. Terminating the process immediately stops all operations, preventing errors from escalating and reducing server-side losses. Releasing the distributed lock avoids deadlocks, further conserving computing resources. The beneficial effects of this method also include: 1. It is ready to use out of the box, convenient and quick to use, with a low learning curve, requiring no expertise in Redis middleware or other technologies. Users can directly configure the solution through annotations at the interface, allowing them to focus on the business implementation. 2. It provides excellent adaptive lock expiration time. It avoids application crashes, deadlocks, and data inconsistencies caused by early lock releases. A watchdog mechanism is used to renew locks, and different renewal strategies are selected based on different business loads, optimizing the performance consumption of distributed locks. 3. Through the AOP (Aspect-Oriented Programming) principles of the Java Spring framework, business methods requiring distributed locks are enhanced, introducing distributed locks into the program in a non-intrusive manner. Developers only need to configure custom annotations to easily use distributed locks, without needing to worry about locking, releasing locks, exception handling, or the atomicity of Redis operations. 4. Users don't need to worry about lock expiration times; locks are automatically renewed, and users no longer need to set expiration times. When a thread acquires a lock, this mechanism starts a daemon thread to monitor whether the thread's task is complete. Specifically, it checks whether the lock has been released within a set time interval using a polling method. If the lock has not been released, it means the business still exists. The expiration time of the lock is then extended using Redis commands until it is detected that the lock has been released, at which point no further extension is made. 5. An innovative lock renewal strategy is implemented, building upon point 4, with a time polling interval for lock renewal. The time renewal strategy for distributed locks is optimized. Request frequency is statistically analyzed at the aspect level. If it is determined to be a peak business period, a peak period strategy is used with a very short polling interval. If it is determined to be an off-peak business period, an off-peak period strategy is used with a relatively longer polling interval. The time interval is adaptively set according to different business loads to save resources.

[0152] Figure 5 This is a schematic diagram of a control device for a distributed lock provided in an embodiment of this application. Figure 5 As shown, the control device 500 of the distributed lock includes: an acquisition module 501, a thread filtering module 502, a thread starting module 503, a processing module 504, and a release module 505.

[0153] The acquisition module 501 is used to acquire the business load information of multiple business threads and the server for the target resource business, including the business load rate of the server. The thread filtering module 502 is used to filter the target threads that have successfully occupied the business resources in the target resource business from among the business threads. The thread startup module 503 is used to add a distributed lock to the target thread and start a monitoring thread configured for the distributed lock; the distributed lock is used to prevent business threads other than the target thread from processing business resources; The processing module 504 is used to poll the completion status of the target thread according to the polling interval of the monitoring thread. If the target thread has not completed the processing of business resources, the validity period of the distributed lock is extended. The extension time of the validity period of the distributed lock is positively correlated with the business load rate, and the polling interval is positively correlated with the business load rate. The polling interval is less than or equal to the extension time. Release module 505 is used to release the distributed lock of the target thread and terminate the monitoring thread after the target thread has completed the processing of business resources.

[0154] In other embodiments, the acquisition module 501 is further configured to, in response to the configuration operation of the object for the target resource business, acquire annotation parameters for the target resource business; acquire multiple basic threads for the target resource business; write the annotation parameter values ​​of the annotation parameters into each basic thread respectively to obtain the business thread corresponding to each basic thread, wherein each business thread includes annotation parameter values ​​and processing methods for each of the multiple basic resources in the target resource business; the thread filtering module 502 is further configured to, among the basic resources, filter business resources that match the annotation parameter values; and among the business threads, filter the target thread that has successfully occupied the business resource.

[0155] In other embodiments, the acquisition module 501 is further configured to acquire the interface call frequency of the target resource service, the hardware utilization rate of the server, the interface call weight configured for the interface call frequency, and the hardware utilization weight configured for the hardware utilization rate; and determine the service load rate based on the product of the interface call frequency and the interface call weight, and the product of the hardware utilization rate and the hardware utilization weight.

[0156] In other embodiments, the business load situation further includes: business load type; the polling interval includes a first interval, a second interval, and a third interval, wherein the first interval is longer than the second interval, and the second interval is longer than the third interval; the processing module 504 is further used to determine the business load type of the server; when the business load type is high load, the completion status of the target thread is polled according to the first interval of the monitoring thread, and the validity period of the distributed lock is extended if the target thread has not completed the business resource processing; when the business load type is medium load, the completion status of the target thread is polled according to the second interval of the monitoring thread, and the validity period of the distributed lock is extended if the target thread has not completed the business resource processing; when the business load type is low load, the completion status of the target thread is polled according to the third interval of the monitoring thread, and the validity period of the distributed lock is extended if the target thread has not completed the business resource processing, wherein the business load rate corresponding to the high load type is greater than the business load rate corresponding to the medium load type, and the business load rate corresponding to the medium load type is greater than the business load rate corresponding to the low load type.

[0157] In other embodiments, the processing module 504 is further configured to obtain the business load rate threshold corresponding to the business load type being high load type; when the business load type is high load type, update the first interval duration of the monitoring thread according to the difference between the business load rate and the business load rate threshold to obtain the update interval duration; and extend the validity period of the distributed lock according to the update interval duration.

[0158] In other embodiments, the control device of the distributed lock described above may further include an exception release module, which is used to monitor the target thread based on the monitoring thread to obtain the status information of the target thread; if the status information includes exception status information, the distributed lock of the target thread is released and the monitoring thread is terminated.

[0159] The control device for the distributed lock provided in this application embodiment can execute the method shown in the above method embodiment. Its implementation principle and beneficial effects can be referred to the relevant description in the method embodiment, and will not be repeated here.

[0160] Figure 6 This is a schematic diagram of the structure of a distributed lock control device provided in an embodiment of this application. Figure 6 As shown, the control device of the distributed lock includes: a memory 601, a transceiver 602, and at least one processor 603.

[0161] The transceiver 602 is used to interact with other devices to send and receive data. For example, in this embodiment, the transceiver 602 can specifically be used to send and receive data such as service load rate, polling interval duration, and the validity period of the distributed lock.

[0162] The memory 601 stores computer program code, which includes computer instructions. These computer instructions run in the control device of the distributed lock described above to implement the method shown in the above method embodiments. For example, the memory may include high-speed random access memory (RAM), and may also include non-volatile memory (NVM), such as at least one disk storage device, or a USB flash drive, external hard drive, read-only memory, disk, or optical disc, etc.

[0163] Processor 603 can be a general-purpose processor, including a Central Processing Unit (CPU), a network processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Processor 603 can also be other general-purpose processors. The general-purpose processor can be a microprocessor or any conventional processor.

[0164] The memory 601, transceiver 602, and processor 603 are communicatively connected. For example, the memory 601 and transceiver 602 can be connected to the processor 603 via a system bus and communicate with each other. The system bus can be a peripheral component interconnect (PCI) bus, an extended industry standard architecture (EISA) bus, an industry standard architecture (ISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the figure, but this does not mean that there is only one bus or one type of bus.

[0165] Optionally, the memory 601 can be either standalone or integrated with the processor 603. When the memory 601 is set up independently, it is connected to the processor 603 via a system bus.

[0166] This application also provides a chip for executing instructions, which is used to execute the technical solution of the distributed lock control method in the above embodiments.

[0167] This application also provides a computer-readable storage medium storing computer instructions. When these computer instructions are executed by a processor, they are used to implement the technical solution of the distributed lock control method described in the above embodiments. Specifically, when the computer instructions are executed by a processor, the control device of the distributed lock can execute the technical solution of the distributed lock control method described in the above embodiments.

[0168] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium, and when the at least one processor executes the computer program, it can implement the technical solution of the distributed lock control method in the above embodiments.

[0169] The aforementioned computer-readable storage media can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The computer-readable storage media can be any available medium accessible to a general-purpose or special-purpose computer.

[0170] An exemplary computer-readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the computer-readable storage medium can also be a component of the processor. The processor and the computer-readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the computer-readable storage medium can exist as discrete components in an electronic control unit or main control device; this application does not limit this.

[0171] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0172] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to implement the solution of this embodiment according to actual needs.

[0173] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.

[0174] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0175] It should be understood that the steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.

[0176] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0177] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A control method for a distributed lock, characterized in that, The method includes: Obtain the business load information of multiple business threads and the server for the target resource business, including the business load rate of the server; Among the various business threads, select the target thread that has successfully occupied the business resources in the target resource business; A distributed lock is added to the target thread, and a monitoring thread configured for the distributed lock is started; the distributed lock is used to prevent business threads other than the target thread from processing the business resources; The monitoring thread polls the target thread's completion status according to the polling interval. If the target thread fails to complete the processing of the business resources, the validity period of the distributed lock is extended. The extension period of the distributed lock is positively correlated with the business load rate, and the polling interval is positively correlated with the business load rate. The polling interval is less than or equal to the extension period. Once the target thread completes the processing of the business resources, the distributed lock of the target thread is released and the monitoring thread is terminated based on the extended validity period.

2. The method according to claim 1, characterized in that, The acquisition of multiple business threads for the target resource business includes: In response to the configuration operation of the object for the target resource service, obtain the annotation parameters for the target resource service; Obtain multiple basic threads for the target resource service; The annotation parameter values ​​of the annotation parameters are written into each of the basic threads to obtain the business threads corresponding to each of the basic threads. Each business thread includes the annotation parameter value and a processing method for each of the multiple basic resources in the target resource business. The step of selecting the target thread that has successfully occupied the business resources in the target resource business from among the various business threads includes: Among the basic resources, select business resources that match the annotation parameter values; Among the various business threads, select the target thread that has successfully occupied the business resources.

3. The method according to claim 1, characterized in that, The process of obtaining the server's business load includes: Obtain the interface call frequency of the target resource service, the hardware utilization rate of the server, the interface call weight configured for the interface call frequency, and the hardware utilization weight configured for the hardware utilization rate; The service load rate is determined based on the product of the interface call frequency and the interface call weight, and the product of the hardware utilization rate and the hardware utilization weight.

4. The method according to claim 1, characterized in that, The service load information also includes: service load type; the polling interval includes a first interval, a second interval, and a third interval, wherein the first interval is longer than the second interval, and the second interval is longer than the third interval. The step of polling the target thread according to the polling interval of the monitoring thread, and extending the validity period of the distributed lock if the target thread has not completed the processing of the business resources, includes: Determine the service load type of the server; When the business load type is high load, the completion status of the target thread is polled according to the first interval of the monitoring thread. If the target thread has not completed the processing of the business resources, the validity period of the distributed lock is extended. When the business load type is medium load, the completion status of the target thread is polled according to the second interval of the monitoring thread. If the target thread has not completed the processing of the business resources, the validity period of the distributed lock is extended. When the business load type is low load, the completion status of the target thread is polled according to the third interval of the monitoring thread. If the target thread has not completed the business resource processing, the validity period of the distributed lock is extended. The business load rate corresponding to the high load type is greater than the business load rate corresponding to the medium load type, and the business load rate corresponding to the medium load type is greater than the business load rate corresponding to the low load type.

5. The method according to claim 4, characterized in that, When the business load type is high load, the validity period of the distributed lock is extended according to the first interval of the monitoring thread, including: Obtain the service load rate threshold corresponding to the service load type being high load type; When the service load type is high load type, the first interval duration of the monitoring thread is updated according to the difference between the service load rate and the service load rate threshold to obtain the update interval duration; The validity period of the distributed lock is extended according to the update interval.

6. The method according to claim 1, characterized in that, The method further includes: The target thread is monitored based on the monitoring thread to obtain the status information of the target thread; If the status information includes abnormal status information, release the distributed lock of the target thread and terminate the monitoring thread.

7. A control device for a distributed lock, characterized in that, include: The acquisition module is used to acquire the business load information of multiple business threads and the server for the target resource business, wherein the business load information includes the business load rate of the server. The thread filtering module is used to filter the target threads that have successfully occupied the business resources in the target resource business from among the business threads. The thread startup module is used to add a distributed lock to the target thread and start a monitoring thread configured for the distributed lock; the distributed lock is used to prevent business threads other than the target thread from processing the business resources; The processing module is used to poll the completion status of the target thread according to the polling interval of the monitoring thread. If the target thread has not completed the processing of the business resources, the validity period of the distributed lock is extended. The extension time of the validity period of the distributed lock is positively correlated with the business load rate, the polling interval is positively correlated with the business load rate, and the polling interval is less than or equal to the extension time. The release module is used to release the distributed lock of the target thread and terminate the monitoring thread based on the extended validity period when the target thread completes the processing of the business resources.

8. A control device for a distributed lock, characterized in that, include: A memory and at least one processor; the memory is communicatively connected to the processor; the memory is used to store computer program code, the computer program code including computer instructions; when the processor executes the computer instructions, it causes the control device of the distributed lock to perform the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, When the computer program product is run on a computer / executed by the computer's processor, it implements the method as described in any one of claims 1-6.

Images