Locking exception processing method and device, storage medium and computer equipment

Abstract

The application relates to the computer technical field and discloses a locking exception processing method and device, a storage medium and a computer device, the method comprising the following steps: a locking component receives a calling request for a distributed lock tool, wherein the calling request comprises a calling sequence of the distributed lock tool; the distributed lock tool is called according to the calling sequence; if one distributed lock tool calling succeeds, the distributed lock tool calling successfully is used for locking; if all the distributed lock tools call abnormally, the locking is interrupted. After the distributed lock calling appears an exception, each distributed lock tool can be automatically switched, so that the human resources are saved, and the work efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method and apparatus for handling locking exceptions, a storage medium, and a computer device. Background Technology

[0002] Locking refers to acquiring control over a resource. Methods for implementing locking include calling distributed lock tools, and there are many types of distributed lock tools, such as Redis distributed locks, ZooKeeper distributed locks, and database unique index locks.

[0003] Currently, when a certain type of distributed lock tool is called using code, if a locking exception occurs (i.e., the call fails), either one has to manually try several more times or modify the code to call other distributed lock tools. This way of handling locking exceptions wastes a lot of human resources and reduces work efficiency. Summary of the Invention

[0004] In view of this, this application provides a method, apparatus, storage medium, and computer device for handling locking exceptions, which enables automatic switching between various distributed lock tools after an exception occurs when calling a distributed lock, thereby saving manpower and improving work efficiency.

[0005] According to one aspect of this application, a method for handling locking exceptions is provided, the method comprising:

[0006] The locking component receives a call request to a distributed lock tool, wherein the call request includes the order in which the distributed lock tool is called;

[0007] The distributed lock tool is invoked according to the invocation order;

[0008] If one of the distributed lock tools is successfully invoked, then the lock is acquired using the successfully invoked distributed lock tool;

[0009] If all of the aforementioned distributed lock tools fail to execute, the locking process is interrupted.

[0010] Optionally, invoking the distributed lock tool according to the invocation order includes:

[0011] The first-order distributed lock tool is determined according to the calling order, and the first-order distributed lock tool is called.

[0012] Determine whether the first-order distributed lock tool was successfully invoked;

[0013] If the first-order distributed lock tool is successfully invoked, then the first-order distributed lock tool is used to acquire the lock;

[0014] If the first-order distributed lock tool fails to be invoked, the second-order distributed lock tool is determined according to the invocation order, and it is determined whether the second-order distributed lock tool is invoked successfully. The process continues until one of the distributed lock tools is invoked successfully, or until all the distributed lock tools fail to be invoked.

[0015] Optionally, the call request may further include: the number of times each of the distributed lock tools is repeatedly called after a call exception;

[0016] The step of determining whether the first-order distributed lock tool was successfully invoked includes:

[0017] If the first-priority distributed lock tool succeeds once within a number of repeated calls less than or equal to the specified number of calls, then the first-priority distributed lock tool is successfully invoked.

[0018] If the first-order distributed lock tool fails to call within a number of repeated calls less than or equal to the specified number, then the first-order distributed lock tool fails to call.

[0019] According to another aspect of this application, a method for handling locking exceptions is provided, the method comprising:

[0020] Send a distributed lock invocation request to the locking component, so that the locking component invokes the distributed lock tool encapsulated in the locking component according to the invocation request;

[0021] If one of the distributed lock tools is successfully invoked, then the locking success message sent by the locking component is received;

[0022] If all the distributed lock tools encounter an invocation exception, then the interrupted locking information sent by the locking component is received.

[0023] Optionally, before sending the distributed lock invocation request to the locking component, the method further includes:

[0024] The distributed lock tool is encapsulated in the locking component.

[0025] Optionally, the method further includes:

[0026] Identify the new distributed lock tool and update the locking component with the new distributed lock tool;

[0027] Sending the distributed lock invocation request to the locking component includes:

[0028] Send a distributed lock invocation request to the locking component that has been updated with the newly added distributed lock tool.

[0029] According to another aspect of this application, a locking exception handling apparatus is provided, the apparatus comprising:

[0030] A receiving module is used for the locking component to receive a call request for a distributed lock tool, wherein the call request includes the call order of the distributed lock tool;

[0031] The calling module is used to invoke the distributed lock tool according to the invocation order;

[0032] The locking module is used to lock the device if one of the distributed lock tools is successfully invoked.

[0033] An interrupt module is used to interrupt locking if all the aforementioned distributed lock tools fail to execute.

