File lock management method and device, computer equipment, medium and product

Abstract

The invention relates to a file lock management method and device, computer equipment, a medium and a product. The method is applied to a file lock management node, the file lock management node, a metadata server and a first client are in pairwise communication connection, and the method comprises the following steps: when it is detected that communication between the metadata server and the first client is abnormal, obtaining a file lock according to a file lock obtaining request sent for the first client; generating file lock management information of a target file lock corresponding to the first client, wherein the file lock acquisition request is sent to a file lock management node by a second client; sending file lock management information to the first client, so that the first client executes management operation based on the file lock management information to obtain a file lock operation result; and after a file lock operation result sent by the first client is received, generating an acquisition request result of the target file lock according to the file lock operation result, and sending the acquisition request result to the second client. By adopting the method, the management self-healing performance of file lock management is improved.

Description

Technical Field

[0001] The present application relates to the field of distributed storage technology, and in particular to a file lock management method, device, computer equipment, computer-readable storage medium and computer program product. Background Art

[0002] With the development of technology, file locks have been widely used in many application scenarios. File locks can ensure that only one process of the client can access a specific file at the same time, thereby playing an important role in preventing data conflicts, achieving synchronization between processes, and protecting key data.

[0003] At present, deadlock is prone to occur in the process of file lock management. For example, when the file lock management node retains the client's access rights and the client does not actively release the file lock, file deadlock will occur, that is, other clients cannot read specific files through the file lock, which makes business interruption prone. Therefore, the current file lock management has poor self-healing ability. Summary of the invention

[0004] Based on this, it is necessary to provide a file lock management method, apparatus, computer device, computer-readable storage medium and computer program product to improve the self-healing performance of file lock management in response to the above technical problems.

[0005] In a first aspect, the present application provides a file lock management method, which is applied to a file lock management node, wherein the file lock management node, a metadata server, and a first client are connected to each other in communication, including:

[0006] In the case of detecting a communication anomaly between the metadata server and the first client, generating file lock management information of a target file lock corresponding to the first client according to a file lock acquisition request sent to the first client, wherein the file lock acquisition request is sent by the second client to the file lock management node;

[0007] Sending the file lock management information to the first client, so that the first client can perform a management operation on the target file lock according to the file lock management information to obtain a file lock operation result;

[0008] After receiving the file lock operation result sent by the first client, generating an acquisition request result of the target file lock according to the file lock operation result, and sending the acquisition request result to the second client.

[0009] In one embodiment, generating file lock management information of a target file lock corresponding to the first client according to the file lock acquisition request sent by the first client includes:

[0010] Extracting the first file lock identity information from the file lock acquisition request, and acquiring the second file lock identity information fed back by the first client;

[0011] taking the file lock jointly identified by the first file lock identity information and the second file lock identity information as the target file lock;

[0012] Generate corresponding file lock management information according to the file lock usage status of the target file lock.

[0013] In one embodiment, the file lock management information includes file lock release information and file lock holding information; the generating corresponding file lock management information according to the file lock state of the target file lock includes:

[0014] If the file lock usage status is in use, generating the file lock holding information;

[0015] If the file lock usage status is an unused status, the file lock release information is generated.

[0016] In one embodiment, generating the file lock release information includes:

[0017] Obtaining a list of trusted clients fed back by the first client;

[0018] In the case where it is detected that the second client is in the trusted client list, the file lock release information is generated.

[0019] In one embodiment, the acquisition request result includes an acquisition request permission result and an acquisition request rejection result; and generating the acquisition request result of the target file lock according to the file lock operation result includes:

[0020] If the file lock operation result is a first file lock operation result in which the first client releases the target file lock, generating the acquisition request permission result;

[0021] If the file lock operation result is a second file lock operation result in which the first client holds the target file lock, the acquisition request rejection result is generated.

[0022] In one embodiment, sending the acquisition request result to the second client includes:

[0023] Detecting the request type of the file lock acquisition request;

[0024] If the request type is the first request type, sending the request permission result to the second client at a preset sending time point;

[0025] If the request type is the second request type, the designated sending time point of the acquisition request permission result is determined according to the request time point of the file lock acquisition request, and the acquisition request permission result is sent to the second client at the designated sending time point.

[0026] In a second aspect, the present application further provides a file lock management method device, which is applied to a file lock management node, wherein the file lock management node, the metadata server and the first client are connected to each other in communication, including:

