Distributed lock management method and device, network hardware and server

Abstract

A distributed lock management method is applied to network hardware. The network hardware is deployed between the node device and the lock management server. The method comprises the steps that a lock taking request sent by first node equipment is received, the lock taking request is initiated by an application thread on the first node equipment, and the first node equipment is one of at least one piece of node equipment; a lock authorization decision is made according to the lock taking request; under the condition that the authorization application thread is decided to take the lock, authorization information is generated and sent to the node equipment; and under the condition of deciding that the application thread is not authorized to take the lock, forwarding the lock taking request to a lock management server so as to process the lock taking request on the lock management server. In this way, lock authorization and metadata maintenance are decoupled, network hardware with strong network packet processing capacity is used for decision making, and adverse effects of lock metadata maintenance on delay or throughput of lock authorization are greatly avoided.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a distributed lock management method, device, network hardware and server. Background Art

[0002] Distributed lock management is a management mechanism in distributed systems that coordinates concurrent access to shared data between application threads on multiple devices. When an application thread reads or writes shared data, it needs to request the distributed lock manager to authorize the application thread to hold the corresponding lock in shared mode or exclusive mode to ensure the correctness of the read and write results.

[0003] Distributed lock managers are often implemented in a centralized form on one or more servers, responsible for maintaining lock metadata (including lock status, lock holders, waiting queues, etc.) and processing lock requests (lock acquisition or release requests) from application threads. For example, application thread 1 and application thread 2 both request to acquire lock A in exclusive mode. If the distributed lock manager first authorizes application thread 1 to hold lock A (authorizes lock acquisition through network packets), application thread 2 must wait in line for application thread 1 to release lock A to the distributed lock manager before it can be authorized to acquire lock A.

[0004] However, systems with distributed lock management (such as cloud databases and distributed file systems) usually use millions of fine-grained locks to protect the massive shared data they store, and all lock acquisition and release operations are completed in the form of network requests. This is prone to long and unstable delays in lock acquisition operations due to network delays in each lock acquisition and release operation, or packet queuing delays introduced by the limited network packet processing capabilities of the server's central processing unit (CPU), etc., thereby reducing lock processing efficiency. Summary of the invention

[0005] Embodiments of the present application provide a distributed lock management method, apparatus, device, network hardware, server, computer storage medium, and computer program product, which can improve lock processing efficiency.

[0006] In the first aspect, an embodiment of the present application provides a distributed lock management method, which is applied to network hardware, and the network hardware is deployed between at least one node device and a lock management server. The lock management server is used to maintain the metadata of the lock, and the method includes: receiving a lock acquisition request sent by a first node device, and the lock acquisition request is initiated by an application thread on the first node device, and the first node device is one of the at least one node devices; making a lock authorization decision based on the lock acquisition request; in the case where the decision is to authorize the application thread to acquire the lock, generating authorization information and sending it to the first node device; in the case where the decision is not to authorize the application thread to acquire the lock, forwarding the lock acquisition request to the lock management server, so as to process the lock acquisition request on the lock management server.

[0007] In this embodiment, the two functions of lock authorization decision and metadata maintenance in the lock processing operation are decoupled through two different network entities, the network hardware and the lock management server. After decoupling, the requester's lock request can be processed synchronously on the network hardware, and the subsequent metadata maintenance is performed asynchronously on the lock management server, that is, the metadata maintenance of the lock is separated from the critical path of the lock authorization decision. In this way, during the lock management process, precious hardware resources (that is, network hardware with powerful network packet processing capabilities) can be used for authorization decisions, thereby avoiding the adverse effects of relatively slow metadata maintenance on the delay or throughput of the lock authorization decision. Since the lock authorization decision only needs the current lock status information of the lock to be completed, even network hardware with limited memory can provide decision services for millions of locks, and can largely eliminate the impact of workload or hot data, thereby improving lock processing efficiency.

[0008] In some possible implementations, metadata of multiple locks are maintained on a lock management server, and a lock acquisition request is initiated by an application thread to the lock management server. The lock acquisition request includes lock information of a target lock, and the target lock is one of multiple locks. When a decision is made to authorize the application thread to acquire the lock, authorization information is generated and sent to the first node device, and the authorization information is also included: forwarding the authorized lock acquisition request to the lock management server, so that the lock management server updates the metadata of the target lock according to the lock information, wherein the metadata of the target lock includes at least lock holder information and a waiting queue.

[0009] In this way, the lock request sent by the node device to the lock management server can directly make a lock authorization decision on the network hardware. The lock management server only needs to update the metadata to achieve synchronous lock authorization decisions and asynchronous metadata maintenance.

[0010] In some possible implementations, the network hardware stores lock status information of multiple locks, and the lock acquisition request includes the lock information and lock acquisition mode of the target lock, the target lock is one of the multiple locks, and the lock acquisition mode includes a shared mode or an exclusive mode; according to the lock acquisition request, a corresponding lock authorization decision is made, specifically including: according to the lock information in the lock acquisition request, querying the lock status information of the target lock; when the queried lock status information and the lock acquisition mode in the lock acquisition request meet the lock acquisition conditions, authorizing the application thread to acquire the target lock.

[0011] In this way, since the lock status information occupies less memory on the network hardware, the logic of the lock authorization decision executed on the network hardware is also relatively simple and will not cause a large burden on the memory, so efficient authorization decision processing can be achieved.

[0012] In some possible implementations, metadata of multiple locks are maintained on a lock management server, network hardware stores lock status information of multiple locks, a lock acquisition request includes lock information of a target lock, and the target lock is one of the multiple locks. After the lock acquisition request is forwarded to the lock management server and the lock acquisition request is processed on the lock management server, the method includes: obtaining return information from the lock management server, the return information is used to characterize the authorization of the application thread to acquire the target lock; updating the lock status information of the target lock based on the return information; and forwarding the return information to the first node device.

[0013] In this way, the in-path hardware does not maintain metadata such as queues to avoid burdening the memory. The network hardware only needs to update the lock status information when forwarding the return information of the authorization to take the lock, so as to maintain the consistency of the lock status between different network entities.

[0014] In some possible implementations, the method further includes: receiving a lock release request sent by the first node device, the lock release request being initiated by the application thread; and sending the lock release request to the lock management device so that the lock management server processes the lock release request.

[0015] In some possible implementations, the network hardware stores lock status information of multiple locks, and the method further includes: obtaining idle prompt information from the lock management server, the idle prompt information is used to indicate that the lock holder information of the target lock is empty or the waiting queue is empty, and the target lock is one of the multiple locks; and updating the lock status information of the target lock according to the idle prompt information. In this way, after releasing the lock, the two network entities interact to maintain lock status consistency.

[0016] In some possible implementations, metadata of multiple locks are maintained on a lock management server, network hardware stores lock status information of multiple locks, a lock acquisition request includes lock information and a lock acquisition mode of a target lock, the target lock is one of multiple locks, and the lock acquisition mode includes a shared mode or an exclusive mode. The method also includes: when the lock acquisition mode in the lock acquisition request is a shared mode, generating a first request count for the target lock; receiving a network packet sent by the lock management server, the network packet including a second request count for the target lock recorded on the lock management server, and idle prompt information or return information, the idle prompt information is used to indicate that the lock holder information of the target lock is empty or the waiting queue is empty, and the return information is used to indicate that the application thread is authorized to acquire the target lock; comparing the second request count with the first request count; and when the second request count is inconsistent with the first request count, abandoning updating the lock status information of the target lock.

[0017] In this way, by taking the lock request count, the information consistency between different network entities is guaranteed, and the abnormal processing of the lock request in the shared mode due to network abnormality is avoided.

[0018] In the second aspect, an embodiment of the present application provides a distributed lock management method, which is applied to a lock management server, and the lock management server is used to maintain the metadata of the lock. The method includes: receiving a lock acquisition request forwarded by network hardware, the network hardware is deployed between at least one node device and the lock management server, the lock acquisition request is initiated by an application thread on a first node device, and the first node device is one of the at least one node devices; when the network hardware decides to authorize the application thread to acquire the lock based on the lock acquisition request, updating the metadata; when the network hardware decides not to authorize the application thread to acquire the lock based on the lock acquisition request, authorizing the lock acquisition request according to the metadata.

[0019] In some possible implementations, metadata of multiple locks is maintained on a lock management server, where the metadata includes lock holder information, and a lock request includes lock information of a target lock, where the target lock is one of the multiple locks; when the network hardware decides to authorize an application thread to acquire the lock based on the lock request, the metadata is updated, including: when the network hardware decides to authorize an application thread to acquire the lock based on the lock request, the application thread is used as the lock holder, and the lock holder information of the target lock is updated.

[0020] In some possible implementations, metadata of multiple locks is maintained on a lock management server, the metadata including lock holder information, and the lock request includes lock information of a target lock. Metadata of multiple locks is maintained on a lock management server, the metadata including a waiting queue, and the lock request includes lock information of a target lock, and the target lock is one of multiple locks; when the network hardware decides that the application thread is not authorized to take the lock based on the lock request, authorization processing is performed on the lock request based on the metadata, including: when the network hardware decides that the application thread is not authorized to take the lock based on the lock request, the lock request is added to the waiting queue of the target lock to wait for authorization processing.

[0021] In some possible implementations, metadata of multiple locks is maintained on a lock management server, the metadata including lock holder information, and a lock acquisition request includes the lock of a target lock. Metadata of multiple locks is maintained on a lock management server, the metadata including lock holder information and a waiting queue; the method also includes: receiving a lock release request forwarded by network hardware, the lock release request including lock information of a target lock, the target lock being one of multiple locks; updating the lock holder information of the target lock according to the lock release request; or, according to the lock release request, authorizing the lock acquisition request in the waiting queue of the target lock to generate return information, the return information being used to represent the authorization of the application thread to acquire the target lock.