[0034] According to another aspect of this application, a locking exception handling apparatus is provided, the apparatus comprising:

[0035] The sending module is used to send a distributed lock invocation request to the locking component, so that the locking component can invoke the distributed lock tool encapsulated by the locking component according to the invocation request;

[0036] The first receiving module is used to receive the locking success information sent by the locking component if one of the distributed lock tools is successfully invoked.

[0037] The second receiving module is used to receive the interrupted locking information sent by the locking component if all the distributed lock tools encounter an invocation exception.

[0038] According to another aspect of this application, a storage medium is provided that stores a computer program thereon, which, when executed by a processor, implements the above-described method for handling locking exceptions.

[0039] According to another aspect of this application, a computer device is provided, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor executes the program to implement the above-described method for handling locking exceptions.

[0040] Using the above technical solution, this application provides a method, apparatus, storage medium, and computer device for handling locking exceptions. First, the locking component receives a call request for a distributed lock tool, wherein the call request includes the call order of the distributed lock tools; further, the distributed lock tools are called according to the call order; finally, if one distributed lock tool is successfully called, the successfully called distributed lock tool is used to lock; if all distributed lock tools fail to be called, the locking is interrupted.

[0041] The locking component encapsulates a distributed lock tool. Compared to existing technologies that lock via code calls, this application directly sends a call request for the distributed lock tool to the locking component. The call request includes the order of calls for the distributed lock tools. When a locking exception occurs, the locking component calls the encapsulated distributed lock tools in the order of calls, realizing automatic switching between multiple distributed lock tools. This eliminates the need for manual retrying or code modification, reducing the waste of human resources and improving work efficiency.

[0042] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0043] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0044] Figure 1 A flowchart illustrating a method for handling locking exceptions provided in an embodiment of this application is shown.

[0045] Figure 2 A flowchart illustrating another method for handling locking exceptions provided in an embodiment of this application is shown.

[0046] Figure 3 A flowchart illustrating another method for handling locking exceptions provided in an embodiment of this application is shown.

[0047] Figure 4 A schematic diagram of the structure of a locking exception handling device provided in an embodiment of this application is shown;

[0048] Figure 5 A schematic diagram of another locking exception handling device provided in an embodiment of this application is shown;

[0049] Figure 6 A schematic diagram of the structure of another locking exception handling device provided in an embodiment of this application is shown. Detailed Implementation

[0050] The present application will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of the present application can be combined with each other.

[0051] It should be noted that in existing technologies, when a distributed lock tool is invoked via code, if the invocation fails (i.e., the call fails), the process involves manual retrying several times, or modifying the code to use another distributed lock tool. If the call still fails after several manual attempts, or if another distributed lock tool also fails, the process continues manually, or the code is modified again to use yet another distributed lock tool. Using this method results in a significant waste of human resources, code redundancy, and a substantial reduction in efficiency. Furthermore, the invocation failure might be caused by factors such as intermittent network connections.

[0052] Therefore, to address the problem of low efficiency in handling locking exceptions, this embodiment provides a method for handling locking exceptions, such as... Figure 1 As shown, the method includes:

[0053] Step 101: The locking component receives a call request to the distributed lock tool, wherein the call request includes the order of calls to the distributed lock tool.

[0054] When it is necessary to acquire and control a resource, the system invokes the locking method to achieve this. In this embodiment, the system sends a request to the locking component to invoke a distributed lock tool. The locking component encapsulates multiple distributed lock tools for the locking component to invoke. These distributed lock tools include, for example, Redis distributed locks, ZooKeeper distributed locks, and database unique index locks.

[0055] Since multiple distributed lock tools are already encapsulated in the locking component, there is no need to manually write code to call a particular distributed lock tool. If the call fails, the code is modified to call another distributed lock tool. Simply input the call request into the locking component, and the locking component will automatically switch to another distributed lock tool after one of the distributed lock tools fails. Specifically, the call request includes the order in which the distributed lock tools are called. The order is as follows: the first-priority distributed lock tool is called first, and if the first-priority distributed lock tool fails, the second-priority distributed lock tool is called, and so on.

[0056] Step 102: Invoke the distributed lock tool according to the invocation order.

[0057] Step 103: If a distributed lock tool is successfully invoked, then use the successfully invoked distributed lock tool to acquire the lock.

[0058] Step 104: If all distributed lock tools fail to execute, then the locking process is interrupted.

