Lock request processing method, device and equipment

Abstract

The embodiment of the invention provides a lock request processing method, device and equipment. The method comprises the following steps: receiving a first lock request sent by a client; the first lock request is used for requesting to obtain a lock permission of the target file; the first lock request is used for indicating a first network address of the client, a second network address of the server and a check code of the first lock request; generating an identifier of the first lock request according to the first network address and the second network address; processing the first lock request according to the check code of the first lock request and the identifier of the first lock request, and determining a processing result of the first lock request; the processing result is processing success or processing failure; and sending the processing result to the client. The problem that lock residues exist in the processing process of the file lock request is solved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus and device for processing lock requests. Background Technology

[0002] In distributed file systems, the Network File System (NFS) provides file locks, a core mechanism for managing file access permissions. File locks prevent multiple processes or clients from simultaneously performing conflicting operations on the same file by imposing access restrictions on files or specific regions within a file. In some scenarios, NFS needs to handle file lock requests sent by clients.

[0003] In related technologies, NFS relies on a Network Lock Manager (NLM) and the Remote Procedure Call (RPC) protocol to handle file lock requests. Specifically, after a client initiates a file lock request, the request is encapsulated via the RPC protocol and transmitted to the processing node providing the NFS service. The NLM service on the processing node allocates a local memory structure for the client and identifies the lock requester using the address value of the memory structure. Based on the corresponding file lock data structure in the kernel, it completes the registration, verification, and final processing of the file lock. However, the above-described process for handling file lock requests suffers from lock remnants. Summary of the Invention

[0004] This application provides a method, apparatus, and device for processing lock requests, which solves the problem of lock residue in the process of processing file lock requests.

[0005] In a first aspect, embodiments of this application provide a method for processing lock requests, applied to a server, including:

[0006] Receive the first lock request sent by the client; the first lock request is used to request lock permissions for the target file; the first lock request is used to indicate the client's first network address, the server's second network address, and the checksum of the first lock request;

[0007] Generate an identifier for the first lock request based on the first network address and the second network address;

[0008] Based on the checksum and identifier of the first lock request, the first lock request is processed to determine the processing result; the processing result is either successful or unsuccessful.

[0009] Send the processing result to the client.

[0010] This application embodiment generates a unique lock request identifier by combining the client's first network address and the server's second network address. At the same time, it accurately identifies the initial and retransmission types of the lock request by relying on the check code. This not only avoids the masterless lock residue caused by RPC retries, but also realizes a globally unified identifier for the client's lock request identity, thereby solving the lock residue problem caused by non-unique identity identifiers and repeated processing of retransmission requests in traditional solutions.

[0011] In one possible implementation, the first lock request is processed based on its checksum and identifier to determine the processing result, including:

[0012] Obtain the checksum and identifier of each of the at least one second lock request; the at least one second lock request includes lock requests processed by the server before the current time.

[0013] Based on the checksums of at least one second lock request and the checksum of the first lock request, determine the type of the first lock request; the type is either initial transmission type or retransmission type.

[0014] In the case of the initial transmission type, the first lock request is processed according to the identifier of the first lock request and the identifier of at least one second lock request, and the processing result is determined.

[0015] This application embodiment identifies the initial and retransmission types of lock requests through a verification code, which can filter duplicate requests for RPC timeout retransmission and avoid the masterless lock residue caused by repeated processing of retransmission lock requests in traditional solutions. At the same time, it verifies the lock permission association based on the lock request identifier to prevent cross-node lock residue caused by non-unique identifiers of the same client. It effectively solves the lock residue problem from both request identification and permission verification aspects, and ensures the accuracy of file lock management.

[0016] In one possible implementation, the first lock request is processed based on the identifier of the first lock request and the respective identifiers of at least one second lock request, and the processing result is determined, including:

[0017] Based on the identifier of the first lock request and the identifiers of at least one second lock request, determine whether there is a target lock request among the at least one second lock request, wherein the identifier of the target lock request is the same as the identifier of the first lock request;

[0018] If no target lock request exists in at least one second lock request, the processing result is determined based on the identifier of the first lock request and the lock permissions of the target file.

[0019] If a target lock request exists in at least one second lock request, the processing result is determined based on the operation type of the first lock request and the operation type of the target lock request.

[0020] This application embodiment can identify historical lock requests from the same client by verifying the uniqueness of the lock request identifier. When there are no requests with the same identifier, a standardized lock permission association is established. When there are requests with the same identifier, permission compatibility is determined based on the operation type. This avoids redundant lock residue caused by repeatedly establishing lock associations and prevents invalid lock residue caused by conflicts in the operation type of the same client. It standardizes the lock request processing flow from the source of lock permission association and solves the lock residue problem.

[0021] In one possible implementation, determining the type of the first lock request based on the checksums of at least one second lock request and the checksum of the first lock request includes:

[0022] Perform a first operation, which includes: determining whether the checksum of the i-th second lock request is the same as the checksum of the first lock request; if the checksum of the i-th second lock request is the same as the checksum of the first lock request, determining that the type of the first lock request is a retransmission type.

[0023] If the checksum of the i-th second lock request is different from the checksum of the first lock request, update i to i+1, repeat the first operation until i is greater than or equal to N, and determine that the type of the first lock request is the initial transmission type.

[0024] Where i is a positive integer, and N is the number of at least one second lock request.

[0025] This application embodiment accurately determines the initial or retransmission type of the current lock request by verifying the checksum of each historical lock request. It can identify and filter duplicate lock requests that are retransmitted due to RPC timeout, thus avoiding the generation of redundant lock records due to repeated processing of the same lock request.

[0026] In one possible implementation, generating an identifier for the first lock request based on a first network address and a second network address includes:

[0027] Determine the address type of the first network address and the address type of the second network address; the address type can be a 32-bit address type or a 128-bit address type.

[0028] Based on the address type of the first network address, a first target address is determined from the first network address, and the first target address is used to uniquely indicate the client;

[0029] Based on the address type of the second network address, the second target address is determined from the second network address. The second target address is used to uniquely indicate the server.

[0030] The first target address and the second target address are processed to generate an identifier for the first lock request.