[0022] In some possible implementations, metadata of multiple locks is maintained on a lock management server, the metadata includes lock holder information, and a lock request includes a lock of a target lock. Metadata of multiple locks is maintained on a lock management server, and network hardware stores lock status information of multiple locks. The method also includes: generating idle prompt information, the idle prompt information is used to characterize that the lock holder information of the target lock is empty or the waiting queue is empty, and the target lock is one of the multiple locks; and sending the idle prompt information to the network hardware to enable the network hardware to update the lock status information of the target lock.

[0023] In some possible implementations, metadata of multiple locks is maintained on a lock management server, the metadata including lock holder information, and a lock acquisition request includes a lock of a target lock. Metadata of multiple locks is maintained on a lock management server, and network hardware stores lock status information of multiple locks. The lock acquisition request includes lock information and a lock acquisition mode of the target lock, the target lock is one of the multiple locks, and the lock acquisition mode includes a shared mode or an exclusive mode. The method also includes: when the lock acquisition mode in the lock acquisition request is a shared mode, generating a second request count for the target lock; sending a network packet to the network hardware, the network packet including the second request count, and idle prompt information or return information, so that the network hardware compares the second request count with the first request count of the target lock recorded on the network hardware to determine whether to update the status information of the target lock; wherein the idle prompt information is used to indicate that the lock holder information of the target lock is empty or the waiting queue is empty, and the return information is used to indicate that the authorized application thread has taken the target lock.

[0024] In some possible implementations, the method also includes: receiving a release request sent by a first node device, the release request being initiated by an application thread, and the release request including a first identifier of the application thread; caching the release request when it is determined that the application thread is not authorized to take the lock based on the release request; receiving a first take-lock request, the first take-lock request including a second identifier, and the second identifier being an identifier of the application thread that initiated the first take-lock request; comparing the second identifier with the first identifier of the cached release request; if the second identifier is the same as the first identifier, deleting the first take-lock request and the release request.

[0025] In this implementation, to prevent network anomalies, the consistency of the requester (application thread) identifiers of the earlier lock release request and the later lock acquisition request is compared to avoid errors caused by reordering of the authorized lock acquisition request and its lock release request.

[0026] In the third aspect, an embodiment of the present application provides a distributed lock management device, which is applied to network hardware, and the network hardware is deployed between at least one node device and a lock management server, and the lock management server is used to maintain the metadata of the lock, and the device includes: a receiving module, which is used to receive a lock acquisition request sent by a first node device, and the lock acquisition request is initiated by an application thread on the first node device, and the first node device is one of the at least one node devices; a lock decision module, which is used to make a lock authorization decision based on the lock acquisition request, and the lock authorization decision is used to decide whether to authorize the application thread to acquire the lock; the lock decision module is also used to generate authorization information and send it to the first node device when it is decided to authorize the application thread to acquire the lock; the lock decision module is also used to forward the lock acquisition request to the lock management server when it is decided that the application thread is not authorized to acquire the lock, so as to process the lock acquisition request on the lock management server.

[0027] In the fourth aspect, an embodiment of the present application provides a distributed lock management device, which is applied to a lock management server, and the lock management server stores the metadata of the lock, and the device includes: a receiving module, which is used to receive a lock acquisition request forwarded by network hardware, and the network hardware is deployed between at least one node device and the lock management server, and the lock acquisition request is initiated by an application thread on a first node device, and the first node device is one of the at least one node devices; a lock metadata maintenance module, which is used to update the metadata when the network hardware decides to authorize the application thread to acquire the lock according to the lock acquisition request; the lock metadata maintenance module is also used to authorize the lock acquisition request according to the metadata when the network hardware decides not to authorize the application thread to acquire the lock according to the lock acquisition request.

[0028] In a fifth aspect, an embodiment of the present application provides a network hardware, comprising: at least one memory for storing programs; and at least one processor for executing programs stored in the memory; wherein, when the program stored in the memory is executed, the processor is used to execute the method described in the first aspect or any possible implementation of the first aspect.

[0029] In the sixth aspect, an embodiment of the present application provides a server, comprising: at least one memory for storing programs; and at least one processor for executing programs stored in the memory; wherein, when the program stored in the memory is executed, the processor is used to execute the method described in the second aspect or any possible implementation of the second aspect.

[0030] In the seventh aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method described in the first aspect or any possible implementation of the first aspect.

[0031] In an eighth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method described in the second aspect or any possible implementation of the second aspect.

[0032] In a ninth aspect, an embodiment of the present application provides a computer program product, characterized in that when the computer program product runs on a processor, the processor executes the method described in the first aspect or any possible implementation of the first aspect.

[0033] In the tenth aspect, an embodiment of the present application provides a computer program product, characterized in that when the computer program product runs on a processor, the processor executes the method described in the second aspect or any possible implementation of the second aspect.

[0034] In the eleventh aspect, an embodiment of the present application provides a chip, characterized in that it includes at least one processor and an interface; at least one processor obtains program instructions or data through the interface; at least one processor is used to execute program line instructions to implement the method described in the first aspect or any possible implementation method of the first aspect.

[0035] In the twelfth aspect, an embodiment of the present application provides a chip, characterized in that it includes at least one processor and an interface; at least one processor obtains program instructions or data through the interface; at least one processor is used to execute program line instructions to implement the method described in the second aspect or any possible implementation method of the second aspect.

[0036] It can be understood that the beneficial effects of the second to twelfth aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 It is a schematic diagram of a system architecture of distributed lock management in related technologies;

[0038] Figure 2 2 is a schematic diagram of a system architecture of distributed lock management in the related art, wherein (2a) shows a lock partitioning method, and (2b) shows an intra-network lock method;

[0039] Figure 3 It is a schematic diagram of an application scenario of an embodiment of the present application;

[0040] Figure 4 It is a structural diagram of a server provided in an embodiment of the present application;

[0041] Figure 5 It is a schematic diagram of the structure of a network hardware provided in an embodiment of the present application;

[0042] Figure 6 It is a schematic diagram of the architecture of a distributed system provided in an embodiment of the present application;

[0043] Figure 7 is a schematic diagram of distributed lock management in a specific embodiment of the present application;

[0044] Figure 8 It is a flow chart of a distributed lock management method provided by an embodiment of the present application;

[0045] Fig. 9 It is a flowchart of a distributed lock management method provided by a specific embodiment of the present application;

[0046] Fig.10 This is a schematic diagram of the process of taking the lock in a specific embodiment of the present application;

[0047] Fig.11 This is a flowchart of a lock release process in a specific embodiment of the present application;

[0048] Fig.12 This is a flowchart of a lock release process in a specific embodiment of the present application;

[0049] Fig.13 This is a flowchart of lock processing in a specific embodiment of the present application.

[0050] Fig.14 is a data curve chart of a lock processing test for a specific application in an embodiment of the present application;

[0051] Fig.15 is a data curve chart of a lock processing test for a specific application in an embodiment of the present application;

[0052] Fig.16 is a data curve chart of a lock processing test for a specific application in an embodiment of the present application;

[0053] Fig.17 It is a structural diagram of a distributed lock management device provided in an embodiment of the present application;

[0054] Fig.18 It is a structural diagram of a distributed lock management device provided in an embodiment of the present application;

[0055] Fig.19 It is a schematic diagram of the structure of a chip provided in an embodiment of the present application. DETAILED DESCRIPTION

[0056] The term "and / or" in this article is a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. The symbol " / " in this article indicates that the associated objects are in an or relationship, for example, A / B means A or B.

[0057] The terms "first" and "second" in the specification and claims herein are used to distinguish different objects rather than to describe a specific order of the objects. For example, a first response message and a second response message are used to distinguish different response messages rather than to describe a specific order of the response messages.

[0058] In the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

[0059] In the description of the embodiments of the present application, unless otherwise specified, "multiple" means two or more than two. For example, multiple processing units refer to two or more processing units, etc.; multiple elements refer to two or more elements, etc.

[0060] To facilitate understanding of the technical solution of the present application, the terms involved in this document are explained below.

[0061] Distributed locks refer to a type of lock that implements multi-process distributed mutual exclusion in a distributed environment and system cluster deployment. Usually, distributed locks can include shared locks and exclusive locks.

[0062] Shared lock: When an application thread on a device (such as a server or host) in a distributed system holds a shared lock on a resource, it can read the resource. Application threads on multiple devices can hold a shared lock on the same resource.

[0063] Exclusive lock: When an application thread on a device in a distributed system holds an exclusive lock on a resource, it can read and write the resource. At the same time, only one application thread can hold an exclusive lock on a resource.

[0064] Zipfian distribution: A discrete power-law probability distribution in which the frequency of each element is inversely proportional to its rank in the frequency table. For example, among the elements that satisfy this distribution, the most frequent element occurs approximately twice as often as the second most frequent element and three times as often as the third most frequent element.

[0065] Network path: refers to the network channel that a network packet passes through when it is sent from one machine to another.

[0066] Path-associated network hardware: a type of network hardware located on a network path that can perform some simple processing on packets as they pass through it. Typical path-associated network hardware includes smart network cards, programmable switches, etc.

[0067] Line speed: refers to the speed limit of the network physical port, which is the upper limit of network transmission speed. Being able to process network requests at line speed means that the processor will not have network packet queuing under any circumstances.

[0068] Skew: An adjective that measures the degree of balance of data access in a workload. The higher the skew, the more concentrated the access is on certain data.

[0069] In distributed systems such as cloud databases and distributed file systems (Hadoop Distributed File System, HDFS), distributed lock managers (functional modules) can be centrally deployed on one or more servers. Figure 1 As shown, before the application threads (A, B, ...) on the servers P1, P2, ... in the distributed system need to access shared data, they send a network request to the lock manager S1 to acquire the corresponding lock, and the lock manager S1 grants the lock to the requester through a network packet. The application thread that acquires the lock can access the data. After the access is completed, the application thread holding the lock sends a network request to the lock manager S1 to release the lock. The lock acquisition request that cannot be satisfied immediately will be temporarily suspended by the lock manager S1 and authorized again when the conditions are met.

[0070] Although centralized lock managers can use global control over lock requests to achieve predictable delays, anti-starvation and other functional features, all lock acquisition and release operations are completed in the form of network requests. In order to support the operation of millions of fine-grained locks in a distributed system, this method of implementing lock acquisition operations still has the problem of long delays and large variations.

[0071] Some related technologies attempt to use local processing to optimize the processing efficiency of some lock requests. For example, Figure 2 As shown in (2a), the lock partitioning (ParLock) method is adopted. A lock manager S1 is run on each machine P1, P2, ... where the application threads A, B, ... are located, and the locks in the distributed system are statically divided to these lock managers S1 for management. Although this method can process some lock requests locally to obtain lower lock acquisition latency and alleviate the load of remote lock manager package processing, the acceleration ratio in request processing is inversely proportional to the machine scale. Because the more machines there are, the fewer locks there are on each machine, and the proportion of lock requests that can be processed locally will be smaller. For example, in a test environment with 8 machines, the proportion of lock requests that can be accelerated is about 12.5%. In a large-scale cluster, the local acceleration ratio is basically negligible, that is, the optimization effect of this method is not obvious. In addition, this method has the problem of load imbalance. The machine that manages the hot spot lock is easily overloaded, resulting in a high latency for acquiring this part of the lock. If the locks are evenly divided among the machines by intervals, and the lock requests conform to the Zipfian distribution, then the latency of more than half of the lock requests will be more than an order of magnitude higher than normal. When the workload is unevenly distributed among machines, this approach is more prone to load imbalance than using a dedicated lock server to handle requests.

[0072] In other related technologies, attempts are also made to optimize the processing efficiency of some lock requests by using in-network processing as a fast path. Figure 2 As shown in (2b), the in-network lock (NetLock) method is adopted to deploy a fast path lock manager S2 by utilizing the packet processing capability of the programmable switch W1 and its location in the center of the network topology. This method selects a portion of the more frequently accessed locks by analyzing the workload and delegates them to the lock manager S2 on the switch W1 for management. The remaining locks are still managed by the lock manager S1 on the server. However, since the on-chip memory of the programmable switch is only a few MB in size and the length of the lock holder set / waiting queue is uncertain, the switch can only reserve storage space for the metadata of thousands of locks, which easily leads to the dependence of this method on the workload in two aspects:

[0073] First, it is only suitable for workloads with high skewness. Since the number of locks on the switch is limited, the higher the skewness of the workload, the more requests are concentrated on a small number of locks, and the higher the proportion of lock requests that the switch can accelerate. After testing, even under Zipfian distribution, the switch can only accelerate about 31% of lock requests, while the acceleration ratio under uniform distribution is only 1%. Second, the workload pattern needs to be analyzed in advance. It is very difficult to dynamically adjust the set of locks managed on the switch, so this method must know the identity of the frequently accessed locks in the workload before the system starts, which makes this method basically ineffective when the workload pattern is difficult to predict or changes dynamically. As shown in the figure, the lock management optimization performance of this method immediately drops to a level close to that before optimization after the load hotspot leaves the switch.

[0074] Therefore, the performance and effect of the above-mentioned related technologies on distributed lock management are not ideal.

[0075] In order to speed up the distributed lock operation and improve the processing efficiency, the embodiment of the present application provides a distributed lock management method. The method mainly decouples the authorization decision of the lock from the metadata maintenance of the lock, uses the powerful packet processing capability of the network hardware in the network to perform synchronous authorization decisions, and performs asynchronous metadata maintenance in other devices, thereby greatly reducing the delay of lock requests in the distributed environment and improving the lock operation processing efficiency.

[0076] To facilitate understanding of the technical solution of the embodiments of the present application, at least one application scenario of the embodiments of the present application is introduced below.

[0077] For example, Figure 3 FIG. 1 is a schematic diagram of an application scenario of an embodiment of the present application. Figure 3 As shown, in a distributed database system, shared resources 40 can be stored on one or more devices, and access to all shared resources 40 is controlled by a number of locks 20. The distributed database system may include multiple servers (11, 12, 13, ...), wherein a lock table 1 is set on one server 11 to maintain metadata such as lock holders and waiting queues of the distributed locks 20, and other servers (12, 13, ...) can communicate and interact with the server 11 through the accompanying network hardware 30, and the accompanying network hardware 30 also has the function of maintaining the status information of the lock 20 and making decisions and authorizations on the lock acquisition requests of the servers (12, 13, ...).

[0078] When the application thread (a, b, ...) on the server (12, 13, ...) needs to access the shared data 40, a lock request (X01, X02, ...) corresponding to the shared data 40 is generated and respectively Figure 3Steps 1 and 2 shown in the figure send a lock request (X01, X02, ...) to the server 11. The lock request (X01, X02, ...) will pass through the accompanying network hardware 30 when it is transmitted in the network path. The accompanying network hardware 30 executes step 3 to parse the received lock request (X01, X02, ...) and decide whether to authorize these requesters to take the lock.

[0079] If the associated network hardware 30 decides to authorize one or some requesters (such as thread a on server 12) to take the lock, step 4 is executed to return the authorization information to the corresponding server, and the network packet of the request X01 is forwarded to server 11 through step 5 to update the metadata (lock holder information). If the associated network hardware 30 decides not to authorize one or some requesters (such as thread b on server 13) to take the lock, the corresponding lock request X02 is forwarded to server 11 through step 5 and added to the waiting queue maintained by server 11, so as to authorize these requesters to take the lock at an appropriate time.

[0080] The server 12 that receives the authorization information can access the corresponding shared data 40 with the lock 20 through step 6 to perform a read or write operation. After the operation is completed, the server 12 generates a lock release request X11 and forwards it via the associated network hardware 30, sending the lock release requests X11 and X12 to the server 11 to release the corresponding lock 20. After that, the server 11 authorizes other requesters (such as thread b on the server 13) according to the situation, and returns through steps 9 and 10. These requesters can access data and request to release the lock 20 through steps 11, 12, 13, etc.

[0081] In this way, the authorization decision and metadata maintenance of distributed locks are decoupled, and the powerful packet processing capability of the accompanying network hardware 30 (much higher than the server CPU) is used to implement authorization decisions for all locks in the system. This can support stable and efficient lock authorization under large-scale fine-grained locks, reduce network latency, avoid queuing delays, and improve the processing efficiency of lock requests.

[0082] In other application scenarios, such as distributed environments such as distributed cache, distributed file systems, and distributed transaction processing, the above-mentioned distributed lock management solution can be used to perform similar lock acquisition and release operations on the application threads (a, b, ...) on the above-mentioned servers (12, 13, ...) to achieve corresponding shared resource access, which will not be repeated here.

[0083] Next, a server provided in an embodiment of the present application is introduced.

[0084] For example, Figure 4The schematic diagram of the structure of a server provided in an embodiment of the present application is shown. It can be understood that the server 100 can be a device that can provide data processing functions, computing functions or storage functions. Exemplarily, the server 100 can be a hardware server, a cloud server, or a virtualized device, such as a virtual machine, a container, etc.

[0085] like Figure 4 As shown, the server 100 may include: a processor 110, a network interface 120, and a memory 130. Among them, the processor 110, the network interface 120, and the memory 130 may be connected via a bus or other means. In this embodiment, the processor 110 (or referred to as a central processing unit (CPU)) is the computing core and control core of the server 100. In some embodiments, the processor 110 may perform some or all of the steps of the method provided in this embodiment. The network interface 120 may optionally include a standard wired interface, a wireless interface (such as WI-FI, a mobile communication interface, etc.), and may be connected to hardware such as a network card to be controlled by the processor 110 for sending and receiving data. The memory 130 (memory) is a memory device of the server 100, which is used to store programs and data, etc. It can be understood that the memory 130 may be a RAM memory or a non-volatile memory, such as at least one disk memory. The memory 130 provides a storage space that stores the server's operating system and executable program code, which may include but is not limited to: Windows system, Linux system, Hongmeng system, etc., which are not limited here.

[0086] As a specific example, the server 100 may be deployed as a server for distributed lock management, for example Figure 3 The server 11 shown in the figure includes a lock metadata maintenance module 140 in the server 100, and the lock metadata maintenance module 140 can be stored in the memory 130 in the form of program code. The memory 130 can also store a lock table 1, which is used to record lock metadata. The lock metadata includes at least lock holder information and a waiting queue, and can also include lock status information, etc.

[0087] The structure of a network hardware provided in an embodiment of the present application is introduced below in conjunction with the accompanying drawings.

[0088] For example, Figure 5 FIG. 1 shows a schematic diagram of the structure of a network hardware provided by an embodiment of the present application. Figure 5 As shown in , the network hardware 300 includes a processor 310 , a memory 320 , and a network device 330 , and both the network device 330 and the memory 320 are connected to the processor 310 .

[0089] The processor 310 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or a network processor (NP). The processor 310 may be a processor group consisting of multiple processors, and the multiple processors are coupled to each other through one or more buses.

[0090] The memory 320 may be coupled to the processor 310. Specifically, the memory 320 may be coupled to the processor 310 via one or more memory controllers. The memory 320 may be used to store computer program instructions and data, such as an authorization decision program of a distributed lock, a lock state table, a gateway flow table, and the like. The memory 320 may be a non-power-off volatile memory, such as a read-only memory (ROM), or a power-off volatile memory (volatile memory), such as a random access memory (RAM), but is not limited thereto.

[0091] Exemplarily, the distributed lock authorization decision program stored in the memory 320 may be deployed in the form of a lock decision module 340 to execute part or all of the steps of the distributed lock management method described below in the embodiment of the present application.

[0092] The network device 330 may be a physical network interface (Ethernet interface, such as an RJ-45 interface) connected to the network side, or a programmable switching chip, etc., but is not limited thereto.