[0059] For steps 102-104 of the embodiment, as one implementation method, for example, the locking component encapsulates three distributed lock tools, and the call request includes: the first priority distributed lock tool is a Redis distributed lock, the second priority distributed lock tool is a ZooKeeper distributed lock, and the third priority distributed lock tool is a database unique index lock.

[0060] First, the Redis distributed lock is invoked. If the Redis distributed lock invocation succeeds, the lock is acquired using the Redis distributed lock. If the Redis distributed lock invocation fails, the ZooKeeper distributed lock is invoked. If the ZooKeeper distributed lock invocation succeeds, the lock is acquired using the ZooKeeper distributed lock. If the ZooKeeper distributed lock invocation fails, the database unique index lock is invoked. If the database unique index lock invocation succeeds, the locking operation is performed using the database unique index lock. If the database unique index lock invocation fails, the locking operation is interrupted.

[0061] In other words, if at least one of the distributed lock tools is successfully invoked, the successfully invoked distributed lock tool will be used to acquire the lock. If all distributed lock tools encounter errors, it means that the error cannot be resolved by invoking different types of distributed lock tools, and the locking process needs to be interrupted, causing the business process to stop.

[0062] Additionally, if one distributed lock tool is successfully invoked, a successful locking message is sent to the locking component. If all distributed lock tools encounter invocation errors, an interrupted locking message is sent to the locking component.

[0063] By applying the technical solution of this embodiment, the locking component first receives a call request for a distributed lock tool, wherein the call request includes the call order of the distributed lock tools; further, the distributed lock tools are called according to the call order; finally, if one distributed lock tool is successfully called, the successfully called distributed lock tool is used to lock; if all distributed lock tools fail to be called, the locking is interrupted.

[0064] The locking component encapsulates a distributed lock tool. Compared to existing technologies that lock via code calls, this application directly sends a call request for the distributed lock tool to the locking component. The call request includes the order of calls for the distributed lock tools. When a locking exception occurs, the locking component calls the encapsulated distributed lock tools in the order of calls, realizing automatic switching between multiple distributed lock tools. This eliminates the need for manual retrying or code modification, reducing the waste of human resources and improving work efficiency.

[0065] Furthermore, as a refinement and extension of the specific implementation of the above embodiments, and to fully illustrate the specific implementation process of this embodiment, another method for handling locking exceptions is provided, such as... Figure 2 As shown, the method includes:

[0066] Step 201: The locking component receives a call request to the distributed lock tool, wherein the call request includes the order of calls to the distributed lock tool.

[0067] The specific implementation method is the same as step 101 in the embodiment, and will not be repeated here.

[0068] Step 202: Determine the first-order distributed lock tool according to the calling order, call the first-order distributed lock tool, and determine whether the call to the first-order distributed lock tool was successful. 。

[0069] Step 203: If the first-order distributed lock tool is successfully invoked, then the first-order distributed lock tool is used to acquire the lock.

[0070] Step 204: If the first-order distributed lock tool call fails, determine the second-order distributed lock tool according to the call order, and determine whether the second-order distributed lock tool is successfully called, until one distributed lock tool is successfully called, or until all distributed lock tools fail to call.

[0071] Step 205: If a distributed lock tool is successfully invoked, then use the successfully invoked distributed lock tool to acquire the lock;

[0072] Step 206: If all distributed lock tools fail to execute, then the locking process is interrupted.

[0073] For steps 202-206 of the embodiment, as one implementation method, the call request further includes: the number of repeated calls for each distributed lock tool after a call exception; determining whether the first-priority distributed lock tool was successfully called, including: if the first-priority distributed lock tool is successfully called once within a number of repeated calls less than or equal to the number of repeated calls, then the first-priority distributed lock tool was successfully called; if the first-priority distributed lock tool is called and fails within a number of repeated calls less than or equal to the number of repeated calls, then the first-priority distributed lock tool was called and failed.

[0074] For example, the locking component encapsulates three distributed lock tools. The call request includes: the first priority distributed lock tool is a Redis distributed lock, the second priority distributed lock tool is a ZooKeeper distributed lock, and the third priority distributed lock tool is a database unique index lock. The call request also includes: the distributed lock tool can be called 3 times after an exception occurs.

[0075] The number of times different distributed lock tools can be called repeatedly after an exception is not limited here.

