CN116737399A - Distributed lock implementation method, device, computer equipment and storage medium - Google Patents
Distributed lock implementation method, device, computer equipment and storage medium Download PDFInfo
- Publication number
- CN116737399A CN116737399A CN202310851437.5A CN202310851437A CN116737399A CN 116737399 A CN116737399 A CN 116737399A CN 202310851437 A CN202310851437 A CN 202310851437A CN 116737399 A CN116737399 A CN 116737399A
- Authority
- CN
- China
- Prior art keywords
- distributed lock
- locking
- service
- annotation
- determining
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 66
- 238000012545 processing Methods 0.000 claims abstract description 43
- 230000008569 process Effects 0.000 claims description 8
- 238000013515 script Methods 0.000 claims description 6
- 230000009545 invasion Effects 0.000 abstract description 4
- 238000004590 computer program Methods 0.000 description 13
- 230000007717 exclusion Effects 0.000 description 6
- 230000006870 function Effects 0.000 description 6
- 238000010586 diagram Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000014509 gene expression Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 230000006835 compression Effects 0.000 description 2
- 238000007906 compression Methods 0.000 description 2
- 238000001914 filtration Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 239000012141 concentrate Substances 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 239000007943 implant Substances 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 239000003826 tablet Substances 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
- G06F9/524—Deadlock detection or avoidance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
- G06F21/562—Static detection
- G06F21/563—Static detection by source code analysis
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Virology (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application relates to a distributed lock implementation method, a device, computer equipment and a storage medium, wherein the method comprises the following steps: setting target annotation and defining locking parameters of the distributed lock; determining a service code to be locked, and adding a target annotation in the service code; performing addition distributed lock processing on the service codes according to the target annotation; executing service codes when the distributed lock addition result is successful; and when the distributed lock addition result is failure, determining the reason of the failure of the distributed lock addition. The method provides a simpler distributed lock configuration mode, simplifies a large number of codes, only adds notes on the method, and has no invasion to service codes.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a method and apparatus for implementing a distributed lock, a computer device, and a storage medium.
Background
With the development of services, the request traffic increases, and most of the current applications are cluster deployment. In a distributed system, if one or a group of resources are shared between different systems or different hosts of the same system, when accessing the resources, in order to ensure that operations of the systems can be performed synchronously or mutually exclusively, a distributed lock needs to be used to coordinate operations associated with the systems.
A problem with this is that the stand-alone jvm locking approach has not been able to meet the needs for multi-threaded concurrent requests. There is a need for a distributed lock implementation, most of which are implemented using Redis, zookeeper locks, etc., to perform the locking/unlocking logic at the beginning and end of a code block, which has the following disadvantages and problems.
Intrusion into the service code, strong coupling with the code, and difficult modification.
The locking implementation is single, and multiple sets of codes may be written.
Flexible configuration and adjustment are not supported.
Disclosure of Invention
The application provides a distributed lock realization method, a distributed lock realization device, computer equipment and a distributed lock medium, which are used for solving the technical problem that a plurality of sets of codes are possibly written when a locking realization mode is single, and further improving the calling efficiency of the distributed lock
In a first aspect, a distributed lock implementation method is provided, including:
setting target annotation and defining locking parameters of the distributed lock;
determining a business code to be locked, and adding the target annotation in the business code;
performing distributed lock adding processing on the service codes according to the target annotation;
executing the service code when the distributed lock addition result is successful;
and when the distributed lock addition result is failure, determining the reason of the failure of the distributed lock addition.
In one embodiment, the setting the target annotation defines a locking parameter of the distributed lock, including:
the locking parameters include a locking primary key, a specified prefix, an expiration time, a wait time, a lock type, and a locking mode of the distributed lock.
In one embodiment, the determining the service code to be locked according to a preset rule, adding the target annotation in the service code, includes:
and when a plurality of service requests access the service codes to be locked, adding the target annotation in the service codes to be locked, and automatically locking the service codes to be locked through the target annotation.
In one embodiment, the adding a distributed lock to the service code according to the target annotation includes:
executing MVEL script, extracting locking parameters of the distributed lock defined by the target annotation;
calling a corresponding locking thread to execute the locking operation of the service code based on the lock type in the locking parameter;
the locking thread feeds back success or failure of the locking operation.
In one embodiment, each locking parameter in the target annotation comprises a parameter name of the locking parameter and a parameter value corresponding to the parameter name, each parameter name is linked with a parameter value database, and the parameter values are stored in the parameter value database in json format;
the extracting the locking parameters of the distributed lock defined by the target annotation comprises the following steps:
determining a locking main key in the locking parameter according to predefined logic judgment;
it is determined whether there is a change in the parameter values in the parameter value database.
If yes, the json character string in the parameter value database is converted into annotation metadata, and the corresponding parameter value in the target annotation is covered by the annotation metadata.
In one embodiment, the determining a cause of the distributed lock addition failure includes:
determining a service request to be executed by the service code, and respectively setting target indexes for each service to be processed according to the service identifier of each service to be processed;
and according to the service request, inquiring whether service data corresponding to the service identifier is included in a data server through a target index corresponding to the service identifier, and determining the reason of the failure of adding the distributed lock.
In one embodiment, after the executing the service code, the method further includes:
acquiring execution information of the service codes, wherein the execution information comprises a processing progress and a processing time length;
if the processing progress indicates that the locking processing for the service codes is completed, determining that an unlocking condition is met;
or if the processing time length is longer than the preset locking timeout length, determining that the unlocking condition is met, wherein the preset locking timeout length is obtained by extracting locking parameters contained in the annotation.
In a second aspect, a distributed lock implementation apparatus is provided, including:
the annotation setting unit is used for setting target annotations and defining locking parameters of the distributed lock;
an annotation adding unit, configured to determine a service code to be locked, and add the target annotation to the service code;
the method locking unit is used for carrying out addition distributed locking processing on the service codes according to the target annotation;
the first processing unit is used for executing the service code when the distributed lock addition result is successful;
and the second processing unit is used for determining the reason of the failure of the addition of the distributed lock when the result of the addition of the distributed lock is failure.
In a third aspect, a computer device is provided, comprising a memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the steps of the above-described distributed lock implementation method when the computer program is executed.
In a fourth aspect, a computer readable storage medium is provided, the computer readable storage medium storing a computer program which, when executed by a processor, implements the steps of the distributed lock implementation method described above.
In the scheme realized by the method, the device, the computer equipment and the storage medium for realizing the distributed lock, the locking parameters of the distributed lock can be defined by setting target notes; determining a business code to be locked, and adding the target annotation in the business code; performing distributed lock adding processing on the service codes according to the target annotation; executing the service code when the distributed lock addition result is successful; when the distributed lock addition result is failure, determining the reason of the failure of the distributed lock addition, in the application, by setting a target annotation, defining the parameter information of the distributed lock, the distributed lock can be realized by only adding the annotation on a method, a simpler distributed lock configuration mode is provided, a large number of codes are simplified, and no invasion to service codes is caused. Redis, zookeeper and other implementations are provided, repetition coding is reduced, and expansion can be realized automatically. The service code is focused more without paying attention to the implementation of the lock. The designated key value can be dynamically obtained from the input parameters, and the related parameters support flexible configuration.
Drawings
FIG. 1 is a schematic diagram of an application environment of an intelligent distributed lock implementation method according to an embodiment of the present application;
FIG. 2 is a flow chart of an implementation method of the intelligent distributed lock according to an embodiment of the present application;
FIG. 3 is a flowchart illustrating step S23 in FIG. 2;
FIG. 4 is a flowchart illustrating the step S231 of FIG. 3;
FIG. 5 is a flowchart illustrating a step S23 in FIG. 2;
FIG. 6 is a schematic diagram of a distributed intelligent lock implementation device according to an embodiment of the present application;
FIG. 7 is a schematic diagram of a computer device according to an embodiment of the application;
fig. 8 is a schematic diagram of another configuration of a computer device according to an embodiment of the present application.
Detailed Description
The present application will be described in further detail with reference to the drawings and examples, in order to make the objects, technical solutions and advantages of the present application more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application.
FIG. 1 illustrates an exemplary system architecture 100 in which embodiments of a distributed lock implementation method or distributed lock implementation apparatus of the present application may be applied.
As shown in fig. 1, a system architecture 100 may include terminal devices 101, 102, 103, a network 104, and a server 105.
The network 104 is used as a medium to provide communication links between the terminal devices 101, 102, 103 and the server 105. The network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.
The user may interact with the server 105 via the network 104 using the terminal devices 101, 102, 103 to receive or send messages or the like. Various client applications, such as a distributed resource request class application, a web browser application, a shopping class application, a search class application, an instant messaging tool, a mailbox client, social platform software, etc., may be installed on the terminal devices 101, 102, 103.
The terminal devices 101, 102, 103 may be various electronic devices with processors including, but not limited to, smartphones, tablet computers, e-book readers, MP3 players (Moving Picture Experts Group Audio Layer III, moving picture experts compression standard audio layer 3), MP4 (Moving Picture Experts Group Audio Layer IV, moving picture experts compression standard audio layer 4) players, laptop and desktop computers, and the like.
The server 105 may be a server providing various services, such as a distributed lock control server providing support for distributed resource request class applications installed on the terminal devices 101, 102, 103. The distributed lock control server may analyze and process the received data such as the locking request and the unlocking request sent by the terminal device, and feed back the processing result (for example, the locking success message and the unlocking success message) to the terminal device.
It should be noted that, the control method of the distributed lock provided in the embodiment of the present application is generally executed by the server 105, and accordingly, the control device of the distributed lock is generally disposed in the server 105.
It should be understood that the number of terminal devices, networks and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.
Referring to fig. 2, fig. 2 is a schematic flow chart of a distributed lock implementation method according to an embodiment of the present application, including the following steps:
s21, setting target annotation and defining locking parameters of the distributed lock.
It will be appreciated that Annotation, also called meta-data, refers to data used to describe data, often in the form of tags, primarily to describe the links between blocks of code. It is a code-level specification at the same level as classes, interfaces, enumerations, which may be declared in front of packages, classes, fields, methods, local variables, method parameters, etc. for the specification and annotation of these elements. In short, the annotation is a tag, and can be understood as a special annotation, which can be inserted into the source code, and does not play any role, and does not change the execution sequence of the instructions, so that the server is required to read the annotation content in the source code and then realize certain operation. It should be appreciated that the annotations are simply metadata, independent of the business code. Therefore, in this embodiment, an annotation can be customized, marked on the service code to be locked, and another non-service code that does not invade the service code is dynamically cut in front of the service code, so as to solve the problem that the same service is parallel processed due to repeated service request submission, and the exception of service data is caused, that is, the same service is prevented from being parallel processed in the other non-service code that does not invade the service code.
In this embodiment, before the server receives the service request through its interface, the service code (method) needs to be labeled with the custom target annotation in advance. For example, define annotation @ DLM of the distributed lock, add the annotation to the method that needs to be locked, the code of the annotation @ DLM is as follows:
specifically, referring to table one, when setting custom notes, the locking parameters may include a locking primary KEY of the distributed lock, a specified prefix, an expiration time, a waiting time, a lock type, a locking mode, and the like, where the extraction of the KEY value of the locking primary KEY is generally not a fixed value, but a KEY needs to be obtained from an entry, such as an order number, a user id, and the like. MVEL scripts support dynamic acquisition of parameters and make simple logic decisions. For example: the entry is user information: { "userId": "3324234", "cid": "4223443" }, requiring locking for user id, configuration annotation @ DLM (key= "userId"). In addition, the script also supports logical processing, requiring the value of cid to be taken, provided that userId may be empty. Then it can be configured as @ DLM (key= "userid= =nullcid: userId").
List one
S22, determining a service code to be locked, and adding a target annotation in the service code.
It can be understood that, specifically, when a method to be locked is accessed by having multiple service requests at the same time, a target annotation can be added in the method, and automatic locking is realized in the method to be locked through the target annotation, so that a large number of repeated codes are prevented from being written, and the working efficiency is improved. After the method is performed, the lock is released and the next process is continued.
In some application scenarios, for a thread of distributed execution, each thread is processed in a locked manner, for example, the train ticket on the "chinese railway 12306" cannot be sold more, and a ticket is not allowed to be purchased by a plurality of people; such a scenario, where one order is not allowed to pay 2 times, etc., requires a distributed lock to protect the shared resource. In order to realize that a plurality of threads can only execute one thread at one moment in the same code block, a mark needs to be made somewhere, each thread needs to see the mark, the mark can be set when the mark does not exist, the rest of subsequent threads find that the mark exists, the thread waiting for the mark ends the synchronous code block to cancel the mark and then try to set the mark, the effect of the lock is equivalent to the mark, once one thread acquires the lock, the thread is in an executed state, and after the task execution is completed, the lock needs to be released, and other processes are executed because the lock is obtained.
In this embodiment, when the server receives a service request through its interface, the service code (method) is dynamically switched into the distributed locking logic.
The application is realized based on the tangent plane facing programming (Aspect Oriented Program), which is a specified method for dynamically cutting codes into classes when a program runs, AOP is a normal form and an idea, and is not a specified programming language, the programming idea for dynamically cutting codes into the classes and the specified position is one of responsibilities of the tangent plane facing programming, separating functional codes and non-functional code technology AOP, the AOP technology can implant tangent plane codes into tangent points, cut non-functional codes around the functional codes, and the specified operation is completed under the condition of not invading service codes. It can highly decouple the business code from the non-business code so that the developer can only concentrate on the business code during development. In the present application, since different programs are executed, for example, purchasing, paying, determining, submitting, praying, collecting, etc., scenes, they all need to filter the repeated click event. Therefore, based on the section-oriented programming, the non-service code, namely the filtering repeated clicking event code, is isolated from each service code, and when the program runs, the common filtering repeated clicking event code is cut into the service code for execution, so that the intrusion of the service code is avoided, the reusability is improved, the development efficiency is improved, and the maintainability is improved.
S23, adding distributed lock processing to the service codes according to the target annotation.
It can be appreciated that after the target distributed lock is determined, the service code may be locked based on the target distributed lock to obtain a target locking task. In a specific implementation, the target distributed lock includes at least one target code module, each target code module is used for realizing a corresponding function in the distributed lock, and after the target distributed lock is determined, a locking module in the at least one code module is called to lock a task to obtain a target locking task.
In some embodiments, the step S23 may include:
s231, executing the MVEL script, and extracting locking parameters of the distributed lock defined by the target annotation.
It is understood that MVEL is an abbreviation for mvflexexpression language, which is a dynamic/static embeddable expression language and a language that provides run time for Java platforms. Initially, the project has evolved completely independently, starting in the language as an application framework utility. MVELs are typically used to execute basic logic defined by a user (programmer) through configuration XML files or notes, etc. It can also be used to parse simple Java Bean expressions. Run time allows MVEL expressions to be executed after generating bytecodes by interpretation execution or pre-compilation.
In some embodiments, each locking parameter in the target annotation includes a parameter name of the locking parameter and a parameter value corresponding to the parameter name, each parameter name being linked to a parameter value database, the parameter values being stored in json format in the parameter value database;
the step S231 may include:
s2311, determining a locking main key in the locking parameter according to predefined logic judgment;
s2312, determining whether the parameter values in the parameter value database are changed or not;
s2313, if yes, converting the json character string in the parameter value database into annotation metadata, and covering the corresponding parameter value in the target annotation with the annotation metadata.
In this embodiment, the specific content of the parameter value (value) corresponding to the parameter name is stored in the database, and the value is modified in the database. When the method is executed, the configuration data is queried, if the configuration exists, the json object is converted into annotation metadata, and the related fields cover the corresponding parameter values in the DML annotation. The method can realize real-time dynamic adjustment of parameters.
S232, calling a corresponding locking thread to execute locking operation of the service code based on the lock type in the locking parameter;
the implementation of the distributed lock is defined through annotation, and an interface is defined, namely the interface can be traversed to the expansion. The Distributed Lock of the interface is defined, and Distributed Lock implementation based on Redis and ZooKeeper is built in. Through the spi service discovery mechanism, the user can also realize expansion by himself and specify the type in the annotation. In the running process of the method, user expansion is traversed, and realization is obtained according to the designated lock type. The plug-in expands a part of functions of the plug-in, and the plug-in scans all the implementation modes.
S233, the locking thread feeds back success or failure of the locking operation.
Extracting a primary key value from a service request according to a target annotation, and executing a locking thread to obtain a value fed back by the locking thread;
if the value fed back by the locking thread is the first numerical value, the locking result is successful locking;
if the value fed back by the locking thread is the second value, the locking result is locking failure.
Specifically, when executing the locking thread, the locking thread may feed back a corresponding value as a locking result. For example, the first value may be 1, the locking result may be successful locking, the second value may be 0, and the locking result may be failed locking.
In one application scenario, the service code may be a ticket buying service having a unique user identification (user cell phone number). In order to avoid the situation of buying tickets for multiple times, after obtaining a ticket buying request generated by triggering a preset ticket buying icon on a display interface by a user, a distributed lock can be set for the ticket buying request through a preset thread according to the user identification, and a locking result is obtained. If the value fed back by the thread is 1, that is, the locking result is that the locking is successful, the ticket buying request is characterized as being unprocessed, and the ticket buying request can be processed. Otherwise, if the value fed back by the thread is 0, that is, the locking result is that the locking fails, the ticket buying request is indicated to be processed, and in order to avoid repeated ticket buying, the ticket buying request can be ignored.
S24, executing service codes when the distributed lock addition result is successful;
s25, when the distributed lock addition result is failure, determining the reason of the failure of the distributed lock addition.
When a service request is received, the server runs the distributed locking logic of the non-intrusive service code before running the service code, so as to judge whether the corresponding service is executed before executing the service corresponding to the received service request. When determining that the mutual exclusion operation exists in the current business operation, the server can judge whether the mutual exclusion operation corresponding to the business operation is locked or not. If the mutual exclusion operation corresponding to the current business operation is locked, which means that the mutual exclusion operation is being executed, and the user cannot execute the current business operation, the user needs to exit waiting until the execution of the mutual exclusion operation is completed. If the mutual exclusion operation corresponding to the current business operation is not locked, the server allows the user to continue to execute the subsequent operation.
In some embodiments, the step S25 may include:
s251, determining a service request to be executed by a service code, and respectively setting target indexes for each service to be processed according to service identifiers of each service to be processed;
s252, according to the service request, whether service data corresponding to the service identifier are included or not is inquired in the data server through the target index corresponding to the service identifier, and the reason of the failure of adding the distributed lock is determined.
It should be noted that, the case that the distributed lock is already occupied may be a case that the distributed lock is already used by another thread and the service operation protected by the distributed lock is being executed, or may be a case that after the distributed lock is occupied by another thread, due to a failure such as a network flash, a program abort, or the like, an expiration time is not successfully set for the distributed lock and the service operation protected by the distributed lock is not executed.
In some application scenarios, when locking, a key (identification of a distributed lock) is Set through a SETNX (Set if Not present) command of redis, if the key is Set successfully, the distributed lock corresponding to the key is Not occupied, and if the key is Set failed, the distributed lock corresponding to the key is occupied.
In some embodiments, S25 may be followed by:
s26, acquiring execution information of service codes, wherein the execution information comprises a processing progress and a processing time length;
s27, if the processing progress indicates that the locking processing for the service codes is completed, determining that an unlocking condition is met;
or S28, if the processing time length is longer than the preset locking timeout length, determining that the unlocking condition is met, wherein the preset locking timeout length is obtained by extracting locking parameters contained in the annotation.
In this embodiment, when it is detected that the unlocking condition is satisfied, the corresponding unlocking logic is operated to perform unlocking processing, and the target thread is released.
Therefore, in the scheme, a simpler distributed lock configuration mode is provided, a large number of codes are simplified, only the notes are added on the method, and no invasion is caused to the service codes. Redis, zookeeper and other implementations are provided, repetition coding is reduced, and expansion can be realized automatically. The service logic is focused more without paying attention to the realization of the lock. The designated key value can be dynamically obtained from the input parameters, and the related parameters support flexible configuration
It should be understood that the sequence number of each step in the foregoing embodiment does not mean that the execution sequence of each process should be determined by the function and the internal logic, and should not limit the implementation process of the embodiment of the present application.
In an embodiment, a distributed lock implementation device is provided, where the distributed lock implementation device corresponds to the distributed lock implementation method in the foregoing embodiment one by one. As shown in fig. 6, the distributed lock implementation apparatus includes an annotation setting unit 61, an annotation adding unit 62, a method locking unit 63, a first processing unit 64, and a second processing unit 65. The functional modules are described in detail as follows:
an annotation setting unit 61 for setting a target annotation, defining a locking parameter of the distributed lock;
an annotation adding unit 62, configured to determine a service code to be locked, and add a target annotation to the service code;
a method locking unit 63, configured to perform an addition distributed locking process on the service code according to the target annotation;
a first processing unit 64, configured to execute the service code when the distributed lock addition result is successful;
the second processing unit 65 is configured to determine a cause of the failure of the addition of the distributed lock when the result of the addition of the distributed lock is failure.
In an embodiment, the annotation setting unit 61 is specifically configured to:
the locking parameters include the locking primary key, specified prefix, expiration time, latency, lock type, and locking mode of the distributed lock.
In one embodiment, the annotation adding unit 62 is specifically configured to:
when a plurality of service requests access the service codes to be locked, adding target notes in the service codes to be locked, and automatically locking the service codes to be locked through the target notes.
In one embodiment, the method locking unit 63 is specifically configured to:
executing the MVEL script, and extracting locking parameters of the distributed lock defined by the target annotation;
calling a corresponding locking thread to execute locking operation of the service code based on the lock type in the locking parameter;
the locking thread feeds back success or failure of the locking operation.
In one embodiment, each locking parameter in the target annotation comprises a parameter name of the locking parameter and a parameter value corresponding to the parameter name, each parameter name is linked with a parameter value database, and the parameter values are stored in the parameter value database in json format;
the method locking unit 63 is further configured to:
determining a locking main key in the locking parameter according to predefined logic judgment;
it is determined whether there is a change in the parameter values in the parameter value database.
If so, the json character string in the parameter value database is converted into annotation metadata, and the corresponding parameter value in the target annotation is covered by the annotation metadata.
In one embodiment, the first processing unit 64 is specifically configured to:
acquiring execution information of service codes, wherein the execution information comprises a processing progress and a processing time length;
if the processing progress indicates that the locking processing is completed for the service code, determining that an unlocking condition is met;
or if the processing time length is longer than the preset locking timeout length, determining that the unlocking condition is met, wherein the preset locking timeout length is obtained by extracting locking parameters contained in the annotation.
In one embodiment, the second processing unit 65 is specifically configured to:
determining a service request to be executed by a service code, and respectively setting a target index for each service to be processed according to the service identifier of each service to be processed;
and according to the service request, inquiring whether the service data corresponding to the service identifier is included in the data server through the target index corresponding to the service identifier, and determining the reason of the failure of adding the distributed lock.
The application provides a distributed lock realizing device, firstly setting target annotation, defining locking parameters of a distributed lock, then determining a service code to be locked, adding a scheme of the target annotation in the service code, and carrying out distributed lock adding processing on the service code according to the target annotation; executing service codes when the distributed lock addition result is successful; and when the distributed lock addition result is failure, determining the reason of the failure of the distributed lock addition. The method provides a simpler distributed lock configuration mode, simplifies a large number of codes, only adds notes on the method, and has no invasion to service codes.
For specific limitations on the distributed lock implementation means, reference may be made to the above limitation on the intelligent question-answering method, and no further description is given here. The various modules in the distributed lock implementation described above may be implemented in whole or in part in software, hardware, and combinations thereof. The above modules may be embedded in hardware or may be independent of a processor in the computer device, or may be stored in software in a memory in the computer device, so that the processor may call and execute operations corresponding to the above modules.
In one embodiment, a computer device is provided, which may be a server, and the internal structure of which may be as shown in fig. 7. The computer device includes a processor, a memory, a network interface, and a database connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes non-volatile and/or volatile storage media and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface of the computer device is for communicating with an external client via a network connection. The computer program, when executed by a processor, performs functions or steps of a distributed lock implementation method service side.
In one embodiment, a computer device is provided, which may be a client, the internal structure of which may be as shown in fig. 8. The computer device includes a processor, a memory, a network interface, a display screen, and an input device connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface of the computer device is for communicating with an external server via a network connection. The computer program, when executed by a processor, performs a function or steps on a client side of a distributed lock implementation method
In one embodiment, a computer device is provided comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, the processor implementing the steps of when executing the computer program:
setting target annotation and defining locking parameters of the distributed lock;
determining a service code to be locked, and adding a target annotation in the service code;
performing addition distributed lock processing on the service codes according to the target annotation;
executing service codes when the distributed lock addition result is successful;
and when the distributed lock addition result is failure, determining the reason of the failure of the distributed lock addition.
In one embodiment, a computer readable storage medium is provided having a computer program stored thereon, which when executed by a processor, performs the steps of:
setting target annotation and defining locking parameters of the distributed lock;
determining a service code to be locked, and adding a target annotation in the service code;
performing addition distributed lock processing on the service codes according to the target annotation;
executing service codes when the distributed lock addition result is successful;
and when the distributed lock addition result is failure, determining the reason of the failure of the distributed lock addition.
It should be noted that, the functions or steps implemented by the computer readable storage medium or the computer device may correspond to the relevant descriptions on the server side and the client side in the foregoing method embodiments, and are not described herein for avoiding repetition.
Those skilled in the art will appreciate that implementing all or part of the above-described methods in accordance with the embodiments may be accomplished by way of a computer program stored in a computer-readable storage medium, which when executed, may comprise the steps of the embodiments of the methods described above. The storage medium may be a nonvolatile storage medium such as a magnetic disk, an optical disk, a Read-only memory (ROM), or a random access memory (RandomAccessMemory, RAM).
The technical features of the above-described embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above-described embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.
The foregoing examples illustrate only a few embodiments of the application and are described in detail herein without thereby limiting the scope of the application. It should be noted that it will be apparent to those skilled in the art that several variations and modifications can be made without departing from the spirit of the application, which are all within the scope of the application. Accordingly, the scope of protection of the present application is to be determined by the appended claims.
Claims (10)
1. A method for implementing a distributed lock, comprising:
setting target annotation and defining locking parameters of the distributed lock;
determining a business code to be locked, and adding the target annotation in the business code;
performing distributed lock adding processing on the service codes according to the target annotation;
executing the service code when the distributed lock addition result is successful;
and when the distributed lock addition result is failure, determining the reason of the failure of the distributed lock addition.
2. The method for implementing the distributed lock according to claim 1, wherein the setting the target annotation defines a locking parameter of the distributed lock, and the method comprises:
the locking parameters include a locking primary key, a specified prefix, an expiration time, a wait time, a lock type, and a locking mode of the distributed lock.
3. The method for implementing the distributed lock according to claim 1, wherein the determining the service code to be locked according to the preset rule, adding the target annotation in the service code, includes:
and when a plurality of service requests access the service codes to be locked, adding the target annotation in the service codes to be locked, and automatically locking the service codes to be locked through the target annotation.
4. The distributed lock implementation method according to claim 1, wherein the adding a distributed lock process to the service code according to the target annotation includes:
executing MVEL script, extracting locking parameters of the distributed lock defined by the target annotation;
calling a corresponding locking thread to execute the locking operation of the service code based on the lock type in the locking parameter;
the locking thread feeds back success or failure of the locking operation.
5. The distributed lock implementation method of claim 4 wherein each locking parameter in the target annotation comprises a parameter name of the locking parameter and a parameter value corresponding to the parameter name, each parameter name being linked to a parameter value database, the parameter values being stored in json format in the parameter value database;
the extracting the locking parameters of the distributed lock defined by the target annotation comprises the following steps:
determining a locking main key in the locking parameter according to predefined logic judgment;
determining whether a parameter value in the parameter value database has been altered;
if yes, the json character string in the parameter value database is converted into annotation metadata, and the corresponding parameter value in the target annotation is covered by the annotation metadata.
6. The distributed lock implementation method of claim 1, wherein the determining a cause of the distributed lock addition failure comprises:
determining a service request to be executed by the service code, and respectively setting target indexes for each service to be processed according to the service identifier of each service to be processed;
and according to the service request, inquiring whether service data corresponding to the service identifier is included in a data server through a target index corresponding to the service identifier, and determining the reason of the failure of adding the distributed lock.
7. The distributed lock implementation method of claim 1, further comprising, after said executing said business code:
acquiring execution information of the service codes, wherein the execution information comprises a processing progress and a processing time length;
if the processing progress indicates that the locking processing for the service codes is completed, determining that an unlocking condition is met;
or if the processing time length is longer than the preset locking timeout length, determining that the unlocking condition is met, wherein the preset locking timeout length is obtained by extracting locking parameters contained in the annotation.
8. A distributed lock implementation apparatus, comprising:
the annotation setting unit is used for setting target annotations and defining locking parameters of the distributed lock;
an annotation adding unit, configured to determine a service code to be locked, and add the target annotation to the service code;
the method locking unit is used for carrying out addition distributed locking processing on the service codes according to the target annotation;
the first processing unit is used for executing the service code when the distributed lock addition result is successful;
and the second processing unit is used for determining the reason of the failure of the addition of the distributed lock when the result of the addition of the distributed lock is failure.
9. A terminal device, characterized in that the terminal device comprises: a memory, a processor and a distributed lock implementation program stored on the memory and executable on the processor, which when executed by the processor, implements the steps of the distributed lock implementation method of any of claims 1 to 7.
10. A computer storage medium, wherein a distributed lock implementation program is stored on the computer storage medium, which when executed by a processor implements the steps of the method for testing an application program according to any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310851437.5A CN116737399A (en) | 2023-07-12 | 2023-07-12 | Distributed lock implementation method, device, computer equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310851437.5A CN116737399A (en) | 2023-07-12 | 2023-07-12 | Distributed lock implementation method, device, computer equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116737399A true CN116737399A (en) | 2023-09-12 |
Family
ID=87906017
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310851437.5A Pending CN116737399A (en) | 2023-07-12 | 2023-07-12 | Distributed lock implementation method, device, computer equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116737399A (en) |
-
2023
- 2023-07-12 CN CN202310851437.5A patent/CN116737399A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110162344B (en) | Isolation current limiting method and device, computer equipment and readable storage medium | |
| WO2006113107A1 (en) | Configurable functionality chaining | |
| US8239862B2 (en) | Apparatus, method, and computer program product for processing information | |
| CN113326030A (en) | Service request processing method and device | |
| CN113330419A (en) | Equipment application installation method and device | |
| CN116523457A (en) | Workflow processing method, device, equipment and storage medium based on business process | |
| CN112817600A (en) | Program annotation compiling method and corresponding device, equipment and medium | |
| CN108052842B (en) | Signature data storage and verification method and device | |
| CN111158777A (en) | Component calling method and device and computer readable storage medium | |
| CN116737399A (en) | Distributed lock implementation method, device, computer equipment and storage medium | |
| CN116450309A (en) | System service providing method and device, storage medium and electronic equipment | |
| CN115811481A (en) | Interactive service testing method and device, computer equipment and storage medium | |
| CN112130900B (en) | User information management method, system, equipment and medium for BMC | |
| CN111488286B (en) | Method and device for independently developing Android modules | |
| CN114003603A (en) | Data export method, system and storage medium based on big data platform | |
| CN113742235A (en) | Method and device for checking codes | |
| CN111400058A (en) | Method and device for calling message, computer equipment and storage medium | |
| CN113326520B (en) | Method, device, equipment and storage medium for determining main body in access control process | |
| EP3872630B1 (en) | Request processing method and apparatus, electronic device, and computer storage medium | |
| CN113760408B (en) | Hierarchical calling method, hierarchical calling system, hierarchical calling equipment and storage medium | |
| CN113032010B (en) | Command transmission control method, terminal and computer readable storage medium | |
| CN113886428A (en) | Business method based dynamic SQL generation method and device | |
| CN108345507B (en) | Communication method and device between JS module and Java module | |
| CN115408166A (en) | Remote communication method, device, equipment and storage medium | |
| CN114254027A (en) | Data processing method, device, equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |