Request processing method and device of a distributed storage system

Abstract

The application relates to the technical field of distributed storage, and discloses a request processing method and equipment of a distributed storage system, which can receive a first file identifier sent by a metadata server through an intermediate cache module after the metadata server determines that a first file is a deleted file. First file cache data is determined according to the first file identifier, and a file state identifier in the first file cache data is set as a deletion identifier. When a file operation request containing the first file identifier sent by a first client is received, the file operation request is rejected according to the deletion identifier in the first file cache data, and the first client is prompted that the first file is invalid. The application can set a deletion identifier in file cache data when a file is deleted, and can reject a client request and prompt the client that the first file is invalid according to the deletion identifier in the file cache data when a write request of the file sent by the client is received, so that the write operation on the file is not needed, and the loss of written data is avoided.

Description

Technical Field

[0001] This invention relates to the field of distributed storage technology, and more specifically to a request processing method and device for a distributed storage system. Background Technology

[0002] With the development of computer science and technology, the business processing technology of distributed storage systems is constantly improving.

[0003] In a distributed storage system, when a client deletes a file, the system's cache may still contain data related to that file. Later, when another client initiates a write request to that file, the system will still perform the write operation on the file's data in the cache and return a success message. However, the other client will not be able to find the file, resulting in data loss. Summary of the Invention

[0004] In view of this, the present invention provides a request processing method and device for a distributed storage system to solve the above problems.

[0005] In a first aspect, the present invention provides a request processing method for a distributed storage system, the method comprising:

[0006] After the metadata server determines that the first file is a deleted file, it receives the first file identifier sent by the metadata server through the intermediate cache module; wherein, the first file identifier is used to identify the first file;

[0007] The first file cache data is determined from multiple file cache data locally based on the first file identifier; wherein the first file cache data includes a file status identifier and the first file identifier;

[0008] Set the file status identifier in the first file cache data to a deletion identifier;

[0009] When a file operation request containing the first file identifier is received from the first client, the file operation request is rejected according to the deletion identifier in the first file cache data, and a first notification message is returned to the first client. The first notification message is used to indicate that the first file has expired.

[0010] In one optional implementation, when a file operation request containing the first file identifier is received from a first client, rejecting the file operation request based on the deletion identifier in the first file cache data includes:

[0011] When the file operation request is received, the first file identifier in the file operation request is obtained;

[0012] The first file cache data is determined based on the obtained first file identifier, and the file status identifier in the first file cache data is obtained;

[0013] If the file status identifier is determined to be the deletion identifier, the first file is determined to be a deleted file, and the file operation request is rejected.

[0014] In one optional implementation, the step of receiving the first file identifier sent by the metadata server through the intermediate cache module after the metadata server determines that the first file is a deleted file includes:

[0015] Send an event registration instruction to the intermediate cache module so that the intermediate cache module registers a deletion callback event;

[0016] The intermediate cache module receives the first file identifier sent by the intermediate cache module when the deletion callback event is triggered; wherein the deletion callback event is triggered when the intermediate cache module receives the first file identifier sent by the metadata server, and the first file identifier is sent to the intermediate cache module by the metadata server after determining that the first file is the deleted file.

[0017] In an optional implementation, the method further includes:

[0018] When a file processing request containing a second file identifier is received from a second client, the second file identifier is obtained from the file processing request. The second file identifier is used to identify the second file.

[0019] If it is determined that no file cache data corresponding to the second file identifier exists in the multiple local file cache data, a query instruction containing the second file identifier is sent to the intermediate cache module so that the intermediate cache module searches for whether there is a second file cache data corresponding to the second file identifier in the multiple file cache data;

[0020] When the intermediate cache module receives the first message returned by the intermediate cache module, it determines that the second file is a deleted file, rejects the file processing request, and returns a second notification message to the second client; wherein, both the first message and the second notification message are used to indicate that the second file is invalid; the first message is sent by the intermediate cache module when it does not find the cached data of the second file, or when the intermediate cache module finds the cached data of the second file and determines that the file status identifier in the cached data of the second file is a deletion identifier, the deletion identifier in the cached data of the second file is set by the intermediate cache module in the cached data of the second file after receiving the second file identifier sent by the metadata server, and the second file identifier is sent by the metadata server to the intermediate cache module when it determines that the second file is a deleted file;

[0021] When the second message returned by the intermediate cache module is received, it is determined that the second file is not a deleted file; wherein, the second message is used to indicate that the second file is a valid file, and the second message is sent by the intermediate cache module when it finds the cached data of the second file and determines that the file status identifier in the cached data of the second file is not a deleted identifier.

[0022] In one optional implementation, the second file cache data includes file data; after determining that the second file is not a deleted file, the method further includes:

[0023] Send a file operation instruction corresponding to the file processing request to the intermediate cache module so that the intermediate cache module performs the corresponding operation on the file data in the second file cache data.

[0024] In an optional implementation, after obtaining the second file identifier from the file processing request, the method further includes:

[0025] If it is determined that a third file cache data corresponding to the second file identifier exists among multiple local file cache data, the file status identifier in the third file cache data is obtained; the third file cache data includes the file status identifier and file data;

[0026] When the file status identifier in the third file cache data is not a deletion identifier, the corresponding operation is performed on the file data in the third file cache data according to the file processing request.

[0027] In a second aspect, the present invention provides a request processing device for a distributed storage system, the device comprising:

[0028] The first receiving module is configured to receive a first file identifier sent by the metadata server through an intermediate cache module after the metadata server determines that the first file is a deleted file; wherein the first file identifier is used to identify the first file;

[0029] The first determining module is configured to determine first file cache data from multiple file cache data in a local location based on the first file identifier; wherein the first file cache data includes a file status identifier and the first file identifier;

[0030] The first setting module is used to set the file status identifier in the first file cache data to a deletion identifier;

[0031] The first rejection module is used to reject the file operation request based on the deletion identifier in the first file cache data when it receives a file operation request containing the first file identifier sent by the first client.

[0032] The first return module is used to return a first notification message to the first client, the first notification message being used to indicate that the first file has expired.

[0033] Thirdly, the present invention provides a request processing apparatus for a distributed storage system, the apparatus comprising a metadata server, an intermediate cache module, and a server; wherein:

[0034] The metadata server is configured to send a first file identifier to the server through the intermediate cache module after determining that the first file is a deleted file; wherein the first file identifier is used to identify the first file;

[0035] The server is configured to determine first file cache data from multiple local file cache data based on the first file identifier; wherein the first file cache data includes a file status identifier and the first file identifier; set the file status identifier in the first file cache data as a deletion identifier; when receiving a file operation request containing the first file identifier sent by a first client, rejecting the file operation request based on the deletion identifier in the first file cache data and returning a first notification message to the first client, the first notification message being used to indicate that the first file has expired.

[0036] Fourthly, the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the request processing method of the distributed storage system of the first aspect or any corresponding embodiment described above.

[0037] Fifthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to execute the request processing method of the distributed storage system of the first aspect or any corresponding embodiment described above.

[0038] The request processing method and device for a distributed storage system provided by this invention can receive a first file identifier sent by the metadata server through an intermediate cache module after the metadata server determines that a first file is a deleted file; wherein, the first file identifier is used to identify the first file. First file cache data is determined from multiple local file cache data based on the first file identifier; wherein, the first file cache data includes a file status identifier and the first file identifier. The file status identifier in the first file cache data is set as a deletion identifier; when a file operation request containing the first file identifier is received from a first client, the file operation request is rejected according to the deletion identifier in the first file cache data, and a first notification message is returned to the first client, which is used to indicate that the first file is invalid. This embodiment can set a deletion identifier in the corresponding file cache data when a file is deleted, and can reject the client's request and return a notification message to the client when a write request for the file is received from a client, without performing a write operation on the file, thus avoiding the loss of written data. Attached Figure Description

[0039] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0040] Figure 1 This is one of the flowcharts illustrating a request processing method for a distributed storage system according to an embodiment of the present invention;

[0041] Figure 2 This is a schematic diagram of the processing flow of the metadata server according to an embodiment of the present invention;

[0042] Figure 3 This is a schematic diagram of the processing flow of the intermediate cache module according to an embodiment of the present invention;

[0043] Figure 4 This is a second flowchart illustrating a request processing method for a distributed storage system according to an embodiment of the present invention.

[0044] Figure 5 This is a schematic diagram of the structure of a request processing device in a distributed storage system according to an embodiment of the present invention;

[0045] Figure 6 This is a schematic diagram of the structure of a request processing device for a distributed storage system according to an embodiment of the present invention;

[0046] Figure 7 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0048] According to an embodiment of the present invention, a request processing method embodiment for a distributed storage system is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0049] like Figure 1 As shown, this embodiment proposes a first request processing method for a distributed storage system, which may include the following steps:

[0050] S101. After the metadata server determines that the first file is a deleted file, receive the first file identifier sent by the metadata server through the intermediate cache module; wherein, the first file identifier is used to identify the first file.

[0051] It should be noted that a distributed storage system may include multiple node devices, and each node device may include an intermediate storage module and a server.

[0052] The intermediate storage module can be a lib module. The server can be a Network File System (NFS) server, i.e., Ganesha, or the server corresponding to the fuse client.

[0053] Specifically, this embodiment can be applied to the server side of the aforementioned node device.