[0076] First, the Redis distributed lock is invoked. If the Redis distributed lock invocation succeeds, the lock is acquired using the Redis distributed lock. If the Redis distributed lock invocation fails, it is repeated three times. If one of these three invocations succeeds, the lock is acquired using the Redis distributed lock. If all three invocations fail, the ZooKeeper distributed lock is invoked. If the ZooKeeper distributed lock invocation succeeds, the lock is acquired using the ZooKeeper distributed lock. If the ZooKeeper distributed lock invocation fails, it is repeated three times. If one of these three invocations succeeds, the lock is acquired using the ZooKeeper distributed lock. If all three invocations fail, the database unique index lock is invoked. If the database unique index lock invocation succeeds, the lock operation is performed using the database unique index lock. If the database unique index lock invocation fails, it is repeated three times. If one of these three invocations succeeds, the lock is acquired using the database unique index lock. If all three invocations fail, the locking process is interrupted.

[0077] Additionally, if one distributed lock tool is successfully invoked, a locking success message is sent to the locking component. If all distributed lock tools encounter invocation errors, a locking interruption message is sent to the locking component.

[0078] By applying the technical solution of this embodiment, the locking component encapsulates a distributed lock tool. Compared with the prior art of locking through code calls, this application directly sends a call request for the distributed lock tool to the locking component. The call request includes the call order of the distributed lock tools and the number of times each distributed lock tool is called repeatedly after a call exception. When a locking exception occurs, the locking component calls the encapsulated distributed lock tools in sequence according to the call order and the number of repeated calls, realizing automatic switching of multiple distributed lock tools without the need for manual retrying or manual code modification, reducing the waste of human resources and improving work efficiency.

[0079] This embodiment provides yet another method for handling locking exceptions, such as... Figure 3 As shown, the method includes:

[0080] Step 301: Send a distributed lock invocation request to the locking component so that the locking component can invoke the distributed lock tool encapsulated in the locking component according to the invocation request.

[0081] It should be noted that before sending the distributed lock request to the locking component, the process also includes encapsulating the distributed lock tool within the locking component. This distributed lock tool can be, for example, a Redis distributed lock, a ZooKeeper distributed lock, or a database unique index lock.

[0082] It should also be noted that, upon confirming the addition of a distributed lock tool, the process involves updating the locking component with the new distributed lock tool; and sending a distributed lock invocation request to the locking component, including sending the distributed lock invocation request to the locking component that has been updated with the new distributed lock tool.

[0083] First, this locking component is flexible and simple to use, and can be applied to all scenarios that require locking. For example, system A requires a call order A and a number of repeated calls A, while system B requires a call order B and a number of repeated calls B. This locking component is universal between system A and system B. That is, system A inputs the call order A and the number of repeated calls A into the locking component, and the locking component performs the locking operation according to the requirements of system A. Similarly, system B inputs the call order B and the number of repeated calls B into the locking component, and the locking component performs the locking operation according to the requirements of system B.

[0084] Second, the locking component can be horizontally scaled. When a new distributed lock tool is added, it can be updated into the locking component. When a locking operation is required, the locking component updated with the new distributed lock tool is used, which improves the applicability of the locking component for locking operations.

[0085] Step 302: If a distributed lock tool is successfully invoked, then receive the locking success message sent by the locking component.

[0086] Step 303: If all distributed lock tools encounter call exceptions, receive the interrupted locking information sent by the locking component.

[0087] By applying the technical solution of this embodiment, a request to invoke the distributed lock is first sent to the locking component. Furthermore, if one distributed lock tool is invoked successfully, the locking success information sent by the locking component is received. If all distributed lock tools encounter invocation errors, the locking interruption information sent by the locking component is received.

[0088] The locking component encapsulates a distributed lock tool. Compared to existing technologies that lock via code calls, this application directly sends a request to the distributed lock tool to the locking component. When a locking exception occurs, the locking component sequentially calls the encapsulated distributed lock tool according to the request, achieving automatic switching between multiple distributed lock tools. This eliminates the need for manual retrying or code modification, reducing wasted manpower and improving work efficiency. Furthermore, this locking component is flexible and simple to use, applicable to all scenarios requiring locking. It is horizontally scalable; when a new distributed lock tool is added, it can be updated into the locking component. When locking operations are required, the updated locking component is used, improving its applicability for locking operations.

[0089] Furthermore, as Figure 1 and Figure 2 The specific implementation of the method shown in this invention provides a locking exception handling device, such as... Figure 4 As shown, the device includes: a receiving module 41, a calling module 42, a locking module 43, and an interrupt module 44;

[0090] The receiving module 41 is used for the locking component to receive a call request for the distributed lock tool, wherein the call request includes the call order of the distributed lock tool;

[0091] Module 42 is used to invoke the distributed lock tool according to the invocation order;