[0031] This application embodiment generates a lock request identifier by distinguishing network address types and extracting a target address of fixed length, thereby achieving a globally unique and stable identifier for the client's lock request identity. This avoids the problem of identifier failure due to node failure or VIP drift caused by relying on memory address identifiers, enabling the server to accurately associate the client's lock permission information, facilitating the cleanup of residual locks by faulty nodes and the synchronization of lock status by healthy nodes.

[0032] In one possible implementation, determining the first target address from the first network address based on the address type of the first network address includes:

[0033] If the address type of the first network address is a 32-bit address type, the first network address is determined as the first destination address;

[0034] If the address type of the first network address is a 128-bit address type, the address used to indicate the client in the first network address is determined as the first target address.

[0035] This application embodiment establishes a unified target address extraction rule for different types of network addresses, including 32-bit and 128-bit addresses, ensuring the uniqueness and consistency of client identity identifiers under different network environments. This avoids the problem of lock request identifier confusion caused by address format differences, enabling the server to accurately match the client's lock permission records.

[0036] In one possible implementation, the server includes multiple processing nodes, and the method further includes:

[0037] Determine the node state of the first node to process the first lock request; the node state of the first node is either normal or abnormal, and the first node is one of multiple processing nodes;

[0038] If the first node's state is abnormal, perform the following operations:

[0039] The second node is determined among multiple processing nodes. The second node is one of the multiple processing nodes, and the node status of the second node is normal.

[0040] Obtain the association information of the first node, which is used to indicate at least one client that is associated with the first node;

[0041] A lock replay request is sent to at least one client via a second node.

[0042] This application embodiment monitors the status of the processing node, switches to a healthy second node when the first node is abnormal, obtains the client information associated with the first node, and initiates a lock replay request. This allows the second node to take over the original lock request and synchronize the lock status, while also avoiding the absence of masterless lock residue caused by the first node's inability to clear lock records due to a fault.

[0043] Secondly, embodiments of this application provide a lock request processing apparatus, the apparatus comprising:

[0044] The receiving module is used to receive the first lock request sent by the client; the first lock request is used to request lock permissions for the target file; the first lock request is used to indicate the client's first network address, the server's second network address, and the checksum of the first lock request;

[0045] The generation module is used to generate an identifier for the first lock request based on the first network address and the second network address;

[0046] The processing module is used to process the first lock request based on the checksum and identifier of the first lock request, and determine the processing result of the first lock request; the processing result is either successful or unsuccessful.

[0047] The sending module is used to send the processing results to the client.

[0048] In one possible implementation, the processing module is specifically used for:

[0049] Obtain the checksum and identifier of each of the at least one second lock request; the at least one second lock request includes lock requests processed by the server before the current time.

[0050] Based on the checksums of at least one second lock request and the checksum of the first lock request, determine the type of the first lock request; the type is either initial transmission type or retransmission type.

[0051] In the case of the initial transmission type, the first lock request is processed according to the identifier of the first lock request and the identifier of at least one second lock request, and the processing result is determined.

[0052] In one possible implementation, the processing module is specifically used for:

[0053] Based on the identifier of the first lock request and the identifiers of at least one second lock request, determine whether there is a target lock request among the at least one second lock request, wherein the identifier of the target lock request is the same as the identifier of the first lock request;

[0054] If no target lock request exists in at least one second lock request, the processing result is determined based on the identifier of the first lock request and the lock permissions of the target file.

[0055] If a target lock request exists in at least one second lock request, the processing result is determined based on the operation type of the first lock request and the operation type of the target lock request.

[0056] In one possible implementation, the processing module is specifically used for:

[0057] Perform a first operation, which includes: determining whether the checksum of the i-th second lock request is the same as the checksum of the first lock request; if the checksum of the i-th second lock request is the same as the checksum of the first lock request, determining that the type of the first lock request is a retransmission type.

[0058] If the checksum of the i-th second lock request is different from the checksum of the first lock request, update i to i+1, repeat the first operation until i is greater than or equal to N, and determine that the type of the first lock request is the initial transmission type.

[0059] Where i is a positive integer, and N is the number of at least one second lock request.

[0060] In one possible implementation, the generation module is specifically used for:

[0061] Determine the address type of the first network address and the address type of the second network address; the address type can be a 32-bit address type or a 128-bit address type.

[0062] Based on the address type of the first network address, a first target address is determined from the first network address, and the first target address is used to uniquely indicate the client;

[0063] Based on the address type of the second network address, the second target address is determined from the second network address. The second target address is used to uniquely indicate the server.

[0064] The first target address and the second target address are processed to generate an identifier for the first lock request.

[0065] In one possible implementation, the generation module is specifically used for:

[0066] If the address type of the first network address is a 32-bit address type, the first network address is determined as the first destination address;

[0067] If the address type of the first network address is a 128-bit address type, the address used to indicate the client in the first network address is determined as the first target address.

[0068] In one possible implementation, the server includes multiple processing nodes, and the lock request processing device further includes a determining module, which is specifically used for:

[0069] Determine the node state of the first node to process the first lock request; the node state of the first node is either normal or abnormal, and the first node is one of multiple processing nodes;

[0070] If the first node's state is abnormal, perform the following operations:

[0071] The second node is determined among multiple processing nodes. The second node is one of the multiple processing nodes, and the node status of the second node is normal.

[0072] Obtain the association information of the first node, which is used to indicate at least one client that is associated with the first node;

[0073] A lock replay request is sent to at least one client via a second node.

[0074] Thirdly, embodiments of this application provide a lock request processing apparatus, comprising:

[0075] At least one processor; and

[0076] A memory that is communicatively connected to at least one processor; wherein,

[0077] The memory stores instructions that can be executed by at least one processor, such that the at least one processor is able to perform the method shown in any of the first aspects.

[0078] Fourthly, embodiments of this application provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to perform the method shown in any of the first aspects.

[0079] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method shown in any of the first aspects.

[0080] The lock request processing method, apparatus, and device provided in this application carry both client and server network addresses and a unique checksum in the lock request. By combining the two addresses to generate a unique lock request identifier, and then relying on the checksum and identifier to collaboratively complete the lock request type identification and permission verification, this not only achieves accurate filtering of RPC timeout retransmission requests and avoids lock residue problems caused by repeated processing, but also enables standardized control of client lock permissions through a globally unique identifier, thereby further solving the lock residue problem and ensuring data consistency when multiple clients concurrently access the target file. Attached Figure Description