[0054] Understandably, in a distributed storage system, the metadata server (MDS) is responsible for managing the metadata information of the entire file system. When a client deletes a file, causing changes to the file's metadata, the MDS will definitely be able to detect it.

[0055] Specifically, when a file is deleted by a fuse client or NFS client, MDS will detect the update immediately and send the file identifier of the file to the server in the aforementioned node device through the intermediate cache module.

[0056] It's important to note that different intermediate cache modules have different permissions for operating on their respective files. MDS can record the corresponding files and intermediate cache modules, storing this information as a list. Specifically, for a given file, MDS can associate that file with all intermediate cache modules that have permissions to operate on it, and store this association as a list.

[0057] Specifically, when a file is deleted by the Fuse client, MDS can detect the deletion and notify the intermediate cache modules that the file has been deleted by sending the file identifier to all intermediate cache modules that have access permissions to the file. MDS can avoid sending the file identifier to intermediate cache modules that have not accessed the file, thus eliminating the need to notify them of the deletion.

[0058] The first file identifier is the file identifier of the first file.

[0059] Optionally, the MDS can send an announcement message carrying the first file identifier to the intermediate cache module, which can then forward the announcement message to the server in its node device. The server can then obtain the first file identifier from this announcement message.

[0060] It is understandable that when MDS sends notification messages to the relevant intermediate cache modules, it can realize cross-node device information transmission, effectively ensuring that the intermediate cache modules on each node device can synchronously obtain notification messages and ensure information synchronization.

[0061] S102. Determine the first file cache data from multiple file cache data locally based on the first file identifier; wherein the first file cache data includes a file status identifier and the first file identifier.

[0062] Among them, file cache data refers to the data related to a certain file cached on the server side.

[0063] Specifically, the file cache data may include a file status identifier and a file identifier. The file status identifier is information added to the cached file-related data in this embodiment, and can be used to identify the status of the corresponding file, such as whether it has been deleted or not. The file identifier is the file identifier of the corresponding file.

[0064] It should be noted that the server locally stores cached data for multiple files, meaning it caches data for multiple files. Specifically, the intermediate cache module can also include cached data for multiple files.

[0065] Specifically, in this embodiment, the file cache data containing the first file identifier can be found among multiple local file cache data based on the first file identifier, and then identified as the first file cache data.

[0066] S103. Set the file status flag in the first file cache data to the deletion flag.

[0067] The deletion flag can be used to indicate that a file has been deleted.

[0068] Specifically, in this embodiment, the deletion flag `delete_flag` can be used as a parameter name, and its corresponding parameter value can be set to either a deleted or non-deleted flag. The non-deleted flag indicates that the file has not been deleted.

[0069] The parameter values ​​can be either true (true) or false (false). When the parameter value is true, the file status is deleted. When the parameter value is false, the file status is not deleted.

[0070] Optionally, the server can also add the first file cache data to a deletion queue, and clear the corresponding file cache data based on the file cache data recorded in the deletion queue at regular intervals, such as once every 2 minutes, to release the count and release the cache. Furthermore, the server can also notify the intermediate cache module to delete the corresponding file cache data to release the count of the relevant file identifier and release the cache.

[0071] S104. When a file operation request containing a first file identifier is received from the first client, the file operation request is rejected according to the deletion identifier in the first file cache data, and a first notification message is returned to the first client. The first notification message is used to indicate that the first file has expired.

[0072] The first client can be an NFS client.

[0073] Specifically, a file operation request can be used to request the execution of related operations on the first file, such as write operations and copy operations.

[0074] Optionally, step S104 may specifically include:

[0075] When a file operation request is received, the first file identifier in the file operation request is obtained;

[0076] The first file cache data is determined based on the obtained first file identifier, and the file status identifier in the first file cache data is obtained;

[0077] If the file status identifier is determined to be a deletion identifier, the first file is determined to be a deleted file, the file operation request is rejected, and a first notification message is returned to the first client.

[0078] Specifically, in this embodiment, the first file cache data can be found from multiple local file cache data based on the first file identifier, and the file status identifier in the first file cache data can be obtained, effectively ensuring the smooth acquisition of the first file cache data and the subsequent further processing.

[0079] It is understood that this embodiment can determine that the file status identifier in the first file cache data is the deletion identifier. At this time, this embodiment can determine that the first file has been deleted, without needing to execute a file operation request, and can return a first notification message to the client, that is, an exception message to the client indicating that the first file does not exist.