[0027] a generating module, configured to generate file lock management information of a target file lock corresponding to the first client according to a file lock acquisition request sent to the first client when abnormal communication between the metadata server and the first client is detected, wherein the file lock acquisition request is sent by the second client to the file lock management node;

[0028] A first sending module, configured to send the file lock management information to the first client, so that the first client can perform a management operation on the target file lock according to the file lock management information to obtain a file lock operation result;

[0029] The second sending module is used to generate an acquisition request result of the target file lock according to the file lock operation result after receiving the file lock operation result sent by the first client, and send the acquisition request result to the second client.

[0030] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0031] In the case where a communication anomaly is detected between the metadata server and the first client, file lock management information of a target file lock corresponding to the first client is generated according to a file lock acquisition request sent to the first client, wherein the file lock acquisition request is sent by the second client to the file lock management node; the file lock management information is sent to the first client so that the first client can perform a management operation on the target file lock according to the file lock management information to obtain a file lock operation result; after receiving the file lock operation result sent by the first client, an acquisition request result of the target file lock is generated according to the file lock operation result, and the acquisition request result is sent to the second client.

[0032] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the following steps are implemented:

[0033] In the case where a communication anomaly is detected between the metadata server and the first client, file lock management information of a target file lock corresponding to the first client is generated according to a file lock acquisition request sent to the first client, wherein the file lock acquisition request is sent by the second client to the file lock management node; the file lock management information is sent to the first client so that the first client can perform a management operation on the target file lock according to the file lock management information to obtain a file lock operation result; after receiving the file lock operation result sent by the first client, an acquisition request result of the target file lock is generated according to the file lock operation result, and the acquisition request result is sent to the second client.

[0034] In a fifth aspect, the present application further provides a computer program product, including a computer program, which implements the following steps when executed by a processor:

[0035] In the case where a communication anomaly is detected between the metadata server and the first client, file lock management information of a target file lock corresponding to the first client is generated according to a file lock acquisition request sent to the first client, wherein the file lock acquisition request is sent by the second client to the file lock management node; the file lock management information is sent to the first client so that the first client can perform a management operation on the target file lock according to the file lock management information to obtain a file lock operation result; after receiving the file lock operation result sent by the first client, an acquisition request result of the target file lock is generated according to the file lock operation result, and the acquisition request result is sent to the second client.

[0036] The above-mentioned file lock management method, apparatus, computer device, computer-readable storage medium and computer program product first generate file lock management information of a target file lock corresponding to the first client according to a file lock acquisition request sent to the first client when the file lock management node detects that the communication between the metadata server and the first client is abnormal, wherein the file lock acquisition request is sent by the second client to the file lock management node, and when the file lock management node receives the file lock acquisition request sent by the second client to acquire the target file lock of the first client, if the communication between the metadata server and the first client is abnormal, that is, the target file lock deadlock problem of the first client occurs, then the file lock management information for the target file lock is generated, and then the file lock management node actively generates the target file lock for the deadlocked file when the first client is in a file deadlock situation. The target file lock is generated by the file lock management information, and then the file lock management information is sent to the first client, so that the first client can perform management operations on the target file lock based on the file lock management information to obtain the file lock operation result, and finally after receiving the file lock operation result fed back by the first client, the target file lock acquisition request result is fed back to the second client, thereby realizing the file lock management information generated by the file lock management node, acting as a management intermediary for the competition between the first client and the second client for the target file lock, and reasonably managing the target file lock, rather than causing a file deadlock due to abnormal communication between the metadata server and the first client during the file lock management process. Therefore, the technical defect that other clients cannot read specific files through file locks, which makes it easy to interrupt business, is overcome, and the management self-healing property of file lock management is improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the drawings required for use in the embodiments or the related technical descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0038] Figure 1 A schematic diagram of information interaction between a metadata server, a file lock management node and a client in a file lock management method in an embodiment;

[0039] Figure 2 A flowchart of a file lock management method in one embodiment;

[0040] Figure 3 A timing diagram of releasing a file deadlock during a file lock management process of a file lock management method in another embodiment;

[0041] Figure 4 A schematic diagram of the structure of a file lock management system of a file lock management method in one embodiment;

[0042] Figure 5 is a structural block diagram of a file lock management device in one embodiment;