[0081] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0082] Figure 1 A schematic diagram illustrating the application scenarios provided in the embodiments of this application;

[0083] Figure 2 A method for processing lock requests provided for related technologies;

[0084] Figure 3 A flowchart illustrating a lock request processing method provided in an embodiment of this application;

[0085] Figure 4 A flowchart illustrating the process of determining the result of a first lock request, provided as an embodiment of this application;

[0086] Figure 5 This is a schematic diagram illustrating the processing of a first lock request, provided as an embodiment of this application.

[0087] Figure 6 A schematic diagram of a process for generating an identifier for a first lock request, provided as an embodiment of this application;

[0088] Figure 7 A schematic diagram of the drift of a first lock request provided in an embodiment of this application;

[0089] Figure 8 A schematic diagram of the structure of a lock request processing device provided in an embodiment of this application;

[0090] Figure 9 This is a schematic diagram of the structure of a lock request processing device provided in an embodiment of this application.

[0091] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0092] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0093] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0094] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0095] To facilitate understanding, the following will be combined with... Figure 1 The application scenarios applicable to the embodiments of this application will be described.

[0096] Figure 1 This is a schematic diagram illustrating an application scenario provided in an embodiment of this application. Please refer to [link / reference]. Figure 1 It includes a server 101 and a client 102. The server 101 may be an NFS server, and the server includes at least one file. The client 102 may be an NFS client.

[0097] In practical applications, server 101 can transmit data with client 102. For example, client 102 can send a first lock request to server 101. After receiving the first lock request from client 102, server 101 processes the request and determines the processing result. Then, server 101 sends the processing result of the first lock request to client 102.

[0098] NFS is a distributed file-sharing protocol based on the RPC protocol. NFS allows clients to access server-side file resources transparently over the network, just like accessing local storage, enabling collaborative file access across hosts and nodes. There are multiple versions of NFS; for example, NFS versions may include Network File System version 2 (NFSv2), Network File System version 3 (NFSv3), and Network File System version 4 (NFSv4).

[0099] File locks are the core control mechanism for ensuring data consistency in distributed and single-machine file systems. Essentially, they prevent multiple processes and clients from performing concurrent conflict operations on the same file by imposing access restrictions on the entire file or a specified byte range.

[0100] NFS supports the use of file locking mechanisms to control the orderly and safe access of multiple NFS client processes to the same file. For example, when a process on one NFS client is writing to a file, other NFS client processes are prevented from writing or reading.

[0101] NFSv2 and NFSv3 are stateless protocols that do not have built-in file locking functionality. They rely on independent NLM and RPC services for file lock management. Furthermore, the server typically deploys multiple processing nodes and binds them to Virtual Internet Protocol (VIP) addresses to achieve high availability. When a server head fails, the VIP can migrate to a healthy server head. Processing nodes can be, for example, the server head nodes.

[0102] NLM is a protocol that provides file locking functionality in NFS. RPC is a protocol that requests services from a remote computer program over a network without needing to understand the underlying network technology. VIP is an Internet Protocol (IP) address that can migrate between nodes that make up a distributed file system, primarily used to provide uninterrupted services within the distributed file system.

[0103] Specifically, taking the kernel data structure `struct file_lock` as an example, `struct file_lock` is mainly used to record the core elements of a file lock. For instance, `struct file_lock` records the target file, the range of content covered by the lock, the lock type (read lock / write lock, etc.), the lock requester, and relevant lock flags (such as whether it is a blocking lock). This information is fundamental to implementing file lock management and ensuring file access consistency.

[0104] Taking NFSv3 as an example, after receiving the first lock request, the server can allocate a memory region for the client that sent the first lock request in the NLM service of the current processing node, and determine the memory address of the memory region as the identifier of the client that sent the first lock request.

[0105] However, memory addresses are temporary values ​​local to the processing node, lacking global uniqueness and changing with the processing node and process state. Thus, when the same client accesses different processing nodes, each processing node allocates a different memory address for the client's first lock request; that is, the client's identifier differs across processing nodes. Because of this, a client that acquires a lock on one processing node cannot unlock it on another, leading to lock remnant issues.

[0106] For example, suppose a client first connects to processing node A. Processing node A allocates memory address 0x123 for the client's first lock request and uses this address to identify the client. The client successfully acquires the lock on processing node A. Later, the client switches to processing node B, and processing node B allocates memory address 0x456 for the client's first lock request. When the client initiates an unlock request, processing node B will consider that the client corresponding to the identifier 0x456 does not hold a lock on its local machine and cannot complete the unlock. Furthermore, the lock identified by 0x123 on the client's first lock request on A cannot be cleared because the client has switched connections, ultimately causing a lock remnant problem.

[0107] In some embodiments, since NLM's file locking functionality is implemented based on RPC, and the RPC protocol includes timeout retransmission rules, if the server does not send the processing result of the lock request to the client within a preset time interval after receiving the lock request from the client, the client will automatically resend the lock request to the server to ensure that the lock request is not lost.

[0108] Therefore, when the backend storage processing capacity of the business system is insufficient, the response to file lock requests will slow down, which will trigger the aforementioned RPC retry mechanism. As a result, a non-blocking file lock request may be repeatedly sent by the client RPC multiple times, resulting in multiple duplicate requests being sent to the server.

[0109] However, non-blocking lock requests have a characteristic: they don't wait for the server to process them for a long time after being initiated; if the lock cannot be acquired immediately, they will return failure directly. In scenarios where server processing is slow, the first lock request will be processed by NLM first, and the client will eventually receive a result indicating that the lock acquisition failed. The client's locking process may exit directly after receiving the first failure result due to business logic (such as terminating the task if the lock acquisition fails), at which point the process no longer needs the file lock.

[0110] Although the client process has exited, the RPC module had already triggered retry logic, and subsequent repeated lock requests will continue to be sent to the server. If the backend file system's processing capacity recovers at this point, the server may successfully acquire the lock when processing these retry requests. However, since the client process that initiated the lock request has exited, no process will release the lock, and the file lock will remain "attached" in the file system, leading to a lock remnant problem.