[0080] It should be noted that this embodiment can improve data security during concurrent access and deletion in multi-protocol, multi-client scenarios, ensuring that write data results do not generate false alarms and avoiding the problem where a client requests to perform a write operation on a file even though the file has been deleted by another client, but the write operation still shows as successful. This embodiment can set up multiple layers of caching and verification interception in the intermediate caching module and server protocol, allowing clients to detect anomalies immediately and avoiding problems such as difficulty in data location due to data loss. It can also prevent file conflicts caused by caching when one client deletes a file and another client creates a file with the same name. This embodiment starts from the underlying storage software level, effectively ensuring that information is synchronized across clients in real time after a file is deleted, preventing other clients from accessing the file again. It directly improves the data consistency mechanism for multi-client information synchronization and enhances the security of user business scenarios.

[0081] The request processing method for the distributed storage system proposed in this embodiment can receive a first file identifier sent by the metadata server through an intermediate cache module after the metadata server determines that the first file is a deleted file; wherein the first file identifier is used to identify the first file. Based on the first file identifier, first file cache data is determined from multiple local file cache data; wherein the first file cache data includes a file status identifier and the first file identifier. The file status identifier in the first file cache data is set as a deletion identifier; when a file operation request containing the first file identifier is received from a first client, the file operation request is rejected based on the deletion identifier in the first file cache data, and a first notification message is returned to the first client, which is used to indicate that the first file is invalid. This embodiment can set a deletion identifier in the corresponding file cache data when a file is deleted, and can reject the client's request and return a notification message to the client based on the deletion identifier in the file cache data when a client writes to the file, without performing a write operation on the file, thus avoiding the loss of written data.

[0082] based on Figure 1 This embodiment proposes a second request processing method for a distributed storage system. In this method, step S101 may include:

[0083] Send an event registration instruction to the intermediate cache module so that the intermediate cache module registers a deletion callback event;

[0084] The intermediate cache module receives the first file identifier sent by the intermediate cache module when the deletion callback event is triggered. The deletion callback event is triggered when the intermediate cache module receives the first file identifier sent by the metadata server. The first file identifier is sent to the intermediate cache module by the metadata server after determining that the first file is a deleted file.

[0085] Specifically, the intermediate caching module can send a first file identifier to the server when the deletion callback event is triggered, so that the server can determine the first file cache data based on the first file identifier and set the deletion identifier in the first file cache data.

[0086] The request processing method for the distributed storage system proposed in this embodiment can achieve the intermediate cache module sending the first file identifier to the server and triggering the server to perform further processing by registering a deletion callback event.

[0087] based on Figure 1 This embodiment proposes a third request processing method for a distributed storage system, which may further include:

[0088] When a file processing request containing a second file identifier is received from a second client, the second file identifier is obtained from the file processing request. The second file identifier is used to identify the second file.

[0089] If it is determined that no file cache data corresponding to the second file identifier exists in the multiple file cache data locally, a query instruction containing the second file identifier is sent to the intermediate cache module so that the intermediate cache module can search in the multiple file cache data for whether there is a second file cache data corresponding to the second file identifier;

[0090] When the intermediate caching module receives the first message, it determines that the second file is a deleted file, rejects the file processing request, and returns a second notification message to the second client. Both the first and second notification messages are used to indicate that the second file is invalid. The first message is sent by the intermediate caching module when it does not find the cached data for the second file, or when it finds the cached data for the second file and determines that the file status identifier in the cached data is a deletion identifier. The deletion identifier in the cached data is set by the intermediate caching module after receiving the second file identifier sent by the metadata server. The second file identifier is sent by the metadata server to the intermediate caching module when it determines that the second file is a deleted file.

[0091] When the second message returned by the intermediate cache module is received, it is determined that the second file is not a deleted file. The second message is used to indicate that the second file is a valid file. The second message is sent by the intermediate cache module when it finds the cached data of the second file and determines that the file status identifier in the cached data of the second file is not a deleted identifier.

[0092] Specifically, the second client can be a different client than the first client. For example, when the first client is the first NFS client, the second client can be the second NFS client.

[0093] The file processing request is the same as the file operation request mentioned above, and is also used to request the execution of related operations on the file, such as write or copy operations.

[0094] Specifically, when the server receives a file processing request from the second client, it can obtain the second file identifier from the file processing request and search for the existence of the corresponding second file cache data in multiple local file cache data based on the second file identifier.

[0095] If the server finds the second file cache data, it can retrieve the file status identifier from the cache. When the file status identifier is "deleted," the server rejects the file processing request and sends a notification message to the second client, informing them of the file's non-existence. When the file status identifier is not "deleted," the server executes the corresponding file operations normally according to the file processing request.

[0096] If the server does not find the second file cache data, it can send a query command to the intermediate cache module.

[0097] Specifically, after receiving a query command, the intermediate cache module can obtain the second file identifier from the query command and search for the existence of the second file cache data in its own cached multiple file cache data based on the second file identifier.