[0043] Figure 6 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0044] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0045] First of all, it should be understood that in a distributed file system, when multiple clients read and write the same file in the same time period, data reading and writing errors need to be avoided to ensure the reliability of distributed system data. To solve the above problems, file locks are usually applied to ensure that the client has exclusivity in the process of updating data. In the management process of file locks, information interaction is usually involved between the file lock management node, the metadata server and the client. Among them, the file lock management node is used to maintain the client view, monitor new clients joining the view, and delete abnormal clients from the view, for example, delete the client whose heartbeat signal is lost from the view, maintain the file system view, allocate the MDS file system and record the mapping relationship between the file system and the MDS; the metadata server is used to load and maintain the specified file system, file status and provide metadata read and write interfaces, as well as provide file system operation interfaces to the client, obtain the client view from the file lock management node, and check whether the abnormal client still occupies the file. Use file locks, and if there are any, force the file locks to be released; the client provides file operation semantics to the upper-level application, including create / delete, open / close, read and write operations, and registers with the file lock management node and maintains heartbeats, obtains the file system view, and from the file view, can obtain on which target metadata database the operated file is located. Under normal circumstances, the metadata server, the client and the file lock management node communicate normally. The implementation principle of the file lock is as follows: the client obtains the file lock when opening the file, and releases the file lock synchronously when closing the file. If the client has an exception and cannot actively release the file lock, the file management node can monitor whether the current client has an exception. If an exception occurs, the client is directly removed. Then, when the metadata server finds that the current client does not exist through the file lock management node, it forcefully releases the file lock. However, if a local network exception occurs, it may cause a file deadlock, which makes other clients unable to access the file, and eventually leads to business interruption. Refer to Figure 1 , Figure 1 The schematic diagram is a diagram showing the information interaction between the metadata server, the file lock management node and the client, wherein the communication between the client and the file lock management node is normal, the heartbeat is maintained, and the client is retained. When the client sends a message to obtain the file lock to the metadata server, the metadata server will assign the file lock to the client and persist it. Further, the metadata server replies to the client. At this time, the communication between the metadata server and the client is abnormal. The client receives the network abnormality and thinks that it has not obtained the file lock (in fact, the meta server has given the file lock to the client). The client will not actively release the file lock subsequently. Since the file lock management node has retained the client, it will not force the client to release the file lock. At this time, a file deadlock will occur, and other clients cannot access the file corresponding to the file lock. Therefore, a file lock management method that improves the self-healing property of file lock management is urgently needed.

[0046] In one embodiment, Figure 2 As shown, a file lock management method is provided. This embodiment takes the method applied to a file lock management node as an example. The file lock management node can be specifically a terminal, and the terminal includes but is not limited to a personal computer, a laptop computer, a smart phone, and a tablet computer. The terminal includes a generation module, a first sending module, and a second sending module. The generation module is used to generate file lock management information of a target file lock corresponding to the first client according to a file lock acquisition request sent to the first client when abnormal communication between the metadata server and the first client is detected. The file lock acquisition request is sent by the second client to the file lock management node, and the second sending module is used to send the file lock management information to the first client, so that the first client can obtain the target file lock according to the file lock management information. Execute management operations to obtain file lock operation results. The first sending module is used to generate a target file lock acquisition request result based on the file lock operation result after receiving the file lock operation result sent by the first client, and send the acquisition request result to the second client. Through the information interaction between the generation module, the second sending module and the first sending module, the file lock management information generated by the file lock management node can be realized, acting as a management intermediary for the competition between the first client and the second client for the target file lock, and reasonably managing the target file lock, thereby avoiding file deadlock situations and improving the management self-healing of file lock management. It can be understood that this method can also be applied to servers, and can also be applied to systems including terminals and servers, and is implemented through the interaction between terminals and servers. In this embodiment, the method includes the following steps 202 to 206. Among them:

[0047] Step 202, when a communication anomaly is detected between the metadata server and the first client, file lock management information of a target file lock corresponding to the first client is generated according to a file lock acquisition request sent to the first client, wherein the file lock acquisition request is sent by the second client to the file lock management node.