[0093] The network hardware 300 may be a network hardware such as an intelligent network card, a programmable switch, etc. Figure 3 The associated network hardware 30 is shown and will not be described in detail here.

[0094] For example, Figure 6 FIG. 1 shows a schematic diagram of the architecture of a distributed system provided by an embodiment of the present application. Figure 6As shown, in the distributed system 400, shared resources 40 can be stored on one or more devices, and access to all shared resources 40 is controlled by a number of locks 20. The distributed system 400 also includes multiple servers (also referred to as "node devices" in this article) 12, 13, ... running applications (a, b, ...), and the applications (a, b, ...) can hold locks 20 to access these shared resources 40. In addition, the distributed system 400 also includes a lock management server 100, and the lock metadata maintenance module 140 deployed on the lock management server 100 can be used to maintain the lock holder set, waiting queue and other metadata of the lock 20.

[0095] In this example, when the application thread (a, b, ...) accesses the shared resource 40, it needs to initiate a lock request to the lock management server 100 through the request module (2, 3, ...) on the server (12, 13, ...). The network hardware 300 is deployed on the network path between the server (12, 13, ...) and the lock management server 100. The lock decision module 340 is deployed on the network hardware 300. The lock decision module 340 is used to maintain the lock status information of the lock 20 and make an authorization decision on the lock request received to take the lock 20. Among them, the lock status information may include information that the lock 20 is in an idle state, a shared state, or an exclusive state. Then, the application thread (a, b, ...) completes accessing the shared resource 40 and initiates a lock release request to the lock management server 100. The network hardware 300 directly forwards the lock release request to the lock management server 100 to perform the lock release process.

[0096] Specifically, please refer to Figure 7 As shown, the request module (2, 3, ...) is deployed on the server (12, 13, ...), which is responsible for sending the lock request or lock release request of the application thread (a, b, ...) running on the server in the form of a network packet to the lock management server 100, and receiving the lock authorization reply. Taking the request module 2 as an example, the request module 2 may include a lock operation API 21, and the lock operation API 21 may include a lock acquisition API and a lock release API. The lock operation API 21 provides the application thread a with a function interface for acquiring and releasing the lock, and the definition of the function interface may be consistent with a mature stand-alone read-write lock. The request module 2 also includes a network driver 22, which is responsible for data interaction with the network card 1220 in the server 12, that is, sending and receiving network packets.

[0097] The lock decision module 340 of the network hardware 300 may include an authorization decision unit 341, which may be used to make a decision on whether to authorize the application thread to take the lock based on the network packet passing through the network hardware 300 and the lock state information stored locally. The lock decision module 340 may also include a state update unit 342, which may be used to update the lock state information based on the network packet passing through the network hardware 300 and the decision result of the authorization decision unit 341. The lock decision module 340 may also include a packet forwarding unit 343, which may be used to send a lock request or authorization information based on the decision result.

[0098] The lock metadata maintenance module 140 can run the lock request processing daemon 141 to process the lock request received from the network card 120a of the server 100, and maintain the metadata of the lock 20 accordingly. The metadata maintenance may include adding / deleting lock holders, or adding / deleting lock requests and requesters in the waiting queue, generating return information for authorization of the lock request, etc. The lock request processing daemon 141 can encapsulate network packets through the network driver 142 to send information.

[0099] Next, based on the above description, a distributed lock management method provided by an embodiment of the present application is introduced. It can be understood that the method is proposed based on the above description, and part or all of the content of the method can be referred to the above description.

[0100] See also Figure 8 , Figure 8 1 is a flow chart of a distributed lock management method provided by an embodiment of the present application. It can be understood that the method can be implemented by network hardware in a distributed system, and the network hardware is deployed on a network path between at least one node device and a lock processing server. Figure 8 As shown, the method may include:

[0101] S810, receiving a lock acquisition request sent by a first node device, where the lock acquisition request is initiated by an application thread on the first node device, and the first node device is one of the at least one node device.

[0102] In this embodiment, multiple node devices (which may be servers, but not limited to these) and lock management servers may be deployed in the distributed system, and any node device and any lock management server may obtain an exclusive network access by accessing a network hardware. Among them, the application thread on each node device may access the corresponding shared resource with a lock, and these locks may be managed by the lock management server.

[0103] Exemplarily, the lock management server can at least be used to maintain metadata such as lock holders and waiting queues. In addition, in addition to providing network transmission capabilities, the network hardware can also manage the lock status information of the lock and make lock authorization decisions. The lock status information may include information about whether the lock is in an idle state, a shared state, or an exclusive state; the lock authorization decision is used to decide whether to authorize the application thread that initiates the lock acquisition request to acquire the lock. As a specific example, the first node device can be Figure 8 The server 12 in the lock management server may be Figure 8 The server 100 shown in FIG. 1 may be a network hardware Figure 8 The network hardware 300 shown in FIG. 1 is also used as an example in the following description.

[0104] Exemplarily, the application threads a, b, ... running on each node device 12, 13, ... can be different threads within the same distributed application, such as distributed transaction processing as an application, a workload (an application) in a distributed system as an application, key-value storage in a distributed storage system as an application, etc., which are not listed one by one here.

[0105] For example, if application thread a on server 12 wants to access a shared resource, it needs to first initiate a lock acquisition request to request the lock management server 100 to acquire the lock that controls the shared resource (also referred to as the "target lock" herein). As a specific example, the lock acquisition request may include lock information of the target lock (such as a lock identity document (ID)) and a lock acquisition mode, which may include an exclusive mode or a shared mode.

[0106] S820: Make a corresponding lock authorization decision based on the lock acquisition request.

[0107] In this embodiment, when the network hardware 300 receives a lock request from the server 12, 13, ... and determines that it is a lock acquisition request, a lock authorization decision can be made according to the lock acquisition request.

[0108] Exemplarily, the network hardware 300 queries the lock status information of the target lock based on the lock information in the lock acquisition request, and then makes an authorization decision on the lock acquisition request based on the lock status information and the lock acquisition mode in the lock acquisition request, that is, authorizing the requester of the lock acquisition request (such as application thread a on server 12) to acquire the lock, or not authorizing the requester to acquire the lock.

[0109] S830, when the decision is made to authorize the application thread to take the lock, generate authorization information and send it to the first node device;

[0110] In this embodiment, if the network hardware 300 makes a decision and determines that the application thread that initiated the lock request is authorized to acquire the lock, the corresponding lock status information can be updated (such as updating the lock from an idle state to a shared state or an exclusive state, etc.), and authorization information is generated and sent to the corresponding server 12, 13, ..., so that the application thread on the server 12, 13, ... can access the shared resources with the target lock.

[0111] And, exemplarily, the network hardware 300 also forwards the authorized lock acquisition request to the lock management server 100 to update the metadata of the target lock, such as updating the lock holder set of the target lock. The lock holder set records the information of the requester who has been authorized to acquire the lock and has not yet released the lock. The requester information may include the application thread ID and the machine ID of the server where the thread is located.

[0112] S840: If it is decided that the application thread is not authorized to acquire the lock, the lock acquisition request is forwarded to the lock management server so that the lock acquisition request is processed on the lock management server device.

[0113] In this embodiment, if the network hardware 300 determines that the requester is not authorized to take the lock, the lock taking request is forwarded to the lock management server 100 for processing. In this way, the management server 100 can put the lock taking request into a waiting queue, so as to take out the lock taking request from the waiting queue at an appropriate time and authorize the requester to take the lock.

[0114] In this embodiment, after the lock management server 100 authorizes the lock request in the waiting queue, it can generate and send out return information indicating that the requester is authorized to take the lock. When the return information passes through the network hardware 300, the network hardware 300 can update the lock status information to ensure consistency with the metadata maintained on the lock management server 100.

[0115] In this embodiment, the two functions of lock authorization decision and metadata maintenance in the lock processing operation are decoupled through two different network entities, namely, network hardware and lock management server. After decoupling, the requester's request to obtain the lock can be processed synchronously on the network hardware, and the subsequent metadata maintenance is performed asynchronously on the lock management server, that is, metadata maintenance is separated from the critical path of lock authorization decision. In this way, during the lock management process, precious hardware resources (i.e., network hardware with powerful network packet processing capabilities) can be used for lock authorization decisions, thereby avoiding the adverse effects of relatively slow metadata maintenance on the delay or throughput of lock authorization decisions. Since the lock authorization decision only needs the current lock status information of the lock to be completed, even network hardware with limited memory can provide decision services for millions of locks, and can largely eliminate the impact of workload or hot data, thereby improving lock processing efficiency.

[0116] In conjunction with the accompanying drawings, the specific process of the distributed lock management method provided in the embodiment of the present application is described below by taking a user thread accessing a shared resource in a distributed system as an example.

[0117] For example, Fig. 9 FIG. 2 is a flow chart of a distributed lock management method in a specific embodiment of the present application. Fig. 9 As shown, the method may include:

[0118] S910: An application thread on the first node device generates a corresponding lock request according to a resource to be accessed.

[0119] In this embodiment, the shared resources (such as data or objects, etc.) in the distributed system have corresponding locks, the lock management server maintains metadata of multiple locks, and the network hardware stores lock status information of multiple locks. Before the user thread h on the server 12 in the distributed system needs to access these resources, the user thread h needs to generate a corresponding lock request according to the resource to be accessed, so as to request the lock management server 100 to obtain the lock, that is, the target lock.

[0120] Exemplary, combined Fig.10 As shown in the lock acquisition process, the user thread h can Fig.10 Step 1 in the above method calls the lock operation API 21 (lock acquisition API) of the request module in the server 12, determines the target lock to be requested and the lock mode (shared or exclusive), and generates a lock acquisition request. As a specific example, the lock acquisition request may include lock information (such as lock ID), lock acquisition mode, machine ID of the server 12, thread ID of the user thread h initiating the request, etc.