[0098] If the intermediate caching module finds the second file cache data, it can retrieve the file status identifier from the second file cache data. When the file status identifier is a deletion identifier, the intermediate caching module returns the first message mentioned above to the server, causing the server to reject the file processing request and return a second notification message to the second client. When the file status identifier is not a deletion identifier, the intermediate caching module can return a second message to the server, allowing the server to determine that the second file has not been deleted.

[0099] If the intermediate caching module does not find the second file cache data, it can directly return the first message mentioned above to the server, causing the server to reject the file processing request and return the second notification message to the second client.

[0100] Optionally, the second file cache data mentioned above includes file data; after determining that the second file is not a deleted file, the method further includes:

[0101] Send a file operation instruction corresponding to the file processing request to the intermediate cache module so that the intermediate cache module can perform the corresponding operation on the file data in the second file cache data.

[0102] Optionally, after obtaining the second file identifier from the file processing request as described above, the method further includes:

[0103] If it is determined that a third file cache data corresponding to the second file identifier exists among multiple local file cache data, the file status identifier in the third file cache data is obtained; the third file cache data includes the file status identifier and file data;

[0104] When the file status identifier in the third file cache data is not a deletion identifier, perform the corresponding operation on the file data in the third file cache data according to the file processing request.

[0105] Specifically, if the server determines that the second file has not been deleted, it can perform the corresponding file operations according to the file processing request, effectively ensuring the execution of normal file operations and thus ensuring the normal operation of the business.

[0106] like Figure 2 As shown, this embodiment provides a flowchart of MDS processing to better illustrate the MDS processing flow.

[0107] Reference Figure 2 When a fuse client deletes a file, MDS will detect the update immediately. MDS will also check the intermediate cache modules that have permissions to operate on the file, i.e., the lib clients that own the file's cap, and notify each lib client that the file has been deleted. For lib clients that have not accessed the file, MDS will not process the request and will not notify them.

[0108] like Figure 3 As shown, this embodiment provides a processing flowchart of an intermediate cache module to better illustrate the processing flow of the intermediate cache module.

[0109] Reference Figure 3 The intermediate cache module, namely the lib module, can update the local cache information after receiving the mds message, and at the same time call the ganesha module, which is the deletion callback function registered by the server.

[0110] Specifically, when the lib module receives a file deletion notification from the mds for a specific file, it looks up the corresponding file cache data based on the file identifier it carries. It then decrements the file access count and marks the file as deleted from the cache. In other words, it sets a deletion flag in the file cache data so that the next time the client accesses the file, it can directly return an exception message indicating that the file does not exist. Afterward, the lib module can call the deletion callback function registered by ganesha, causing ganesha to perform subsequent processing. When ganesha calls the lookup interface to query the file, the lib module can find the deletion flag in the corresponding file cache data and directly return that the file does not exist.

[0111] like Figure 4 As shown, this embodiment provides a flowchart of the processing of the MDS, intermediate cache module, and server execution to better illustrate the request processing method of this embodiment.

[0112] Reference Figure 4 The execution flow of the fuse client, mds, and lib module can be referenced. Figure 2 and Figure 3The relevant explanations are as follows. Specifically, `mds` can detect file deletion immediately when a file is deleted on the Fuse client and notify all client lib modules. The lib module can mark the lib cache, that is, determine the corresponding file cache data in its own cache and set a deletion flag. It can also trigger the deletion callback function registered by `ganesha`. Through the `ganesha` callback function, the cache is checked and invalidated; that is, the corresponding file cache data is found in `ganesha` and a deletion flag is set in the file cache data.

[0113] Reference Figure 4 For Ganesha, after startup, it can register a deletion callback function with the lib module. When Ganesha receives a client's file operation request, it retrieves the file identifier from the request and checks if it's cached. Specifically, it searches multiple local file caches for the corresponding file. If found, it checks if the cache is invalid, specifically whether the file status identifier in the cache is a deletion identifier. If it is a deletion identifier, the file does not exist, the client's file operation request is rejected, and a file non-existent exception message is returned, ending the request processing. If not, the file processing proceeds normally.

[0114] If ganesha cannot find the corresponding file cache data in multiple local file cache data, it can call the lookup interface to send a query command to the lib module.

[0115] Specifically, when the lib module receives a query command, it searches its multiple file caches for the corresponding file. If the corresponding file is found and its file status identifier is not a deletion identifier, it returns a normal message to ganesha (lookup returns normal), allowing ganesha to perform the file operation normally. If the corresponding file is not found, or if the found file contains a deletion identifier, it returns an exception message to ganesha (lookup returns file not found), causing ganesha to execute the corresponding handling logic for a non-existent file.