[0048] It should be noted that, in the case of file deadlock, in the traditional file lock management process, the second client still cannot obtain the file lock after sending a file lock acquisition request to the file lock management node. At this time, if the metadata server and the first client communicate normally, the metadata server can actively ask the first client whether it still needs to occupy the file lock, and actively release the file lock when the first client confirms that it does not need to continue to occupy the file lock. However, if the communication between the metadata server and the first client is abnormal, file deadlock will occur when the file lock management is performed through the traditional file lock management process. Therefore, the self-healing ability of the file lock management is poor at this time, and then the reasonable management of the file lock can be achieved through the active operation of the file lock management node.

[0049] It should be noted that the file lock acquisition request is used to request to obtain the target file lock corresponding to the first client, and is specifically sent by the second client to the file lock management node. It can be understood that the first client is the client currently occupying the target file lock, and the second client is the client requesting to occupy the target file lock. The target file lock is determined by the file lock management node through the file lock information fed back by the metadata server. For example, in an implementable manner, after the file lock management node receives the file lock acquisition request sent by the second client, the metadata server will actively report the file lock occupation status of the first client to the file lock management node, and then the file lock management node can determine the target file lock that the second client wants to request to occupy after comparison, and then generate corresponding file lock management information for the target file lock. The file lock management information is used to manage the file lock. For example, the file lock management information can specifically be a notification message notifying the first client itself that it occupies the target file lock. After receiving the notification message, if the first client does not need to continue to occupy the target file lock, it will actively release the target file lock so that the second client can occupy the target file lock later.

[0050] As an example, step 202 includes: when a communication anomaly between the metadata server and the first client is periodically detected, if a file lock acquisition request sent by the second client to the first client is obtained, the file lock identification information is extracted from the file lock acquisition request, and based on the comparison result between the file lock identification information and the file lock occupancy information of the first client fed back by the metadata database, the target file lock of the first client that the second client wants to occupy is determined, and the file lock management information corresponding to the target file lock is generated.

[0051] Step 204: Send the file lock management information to the first client, so that the first client can perform a management operation on the target file lock according to the file lock management information to obtain a file lock operation result.

[0052] It should be noted that after the file lock management node sends the file lock management information to the first client, the first client can perform corresponding management operations according to its own situation. For example, the first client can release the target file lock or continue to occupy the target file lock. It can be understood that after the first client performs a management operation on the target file lock, it can report the file lock operation result to the file lock management node, and the metadata server can also report to the file lock management node after receiving the file lock management operation feedback from the first client.

[0053] As an example, step 204 includes: sending file lock management information to the first client, so that the first client performs a management operation on the target file lock according to the file lock management information to obtain a file lock operation result.

[0054] Step 206: after receiving the file lock operation result sent by the first client, generate an acquisition request result of the target file lock according to the file lock operation result, and send the acquisition request result to the second client.

[0055] It should be noted that after receiving the file lock operation result, the file lock management node actively feeds back the target file lock acquisition request result to the second client, so that the second client can perform the corresponding file lock processing operation based on the acquisition request result. For example, in one implementable method, the acquisition request result can specifically be a result that instructs the second client to obtain the target file lock again.

[0056] As an example, step 206 includes: after receiving the file lock management result sent by the first client, generating an acquisition request result for the target file lock according to the file lock operation result, and sending the acquisition request result to the second client, so that the second client can send the file acquisition request again based on the acquisition request result.

[0057] In one practicable manner, referring to Figure 3 , Figure 3The timing diagram is for releasing a file deadlock during the file lock management process, wherein the second client first reports a file lock acquisition request for the first client to the metadata server, and the metadata server informs the second client that the file lock acquisition has failed. At this time, the metadata server reports the file lock occupancy information of the first client to the file lock management node, and the file lock management node sends file lock management information carrying a notification of the occupation of the target file lock to the first client when detecting an abnormal communication between the first client and the metadata server. Then, when the first client realizes that it does not need to continue to occupy the target file lock, it actively releases the target file lock. Finally, the second client obtains the target file lock again under the instruction of the acquisition request result sent by the file lock management node, and successfully occupies the target file lock.