[0111] Specifically, it can be combined with Figure 2 To understand, Figure 2 This provides a method for handling lock requests in related technologies. For example... Figure 2 As shown, the client sends a non-blocking lock request to the server via the RPC protocol. Upon receiving the lock request, the server processes it. Due to the server's slow processing speed, the client does not receive the processing result of the lock request from the server within a preset time interval. At this point, the client sends a duplicate lock request to the server via the RPC protocol. If the server processes the lock request and determines that the processing result is a failure, the client, upon receiving the processing result of the lock request, terminates the business process related to the lock request.

[0112] However, the server will also process duplicate lock requests. If the processing result of the duplicate lock request is successful, but the business process that made the lock request no longer exists in the client, the file lock of the duplicate lock request will remain in the file system, resulting in the lock residue problem.

[0113] In some embodiments, in the event of a single node failure in the business system, in order to ensure uninterrupted external services, the system will adopt a VIP mechanism: when a single point of failure occurs in the processing node providing the service, the VIP originally bound to the failed node will automatically "drift" to a healthy processing node in the cluster. Clients only need to access the VIP to continue using the service, and the service interruption will not be perceived from the outside.

[0114] However, NLM file locks are stateful, and lock information is bound to specific processing nodes. Related technologies lack lock synchronization / cleanup mechanisms for VIP migration. Specifically, when a VIP migrates from a faulty processing node to a new one, the old processing node, due to failure or going offline, loses its ability to provide external services and clean up its own locks, and its locally recorded file lock information becomes a residual lock.

[0115] Because file locks in the business system need to be globally consistent, when other NFS clients attempt to acquire a lock on the same file, the system will detect residual locks on the old processing node, determine that the file is already locked, and thus reject new lock requests, thereby obstructing normal file access logic.

[0116] In addition, after the new processing node takes over the VIP, it does not have the client lock information previously maintained by the old processing node locally, and it lacks a notification mechanism, so it cannot proactively inform the NFS clients that were previously connected to the VIP to restore the original file locks.

[0117] This can lead to two cognitive biases: first, the client may believe it still holds the file lock, while the new processing node has no record of this lock; second, the new processing node may determine that the file is unlocked and allow other clients to acquire the lock, ultimately causing the lock view between the client and the processing node to be inconsistent, which undermines the core semantics of file locks to "control ordered access" and may lead to problems such as multiple clients modifying files simultaneously and data consistency being broken.

[0118] In this embodiment, by having the lock request carry both the client's and server's network addresses and a unique checksum, and combining the two addresses to generate a unique lock request identifier, and then relying on the checksum and identifier to collaboratively complete the lock request type identification and permission verification, it not only achieves accurate filtering of RPC timeout retransmission requests, avoiding the lock residue problem caused by repeated processing, but also enables standardized management of client lock permissions through a globally unique identifier, thereby further solving the lock residue problem and ensuring data consistency when multiple clients concurrently access the target file.

[0119] The method described in this application will now be illustrated through specific embodiments. It should be noted that the following embodiments may exist independently or in combination with each other; identical or similar content will not be repeated in different embodiments.

[0120] Figure 3 This is a flowchart illustrating a lock request processing method provided in an embodiment of this application. Please refer to [link / reference]. Figure 3 The method may include:

[0121] S301. Receive the first lock request sent by the client; the first lock request is used to request lock permissions for the target file; the first lock request is used to indicate the client's first network address, the server's second network address, and the checksum of the first lock request.

[0122] The execution entity in this application embodiment can be a lock request processing device or a lock request processing apparatus set in the lock request processing device. The lock request processing apparatus can be implemented by software or by a combination of software and hardware. The lock request processing device can be a client, wherein the client can be a terminal device with a display page, such as a mobile phone or a computer.

[0123] A client is a terminal device or application that initiates a file lock permission request, possessing network communication capabilities and file access needs. An example client could be an NFS client.

[0124] The first lock request refers to a specific request instance initiated by the client to the server to request lock permissions for the target file. The first lock request includes core data fields such as the client's network address, the server's network address, and a verification code.

[0125] The business system includes multiple files. The target file is the specific file among these files that the client wants to acquire lock permissions for. Lock permissions refer to the client's concurrent access control over the target file. Lock permissions can be, for example, shared lock permissions and exclusive lock permissions.

[0126] The first network address refers to the identifier of the client that initiated the lock request on the network. For example, the first network address can be the client's IP address.

[0127] The server is the server-side component of the business system; for example, it could be an NFS server. The second network address refers to the identifier of the server receiving the lock request within the network. For example, the second network address could be the server's VIP address.

[0128] The checksum for the first lock request is a unique verification identifier generated by the client for that first lock request, typically a unique string of characters or a numerical value. It should be noted that for any given first lock request, the checksum of any subsequent repeating lock request sent by the client for that first lock request is the same as the checksum of the first lock request itself.

[0129] Optionally, when a client needs to obtain concurrent access control permissions for a target file in a business system, it can send a first lock request to the server to request the server to obtain lock permissions for the target file.

[0130] S302. Generate an identifier for the first lock request based on the first network address and the second network address.

[0131] The identifier for the first lock request is a globally unique feature field generated by the server based on the client's first network address and the server's second network address through specific rules. It is used to distinguish different lock request instances.

[0132] Optionally, the server can determine the first network address and the second network address from the first lock request. Then, it can perform hash processing on the first network address and the second network address to generate an identifier for the first lock request.

[0133] S303. Based on the checksum and identifier of the first lock request, process the first lock request and determine the processing result of the first lock request; the processing result is either successful or unsuccessful.

[0134] The result of processing the first lock request indicates whether the client can acquire lock permissions for the target file. If the request is processed successfully, the result indicates that the client can acquire lock permissions for the target file; if the request fails, the result indicates that the client cannot acquire lock permissions for the target file.