[0116] It should also be noted that this embodiment starts from the underlying storage software level, ensuring that information from all clients is synchronized in real time after a client deletes a file, preventing other clients from accessing the file. Through the mds, lib modules, and the Ganesha deletion callback notification mechanism, file deletion is promptly detected and synchronized across multiple protocols and clients, preventing data loss and corruption caused by operations still being performed on the file after deletion, thus solving the data synchronization problem in multi-protocol, multi-client scenarios.

[0117] This embodiment also provides a request processing device for a distributed storage system, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0118] like Figure 5 As shown, this embodiment proposes a request processing device for a distributed storage system, the device comprising:

[0119] The first receiving module 501 is used to receive a first file identifier sent by the metadata server through the intermediate cache module after the metadata server determines that the first file is a deleted file; wherein the first file identifier is used to identify the first file;

[0120] The first determining module 502 is used to determine the first file cache data from multiple file cache data in the local system based on the first file identifier; wherein the first file cache data includes a file status identifier and the first file identifier;

[0121] The first setting module 503 is used to set the file status identifier in the first file cache data to a deletion identifier;

[0122] The first rejection module 504 is used to reject the file operation request based on the deletion identifier in the first file cache data when it receives a file operation request containing a first file identifier sent by the first client.

[0123] The first return module 505 is used to return a first notification message to the first client. The first notification message is used to indicate that the first file has expired.

[0124] Optionally, the first rejection module 504 is also used to obtain the first file identifier in the file operation request when a file operation request is received;

[0125] Optionally, the first rejection module 504 is further configured to determine the first file cache data based on the acquired first file identifier, and obtain the file status identifier in the first file cache data;

[0126] Optionally, the first rejection module 504 is also used to determine that the first file is a deleted file and reject the file operation request if the file status identifier is a deletion identifier.

[0127] Optionally, the first receiving module 501 is also used to send an event registration instruction to the intermediate cache module so that the intermediate cache module registers a deletion callback event;

[0128] Optionally, the first receiving module 501 is further configured to receive a first file identifier sent by the intermediate cache module when the deletion callback event is triggered; wherein, the deletion callback event is triggered when the intermediate cache module receives the first file identifier sent by the metadata server, and the first file identifier is sent to the intermediate cache module by the metadata server after determining that the first file is a deleted file.

[0129] Optionally, the above-mentioned device further includes:

[0130] The first acquisition module is used to acquire the second file identifier from the file processing request when it receives a file processing request containing the second file identifier sent by the second client. The second file identifier is used to identify the second file.

[0131] The first sending module is used to send a query instruction containing the second file identifier to the intermediate cache module when it is determined that no file cache data corresponding to the second file identifier exists in the multiple file cache data locally, so that the intermediate cache module can search in the multiple file cache data for whether there is a second file cache data corresponding to the second file identifier.

[0132] The second determining module is used to determine that the second file is a deleted file when it receives the first message returned by the intermediate caching module;

[0133] The second rejection module is used to reject file processing requests;

[0134] The second return module is used to return a second notification message to the second client. Both the first message and the second notification message are used to indicate that the second file has expired. The first message is sent by the intermediate caching module when it cannot find the cached data for the second file, or when it finds the cached data for the second file and determines that the file status identifier in the cached data is a deletion identifier. The deletion identifier in the cached data is set by the intermediate caching module after receiving the second file identifier sent by the metadata server. The second file identifier is sent by the metadata server to the intermediate caching module when it determines that the second file is a deleted file.

[0135] The third determining module is used to determine that the second file is not a deleted file when it receives the second message returned by the intermediate caching module. The second message is used to indicate that the second file is a valid file. The second message is sent by the intermediate caching module when it finds the cached data of the second file and determines that the file status identifier in the cached data of the second file is not a deleted identifier.

[0136] Optionally, the second file cache data includes file data; the above apparatus further includes:

[0137] The second sending module is used to send a file operation instruction corresponding to the file processing request to the intermediate cache module after determining that the second file is not a deleted file, so that the intermediate cache module can perform corresponding operations on the file data in the cached data of the second file.

[0138] Optionally, the above-mentioned device further includes:

[0139] The second acquisition module is used to acquire the file status identifier in the third file cache data when it is determined that there is third file cache data corresponding to the second file identifier among multiple local file cache data; the third file cache data includes the file status identifier and file data;

[0140] The first execution module is used to perform corresponding operations on the file data in the third file cache data according to the file processing request when the file status identifier in the third file cache data is not a deletion identifier.

[0141] Further functional descriptions of the above modules are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0142] The request processing device of the distributed storage system proposed in this embodiment can set a deletion flag in the corresponding file cache data when a file is deleted, and can reject the client's request and return a notification message to the client when a client writes to the file based on the deletion flag in the file cache data, without performing a write operation on the file, thus avoiding the loss of written data.