[0092] The locking module 43 is used to lock the device if a distributed lock tool is successfully invoked.

[0093] Interrupt module 44 is used to interrupt locking if all the aforementioned distributed lock tools fail to execute.

[0094] Correspondingly, such as Figure 5 As shown, the calling module 42 may specifically include: a determining unit 421, a first judging unit 422, a calling success unit 423, and a calling exception unit 424;

[0095] The determining unit 421 can be used to determine the first-order distributed lock tool according to the calling order, and call the first-order distributed lock tool;

[0096] The first judgment unit 422 can be used to determine whether the first-order distributed lock tool has been successfully invoked;

[0097] The successful call unit 423 can be used to acquire a lock using the first-order distributed lock tool if the first-order distributed lock tool is successfully called.

[0098] The exception call unit 424 can be used to determine the second-order distributed lock tool according to the call order if the first-order distributed lock tool call fails, and to determine whether the second-order distributed lock tool call is successful, until one of the distributed lock tools is successfully called, or until all the distributed lock tools call fails.

[0099] Correspondingly, the call request also includes: the number of times each of the distributed lock tools is called repeatedly after an error occurs; in order to determine whether the first-order distributed lock tool is called successfully, the first judgment unit 422 can be used to: if the first-order distributed lock tool is called successfully once within a number of repeated calls less than or equal to the number of repeated calls, then the first-order distributed lock tool is called successfully; if the first-order distributed lock tool is called unsuccessfully within a number of repeated calls less than or equal to the number of repeated calls, then the first-order distributed lock tool is called unsuccessfully.

[0100] Furthermore, as Figure 3 The specific implementation of the method shown in this invention provides a locking exception handling device, such as... Figure 6 As shown, the device includes: a transmitting module 51, a first receiving module 52, and a second receiving module 53;

[0101] The sending module 51 is used to send a call request for the distributed lock to the locking component, so that the locking component can call the distributed lock tool encapsulated by the locking component according to the call request;

[0102] The first receiving module 52 is used to receive the locking success information sent by the locking component if one of the distributed lock tools is successfully invoked.

[0103] The second receiving module 53 is used to receive the interrupted locking information sent by the locking component if all the distributed lock tools encounter an invocation exception.

[0104] In specific application scenarios, before sending the distributed lock call request to the locking component, such as Figure 6 As shown, the device also includes a determination module 54, which can be used to encapsulate the distributed lock tool in the locking component.

[0105] In specific application scenarios, such as Figure 6 As shown, the device further includes: an update module 55, which can be used to determine the newly added distributed lock tool and update the newly added distributed lock tool to the locking component; correspondingly, a sending module 51 can be used to send a distributed lock invocation request to the locking component that has been updated with the newly added distributed lock tool.

[0106] It should be noted that other corresponding descriptions of the functional units involved in the locking exception handling device provided in this application embodiment can be found in the following references. Figures 1 to 3 The corresponding descriptions in the method will not be repeated here.

[0107] Based on the above, Figures 1 to 3 Accordingly, this application also provides a storage medium storing a computer program, which, when executed by a processor, implements the above-described method. Figures 1 to 3 The method for handling locking exceptions is shown.

[0108] Based on this understanding, the technical solution of this application can be embodied in the form of a software product. This software product can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, or portable hard drive), and includes several instructions to cause a computer device (such as a personal computer, server, or network device) to execute the methods described in the various implementation scenarios of this application.

[0109] Based on the above, Figures 1 to 3 The method shown, and Figure 4 and Figure 6 To achieve the above objectives, the present application also provides a computer device, specifically a personal computer, server, network device, etc., as shown in the virtual device embodiment. This computer device includes a storage medium and a processor; the storage medium stores a computer program; the processor executes the computer program to achieve the above-described objectives. Figures 1 to 3 The method for handling locking exceptions is shown.

[0110] Optionally, the computer device may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB interfaces, card reader interfaces, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Bluetooth interfaces, Wi-Fi interfaces), etc.

[0111] Those skilled in the art will understand that the computer device structure provided in this embodiment does not constitute a limitation on the computer device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0112] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages and stores the hardware and software resources of a computer device, supporting the operation of information processing programs and other software and / or programs. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other hardware and software within the physical device.

[0113] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platform, or it can be implemented by hardware.