[0135] Optionally, the server can compare the checksum of the first lock request with the checksums of all previously processed lock requests. If a matching checksum is found, the first lock request is determined to be a retransmission, and the processing result is directly determined to be a failure. If no matching checksum is found, it is determined to be an initial transmission. The server then matches the identifier of the first lock request with the identifiers of all lock requests. If no second lock request with the same identifier exists, and the lock permissions requested by the first lock request do not conflict with the current lock state of the target file, a lock permission association between the client and the target file is established, and the processing result is determined to be a success. If a lock request with the same identifier exists, the server further combines the operation types of the first lock request and the target lock request to determine permission compatibility. If compatible, the corresponding lock operation is executed, and the processing result is determined to be a success; otherwise, the processing result is determined to be a failure.

[0136] S304. Send the processing result to the client.

[0137] Optionally, after determining the processing result, the server can send the processing result to the client to notify the client whether it succeeded or failed to acquire the lock permission of the target file.

[0138] The lock request processing method provided in this application carries both client and server network addresses and a unique checksum in the lock request. A unique lock request identifier is generated by combining the two addresses. The lock request type identification and permission verification are then completed by relying on the checksum and the identifier. This not only achieves accurate filtering of RPC timeout retransmission requests and avoids lock residue problems caused by repeated processing, but also enables standardized control of client lock permissions through a globally unique identifier, thereby further solving the lock residue problem and ensuring data consistency when multiple clients concurrently access the target file.

[0139] Based on any of the above embodiments, the following, in conjunction with Figure 4 The detailed process of processing the first lock request based on its checksum and identifier, and determining the processing result of the first lock request, is explained.

[0140] Figure 4 This is a flowchart illustrating the process of determining the result of a first lock request, provided as an embodiment of this application. Please refer to... Figure 4 The process includes:

[0141] S401. Obtain the checksum of at least one second lock request and the identifier of at least one second lock request; at least one second lock request includes lock requests processed by the server before the current time.

[0142] The second lock request is a lock request that the server has processed before the current time. The checksum of the second lock request is a unique identifier generated by the client for the first lock request, typically a unique string of characters or a numerical value. The identifier for the second lock request is generated based on the server's network address and the network address of the client that sent the second lock request.

[0143] Optionally, the server stores the checksums and identifiers of all lock requests processed by the server up to the current time. Therefore, the server can determine the checksum and identifier of at least one second lock request within the storage area.

[0144] S402. Determine the type of the first lock request based on the checksums of at least one second lock request and the checksum of the first lock request; the type is either initial transmission type or retransmission type.

[0145] The first lock request is of type "Initial Transmission," indicating that the client is sending the first lock request to the server for the first time; the first lock request is of type "Retransmission," indicating that the client is sending the first lock request to the server for the nth time. Here, n is a positive integer greater than or equal to 2.

[0146] Optionally, the server can determine the type of the first lock request as follows: Perform a first operation, which includes: determining whether the checksum of the i-th second lock request is the same as the checksum of the first lock request; if the checksum of the i-th second lock request is the same as the checksum of the first lock request, determine that the type of the first lock request is a retransmission type; if the checksum of the i-th second lock request is different from the checksum of the first lock request, update i to i+1, repeat the first operation, until i is greater than or equal to N, and determine that the type of the first lock request is an initial transmission type; where i is a positive integer, and N is the number of at least one second lock request.

[0147] If the checksum of the i-th second lock request is the same as the checksum of the first lock request, it indicates that the first lock request is a duplicate lock request of the i-th second lock request sent by the client. Therefore, it can be determined that the type of the first lock request is a retransmission type.

[0148] If the checksums of at least one second lock request are different from those of the first lock request, it indicates that the first lock request was the first lock request sent by the client. Therefore, the type of the first lock request can be determined to be the initial transmission type.

[0149] For example, suppose the checksum of the first lock request is XXX, and at least one second lock request includes second lock request 1, second lock request 2, and second lock request 3. The checksum of second lock request 1 is AAA, the checksum of second lock request 2 is BBB, and the checksum of second lock request 3 is XXX.

[0150] The server compares the checksum of the first lock request with the checksum of the second lock request 1, determining that the checksum XXX of the first lock request is different from the checksum AAA of the second lock request 1. Then, the server compares the checksum of the first lock request with the checksum of the second lock request 2, determining that the checksum XXX of the first lock request is different from the checksum BBB of the second lock request 1. Next, the server compares the checksum of the first lock request with the checksum of the second lock request 3, determining that the checksum XXX of the first lock request is the same as the checksum XXX of the second lock request 1. Since the checksum XXX of the first lock request is the same as the checksum XXX of the second lock request 1, the server determines that the type of the first lock request is a re-type.

[0151] This application embodiment accurately determines the initial or retransmission type of the current lock request by verifying the checksum of each historical lock request. It can identify and filter duplicate lock requests that are retransmitted due to RPC timeout, thus avoiding the generation of redundant lock records due to repeated processing of the same lock request.

[0152] S403. When the type is initial transmission type, process the first lock request according to the identifier of the first lock request and the identifier of at least one second lock request, and determine the processing result.

[0153] If the server determines that the first lock request is a retransmission request, it will not process the first lock request. If the server determines that the first lock request is an initial transmission request, it will process the first lock request.

[0154] Optionally, the server may process the first lock request as follows: Based on the identifier of the first lock request and the identifiers of at least one second lock request, determine whether a target lock request exists in the at least one second lock request, wherein the identifier of the target lock request is the same as the identifier of the first lock request; if no target lock request exists in the at least one second lock request, determine the processing result based on the identifier of the first lock request and the lock permissions of the target file; if a target lock request exists in the at least one second lock request, determine the processing result based on the operation type of the first lock request and the operation type of the target lock request.

[0155] The operation type for a lock request can be, for example, lock acquisition or lock release.

[0156] Optionally, the server can compare the identifier of each of the at least one second lock request with the identifier of the first lock request. If there is a second lock request among the at least one second lock requests with the same identifier as the first lock request, then it is determined that there is a target lock request among the at least one second lock requests, and the second lock request is identified as the target lock request. If there is no second lock request among the at least one second lock requests with the same identifier as the first lock request, then it is determined that there is no target lock request among the at least one second lock requests.

[0157] If at least one of the second lock requests does not contain a target lock request, it indicates that the first lock request was the client's first lock permission application for that file. In this case, the server can determine the processing result based on the identifier of the first lock request and the lock permissions of the target file.