[0058] In the above file lock management method, the communication status between the metadata server and the first client is first detected. When the communication between the metadata server and the first client is detected to be abnormal, if the file lock acquisition request sent by the second client to the file lock management node for the first client is obtained, the target file lock that the second client wants to occupy is determined, and corresponding file lock management information is generated, and then the file lock management information is sent to the first client, so that the first client can perform corresponding management operations on the target file lock based on the file lock management information, and after the file lock operation result performed by the first client, the target file lock acquisition request result is generated, thereby providing a basis for the second client to send the file lock acquisition request again and successfully occupy the target file lock, thereby achieving the purpose of reasonably managing the target file lock by acting as a management intermediary for the competition between the first client and the second client through the file lock management information generated by the file lock management node, rather than causing a file deadlock due to abnormal communication between the metadata server and the first client during the file lock management process. Therefore, the technical defect that other clients cannot read specific files through file locks, which makes it easy to cause business interruption, is overcome, and the management self-healing property of file lock management is improved.

[0059] In one embodiment, Figure 4 As shown, according to the file lock acquisition request sent by the first client, the file lock management information of the target file lock corresponding to the first client is generated, including:

[0060] Step 302: extract the first file lock identity information from the file lock acquisition request, and acquire the second file lock identity information fed back by the first client.

[0061] It should be noted that the second file lock identity information fed back by the first client is used to identify the file lock identity currently occupied by the first client, and can be specifically fed back by the metadata server to the file lock management node. The first file lock identity information is used to identify the file lock identity that the second client wants to occupy. The first file lock identity information and the second file lock identity information can both exist in the form of fields. It can be understood that the time points at which the file lock management node obtains the first file lock identity information and the second file lock identity information may have no time sequence relationship.

[0062] As an example, step 302 includes: parsing the file lock acquisition request to obtain first file lock identity information, and receiving second file lock identity information of the first client fed back by the metadata server.

[0063] Step 304: Use the file lock jointly identified by the first file lock identity information and the second file lock identity information as the target file lock.

[0064] It should be noted that, since the first file lock identity information is used to specify and identify a certain file lock, and the second file lock identity information may identify multiple file locks, the file lock commonly identified by the two file lock identity information may be used as the target file lock.

[0065] As an example, step 304 includes: searching the second file lock identity information for a file lock that matches the first file lock identity information as a target file lock.

[0066] Step 306: Generate corresponding file lock management information according to the file lock usage status of the target file lock.

[0067] It should be noted that the file lock usage information is used to reflect the usage status of the target file lock by the first client, and the file lock management information obtained by encapsulating the file lock usage status is sent to the first client by the file lock management node. The first client can know its current usage status of the target file lock, thereby providing a basis for the first client to perform corresponding management operations on the target file lock.

[0068] As an example, step 306 includes: receiving the file lock usage status of the target file lock fed back by the metadata server, and encapsulating the file lock usage status into corresponding file lock management information.

[0069] In this embodiment, in the process of generating file lock management information of the target file lock, the first file lock identity information and the second file lock identity information are first collected from different dimensions, and then the target file lock of the first client that the second client wants to occupy is determined through the first file lock identity information and the second file lock identity information, and finally, based on the file lock usage status of the target file lock, the corresponding file lock management operation is generated, so that the purpose of providing an operational basis for reasonable management of the target file lock by the file lock management node can be achieved, thereby laying a foundation for improving the self-healing management of file lock management.

[0070] In one embodiment, the file lock management information includes file lock release information and file lock holding information; and the corresponding file lock management information is generated according to the file lock state of the target file lock, including:

[0071] If the file lock usage status is in use, file lock holding information is generated; if the file lock usage status is not in use, file lock release information is generated.

[0072] It should be noted that, in addition to the ability to notify the first client of the usage status of the target file lock, the file lock management node can also actively instruct the first client to perform corresponding management operations on the target file lock. Therefore, the file lock management information includes file lock release information and file lock holding information, wherein the file lock release information is used to instruct the first client to release the target file lock, and the file lock holding information is used to instruct the first client to continue to hold the target file lock. The in-use state is used to indicate that the first client is using the target file lock, and the unused state is used to indicate that the first client is not using the target file lock. It can be understood that in the case of abnormal communication between the metadata server and the first client, the metadata server cannot send a message to the first client, but the first client can still send a message to the metadata server. Then, after receiving the file lock usage status of the target file lock fed back by the first client, the metadata server can feed back the file lock usage status to the file lock management node for the file lock management node to generate file lock management information.

[0073] As an example, if the file lock usage status is in use, file lock holding information is generated; if the file lock usage status is not in use, file lock release information is generated.