[0121] It can be understood that when the user thread h wants to perform a read operation on the resource, the lock mode requested in the lock request can be a shared mode or an exclusive mode. When performing a write operation, the lock mode in the lock request is an exclusive mode.

[0122] In this embodiment, the request module 2 of the server 12 may execute Fig.10 In step 2, the lock request is encapsulated into a network packet, the target address of the network packet is the address of the device where the lock manager is located (ie, the lock management server 100), and then the network packet is sent out through the network driver 22.

[0123] S920, the network hardware receives the lock taking request;

[0124] S930: Make a lock authorization decision based on the lock acquisition request.

[0125] In this embodiment, the network packet sent by the server 12 is transmitted in the network path and passes through the network hardware 300. After receiving the network packet, the network hardware 300 analyzes it. If it is determined that the network packet is a lock request, it directly makes a lock authorization decision for the lock request. For example, the network hardware 300 passes Fig.10 Steps 3 and 4 in the above are handed over to the lock decision module 340 to perform authorization decision on the network packet.

[0126] Exemplarily, making an authorization decision in S930 may specifically include:

[0127] S931, querying the lock status information of the target lock according to the lock information in the lock acquisition request;

[0128] In this example, when the network hardware 300 makes a lock-taking authorization decision, the network hardware 300 queries the lock status information of the target lock among all the lock status information stored inside the network hardware 300 according to the lock ID parsed from the lock-taking request.

[0129] S932: When the queried lock status information and the lock acquisition mode meet the lock acquisition condition, authorize the application thread to acquire the lock.

[0130] In this example, the preset unlocking conditions may include:

[0131] If the target lock is in an idle state, or the lock state is a shared state (currently other requesters share the lock) and the lock acquisition mode in the lock acquisition request is shared, the network hardware 300 determines that the user thread h on the current server 12 can be authorized to acquire the lock. On the contrary, if the lock state information of the target lock is a shared state, but the lock acquisition mode in the lock acquisition request is an exclusive mode, or the lock state information of the target lock is other states that cannot be authorized currently, the network hardware 300 determines that the user thread h is not authorized to acquire the lock temporarily.

[0132] S940, when the network hardware decides to authorize the application thread to acquire the lock, the network hardware generates authorization information, returns the information to the first node device, and forwards the lock acquisition request to the lock management server.

[0133] In this embodiment, if the network hardware 300 makes a decision on the lock acquisition request and authorizes thread h to acquire the lock, the lock state information of the target lock is updated, such as updating from an idle state to an exclusive state or a shared state, or increasing the number of shared lock holders in a shared state. In addition, the network hardware 300 generates authorization information and returns it to the server 12. As a specific example, the authorization information may include the lock ID of the authorized target lock, as well as the machine ID, thread ID, etc.

[0134] In addition, the network hardware 300 also forwards the network packet of the lock request to the server 11, for example Fig.10As a specific example, the forwarded network packet may include, in addition to the lock request, information that the lock request has been authorized.

[0135] S950: When the network hardware determines that the application thread is not authorized to acquire the lock, the network hardware forwards the lock acquisition request to the lock management server.

[0136] In this embodiment, if the network hardware 300 makes a decision on the lock taking request and the requester is not authorized to take the lock, the network packet of the lock taking request is forwarded to the lock management server 100, for example Fig.10 In some specific examples, the network packet may also include information that the lock-taking request is not authorized.

[0137] S960: The lock management server updates metadata according to the authorized lock acquisition request, where the metadata at least includes lock holder information or a waiting queue.

[0138] In this embodiment, the lock metadata maintenance module deployed on the lock management server 100 maintains and updates the corresponding lock table. Specifically, the lock metadata maintenance module 140 runs the daemon thread (background thread) 141 to achieve: if the lock management server 100 parses the received network packet and determines that the lock acquisition request encapsulated in the network packet has been authorized to acquire the lock on the network hardware, the lock metadata maintenance module 140 executes Fig.10 In step 6 shown, the machine ID and thread ID represented in the lock request are associated and then added to the lock holder set of the target lock.

[0139] S970, the lock management server performs lock taking processing according to the unauthorized lock taking request.

[0140] In this embodiment, if the lock management server 100 determines that the lock acquisition request is not authorized to acquire the lock on the network hardware 300, the lock metadata maintenance module 140 executes Fig.10 In step 9 shown, the lock acquisition request and the corresponding requester are added to the waiting queue of the target lock. It can be understood that each lock can be associated with a waiting queue. In some examples, the lock acquisition request corresponding to a lock can be placed in a waiting queue.

[0141] For example, continue to refer to Fig.10 When all lock holders in the shared mode release the lock, or when the lock holder in the exclusive mode releases the lock, the lock metadata maintenance module 140 can execute step 10, take out the lock request from the waiting queue, add the corresponding requester (i.e., the application thread on the server) to the lock holder set, and generate return information to the corresponding server 12, and the return information is used to indicate that the application thread is authorized to take the target lock.

[0142] Exemplarily, when the return information of the lock management server 100 is returned to the server 12 via the network hardware 300, the network hardware 300 will update the corresponding lock status information according to the return information, for example Fig.10 as shown in step 11.

[0143] S980, the first node device receives the authorization information or the return information to access the resource with the corresponding lock.

[0144] In this embodiment, after receiving the authorization information decided by the network hardware or the return information forwarded by the network hardware, the server 12 sends it to the user thread h, and the user thread h can access the corresponding shared resource with the target lock, for example, by Fig.10 Step 7 shown in , implements thread h's access to resources.

[0145] In this embodiment, the lock authorization decision-making capability of the network hardware is decoupled from the lock metadata maintenance and lock request processing flow of the lock manager (deployed on the server). Since the lock authorization decision logic is simple, the implementation of the lock authorization decision function (especially relative to the maintenance of data such as lock holders and waiting queues) places less burden on the network hardware memory. Therefore, in the process of accelerating lock processing, it is possible to avoid the network hardware memory capacity becoming a system scale bottleneck, and avoid significantly reducing the latency of all lock requests in a distributed lock scenario of millions of levels due to insufficient network hardware memory capacity.

[0146] In addition, since the network packet processing capability of the network hardware (which can be smart network cards, programmable switches and other network hardware) is much higher than the processing capability of the CPU on the server, especially the programmable switch, which can process network packets at line rate to ensure sufficiently efficient processing of lock requests under the scale of millions of locks, there will be no processing delay. In this way, not only can stable and efficient lock authorization under large-scale fine-grained locks be supported, but also fast processing of applications with high offset (such as workloads) or hot spot locks (frequent requests) can be supported, and the lock request passing through the network hardware is directly processed by fast decision, so that the authorized lock request can be returned to the application thread after reaching the accompanying network, and the network path length is greatly shortened, which can greatly reduce the delay of lock authorization and improve the efficiency of lock processing.

[0147] After the lock operation on the user thread h is implemented through the above steps S910 to S980, next, in conjunction with the attached Fig. 9 The process of releasing the lock of user thread h is introduced.

[0148] Please refer to Fig.11 As shown, the distributed lock management method may also include:

[0149] S1110: The application thread on the first node device generates a corresponding lock release request according to the acquired lock.

[0150] In this embodiment, when the user thread h ends resource access, it can call the lock operation API 21 (lock release API), determine the lock to be released, and then generate a lock release request. As a specific example, the lock release request can include the ID of the target lock requested to be released, the machine ID, and the thread ID.

[0151] The request module 2 of the server 12 may execute S1111 to encapsulate the lock release request into a network packet, the target address of the network packet being the address of the lock management server 100, and then send the network packet out.

[0152] S1120: The network hardware receives the lock release request and forwards the lock release request to the lock management server.

[0153] In this embodiment, when the network packet of the lock release request passes through the network hardware 300 , the network hardware may not process the network packet and directly forward it to the lock management server 100 .

[0154] S1130: The lock management server updates metadata according to the lock release request. The lock metadata includes a lock holder set or a waiting queue.

[0155] In this embodiment, after the lock management server 100 receives the network packet of the lock release request, the lock metadata maintenance module can remove the requester from the lock holder set according to the lock ID, machine ID and thread ID parsed from the lock release request.

[0156] In addition, illustratively, after removing the requester of the lock release request from the lock holder set, the lock metadata maintenance module may further determine whether the lock holder set and the waiting queue are empty. If the lock holder set is not empty, the lock release operation ends; if the lock holder set is empty and the waiting queue is empty, the lock management server 100 may further execute:

[0157] S1131, generating idle prompt information of the target lock, and sending it to the network hardware, so that the network hardware updates the lock state information. The idle prompt information is used to indicate that the lock holder information of the target lock is empty or the waiting queue is empty.

[0158] In this example, if the lock holder set is empty and the waiting queue is empty, the lock management server 100 may send an idle prompt message (in the form of a network packet) to the network hardware 300 through the lock metadata maintenance module 140 .

[0159] Next, after receiving the idle prompt information, the lock decision module 340 on the network hardware 300 executes step S1132 to change the corresponding lock state to idle, and the current lock release operation ends.

[0160] Exemplarily, after removing the requester of the lock release request from the lock holder set, the lock management server 100 may further execute:

[0161] S1133, read the lock request in the waiting queue;

[0162] S1134: Update the lock holder set according to the lock acquisition request in the waiting queue, and generate corresponding return information to send to the first node device.

[0163] In this example, when the lock holder set is empty, the lock metadata maintenance module 140 can take out the next batch of lock requests to be authorized (one exclusive mode request or multiple shared mode requests) from the waiting queue, add the requesters of these lock requests to the lock holder set, and generate corresponding return information to return to each requester, and the lock release operation ends.