[0158] Specifically, the server determines whether the lock permission for the target file is already held by another client. If the lock permission is already held by another client, it determines whether the lock held by that client is a shared lock or an exclusive lock. If no other client holds the lock, or if another client holds a shared lock, the server establishes a lock permission association between the client and the target file based on the identifier of the first lock request, thereby enabling the client to acquire the lock permission for the target file. Therefore, the processing result of the first lock request is determined to be successful. If another client holds an exclusive lock, the server determines the processing result of the first lock request to be failed.

[0159] If at least one second lock request contains a target lock request, it indicates that the first lock request is a subsequent associated lock operation on the same file by the same client. In this case, the server can compare the operation types of the first lock request and the target lock request. If their operation types are compatible, the server processes the first lock request based on its identifier and determines the processing result as successful. If their operation types are incompatible, the server determines the processing result as failed.

[0160] Specifically, it can be combined with Figure 5 To understand, Figure 5 This is a schematic diagram illustrating the processing of a first lock request, provided as an embodiment of this application. For example... Figure 5 As shown, the client sends a first lock request to the server. Upon receiving the first lock request, the server determines it to be an initial transmission and processes it. If no processing result is received from the server within a preset time interval, the client sends a retransmission request for the first lock request. Upon receiving this retransmission request, the server determines it to be a retransmission and does not process it. Furthermore, after processing the first lock request, the server determines the processing result and sends it to the client.

[0161] This application embodiment can identify historical lock requests from the same client by verifying the uniqueness of the lock request identifier. When there are no requests with the same identifier, a standardized lock permission association is established. When there are requests with the same identifier, permission compatibility is determined based on the operation type. This avoids redundant lock residue caused by repeatedly establishing lock associations and prevents invalid lock residue caused by conflicts in the operation type of the same client. It standardizes the lock request processing flow from the source of lock permission association and solves the lock residue problem.

[0162] exist Figure 4 In the illustrated embodiment, by retrieving the checksum and identifier of the historical second lock request, the initial or retransmission type of the first lock request is accurately determined by verifying the checksum one by one. This can directly filter out duplicate requests that are retransmitted due to RPC timeout, avoiding redundant lock residues caused by repeated processing. At the same time, for initial transmission type requests, historical associated requests are identified based on identifier matching. If there is no match, a standardized lock permission association is established. If there is a match, permission compatibility is determined by combining the operation type. This not only eliminates invalid lock residues caused by the same client repeatedly requesting lock permissions, but also avoids the lock management chaos caused by operation type conflicts.

[0163] Below, in conjunction with Figure 6 The process of generating an identifier for the first lock request based on the first network address and the second network address is explained. Figure 6 This is a schematic diagram illustrating a process for generating an identifier for a first lock request, provided as an embodiment of this application. Figure 6 As shown, the process may include the following steps:

[0164] S601. Determine the address type of the first network address and the address type of the second network address; the address type is either a 32-bit address type or a 128-bit address type.

[0165] Network addresses can be either 32-bit or 128-bit. For example, a 32-bit address could be an Internet Protocol version 4 (IPv4) address; a 128-bit address could be an Internet Protocol version 6 (IPv6) address.

[0166] Optionally, taking the first network address as an example, the server can determine whether the first network address is an IPv4 address or an IPv6 address. If the first network address is an IPv4 address, then the address type of the first network address is determined to be a 32-bit address type; if the first network address is an IPv6 address, then the address type of the first network address is determined to be a 128-bit address type.

[0167] S602. Based on the address type of the first network address, determine the first target address from the first network address. The first target address is used to uniquely indicate the client.

[0168] Optionally, the server may determine the first target address in the following ways: if the address type of the first network address is a 32-bit address type, the first network address is determined as the first target address; if the address type of the first network address is a 128-bit address type, the address used to indicate the client in the first network address is determined as the first target address.

[0169] For example, assuming the first network address is 192.168.1.10, the server determines that the address type of the first network address is a 32-bit address type. Therefore, the server determines the first target address to be 192.168.1.10.

[0170] This application embodiment establishes a unified target address extraction rule for different types of network addresses, including 32-bit and 128-bit addresses, ensuring the uniqueness and consistency of client identity identifiers under different network environments. This avoids the problem of lock request identifier confusion caused by address format differences, enabling the server to accurately match the client's lock permission records.

[0171] S603. Based on the address type of the second network address, determine the second target address from the second network address. The second target address is used to uniquely indicate the server.

[0172] Optionally, the server determines the second target address using the same method as it determines the first target address. Specifically, if the second network address is a 32-bit address type, the second network address is determined as the second target address; if the second network address is a 128-bit address type, the address used to indicate the client in the second network address is determined as the first target address.

[0173] S604. Process the first target address and the second target address to generate an identifier for the first lock request.

[0174] Optionally, the server can concatenate the first target address and the second target address to generate the identifier of the first lock request. Therefore, the identifier of the first lock request is a 64-bit code, where the high 32 bits can be the first target address and the low 32 bits can be the second target address. Optionally, the high 32 bits can also be the second target address and the low 32 bits can be the first target address.

[0175] exist Figure 6 In the illustrated embodiment, by distinguishing between 32-bit and 128-bit network address types, a first target address uniquely indicating the client and a second target address uniquely indicating the server are extracted. A lock request identifier is then generated based on these dual target addresses. This eliminates the impact of different address format differences on identifier uniqueness, ensuring global uniformity of lock request identifiers in IPv4 and IPv6 network environments. It also avoids lock permission association errors caused by address identifier confusion, enabling the server to accurately match client and lock permission records. This facilitates targeted cleanup of residual locks in fault scenarios, further improving the lock remnant problem from the identifier generation level.

[0176] In some embodiments, the business system includes multiple processing nodes. The server can determine the node status of the first node that processes the first lock request, and if the node status of the first node is abnormal, the server can transfer the first lock request to a node with a normal node status among the multiple processing nodes to which the request is transferred, and process the first lock request through that processing node.