[0114] By employing the above technical solution, this application provides a method, apparatus, storage medium, and computer device for handling locking exceptions. First, the locking component receives a request to invoke a distributed lock tool, wherein the request includes the invocation order of the distributed lock tools. Further, the distributed lock tools are invoked according to the invocation order. Finally, if one distributed lock tool is successfully invoked, the successfully invoked distributed lock tool is used to acquire the lock; if all distributed lock tools encounter invocation exceptions, the locking process is interrupted. This achieves automatic switching between various distributed lock tools after an exception occurs, thereby saving manpower and improving work efficiency.

[0115] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of a preferred embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing this application. Those skilled in the art will understand that the modules in the apparatus of the embodiment can be distributed within the apparatus of the embodiment as described, or can be modified to be located in one or more apparatuses different from this embodiment. The modules of the above-described embodiment can be combined into one module, or further divided into multiple sub-modules.

[0116] The serial numbers in this application are for descriptive purposes only and do not represent the superiority or inferiority of any particular implementation scenario. The above disclosures are merely a few specific implementation scenarios of this application; however, this application is not limited thereto, and any variations conceived by those skilled in the art should fall within the protection scope of this application.

Claims

1. A method for handling locking exceptions, characterized in that, The method includes: The locking component receives a call request for a distributed lock tool, wherein the call request includes the call order of the distributed lock tool, and the locking component encapsulates different types of distributed lock tools; The distributed lock tool is invoked according to the invocation order; If one of the distributed lock tools is successfully invoked, then the lock is acquired using the successfully invoked distributed lock tool; If all of the aforementioned distributed lock tools fail to execute, the locking process is interrupted.

2. The method according to claim 1, characterized in that, The step of invoking the distributed lock tool according to the invocation order includes: The first-order distributed lock tool is determined according to the calling order, and the first-order distributed lock tool is called. Determine whether the first-order distributed lock tool was successfully invoked; If the first-order distributed lock tool is successfully invoked, then the first-order distributed lock tool is used to acquire the lock; If the first-order distributed lock tool fails to be invoked, the second-order distributed lock tool is determined according to the invocation order, and it is determined whether the second-order distributed lock tool is invoked successfully. The process continues until one of the distributed lock tools is invoked successfully, or until all the distributed lock tools fail to be invoked.

3. The method according to claim 2, characterized in that, The call request also includes: the number of times each of the distributed lock tools is repeatedly called after a call exception; The step of determining whether the first-order distributed lock tool was successfully invoked includes: If the first-priority distributed lock tool succeeds once within a number of repeated calls less than or equal to the specified number of calls, then the first-priority distributed lock tool is successfully invoked. If the first-order distributed lock tool fails to call within a number of repeated calls less than or equal to the specified number, then the first-order distributed lock tool fails to call.

4. A method for handling locking exceptions, characterized in that, The method includes: Send a distributed lock invocation request to the locking component, so that the locking component invokes the distributed lock tool encapsulated in the locking component according to the invocation request; If one of the distributed lock tools is successfully invoked, then the locking success message sent by the locking component is received; If all the aforementioned distributed lock tools encounter an invocation exception, then the interrupted locking information sent by the locking component is received; Before sending the distributed lock invocation request to the locking component, the method further includes: Different types of distributed lock tools are encapsulated in the locking component.

5. The method according to claim 4, characterized in that, The method further includes: Identify the new distributed lock tool and update the locking component with the new distributed lock tool; Sending the distributed lock invocation request to the locking component includes: Send a distributed lock invocation request to the locking component that has been updated with the newly added distributed lock tool.

6. A device for handling lockout anomalies, characterized in that, The device includes: A receiving module is used for the locking component to receive call requests for distributed lock tools, wherein the call request includes the call order of the distributed lock tools, and the locking component encapsulates different types of distributed lock tools; The calling module is used to invoke the distributed lock tool according to the invocation order; The locking module is used to lock the device if one of the distributed lock tools is successfully invoked. An interrupt module is used to interrupt locking if all the aforementioned distributed lock tools fail to execute.

7. A device for handling lockout anomalies, characterized in that, The device includes: The sending module is used to send a distributed lock invocation request to the locking component, so that the locking component can invoke the distributed lock tool encapsulated by the locking component according to the invocation request; The first receiving module is used to receive the locking success information sent by the locking component if one of the distributed lock tools is successfully invoked. The second receiving module is used to receive the interrupted locking information sent by the locking component if all the distributed lock tools encounter an invocation exception. The module is used to encapsulate different types of distributed lock tools within the locking component.

8. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the locking exception handling method according to any one of claims 1 to 5.

9. A computer device, comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that, When the processor executes the computer program, it implements the locking exception handling method according to any one of claims 1 to 5.

Images