[0074] In this embodiment, the status types of the file lock usage status are first distinguished, and different types of file lock management information are generated based on the different types of file lock usage status. Then, based on the different file lock management information, the first client can be instructed to perform corresponding management operations on the target file lock. Therefore, while improving the self-healing ability of the file lock management, the management effect of the file lock management is also improved.

[0075] In one embodiment, generating file lock release information includes:

[0076] A trusted client list fed back by the first client is obtained; and when it is detected that the second client is in the trusted client list, file lock release information is generated.

[0077] It should be noted that since the identity of the second client is unknown, if the first client is rashly instructed to release the target file lock, the target file lock may be occupied by an unsafe client, thereby causing data leakage. Therefore, in the process of generating file lock release information, the file lock management node can be used to identify whether the second client is a trusted client of the first client to avoid the target file lock being released due to a file lock acquisition request sent by an unsafe client. It can be understood that the trusted client list records the client identification of one or more clients.

[0078] As an example, a list acquisition request is sent to the first client, and a trusted client list fed back by the first client is received based on the list acquisition request; when it is detected that the client identifier of the second client exists in the trusted client list, file lock release information is generated.

[0079] In this embodiment, in the process of generating file lock release information, a list acquisition request is first sent to the first client, and then by detecting whether the client identifier of the second client is located in the trusted client device, it is identified whether the second client is a trusted client of the first client. Finally, when the second client is identified as a trusted client of the first client, the file lock release information is generated, thereby avoiding the situation where the target file lock is released due to the file lock acquisition request sent by an unsafe client. Therefore, while improving the management self-healing property of file lock management, the management security of file lock management is also improved.

[0080] In one embodiment, the acquisition request result includes an acquisition request permission result and an acquisition request rejection result; and generating an acquisition request result of a target file lock according to the file lock operation result includes:

[0081] If the file lock operation result is a first file lock operation result in which the first client releases the target file lock, a get request permission result is generated; if the file lock operation result is a second file lock operation result in which the first client holds the target file lock, a get request rejection result is generated.

[0082] It should be noted that after receiving the file lock management information, the first client has the ability to independently decide whether to release the target file lock. Therefore, after performing corresponding management operations on the target file lock, it may feedback different types of file lock operations to the file lock management node. The file lock management node can generate different acquisition request results based on different file lock operation results. For example, the acquisition request result includes an acquisition request permission result and an acquisition request rejection result, so as to instruct the second client to perform corresponding processing operations based on different acquisition request results.

[0083] As an example, if the file lock operation result is the first file lock operation result in which the first client releases the target file lock, a request permission result is generated; if the file lock operation result is the second file lock operation result in which the first client holds the target file lock, a request rejection result is generated.

[0084] In this embodiment, based on the file lock operation performed by the first client on the target file lock, the first client can generate different types of file lock operation results, and then after the file lock management node receives different types of file lock operation results fed back by the first client, it generates different acquisition request results to indicate that the second client can perform different file lock processing operations based on the acquisition request result, such as requesting to obtain the target file lock again or canceling the acquisition of the target file lock, thereby achieving the purpose of targeted management of the target file lock in different application scenarios. Therefore, while improving the self-healing ability of file lock management, the management effect of file lock management is further improved.

[0085] In one embodiment, sending the acquisition request result to the second client includes:

[0086] The request type of the file lock acquisition request is detected; if the request type is the first request type, the request permission result is sent to the second client at a preset sending time point; if the request type is the second request type, the designated sending time point for obtaining the request permission result is determined according to the request time point of the file lock acquisition request, and the request permission result is sent to the second client at the designated sending time point.

[0087] It should be noted that, since the request type of the second client's request to obtain the file lock is different, the request permission results can be sent to the second client at different time points in a targeted manner. For example, when the second client obtains the target file lock in order to perform a read operation on the file corresponding to the target file lock, since the file can be read concurrently by different clients, the request permission result can be directly sent to the second client at a preset time point, wherein the preset time point is the same time point set for the file lock management node to send the request permission results to multiple clients. When the second client obtains the target file lock in order to perform a write operation on the file corresponding to the target file lock, a specified sending time point needs to be set for the second client to avoid possible data conflict problems.