[0177] Specifically, the server can determine the node status of the first node that processes the first lock request; the node status of the first node is either normal or abnormal, and the first node is one of multiple processing nodes; if the node status of the first node is abnormal, the following operations are performed: determine the second node among the multiple processing nodes, the second node is one of the multiple processing nodes, and the node status of the second node is normal; obtain the association information of the first node, the association information is used to indicate at least one client that has an association relationship with the first node; and send a lock replay request to at least one client through the second node.

[0178] The first node is the first processing node among the multiple processing nodes on the server to receive and begin processing the first lock request.

[0179] The node status of a processing node indicates its operational status and measures whether it can normally accept and process lock requests. A normal node status indicates that the processing node can normally accept and process lock requests; an abnormal node status indicates that the processing node cannot normally accept and process lock requests.

[0180] Optionally, the server can determine the node status of the first node. If the first node's node status is abnormal, it means that the first node cannot process the first lock request normally. Therefore, the server can determine the processing nodes with normal processing status as candidate nodes based on the processing status of multiple processing nodes, obtaining at least one candidate node. Then, any one of the at least one candidate node is determined as the second node.

[0181] The association information of the first node refers to the information stored on the server that records the correspondence between the first node and the client. The association information of the first node indicates at least one client that has an association with the first node. Specifically, at least one client refers to a client that has initiated a lock request to the first node and established a lock permission association with the first node.

[0182] A lock replay request is an instruction sent by the second node to the client, which requests the client to re-initiate the lock request. It is the core carrier for realizing lock permission state synchronization.

[0183] Optionally, the server can determine at least one client associated with the first node based on the association information of the first node, and send a lock replay request to at least one client through the second node. For each of the at least one client, after receiving the lock replay request sent by the server through the second node, the client restores the file lock information it previously held.

[0184] In addition, the NLM on the first node will proactively clear file locks held by at least one client on the first node. Meanwhile, the server limits the impact of the grace period to a subset of connections, ensuring it does not affect file lock requests from other clients that have not experienced file drift.

[0185] Can be combined Figure 7 To understand, Figure 7 This is a schematic diagram illustrating the drift of a first lock request as provided in an embodiment of this application. Please refer to... Figure 7 The server-side configuration includes multiple processing nodes, including Processing Node 1 and Processing Node 2. A client sends a first lock request to the server. Processing Node 1 on the client receives the first lock request, processes it, and determines that the processing result is successful. The server sends the processing result of the first lock request to the client. The server determines that the state of Processing Node 1 is abnormal, and the state of Processing Node 2 is normal. At this point, the server migrates the first lock request from Processing Node 1 to Processing Node 2. The NLM in Processing Node 1 clears the file locks held by at least one client on Processing Node 1. Processing Node 2 obtains the association information of the first node and then sends a lock replay request to at least one client to notify at least one client to restore the file locks previously generated on Processing Node 1.

[0186] This application embodiment monitors the status of the processing node, switches to a healthy second node when the first node is abnormal, obtains the client information associated with the first node, and initiates a lock replay request. This allows the second node to take over the original lock request and synchronize the lock status, while also avoiding the absence of masterless lock residue caused by the first node's inability to clear lock records due to a fault.

[0187] Figure 8 This is a schematic diagram of the structure of a lock request processing apparatus provided in an embodiment of this application. Please refer to... Figure 8 The processing device 10 for the lock request may include:

[0188] The receiving module 11 is used to receive a first lock request sent by the client; the first lock request is used to request lock permissions for the target file; the first lock request is used to indicate the client's first network address, the server's second network address, and the checksum of the first lock request;

[0189] The generation module 12 is used to generate an identifier for the first lock request based on the first network address and the second network address;

[0190] The processing module 13 is used to process the first lock request based on the check code and the identifier of the first lock request, and determine the processing result of the first lock request; the processing result is either successful or unsuccessful.

[0191] The sending module 14 is used to send the processing results to the client.

[0192] In one possible implementation, the processing module 13 is specifically used for:

[0193] Obtain the checksum and identifier of each of the at least one second lock request; the at least one second lock request includes lock requests processed by the server before the current time.

[0194] Based on the checksums of at least one second lock request and the checksum of the first lock request, determine the type of the first lock request; the type is either initial transmission type or retransmission type.

[0195] In the case of the initial transmission type, the first lock request is processed according to the identifier of the first lock request and the identifier of at least one second lock request, and the processing result is determined.

[0196] In one possible implementation, the processing module 13 is specifically used for:

[0197] Based on the identifier of the first lock request and the identifiers of at least one second lock request, determine whether there is a target lock request among the at least one second lock request, wherein the identifier of the target lock request is the same as the identifier of the first lock request;

[0198] If no target lock request exists in at least one second lock request, the processing result is determined based on the identifier of the first lock request and the lock permissions of the target file.

[0199] If a target lock request exists in at least one second lock request, the processing result is determined based on the operation type of the first lock request and the operation type of the target lock request.

[0200] In one possible implementation, the processing module 13 is specifically used for:

[0201] Perform a first operation, which includes: determining whether the checksum of the i-th second lock request is the same as the checksum of the first lock request; if the checksum of the i-th second lock request is the same as the checksum of the first lock request, determining that the type of the first lock request is a retransmission type.

[0202] If the checksum of the i-th second lock request is different from the checksum of the first lock request, update i to i+1, repeat the first operation until i is greater than or equal to N, and determine that the type of the first lock request is the initial transmission type.

[0203] Where i is a positive integer, and N is the number of at least one second lock request.

[0204] In one possible implementation, the generation module 12 is specifically used for:

[0205] Determine the address type of the first network address and the address type of the second network address; the address type can be a 32-bit address type or a 128-bit address type.

[0206] Based on the address type of the first network address, a first target address is determined from the first network address, and the first target address is used to uniquely indicate the client;

[0207] Based on the address type of the second network address, the second target address is determined from the second network address. The second target address is used to uniquely indicate the server.

[0208] The first target address and the second target address are processed to generate an identifier for the first lock request.

[0209] In one possible implementation, the generation module 12 is specifically used for:

[0210] If the address type of the first network address is a 32-bit address type, the first network address is determined as the first destination address;

[0211] If the address type of the first network address is a 128-bit address type, the address used to indicate the client in the first network address is determined as the first target address.