[0164] In some possible implementations, since a machine is often multi-threaded and parallel when receiving network packets, the network packets received in a certain period will be reordered before being processed, which may cause the network packets that arrive first to be processed later. Therefore, under this mechanism, the lock management server 100 may have the same requester's lock request and lock release request for the same lock to be reordered, which may then cause the lock release to fail. For example, a lock request X01 is authorized by decision on the network hardware and forwarded to the lock management server 100 for metadata update. At the same time, the requester who initiated the lock request X01 may have accessed the data with the lock and initiated a lock release request X21 to the lock management server 100. In this way, after the network packets are reordered on the lock management server 100, the lock release request X21 is processed before the lock request X01. The lock metadata on the lock management server 100 is not updated in time, which is inconsistent with the lock status on the network hardware, and the lock release fails.

[0165] In view of this, in order to improve the reliability of distributed lock management and prevent the state inconsistency between the lock decision module and the lock metadata maintenance module in the distributed system, such as Fig.12 As shown, the method may further include:

[0166] S1210: When the lock management server determines, based on the lock release request, that the application thread is not authorized to hold the lock, the lock release request is cached, wherein the lock release request includes a first identifier of the application thread.

[0167] In this embodiment, after receiving the network packet of the lock release request, the lock metadata maintenance module 140 on the lock management server 100 can determine whether the requester of the lock release request is the lock holder through the application thread ID (i.e., the first identifier) ​​in the request, and if so, execute the normal lock release process. If the requester is not in the lock holder set, execute S1210 to cache the lock release request locally.

[0168] S1220, receiving a first lock acquisition request, the first lock acquisition request including a second identifier, the second identifier being an identifier of an application thread initiating the first lock acquisition request, and comparing the second identifier with the first identifier of the cached lock release request;

[0169] S1230: If the second identifier is the same as the first identifier, the first lock-taking request and the lock-releasing request are deleted.

[0170] In this embodiment, after caching the lock release request, when the lock management server 100 subsequently receives a lock acquisition request (i.e., the first lock acquisition request) for processing, the lock metadata maintenance module 140 can check the local cache and compare the cached machine ID, thread ID and other requestor information (first identifier) ​​of each lock release request with the machine ID, thread ID and other information (i.e., the second identifier) ​​of the received lock acquisition request to determine the consistency. If the comparison is inconsistent, the lock metadata maintenance module 140 can process the lock acquisition request normally through S1221.

[0171] If the comparison is consistent, the lock metadata maintenance module 140 deletes the lock request with consistent requester information and the lock release request in the cache through step S1230, updates the lock metadata (such as updating the waiting queue, etc.), and enters the corresponding lock release process, such as the above-mentioned process S1131 to S1134, which will not be repeated here.

[0172] In some possible implementations, since lock decision and lock metadata maintenance are completed concurrently on different network entities, before the authorized lock request forwarded by the network hardware reaches the lock management server 100, the shared lock corresponding to the lock request may have been released or scheduled, resulting in the lock status on the network hardware being incorrectly updated. For example, the network hardware authorizes a lock request X02 to take a shared lock, and forwards the lock request X02 to the lock management server 100. At the same time, on the lock management server 100, the lock metadata maintenance block has released the shared lock according to a lock release request X21 before receiving the lock request X02, and even performs lock scheduling to transfer the lock holder to the next exclusive lock holder in the waiting queue. In this way, the network hardware will receive the relevant information sent by the lock management server 100, thereby incorrectly updating the lock status.

[0173] In this regard, in order to ensure the reliability of lock management, Fig.13 As shown, the method may further include:

[0174] S1310: When the network hardware or the lock management server receives a lock acquisition request in a shared mode, a request count of a target lock is generated.

[0175] In this embodiment, the network hardware 300 and the lock management server 100 both maintain a request count for each lock. When receiving a lock acquisition request for a shared lock, the network hardware and the lock management server 100 respectively increase the request count they maintain by one.

[0176] S1320, when the lock management server sends idle prompt information or return information of the corresponding lock, it adds the request count of the lock and encapsulates it into a network packet.

[0177] In this embodiment, when the lock management server 100 sends idle prompt information or return information corresponding to a certain lock to the network hardware 300, the lock management server 100 adds the request count of the lock (ie, the second request count) and encapsulates the information into a network packet for sending.

[0178] S1330, the network hardware compares the request count in the obtained network packet with the request count of the target lock recorded internally, and abandons updating the status information of the target lock if the two request counts are inconsistent.

[0179] In this embodiment, after the lock decision module 340 of the network hardware 300 receives the network packet of idle prompt information or return information, it parses the second request count in the packet and compares it with the request count of the target lock maintained internally (i.e., the first request count). If the comparison is consistent, the verification is passed and the normal processing flow is carried out. If the comparison is inconsistent, no state of the lock is modified, and if the current network packet is idle prompt information, the packet is discarded, and if the current packet is return information, it is returned to the lock metadata maintenance module 140 of the lock management server 100. In this way, after the lock metadata maintenance module 140 receives the network packet of return information, it can reinsert the authorized requester into the head of the waiting queue and wait for the next re-authorization to take the lock.

[0180] In this way, by utilizing mechanisms such as request counting and request caching, the consistency of the states between the lock decision module and the lock metadata maintenance module located on different network entities is ensured, thus avoiding errors in the global state of the system due to network anomalies.

[0181] The following are test results obtained after performing management comparison tests on several applications using the distributed lock management method in the above-mentioned embodiment of the present application.

[0182] Test 1

[0183] Take a key-value store that stores one million key-value pairs as an application (each key-value pair is protected by a lock). When the application accesses data (a key-value pair), it corresponds to a relatively simple lock request processing process. In this regard, the open source cloud service benchmark (Yahoo! cloud serving benchmark, YCSB) tool is used to evaluate the latency and throughput of the distributed lock management method in the above embodiment of the present application to achieve lock processing, and compare it with the processing effect of related technologies.

[0184] In the test, a programmable switch is used as network hardware, and network communication is performed based on a data plane development kit (DPDK) and a 10 Gigabit network card (transmission rate of up to 200 Gb / s). The steps of the distributed lock management method in the above embodiment of the present application are performed, which can significantly reduce the key-value pair read / write delay in the key-value storage scenario.

[0185] Fig.14 (14a) shows the lock authorization delay distribution (cumulative distribution function, CDF) and throughput formed by using the method of the above embodiment of the present application to process lock requests (denoted as PSLock), and the related technologies of using a centralized lock manager (SrvLock), using ParLock, and using NetLock.

[0186] By comparison, we can see the performance difference under different workloads of YCSB (A represents half reading and half writing, B represents 90% reading, and C represents reading only without writing). Regardless of whether it is under uniform distribution (Uni.) or offset distribution (Zipf.), the use of related technologies for lock processing is obviously affected by the queuing delay, and the lock acquisition delay varies greatly, with the tail delay reaching more than 100 microseconds. However, by using the method of the embodiment of the present application, the lock acquisition delay is controlled within 10 microseconds under each workload, demonstrating very high stability and performance. The results of the test evaluation can be referred to. Fig.14 As shown in (14b), under a uniformly distributed workload, the method of the embodiment of the present application can increase the throughput of lock requests by about 4 to 6 times; under an offset distribution, since the exclusive locks required for write operations will compete with each other, the waiting time for locks becomes a bottleneck for throughput. The throughput improvement effect of lock processing achieved by the method of the embodiment of the present application will decrease as the write ratio increases, and the overall positive acceleration effect will be maintained.

[0187] Test 2

[0188] Taking distributed transaction processing as an application, the open source telecommunication application transaction processing benchmark (TATP) tool and the transaction processing performance council benchmark C (TPC-C) tool are used to evaluate the impact of the distributed lock management method in the embodiment of the present application on transaction processing delay and throughput, and compared with related technologies. Among them, the hardware environment used when the method in the embodiment of the present application is executed is the same as that in test one. The transactions in TATP are mainly read operations, and the accessed data is relatively small, and most transactions only need to take one or two locks; the transactions in TPC-C are mainly write operations, and the transaction processing logic is more complex, and some transactions need to take more than a dozen locks. Since the transactions in the TPC-C benchmark test have a high spatial locality (i.e., they mainly access local data), the data distribution of TPC-C is optimized during the implementation of the method in the embodiment of the present application, and the optimized version is marked as PSLock-Local.

[0189] The test comparison results can be found in Fig.15 As shown, after testing, when executing transactions in the TATP benchmark test, since the method in the embodiment of the present application can obtain locks faster, the delay in transaction execution is significantly lower than the related art, and the throughput is improved by about 1.76 to 2.93 times compared with the related art. When executing transactions in the TPC-C benchmark test, due to the large number of locks obtained in each transaction, the queuing delay problem processed by SrvLock and NetLoc is further amplified, and a considerable number of transactions have millisecond-level execution delays, while the delay of PSLock (the method in the embodiment of the present application) in executing most transactions is stable within one hundred microseconds, thus achieving a throughput more than twice that of the related art. PSLock-Local has higher remote lock performance while having the same local processing performance, so the total throughput is improved by about 1.08 times compared with the ParLock method.

[0190] Test Three

[0191] A workload in which a data hotspot changes periodically over time is used to evaluate the extent to which the performance is affected by the workload pattern when the method in the embodiment of the present application is implemented, and compared with related technologies. The hardware environment used when implementing the method in this embodiment is the same as that in Test 1. The workload used in this test contains one million locks, of which 2,600 are hotspot locks. The targets of 60% of the lock requests in the workload are randomly selected from the hotspot locks, and the targets of the remaining lock requests are randomly selected from other locks. Every 300 milliseconds, the hotspot lock will be randomly reselected from all locks.

[0192] The comparison results can be found in Fig.16 The figure shows a curve of lock-taking throughput versus test time when the lock-taking process is performed using the method of the above embodiment of the present application and compared with the NetLock method, with the benchmark being a curve formed by the lock-taking process using the SrvLock method.

[0193] The throughput changes of the method and NetLock method of the embodiment of the present application under the workload of hotspot changes. In the initial state, 2600 hotspot locks are managed on the switch in the NetLock method, and the rest are managed by the server, so the throughput is slightly higher than the baseline curve. However, after the hotspot of the workload changes, the proportion of lock requests processed by the switch in the NetLock method drops rapidly from about 60% to less than 1%, so the processing performance in the NetLock method returns to the baseline performance. On the contrary, because the method of the embodiment of the present application can accelerate the request processing of all locks with a programmable switch, its throughput remains at a high level before and after the hotspot changes.