[0088] As an example, the request type of the file lock acquisition request is detected based on the request identifier of the file lock acquisition request; if it is detected that the request type of the file lock acquisition request is a file read request, the request permission result is sent to the second client at a preset time point; if it is detected that the request type of the file lock acquisition request is a file modification request, based on the request time point of the file lock acquisition request, a designated sending time point for obtaining the request permission result is set for the second client, and the request permission result is sent to the second client at the designated sending time point.

[0089] In this embodiment, during the process of sending the request for permission results, different time points can be set for sending the request for permission results based on the processing operations to be performed on the file after the second client obtains the target file lock, thereby avoiding data conflicts that may occur after the request results are sent. Therefore, while improving the self-healing ability of file lock management, the management effect of file lock management is further improved.

[0090] In an implementable manner, the file lock management node first detects whether there is a communication anomaly between the metadata server and the first client. If there is a communication anomaly and a file lock acquisition request sent by the second client to the first client is obtained, the first file lock identity information is extracted from the file lock acquisition request, and the second file lock identity information fed back by the metadata server is obtained. Then, by comparing the first file lock identity information and the second file lock identity information, the target file lock to be accessed by the second client is determined, and file lock management information is generated according to the file lock usage status of the target file lock, and the file lock management information is sent to the first client, so that the first client can access the target file lock according to the file lock usage status. Management information, perform corresponding management operations on the target file lock, obtain the file lock operation result, and finally after the file lock management node receives the file lock operation result fed back by the metadata server, generate different acquisition request results according to different types of file lock operation results. If the acquisition request result is an acquisition request permission result, it is necessary to further detect the request type of the acquisition file lock request, so as to determine the sending time point of the acquisition request permission result based on different request types, and send the acquisition request permission result to the second client at the corresponding sending time point, so that the second client can perform the corresponding file lock processing operation based on the request permission result, thereby completing the effective management of the target file lock.

[0091] Through the above, the file lock management information generated by the file lock management node can be realized, acting as a management intermediary for the competition between the first client and the second client for the target file lock, and the purpose of reasonably managing the target file lock is not to cause a file deadlock due to abnormal communication between the metadata server and the first client during the file lock management process. Therefore, the technical defect that other clients cannot read specific files through file locks, thereby making it easy for business interruptions to occur is overcome, thereby improving the self-healing nature of file lock management.

[0092] It should be understood that, although the steps in the flowcharts involved in the above embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0093] Based on the same inventive concept, the embodiment of the present application also provides a file lock management device for implementing the file lock management method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more file lock management device embodiments provided below can refer to the limitations of the file lock management method above, and will not be repeated here.

[0094] In an exemplary embodiment, Figure 5 As shown, a file lock management device is provided, which is applied to a file lock management node, wherein the file lock management node, the metadata server and the first client are connected in pairs for communication, including: a generating module 401, a first sending module 402 and a second sending module 403, wherein:

[0095] A generating module 401 is used to generate file lock management information of a target file lock corresponding to the first client according to a file lock acquisition request sent to the first client when abnormal communication between the metadata server and the first client is detected, wherein the file lock acquisition request is sent by the second client to the file lock management node;

[0096] A first sending module 402 is used to send the file lock management information to the first client, so that the first client can perform a management operation on the target file lock according to the file lock management information to obtain a file lock operation result;

[0097] The second sending module 403 is used to generate an acquisition request result of the target file lock according to the file lock operation result after receiving the file lock operation result sent by the first client, and send the acquisition request result to the second client.

[0098] In one embodiment, the generating module 401 is further used for:

[0099] Extract the first file lock identity information from the file lock acquisition request, and obtain the second file lock identity information fed back by the first client; use the file lock jointly identified by the first file lock identity information and the second file lock identity information as the target file lock; and generate corresponding file lock management information according to the file lock usage status of the target file lock.

[0100] In one embodiment, the file lock management information includes file lock release information and file lock holding information; the generating module 401 is further used to:

[0101] If the file lock usage status is in use, the file lock holding information is generated; if the file lock usage status is not in use, the file lock release information is generated.

[0102] In one embodiment, the generating module 401 is further used for:

[0103] Acquire a trusted client list fed back by the first client; and generate the file lock release information when it is detected that the second client is in the trusted client list.

[0104] In one embodiment, the acquisition request result includes an acquisition request permission result and an acquisition request rejection result; the second sending module 403 is further used to:

[0105] If the file lock operation result is a first file lock operation result in which the first client releases the target file lock, the acquisition request permission result is generated; if the file lock operation result is a second file lock operation result in which the first client holds the target file lock, the acquisition request rejection result is generated.