[0212] In one possible implementation, the server includes multiple processing nodes, and the lock request processing device further includes a determining module, which is specifically used for:

[0213] Determine the node state of the first node to process the first lock request; the node state of the first node is either normal or abnormal, and the first node is one of multiple processing nodes;

[0214] If the first node's state is abnormal, perform the following operations:

[0215] The second node is determined among multiple processing nodes. The second node is one of the multiple processing nodes, and the node status of the second node is normal.

[0216] Obtain the association information of the first node, which is used to indicate at least one client that is associated with the first node;

[0217] A lock replay request is sent to at least one client via a second node.

[0218] The lock request processing device provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be repeated here.

[0219] Figure 9 This is a schematic diagram of the structure of a lock request processing device provided in an embodiment of this application. Please refer to... Figure 9 The processing device 20 for the lock request may include a memory 21 and a processor 22. Exemplarily, the memory 21 and the processor 22 are interconnected via a bus 23.

[0220] Memory 21 is used to store program instructions;

[0221] The processor 22 is used to execute the program instructions stored in the memory, so that the data processing device 20 performs the method shown in the above method embodiment.

[0222] The lock request processing device provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be repeated here.

[0223] This application provides a computer-readable storage medium storing computer-executable instructions, which are used to implement the above-described method when executed by a processor.

[0224] This application embodiment may also provide a computer program product, including a computer program that, when executed by a processor, can implement the above-described method.

[0225] All or part of the steps in the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a readable memory. When the program is executed, it performs the steps of the above-described method embodiments; and the aforementioned memory (storage medium) includes: read-only memory (ROM), random access memory (RAM), flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disc, and any combination thereof.

[0226] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0227] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0228] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0229] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and variations.

[0230] In this application, the term "comprising" and its variations can refer to non-limiting inclusion; the term "or" and its variations can refer to "and / or". The terms "first", "second", etc., in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

Claims

1. A method for processing lock requests, characterized in that, Applied to the server side, the method includes: Receive a first lock request sent by the client; the first lock request is used to request lock permissions for the target file; the first lock request is used to indicate the first network address of the client, the second network address of the server, and the checksum of the first lock request; Generate an identifier for the first lock request based on the first network address and the second network address; Based on the checksum and identifier of the first lock request, the first lock request is processed to determine the processing result of the first lock request; the processing result is either successful or unsuccessful. The processing result is sent to the client.

2. The method according to claim 1, characterized in that, Based on the checksum and identifier of the first lock request, the first lock request is processed to determine the processing result, including: Obtain the checksum of at least one second lock request and the identifier of each of the at least one second lock requests; the at least one second lock request includes lock requests processed by the server before the current time. Based on the checksums of the at least one second lock request and the checksum of the first lock request, the type of the first lock request is determined; the type is either an initial transmission type or a retransmission type. When the type is the initial transmission type, the first lock request is processed according to the identifier of the first lock request and the respective identifiers of the at least one second lock request, and the processing result is determined.

3. The method according to claim 2, characterized in that, The first lock request is processed based on its identifier and the identifiers of the at least one second lock request, and the processing result is determined, including: Based on the identifier of the first lock request and the identifiers of the at least one second lock request, determine whether there is a target lock request among the at least one second lock request, wherein the identifier of the target lock request is the same as the identifier of the first lock request; If the target lock request is not present in any of the at least one second lock request, the processing result is determined based on the identifier of the first lock request and the lock permissions of the target file. If the target lock request exists in at least one of the second lock requests, the processing result is determined based on the operation type of the first lock request and the operation type of the target lock request.

4. The method according to claim 2 or 3, characterized in that, The type of the first lock request is determined based on the checksums of the at least one second lock request and the checksum of the first lock request, including: Perform a first operation, the first operation including: determining whether the checksum of the i-th second lock request is the same as the checksum of the first lock request; if the checksum of the i-th second lock request is the same as the checksum of the first lock request, determining that the type of the first lock request is the retransmission type; If the checksum of the i-th second lock request is different from the checksum of the first lock request, update i to i+1, repeat the first operation until i is greater than or equal to N, and determine that the type of the first lock request is the initial transmission type. Where i is a positive integer, and N is the number of the at least one second lock request.

5. The method according to any one of claims 1-3, characterized in that, Based on the first network address and the second network address, an identifier for the first lock request is generated, including: Determine the address type of the first network address and the address type of the second network address; the address type is either a 32-bit address type or a 128-bit address type; Based on the address type of the first network address, a first target address is determined from the first network address, and the first target address is used to uniquely indicate the client; Based on the address type of the second network address, a second target address is determined from the second network address, and the second target address is used to uniquely indicate the server. The first target address and the second target address are processed to generate the identifier of the first lock request.

6. The method according to claim 5, characterized in that, Based on the address type of the first network address, determine the first target address from the first network address, including: If the address type of the first network address is the 32-bit address type, the first network address is determined as the first target address; If the address type of the first network address is the 128-bit address type, the address in the first network address used to indicate the client is determined as the first target address.

7. The method according to any one of claims 1-3, characterized in that, The server includes multiple processing nodes, and the method further includes: Determine the node status of the first node that processes the first lock request; the node status of the first node is either normal or abnormal, and the first node is one of the plurality of processing nodes; If the node state of the first node is in the abnormal state, perform the following operations: A second node is determined among the plurality of processing nodes, wherein the second node is one of the plurality of processing nodes and the node status of the second node is the normal state; Obtain the association information of the first node, wherein the association information is used to indicate at least one client that is associated with the first node; The second node sends a lock replay request to the at least one client.

8. A lock request processing apparatus, characterized in that, The device includes: The receiving module is used to receive a first lock request sent by the client; the first lock request is used to request lock permissions for the target file; the first lock request is used to indicate the first network address of the client, the second network address of the server, and the checksum of the first lock request; The generation module is used to generate an identifier for the first lock request based on the first network address and the second network address; The processing module is used to process the first lock request based on the checksum and the identifier of the first lock request, and determine the processing result of the first lock request; the processing result is either successful or unsuccessful. The sending module is used to send the processing result to the client.

9. A lock request processing device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, in, The computer instructions are used to cause the computer to perform the method according to any one of claims 1 to 7.

Images