[0143] like Figure 6 As shown, this embodiment also proposes a request processing device for a distributed storage system. The device includes a metadata server 601, an intermediate cache module 602, and a server 603, wherein:

[0144] Metadata server 601 is used to send a first file identifier to server 603 through intermediate cache module 602 after determining that the first file is a deleted file; wherein, the first file identifier is used to identify the first file;

[0145] Server 603 is used to determine the first file cache data from multiple file cache data in the local system based on the first file identifier; wherein the first file cache data includes a file status identifier and the first file identifier; the file status identifier in the first file cache data is set to a deletion identifier; when a file operation request containing the first file identifier is received from the first client, the file operation request is rejected based on the deletion identifier in the first file cache data and a first notification message is returned to the first client, the first notification message is used to indicate that the first file has expired.

[0146] The further functional descriptions of the metadata server 601, intermediate cache module 602, and server 603 are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0147] The request processing device of the distributed storage system proposed in this embodiment can set a deletion flag in the corresponding file cache data when a file is deleted, and can reject the client's request and return a notification message to the client when a client writes to the file based on the deletion flag in the file cache data, without performing a write operation on the file, thus avoiding the loss of written data.

[0148] In this embodiment, the request processing device of the distributed storage system is presented in the form of a functional unit. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0149] This invention also provides a computer device having the above-described features. Figure 5 or Figure 6 The request processing device or apparatus of the distributed storage system shown.

[0150] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 7As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a set of blade servers, or a multiprocessor system). Figure 7 Take a processor 10 as an example.

[0151] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0152] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0153] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0154] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0155] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0156] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0157] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A request processing method for a distributed storage system, characterized in that, The method includes: After the metadata server determines that the first file is a deleted file, it receives the first file identifier sent by the metadata server through the intermediate cache module; wherein, the first file identifier is used to identify the first file; The first file cache data is determined from multiple file cache data locally based on the first file identifier; wherein the first file cache data includes a file status identifier and the first file identifier; Set the file status identifier in the first file cache data to a deletion identifier; When a file operation request containing the first file identifier is received from the first client, the file operation request is rejected according to the deletion identifier in the first file cache data, and a first notification message is returned to the first client. The first notification message is used to indicate that the first file has expired. The method further includes: When a file processing request containing a second file identifier is received from a second client, the second file identifier is obtained from the file processing request. The second file identifier is used to identify the second file. If it is determined that no file cache data corresponding to the second file identifier exists in the multiple local file cache data, a query instruction containing the second file identifier is sent to the intermediate cache module, so that the intermediate cache module searches in the multiple file cache data for whether there is a second file cache data corresponding to the second file identifier; When the intermediate cache module receives the first message returned by the intermediate cache module, it determines that the second file is a deleted file, rejects the file processing request, and returns a second notification message to the second client; wherein, both the first message and the second notification message are used to indicate that the second file is invalid; the first message is sent by the intermediate cache module when it does not find the cached data of the second file, or when the intermediate cache module finds the cached data of the second file and determines that the file status identifier in the cached data of the second file is a deletion identifier, the deletion identifier in the cached data of the second file is set by the intermediate cache module in the cached data of the second file after receiving the second file identifier sent by the metadata server, and the second file identifier is sent by the metadata server to the intermediate cache module when it determines that the second file is a deleted file; When the second message returned by the intermediate cache module is received, it is determined that the second file is not a deleted file; wherein, the second message is used to indicate that the second file is a valid file, and the second message is sent by the intermediate cache module when it finds the cached data of the second file and determines that the file status identifier in the cached data of the second file is not a deleted identifier.

2. The method according to claim 1, characterized in that, When a file operation request containing the first file identifier is received from the first client, rejecting the file operation request based on the deletion identifier in the first file cache data includes: When the file operation request is received, the first file identifier in the file operation request is obtained; The first file cache data is determined based on the obtained first file identifier, and the file status identifier in the first file cache data is obtained; If the file status identifier is determined to be the deletion identifier, the first file is determined to be a deleted file, and the file operation request is rejected.

3. The method according to claim 1, characterized in that, After the metadata server determines that the first file is a deleted file, receiving the first file identifier sent by the metadata server through the intermediate cache module includes: Send an event registration instruction to the intermediate cache module so that the intermediate cache module registers a deletion callback event; The intermediate cache module receives the first file identifier sent by the intermediate cache module when the deletion callback event is triggered; wherein the deletion callback event is triggered when the intermediate cache module receives the first file identifier sent by the metadata server, and the first file identifier is sent to the intermediate cache module by the metadata server after determining that the first file is the deleted file.

4. The method according to claim 1, characterized in that, The second file cache data includes file data; after determining that the second file is not a deleted file, the method further includes: Send a file operation instruction corresponding to the file processing request to the intermediate cache module so that the intermediate cache module performs the corresponding operation on the file data in the second file cache data.