[0106] In one embodiment, the second sending module 403 is further used for:

[0107] The request type of the file lock acquisition request is detected; if the request type is the first request type, the request permission result is sent to the second client at a preset sending time point; if the request type is the second request type, the designated sending time point of the acquisition request permission result is determined according to the request time point of the file lock acquisition request, and the acquisition request permission result is sent to the second client at the designated sending time point.

[0108] Each module in the above-mentioned file lock management device can be implemented in whole or in part by software, hardware or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute the operations corresponding to each module.

[0109] In an exemplary embodiment, a computer device is provided. The computer device may be a terminal, and its internal structure diagram may be as shown in FIG. Figure 6As shown. The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit and an input device. The processor, the memory and the input / output interface are connected via a system bus, and the communication interface, the display unit and the input device are connected to the system bus via the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner can be implemented through WIFI, a mobile cellular network, NFC (near field communication) or other technologies. When the computer program is executed by the processor, a file lock management method is implemented. Those skilled in the art can understand that Figure 6 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0110] In one embodiment, a computer device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above method embodiments when executing the computer program.

[0111] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0112] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0113] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

[0114] The technical features of the above embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0115] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A file lock management method, characterized in that: Applied to a file lock management node, the file lock management node, the metadata server and the first client are connected in pairs for communication, and the method includes: In the case of detecting a communication anomaly between the metadata server and the first client, generating file lock management information of a target file lock corresponding to the first client according to a file lock acquisition request sent to the first client, wherein the file lock acquisition request is sent by the second client to the file lock management node; Sending the file lock management information to the first client, so that the first client performs a management operation on the target file lock according to the file lock management information to obtain a file lock operation result; After receiving the file lock operation result sent by the first client, generating an acquisition request result of the target file lock according to the file lock operation result, and sending the acquisition request result to the second client.

2. The method according to claim 1, characterized in that The step of generating file lock management information of a target file lock corresponding to the first client according to the file lock acquisition request sent by the first client includes: Extracting the first file lock identity information from the file lock acquisition request, and acquiring the second file lock identity information fed back by the first client; taking the file lock jointly identified by the first file lock identity information and the second file lock identity information as the target file lock; Generate corresponding file lock management information according to the file lock usage status of the target file lock.

3. The method according to claim 2, characterized in that The file lock management information includes file lock release information and file lock holding information; the corresponding file lock management information is generated according to the file lock state of the target file lock, including: If the file lock usage status is in use, generating the file lock holding information; If the file lock usage status is an unused status, the file lock release information is generated.

4. The method according to claim 3, characterized in that The generating the file lock release information comprises: Obtaining a list of trusted clients fed back by the first client; In the case where it is detected that the second client is in the trusted client list, the file lock release information is generated.

5. The method according to claim 1, characterized in that The acquisition request result includes an acquisition request permission result and an acquisition request rejection result; The step of generating the acquisition request result of the target file lock according to the file lock operation result includes: If the file lock operation result is a first file lock operation result in which the first client releases the target file lock, generating the acquisition request permission result; If the file lock operation result is a second file lock operation result in which the first client holds the target file lock, the acquisition request rejection result is generated.

6. The method according to claim 5, characterized in that The sending the acquisition request result to the second client includes: Detecting the request type of the file lock acquisition request; If the request type is the first request type, sending the request permission result to the second client at a preset sending time point; If the request type is the second request type, the designated sending time point of the acquisition request permission result is determined according to the request time point of the file lock acquisition request, and the acquisition request permission result is sent to the second client at the designated sending time point.

7. A file lock management device, characterized in that: Applied to a file lock management node, the file lock management node, the metadata server and the first client are connected in pairs for communication, and the device includes: a generating module, configured to generate file lock management information of a target file lock corresponding to the first client according to a file lock acquisition request sent to the first client when abnormal communication between the metadata server and the first client is detected, wherein the file lock acquisition request is sent by the second client to the file lock management node; A first sending module, configured to send the file lock management information to the first client, so that the first client can perform a management operation on the target file lock according to the file lock management information to obtain a file lock operation result; The second sending module is used to generate an acquisition request result of the target file lock according to the file lock operation result after receiving the file lock operation result sent by the first client, and send the acquisition request result to the second client.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images