[0194] Combining the above three test examples, it can be concluded that the method of the embodiment of the present application has a high lock processing performance in simple, complex or highly offset applications, as well as hot spot locks.

[0195] The method of the embodiment of the present application can be applied to distributed lock management in data centers, and other types of distributed systems that require distributed locks to protect concurrent access to shared data, such as distributed transaction processing, distributed file systems, distributed databases, etc. In addition, the method based on the distributed lock and the embodiment of the present application can also be used to guide data synchronization in a distributed system, such as distributed shared memory that implements relaxed consistency.

[0196] Based on the method in the above embodiment, the embodiment of the present application provides a distributed lock management device 700. The device 1700 can be applied to network hardware. The network hardware can be deployed between at least one node device and a lock management server. The lock management server is used to maintain the metadata of the lock. Fig.17As shown, the device 700 may include a receiving module 710 and a lock decision module 340. The receiving module 710 may be used to receive a lock acquisition request sent by a node device. The lock acquisition request is initiated by an application thread on a first node device, and the first node device is one of at least one node device. The lock decision module 340 may be used to make a corresponding lock authorization decision based on the lock acquisition request; the lock decision module 340 may also be used to generate corresponding authorization information and send it to the first node device when deciding to authorize the application thread to acquire the lock. The lock decision module 340 may also be used to forward the lock acquisition request to the lock management server when deciding not to authorize the application thread to acquire the lock, so as to process the lock acquisition request on the lock management server.

[0197] In some possible implementations, metadata of multiple locks are maintained on the lock management server. The lock acquisition request is initiated by the application thread to the lock management server. The lock acquisition request includes lock information of the target lock, and the target lock is one of the multiple locks. The lock decision module 340 can also be used to forward the authorized lock acquisition request to the lock management server so that the lock management server updates the metadata of the target lock according to the lock information, wherein the metadata of the target lock includes at least lock holder information and a waiting queue.

[0198] In some possible implementations, the network hardware stores lock status information of multiple locks, and the lock acquisition request includes the lock information and lock acquisition mode of the target lock, the target lock is one of the multiple locks, and the lock acquisition mode includes a shared mode or an exclusive mode; the lock decision module 340 can be specifically used to query the lock status information of the target lock according to the lock information in the lock acquisition request; when the queried lock status information and the lock acquisition mode in the lock acquisition request meet the lock acquisition conditions, the application thread is authorized to acquire the target lock.

[0199] In some possible implementations, the network hardware stores lock status information, and the receiving module 710 can also be used to obtain return information from the lock management server, the return information is used to indicate that the application thread is authorized to take the target lock; and based on the return information, update the lock status information of the target lock; and forward the return information to the first node device.

[0200] In some possible implementations, the receiving module 710 may also be used to receive a lock release request, and the lock decision module 340 may also be used to send the lock release request to the lock management device, so that the lock management server processes the lock release request.

[0201] In some possible implementations, the network hardware stores lock status information, and the receiving module 710 can also be used to obtain idle prompt information from the lock management server, where the idle prompt information is used to indicate that the lock holder information of the corresponding lock is empty or the waiting queue is empty; the lock decision module 340 can also be used to update the corresponding lock status information based on the idle prompt information.

[0202] In some possible implementations, the lock decision module 340 may also be used to generate a request count for the corresponding lock when the lock acquisition mode in the lock acquisition request is a shared mode. The receiving module 710 may also be used to receive a network packet sent by the lock management server, the network packet including the request count for the corresponding lock, and idle prompt information or return information. The lock decision module 340 may also be used to compare the request count in the network packet with the request count for the corresponding lock recorded internally; if the two request counts are inconsistent, the update of the status information of the corresponding lock is abandoned.

[0203] It should be understood that the above-mentioned device 700 is used to execute the steps performed on the network hardware 300 side in the method of the above-mentioned embodiment. The implementation principle and technical effects of the corresponding program modules in the device 700 are similar to those described in the above-mentioned method. The working process of the device can refer to the corresponding process in the above-mentioned method, which will not be repeated here.

[0204] Based on the method in the above embodiment, the embodiment of the present application provides a distributed lock management device 800, which can be applied to a lock management server that stores lock metadata. Fig.18 As shown, the device 800 may include a receiving module 810 and a lock metadata maintenance module 140. The receiving module 810 may be used to receive a lock request forwarded by network hardware, the network hardware being deployed between at least one node device and the lock management server, the lock request being initiated by an application thread on a first node device, and the first node device being one of the at least one node devices. The lock metadata maintenance module 140 may be used to update metadata when the lock request is a lock acquisition request and the network hardware authorizes the application thread to acquire the lock based on the lock acquisition request decision. The lock metadata maintenance module 140 may also be used to authorize the lock acquisition request based on metadata when the lock request is a lock acquisition request and the network hardware decides not to authorize the application thread to acquire the lock based on the lock acquisition request decision.

[0205] In some possible implementations, the metadata includes lock holder information; the lock metadata maintenance module 140 can be specifically used for: when the lock request is a lock acquisition request, and the network hardware authorizes the application thread to acquire the lock based on the lock acquisition request decision, the application thread is used as the lock holder and the corresponding lock holder information is updated.

[0206] In some possible implementations, the metadata includes a waiting queue; the lock metadata maintenance module 140 can be specifically used for: when the lock request is a lock acquisition request, and the network hardware does not authorize the application thread to acquire the lock based on the lock acquisition request decision, the lock acquisition request is placed in the waiting queue to wait for authorization processing.

[0207] In some possible implementations, the receiving module 810 can also be used to receive a release request, and the lock metadata maintenance module 140 can also be used to: update the lock holder information of the target lock according to the release request; or, perform corresponding authorization processing on the lock acquisition request in the waiting queue according to the release request, and generate corresponding return information, and the return information is used to represent that the application thread corresponding to the lock acquisition request is authorized to acquire the target lock.

[0208] In some possible implementations, the lock metadata maintenance module 140 can also be used to: generate idle prompt information, the idle prompt information is used to indicate that the lock holder information of the corresponding lock is empty or the waiting queue is empty; and send the idle prompt information to the network hardware so that the network hardware updates the corresponding lock status information.

[0209] In some possible implementations, the lock metadata maintenance module 140 can also be used to: generate a request count for the corresponding lock when the lock acquisition mode in the lock acquisition request is a shared mode; then send a network packet to the network hardware, the network packet including the request count for the corresponding lock, and idle prompt information or return information, so that the network hardware compares the request count with the request count for the corresponding lock recorded inside the network hardware to determine whether to update the status information of the corresponding lock.

[0210] In some possible implementations, the lock metadata maintenance module 140 can also be used to: cache the lock release request when it is determined that the corresponding application thread is not authorized to take the lock based on the lock release request, the lock release request is initiated by the application thread, and the lock release request includes the first identifier of the application thread. In addition, the receiving module 810 can also be used to receive a first lock acquisition request, the first lock acquisition request includes a second identifier, the second identifier is the identifier of the application thread that initiated the first lock acquisition request, and the lock metadata maintenance module 140 can also be used to compare the second identifier with the first identifier of the cached lock release request; if the second identifier is the same as the first identifier, the first lock acquisition request and the lock release request are deleted.

[0211] It should be understood that the above-mentioned device 800 is used to execute the steps performed on the lock management server 100 side in the method of the above-mentioned embodiment. The implementation principle and technical effect of the corresponding program module in the device 800 are similar to those described in the above-mentioned method. The working process of the device can refer to the corresponding process in the above-mentioned method, which will not be repeated here.

[0212] Based on the method in the above embodiment, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method in the above embodiment.

[0213] Based on the method in the above embodiment, an embodiment of the present application provides a computer program product, characterized in that when the computer program product runs on a processor, the processor executes the method in the above embodiment.

[0214] Based on the method in the above embodiment, the present application embodiment also provides a chip. Fig.19 , Fig.19 This is a schematic diagram of the structure of a chip provided in an embodiment of the present application. Fig.19 As shown, the chip 900 includes one or more processors 901 and an interface circuit 902. Optionally, the chip 900 may also include a bus 903. Among them:

[0215] Processor 901 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in processor 901 or an instruction in software form. The above processor 901 can be a general-purpose processor, a digital communicator (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component. The disclosed methods and steps in the embodiments of the present application can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc.

[0216] The interface circuit 902 can be used to send or receive data, instructions or information. The processor 901 can use the data, instructions or other information received by the interface circuit 902 to process, and can send the processing completion information through the interface circuit 902.

[0217] Optionally, the chip 900 further includes a memory, which may include a read-only memory and a random access memory, and provides operation instructions and data to the processor. A portion of the memory may also include a non-volatile random access memory (NVRAM).

[0218] Optionally, the memory stores executable software modules or data structures, and the processor can perform corresponding operations by calling operation instructions stored in the memory (the operation instructions can be stored in the operating system).

[0219] Optionally, the interface circuit 902 may be used to output the execution result of the processor 901 .

[0220] It should be noted that the functions corresponding to the processor 901 and the interface circuit 902 can be implemented through hardware design, software design, or a combination of hardware and software, which is not limited here.

[0221] It should be understood that each step of the above method embodiment can be completed by a hardware-based logic circuit or a software-based instruction in a processor.

[0222] It is understandable that the size of the sequence number of each step in the above embodiment does not mean the order of execution, and the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application. In addition, in some possible implementations, each step in the above embodiment can be selectively executed according to actual conditions, and can be partially executed or fully executed, which is not limited here.

[0223] It is understood that the processor in the embodiments of the present application may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0224] The method steps in the embodiments of the present application can be implemented by hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, and the software modules can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an ASIC.

[0225] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions may be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state disk (SSD)), etc.