5. The method according to claim 1, characterized in that, After obtaining the second file identifier from the file processing request, the method further includes: If it is determined that a third file cache data corresponding to the second file identifier exists among multiple local file cache data, the file status identifier in the third file cache data is obtained; the third file cache data includes the file status identifier and file data; When the file status identifier in the third file cache data is not a deletion identifier, the corresponding operation is performed on the file data in the third file cache data according to the file processing request.

6. A request processing device for a distributed storage system, characterized in that, The device includes: The first receiving module is configured to receive a first file identifier sent by the metadata server through an intermediate cache module after the metadata server determines that the first file is a deleted file; wherein the first file identifier is used to identify the first file; The first determining module is configured to determine first file cache data from multiple file cache data in a local location based on the first file identifier; wherein the first file cache data includes a file status identifier and the first file identifier; The first setting module is used to set the file status identifier in the first file cache data to a deletion identifier; The first rejection module is used to reject the file operation request based on the deletion identifier in the first file cache data when it receives a file operation request containing the first file identifier sent by the first client. The first return module is used to return a first notification message to the first client, the first notification message being used to indicate that the first file is invalid; The first acquisition module is used to acquire the second file identifier from the file processing request when it receives a file processing request containing a second file identifier sent by the second client. The second file identifier is used to identify the second file. The first sending module is configured to send a query instruction containing the second file identifier to the intermediate cache module when it is determined that no file cache data corresponding to the second file identifier exists in the multiple file cache data in the local system, so that the intermediate cache module searches in the multiple file cache data for whether there is second file cache data corresponding to the second file identifier. The second determining module is used to determine that the second file is a deleted file when it receives the first message returned by the intermediate cache module; The second rejection module is used to reject the file processing request; The second return module is used to return a second notification message to the second client; wherein, both the first message and the second notification message are used to indicate that the second file has expired; the first message is sent by the intermediate cache module when it does not find the cached data of the second file, or by the intermediate cache module when it finds the cached data of the second file and determines that the file status identifier in the cached data of the second file is a deletion identifier, the deletion identifier in the cached data of the second file is set by the intermediate cache module in the cached data after receiving the second file identifier sent by the metadata server, and the second file identifier is sent by the metadata server to the intermediate cache module when it determines that the second file is a deleted file; The third determining module is used to determine that the second file is not a deleted file when it receives the second message returned by the intermediate caching module; wherein, the second message is used to indicate that the second file is a valid file, and the second message is sent by the intermediate caching module when it finds the cached data of the second file and determines that the file status identifier in the cached data of the second file is not a deleted identifier.

7. A request processing apparatus for a distributed storage system, characterized in that, The device includes a metadata server, an intermediate cache module, and a server; wherein: The metadata server is configured to send a first file identifier to the server through the intermediate cache module after determining that the first file is a deleted file; wherein the first file identifier is used to identify the first file; The server is configured to: determine first file cache data from multiple local file cache data based on the first file identifier; wherein the first file cache data includes a file status identifier and the first file identifier; set the file status identifier in the first file cache data as a deletion identifier; when receiving a file operation request containing the first file identifier from a first client, rejecting the file operation request based on the deletion identifier in the first file cache data and returning a first notification message to the first client, the first notification message indicating that the first file has expired; when receiving a file processing request containing a second file identifier from a second client, obtaining the second file identifier from the file processing request, the second file identifier being used to identify the second file; and if it is determined that no file cache data corresponding to the second file identifier exists in the multiple local file cache data, sending a query instruction containing the second file identifier to the intermediate cache module. The intermediate caching module searches multiple file cache data sets for the existence of a second file cache data set corresponding to the second file identifier. Upon receiving a first message returned by the intermediate caching module, it determines that the second file is a deleted file, rejects the file processing request, and returns a second notification message to the second client. Both the first and second notification messages are used to indicate that the second file is invalid. The first message is sent by the intermediate caching module when it does not find the second file cache data, or when it finds the second file cache data and determines that the file status identifier in the second file cache data is a deletion identifier. The deletion identifier in the second file cache data is set by the intermediate caching module in the second file cache data after receiving the second file identifier sent by the metadata server. The second file identifier is sent to the intermediate caching module by the metadata server when it determines that the second file is a deleted file. Upon receiving a second message returned by the intermediate caching module, it determines that the second file is not a deleted file. The second message is used to indicate that the second file is a valid file. The second message is sent by the intermediate caching module when it finds the second file cache data and determines that the file status identifier in the second file cache data is not a deletion identifier.

8. A computer device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the request processing method of the distributed storage system according to any one of claims 1 to 5.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the request processing method of the distributed storage system according to any one of claims 1 to 5.

Images