[0226] It should be understood that the various numerical numbers involved in the embodiments of the present application are only used for the convenience of description and are not used to limit the scope of the embodiments of the present application.

Claims

1. A distributed lock management method, characterized in that: The method is applied to network hardware, the network hardware is deployed between at least one node device and a lock management server, the lock management server is used to maintain metadata of the lock, and the method includes: receiving a lock request sent by a first node device, where the lock request is initiated by an application thread on the first node device, and the first node device is one of the at least one node device; According to the lock acquisition request, a lock authorization decision is made, wherein the lock authorization decision is used to decide whether to authorize the application thread to acquire the lock; In the case of deciding to authorize the application thread to take the lock, generating authorization information and sending it to the first node device; In the case where it is determined that the application thread is not authorized to acquire the lock, the lock acquisition request is forwarded to the lock management server so that the lock acquisition request is processed on the lock management server.

2. The method according to claim 1, characterized in that The lock management server maintains metadata of multiple locks, the lock acquisition request is initiated by the application thread to the lock management server, and the lock acquisition request includes lock information of a target lock, and the target lock is one of the multiple locks; In the case where the decision is made to authorize the application thread to take the lock, generating authorization information and sending it to the first node device also includes: forwarding the authorized lock acquisition request to the lock management server so that the lock management server updates the metadata of the target lock according to the lock information, The metadata of the target lock includes at least lock holder information and a waiting queue.

3. The method according to claim 1 or 2, characterized in that: The network hardware stores lock status information of multiple locks, the lock acquisition request includes lock information of a target lock and a lock acquisition mode, the target lock is one of the multiple locks, and the lock acquisition mode includes a shared mode or an exclusive mode; The making of a corresponding lock authorization decision according to the lock taking request specifically includes: According to the lock information in the lock acquisition request, query the lock status information of the target lock; When the queried lock status information and the lock acquisition mode in the lock acquisition request meet the lock acquisition condition, the application thread is authorized to acquire the target lock.

4. The method according to any one of claims 1 to 3, characterized in that: The lock management server maintains metadata of multiple locks, the network hardware stores lock status information of the multiple locks, the lock request includes lock information of a target lock, and the target lock is one of the multiple locks. After forwarding the lock-taking request to the lock management server so as to process the lock-taking request on the lock management server, the method includes: Acquire return information from the lock management server, where the return information is used to indicate that the application thread is authorized to acquire the target lock; According to the returned information, the lock status information of the target lock is updated; The returned information is forwarded to the first node device.

5. The method according to any one of claims 1 to 4, characterized in that: The method further comprises: receiving a lock release request sent by the first node device, where the lock release request is initiated by the application thread; The lock release request is sent to the lock management device so that the lock management server processes the lock release request.

6. The method according to claim 5, characterized in that The network hardware stores lock status information of a plurality of locks, and the method further comprises: Acquire idle prompt information of the lock management server, where the idle prompt information is used to indicate that the lock holder information of the target lock is empty or the waiting queue is empty, and the target lock is one of the multiple locks; According to the idle prompt information, the lock state information of the target lock is updated.

7. The method according to any one of claims 1 to 6, characterized in that: The lock management server maintains metadata of multiple locks, the network hardware stores lock status information of the multiple locks, the lock acquisition request includes lock information and a lock acquisition mode of a target lock, the target lock is one of the multiple locks, and the lock acquisition mode includes a shared mode or an exclusive mode. The method further comprises: When the lock acquisition mode in the lock acquisition request is a shared mode, generating a first request count for the target lock; Receive a network packet sent by the lock management server, wherein the network packet includes a second request count of the target lock recorded on the lock management server, and idle prompt information or return information, wherein the idle prompt information is used to indicate that the lock holder information of the target lock is empty or the waiting queue is empty, and the return information is used to indicate that the application thread is authorized to take the target lock; comparing the second request count with the first request count; When the second request count is inconsistent with the first request count, updating the lock state information of the target lock is abandoned.

8. A distributed lock management method, characterized in that: The method is applied to a lock management server, and the lock management server is used to maintain metadata of the lock. The method includes: receiving a lock-taking request forwarded by network hardware, the network hardware being deployed between at least one node device and the lock management server, the lock-taking request being initiated by an application thread on a first node device, the first node device being one of the at least one node device; When the network hardware authorizes the application thread to acquire the lock according to the lock acquisition request, updating the metadata; In the case that the network hardware does not authorize the application thread to acquire the lock according to the lock acquisition request decision, the lock acquisition request is authorized according to the metadata.

9. The method according to claim 8, characterized in that The lock management server maintains metadata of multiple locks, the metadata includes lock holder information, the lock request includes lock information of a target lock, and the target lock is one of the multiple locks; When the network hardware decides to authorize the application thread to acquire the lock according to the lock acquisition request, updating the metadata includes: When the network hardware decides to authorize the application thread to acquire the lock according to the lock acquisition request, the application thread is used as the lock holder, and the lock holder information of the target lock is updated.

10. The method according to claim 8 or 9, characterized in that: The lock management server maintains metadata of multiple locks, the metadata includes a waiting queue, the lock request includes lock information of a target lock, and the target lock is one of the multiple locks; When the network hardware does not authorize the application thread to acquire the lock according to the lock acquisition request decision, authorization processing is performed on the lock acquisition request according to the metadata, including: In the case that the network hardware does not authorize the application thread to acquire the lock according to the lock acquisition request decision, the lock acquisition request is added to the waiting queue of the target lock to wait for authorization processing.

11. The method according to any one of claims 8 to 10, characterized in that: The lock management server maintains metadata of multiple locks, wherein the metadata includes lock holder information and a waiting queue; The method further comprises: receiving a lock release request forwarded by network hardware, wherein the lock release request includes lock information of a target lock, and the target lock is one of the multiple locks; According to the lock release request, updating the lock holder information of the target lock; Alternatively, according to the lock release request, authorization processing is performed on the lock acquisition request in the waiting queue of the target lock, and return information is generated, where the return information is used to indicate that the application thread is authorized to acquire the target lock.

12. The method according to any one of claims 8 to 11, characterized in that: The lock management server maintains metadata of multiple locks, and the network hardware stores lock status information of the multiple locks. The method further comprises: Generate idle prompt information, where the idle prompt information is used to indicate that the lock holder information of the target lock is empty or the waiting queue is empty, and the target lock is one of the multiple locks; The idle prompt information is sent to the network hardware, so that the network hardware updates the lock state information of the target lock.

13. The method according to any one of claims 8 to 12, characterized in that: The lock management server maintains metadata of multiple locks, the network hardware stores lock status information of the multiple locks, the lock acquisition request includes lock information and a lock acquisition mode of a target lock, the target lock is one of the multiple locks, and the lock acquisition mode includes a shared mode or an exclusive mode. The method further comprises: When the lock acquisition mode in the lock acquisition request is a shared mode, generating a second request count for the target lock; Sending a network packet to the network hardware, wherein the network packet includes the second request count and idle prompt information or return information, so that the network hardware compares the second request count with the first request count of the target lock recorded on the network hardware to determine whether to update the state information of the target lock; The idle prompt information is used to indicate that the lock holder information of the target lock is empty or the waiting queue is empty, and the return information is used to indicate that the application thread is authorized to take the target lock.

14. The method according to any one of claims 8 to 13, characterized in that: The method further comprises: receiving a lock release request sent by the first node device, where the lock release request is initiated by the application thread and includes a first identifier of the application thread; When it is determined according to the lock release request that the application thread is not authorized to acquire the lock, caching the lock release request; receiving a first lock-releasing request, wherein the first lock-releasing request includes a second identifier, and the second identifier is an identifier of an application thread that initiates the first lock-releasing request; Compare the second identifier with the first identifier of the cached lock release request; If the second identifier is the same as the first identifier, the first lock-taking request and the lock-releasing request are deleted.

15. A distributed lock management device, characterized in that: The device is applied to network hardware, the network hardware is deployed between at least one node device and a lock management server, the lock management server is used to maintain metadata of the lock, and the device includes: A receiving module, configured to receive a lock-releasing request sent by a first node device, wherein the lock-releasing request is initiated by an application thread on the first node device, and the first node device is one of the at least one node device; A lock decision module, used for making a lock authorization decision according to the lock acquisition request, wherein the lock authorization decision is used for deciding whether to authorize the application thread to acquire the lock; The lock decision module is further configured to generate authorization information and send it to the first node device when deciding to authorize the application thread to take the lock; The lock decision module is further configured to forward the lock acquisition request to the lock management server when it is decided that the application thread is not authorized to acquire the lock, so that the lock acquisition request is processed on the lock management server.

16. A distributed lock management device, characterized in that: The device is applied to a lock management server, and the lock management server stores lock metadata. The device includes: A receiving module, configured to receive a lock-taking request forwarded by network hardware, wherein the network hardware is deployed between at least one node device and the lock management server, wherein the lock-taking request is initiated by an application thread on a first node device, and the first node device is one of the at least one node device; A lock metadata maintenance module, configured to update the metadata when the network hardware authorizes the application thread to acquire the lock according to the lock acquisition request decision; The lock metadata maintenance module is also used to authorize the lock request according to the metadata when the network hardware decides not to authorize the application thread to acquire the lock according to the lock acquisition request.

17. A network hardware, characterized in that: include: at least one memory for storing a program; at least one processor, configured to execute the program stored in the memory; Wherein, when the program stored in the memory is executed, the processor is used to execute the method according to any one of claims 1-7.

18. A server, characterized in that: include: at least one memory for storing a program; at least one processor, configured to execute the program stored in the memory; Wherein, when the program stored in the memory is executed, the processor is used to execute the method according to any one of claims 8-14.

19. A computer-readable storage medium storing a computer program, wherein when the computer program is executed on a processor, the processor is caused to execute the method according to any one of claims 1 to 7, or execute the method according to any one of claims 8 to 14.

Images