CN112559450A

CN112559450A - File access method and device, electronic equipment and storage medium

Info

Publication number: CN112559450A
Application number: CN201910854500.4A
Authority: CN
Inventors: 张振
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Cloud Computing Ltd
Priority date: 2019-09-10
Filing date: 2019-09-10
Publication date: 2021-03-26
Anticipated expiration: 2039-09-10
Also published as: CN112559450B

Abstract

The embodiment of the disclosure discloses a file access method, a file access device, an electronic device and a storage medium, wherein the method comprises the following steps: receiving a retry write request for a target file; the retry writing request comprises a first write lock of the target file and content to be written; releasing the first write lock of the target file and reopening the target file; and determining whether the content to be written in the retry writing request is written into the target file or not according to the target file which is reopened and the retry writing request. According to the technical scheme, the related information for operating the target file can be obtained, and the server executing the write request and the subsequent re-test write request does not need to use the same server, so that when the server in the distributed file system fails, a non-failure server can be selected through a retry strategy to ensure the continuity and the availability of the service.

Description

File access method and device, electronic equipment and storage medium

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to a file access method and apparatus, an electronic device, and a storage medium.

Background

In a distributed file system, a client accesses a back-end server in the distributed file system usually in a load balancing mode; when a user sends a write request of a file through a client, if no response is received for a long time due to the reasons of network, software, hardware and the like, the client retries the write request; however, in this case, the backend server may receive the same retry write request many times, and since the distributed file system only supports the additional write mode, how to ensure that the write is successful only once, and ensure the correctness of the data becomes a technical problem that needs to be solved by the distributed file system.

Disclosure of Invention

The embodiment of the disclosure provides a file access method, a file access device, electronic equipment and a computer-readable storage medium.

In a first aspect, a file access method is provided in an embodiment of the present disclosure.

Specifically, the file access method includes:

receiving a retry write request for a target file; the retry writing request comprises a first write lock of the target file and content to be written;

releasing the first write lock of the target file and reopening the target file;

and determining whether the content to be written in the retry writing request is written into the target file or not according to the target file which is reopened and the retry writing request.

Further, the retry write request also includes the first unique identifier of the target file.

Further, after the target file is reopened, the method further comprises at least one of:

obtaining a second unique identifier assigned to the reopened target file;

a second write lock assigned to reopen the target file is obtained.

Further, after obtaining the second unique identifier assigned to the target file reopened, the method further comprises:

and when the first unique identification is inconsistent with the second unique identification, returning a result of executing failure of the retry write request to the client.

Further, determining whether the content to be written in the retry write request has been written into the target file according to the target file which is reopened and the retry write request includes:

determining the current length of the target file;

and determining whether the content to be written is written into the target file or not according to the initial position of the content to be written into the target file and the current length.

Further, the method further comprises:

and after the content to be written is determined not to be written into the target file, writing the content to be written into the target file according to the initial position of the content to be written.

Further, determining whether the content to be written has been written into the target file according to the starting position where the content to be written is to be written into the target file and the current length includes:

when the current length is equal to the length of the target file at the starting position plus the length of the content to be written, determining whether the content to be written is consistent with the existing content; the existing content is the content which begins from the starting position in the target file and has the length equal to that of the content to be written;

and when the content to be written is consistent with the existing content, determining that the content to be written is written into the target file.

Further, determining whether the content to be written has been written into the target file according to the starting position where the content to be written is to be written into the target file and the current length, further comprising:

and when the current length is equal to the length of the target file at the starting position, determining that the content to be written is not written into the target file.

and when the current length is not equal to the length of the target file at the starting position plus the length of the content to be written and the current length is not equal to the length of the target file at the starting position, returning a result of the failed retry of the execution of the write request to the client.

Further, after writing the content to be written into the target file according to the start position of the content to be written, the method further includes:

determining whether the content to be written is successfully written into the target file;

and when the content to be written is not successfully written into the target file and the retry times do not exceed a preset threshold value, generating a retry writing request for the target file.

In a second aspect, a file access method is provided in an embodiment of the present disclosure.

Specifically, the file access method includes:

sending a write request of a target file to a first server in the distributed file system;

when a feedback result of the first server is not received within a preset time, sending a retry writing request of the target file to a second server in the distributed file system; wherein the first server is different from the second server.

Further, before sending the write request of the target file to the first server in the distributed file system, the method further includes:

and acquiring a first unique identifier and a first write lock of the target file.

Further, the retry write request includes the first unique identifier and a first write lock.

In a third aspect, an embodiment of the present disclosure provides a file access method.

Specifically, the file access method includes:

detecting the write operation of a user on a target file;

sending a write request of the target file to a first server in a distributed file system;

In a fourth aspect, a file access device is provided in the embodiments of the present disclosure.

Specifically, the file access device includes:

a receiving module configured to receive a retry write request for a target file; the retry writing request comprises a first write lock of the target file and content to be written;

a release module configured to release the first write lock of the target file and reopen the target file;

a determining module configured to determine whether the content to be written in the retry write request has been written into the target file according to the target file reopened and the retry write request.

Further, after the module is released, the apparatus further comprises at least one of:

a first obtaining module configured to obtain a second unique identifier assigned to the reopened target file;

a second acquisition module configured to acquire a second write lock assigned to reopen the target file.

Further, after the first obtaining module, the apparatus further includes:

and the return module is configured to return a result of executing failure of retrying the write request to the client when the first unique identifier is inconsistent with the second unique identifier.

Further, the determining module includes:

a first determining submodule configured to determine a current length of the target file;

and the second determining submodule is configured to determine whether the content to be written is written into the target file according to the starting position of the content to be written in the target file and the current length.

Further, the apparatus further comprises:

and the writing module is configured to write the content to be written into the target file according to the initial position of the content to be written after the content to be written is determined not to be written into the target file.

Further, the second determination submodule includes:

a third determining sub-module, configured to determine whether the content to be written is consistent with the existing content when the current length is equal to the length of the target file at the start position plus the length of the content to be written; the existing content is the content which begins from the starting position in the target file and has the length equal to that of the content to be written;

a fourth determining submodule configured to determine that the content to be written has been written into the target file when the content to be written is consistent with the existing content.

Further, the second determining sub-module further includes:

a fifth determining sub-module configured to determine that the content to be written is not written in the target file when the current length is equal to the length of the target file at the start position.

Further, the second determining sub-module further includes:

and the return submodule is configured to return a result of failed execution of the retry write request to the client when the current length is not equal to the length of the target file at the starting position plus the length of the content to be written and the current length is not equal to the length of the target file at the starting position.

Further, after the writing module, the apparatus further includes:

a sixth determining submodule configured to determine whether the content to be written is successfully written into the target file;

and the generation submodule is configured to generate a retry write request for the target file when the content to be written is not successfully written into the target file and the retry number does not exceed a preset threshold value.

In a fifth aspect, a file access device is provided in the embodiments of the present disclosure.

Specifically, the file access device includes:

a write request module configured to send a write request for a target file to a first server in a distributed file system;

the retry write request module is configured to send a retry write request of the target file to a second server in the distributed file system when a feedback result of the first server is not received within a preset time; wherein the first server is different from the second server.

Further, before the write request module, the method further includes:

and the third acquisition module is configured to acquire the first unique identifier and the first write lock of the target file.

In a sixth aspect, a file access device is provided in the embodiments of the present disclosure.

Specifically, the file access device includes:

the detection module is configured to detect the write operation of a user on a target file;

a first sending module configured to send a write request of the target file to a first server in a distributed file system;

the second sending module is configured to send a retry write request of the target file to a second server in the distributed file system when a feedback result of the first server is not received within a preset time; wherein the first server is different from the second server.

The functions can be realized by hardware, and the functions can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the above-described functions.

In one possible design, the file access device includes a memory and a processor, the memory is used for storing one or more computer instructions for supporting the file access device to execute the file access method in the first aspect, the second aspect or the third aspect, and the processor is configured to execute the computer instructions stored in the memory. The file access device may further comprise a communication interface for the file access device to communicate with other devices or a communication network.

In a seventh aspect, an embodiment of the present disclosure provides an electronic device, including a memory and a processor; wherein the memory is to store one or more computer instructions, wherein the one or more computer instructions are to be executed by the processor to implement the method of the first, second or third aspect.

In an eighth aspect, the disclosed embodiments provide a computer-readable storage medium for storing computer instructions for a security authentication apparatus for an enterprise account, which includes computer instructions for performing the file access method according to the first, second, or third aspect.

The technical scheme provided by the embodiment of the disclosure can have the following beneficial effects:

in the embodiment of the disclosure, after a server in a distributed file system receives a retry write request for a target file, a write lock for the target file in the retry write request is released first, the target file is reopened, and then whether content to be written in the retry write request is written in the target file is determined according to the retry write request and the reopened target file. In the embodiment of the disclosure, after receiving a retry write request of a target file, a server in the distributed file system can obtain relevant information for operating the target file by reopening the target file, and since the server executing the write request and a subsequent retry write request does not need to use the same server, when a server in the distributed file system fails, a failure-free server can be selected by a retry policy to ensure continuity and availability of a service.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

Other features, objects, and advantages of the present disclosure will become more apparent from the following detailed description of non-limiting embodiments when taken in conjunction with the accompanying drawings. In the drawings:

FIG. 1 is a schematic diagram illustrating an implementation scenario of a distributed file system according to an embodiment of the present disclosure;

FIG. 2 illustrates a flow diagram of a file access method according to an embodiment of the present disclosure;

FIG. 3 shows a flowchart of step S203 according to the embodiment shown in FIG. 2;

FIG. 4 shows a flowchart of step S302 according to the embodiment shown in FIG. 3;

FIG. 5 illustrates a flow diagram of the second server generating a portion of a rewrite request according to one embodiment of the present disclosure;

FIG. 6 shows a flow diagram of a file access method according to another embodiment of the present disclosure;

FIG. 7 illustrates a flow diagram of a file access method according to yet another embodiment of the present disclosure;

FIG. 8 shows a block diagram of a file access device according to an embodiment of the present disclosure;

FIG. 9 is a block diagram of the determining module 803 according to the embodiment shown in FIG. 8;

FIG. 10 is a block diagram illustrating the structure of the second determination submodule 902 according to the embodiment shown in FIG. 9;

FIG. 11 is a block diagram illustrating a structure of a portion of a second server generating a retry request according to an embodiment of the present disclosure;

fig. 12 is a block diagram showing a configuration of a file access apparatus according to another embodiment of the present disclosure;

fig. 13 is a block diagram illustrating a structure of a file access apparatus according to still another embodiment of the present disclosure;

fig. 14 is a schematic structural diagram of an electronic device suitable for implementing a file access method according to an embodiment of the present disclosure.

Detailed Description

Hereinafter, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings so that those skilled in the art can easily implement them. Also, for the sake of clarity, parts not relevant to the description of the exemplary embodiments are omitted in the drawings.

In the present disclosure, it is to be understood that terms such as "including" or "having," etc., are intended to indicate the presence of the disclosed features, numbers, steps, behaviors, components, parts, or combinations thereof, and are not intended to preclude the possibility that one or more other features, numbers, steps, behaviors, components, parts, or combinations thereof may be present or added.

It should be further noted that the embodiments and features of the embodiments in the present disclosure may be combined with each other without conflict. The present disclosure will be described in detail below with reference to the accompanying drawings in conjunction with embodiments.

Fig. 1 is a schematic diagram illustrating an implementation scenario of a distributed file system according to an embodiment of the present disclosure. As shown in fig. 1, the distributed file system includes a client 101, a first server 102, a second server 103, a management server 104, and a disk file 105. Wherein, a user can operate on a file in the disk file 105 through the client 101; the client 101 sends an operation request of the user, such as a write request, to the server cluster based on the operation of the distributed file by the user.

Firstly, a user opens a file through a client 101, the client 101 sends a file opening request to a server in a server cluster, the file opening request is responded by a first server 102 in the server cluster, the first server 102 requests a management server 104 to open the file, and the management server 104 returns file information (such as an address of the file in a disk, a file identifier, a file length and the like) and a first write lock of the file; the first server 102 returns the opened file identifier, the first write lock and the content of the file to the client 101; a user writes an opened file on the client 101; the client 101 sends the content written by the user to the first server 102 to request writing of a file. At this time, if no response is received for a long time due to a network, software, hardware, or the like, the client 101 transmits a retry write request to the server cluster, and the retry write request is responded by the second server 103. After receiving the retry write request, the second server 103 releases the first write lock and re-requests the management server to open the file, the management server 104 returns the second write lock of the re-opened file and file information to the second server 103, and the second server 103 may perform a write operation on the file in the disk file based on the file information and return a result, such as a successful write, to the client 101.

To this end, the embodiments of the present disclosure provide a file access method as described in the following embodiments.

The file access method proposed by the present disclosure is described in detail below by specific embodiments.

Fig. 2 illustrates a flow chart of a file access method according to an embodiment of the present disclosure. The file access method runs on a server in the server cluster shown in fig. 1. As shown in fig. 2, the file access method includes the following steps S201 to S203:

in step S201, a retry write request for a target file is received; the retry writing request comprises a first write lock of the target file and content to be written;

in step S202, releasing the first write lock of the target file, and reopening the target file;

in step S203, it is determined whether the content to be written in the retry write request has been written in the target file according to the target file that is reopened and the retry write request.

In this embodiment, the target file may be a distributed file in a distributed file system; a user can operate the distributed files in the distributed file system through a client; the client generates a corresponding operation request according to corresponding operation of a user and sends the operation request to the servers in the server cluster so as to perform corresponding operation on the target file, and the client can select to send the operation request to one of the servers in the server cluster through a load balancing strategy or other preset enrichment strategies.

When a user prepares to execute write operation on a target file, the target file can be opened through a client, the client can send an opening request to a first server in a server cluster, the first server executes the opening request, and after the first server opens the target file, a management server in a distributed file system can automatically distribute a first write lock of the target file to the client so as to ensure that the target file is only written into the client; the first server also returns the first write lock to the client so that the client can use the target file when operating next time. The client may then send a write request to the first server to write the content to be written to the target file, and after the first server completes the write request of the target file, a result (success or failure) of the write request may be returned to the client. If the client cannot know whether the write request is successful or not due to network, software, hardware and other faults, the client can try to retry, namely, the retry write request is sent to a second server in the server cluster, so that the continuity of data writing is guaranteed.

In the embodiment of the present disclosure, one of the reasons for the feedback result that the write request is not successfully completed or the client does not receive the write request may be that the first server executing the original write request fails. Therefore, when initiating the retry write request, the client may send the retry write request to a second server in the server cluster, so as to improve the success rate of the retry write request. The first server and the second server may be different.

The client can carry the first write lock of the target file and the content to be written in the retry write request and send the retry write request to a second server in the server cluster. After receiving the retry write request, the second server analyzes a first write lock in the retry write request, requests a management server in the distributed file system to release the first write lock, and reopens the target file. Because the second server executing the retry write request may not be the same server as the first server opening the target file when executing the original write request, and the second server may not directly execute the write operation on the target file because there is no related information of the target file, the second server may obtain the related information of the target file by releasing the original first write lock and re-opening the target file, and then perform the write operation on the target file. In this way, the server executing the write request and the server executing the retry write request do not need to be the same server, so that when a server in the distributed file system fails, the selection of a server without failure through the retry strategy can ensure the continuity and availability of services.

After the target file is reopened by the second server, the related information of the reopened target file, such as the storage address, the unique identifier, the length, the reassigned second write lock, etc. of the target file can be obtained. And then the second server determines whether the content to be written has been written into the target file according to the reopened target file and the retry write request, and if the content to be written has been written into the target file, the second server can directly return a successful execution result to the client. If the content to be written is not written to the target file, the second server may write the content to be written to the target file and return a successful execution result.

In the embodiment of the disclosure, when a server in a distributed file system receives a retry write request for a target file, a write lock for the target file in the retry write request is released first, the target file is reopened, and then whether content to be written in the retry write request is written in the target file is determined according to the retry write request and the reopened target file. In the embodiment of the disclosure, after receiving a retry write request of a target file, a server in the distributed file system can obtain relevant information for operating the target file by reopening the target file, and since the server executing the write request and a subsequent retry write request does not need to use the same server, when a server in the distributed file system fails, a failure-free server can be selected by a retry policy to ensure continuity and availability of a service.

In an optional implementation manner of this embodiment, the retry write request further includes a first unique identifier of the target file.

In this optional implementation manner, when a user prepares to write data to a target file, a client sends an open request of the target file to a first server, and the first server obtains, through a management server in the distributed file system, a correlation of the target file, where the correlation information includes, but is not limited to, a unique identifier, a storage address, a length, a write lock, and the like of the target file. The unique identifier of the target file can be obtained in an existing manner, as long as the same target file is ensured to have only one unique identifier. It should be noted that, in the distributed file system, even if the file names are the same, if the file names are not the same file, the unique identifiers of the files are different, for example, after a previous file is deleted, a subsequent file with the same name is created again, and then the unique identifier of the previous file is different from the unique identifier of the subsequent file.

In an optional implementation manner of this embodiment, after reopening the target file in step S202, the method further includes at least one of:

obtaining a second unique identifier assigned to the reopened target file;

a second write lock assigned to reopen the target file is obtained.

In this optional implementation manner, after the second server reopens the target file, the management server in the distributed file system may also reassign the second unique identifier and the second write lock to the target file. The second write lock is used to ensure that only the client performs writes to the target file. In the case where the target file opened by the first server and the target file opened by the second server are the same file, the first unique identifier and the second unique identifier are the same, and in some cases, the first unique identifier and the second unique identifier may be different, for example, the first unique identifier and the second unique identifier may be different in the case where the target file opened by the first server and the target file opened by the second server are different files (for example, the original target file is deleted and the file with the same name is recreated) although the file names are the same.

In an optional implementation manner of this embodiment, after the step of obtaining the second unique identifier assigned to the target file that is reopened, the method further includes the following steps:

In this optional implementation manner, when the first unique identifier and the second unique identifier are not consistent, it may be considered that the target file reopened by the second server is not the target file specified in the retry write request, and may be another file with the same file name, in which case the retry write request cannot be performed, and therefore, a result that the retry write request fails may be returned to the client. Through the embodiment, the accuracy of the writing operation can be ensured by using the unique identifier of the file.

In an optional implementation manner of this embodiment, as shown in fig. 3, the step S203, that is, the step of determining whether the content to be written in the retry write request has been written into the target file according to the target file that is reopened and the retry write request, further includes the following steps S301 to S302:

in step S301, determining a current length of the target file;

in step S302, it is determined whether the content to be written has been written into the target file according to the starting position of the content to be written into the target file and the current length.

In this optional implementation manner, the retry write request includes, in addition to the content to be written, a start position where the content to be written is to be written in the target file. Since the write operation to the file in the distributed file system is usually an additional write mode, the original length of the target file before the original write request can be determined by the starting position, for example, the starting position is the xth line of the xth page in the target file, and when the client opens the target file through the first server, the length of the target file is 0 to the xth line of the xth page. Therefore, whether the content to be written has been written in the target file can be determined by the current length and the start position of the target file obtained after the target file is reopened by the second server. For example, if the current length of the target file is equal to the length at the start position, it may be determined that the content to be written is not written in the target file.

In an optional implementation manner of this embodiment, the method further includes the following steps:

In this optional implementation manner, after it is determined that the content to be written is not written in the target file, the second server may write the content to be written in the target file and at the start position of the target file, and may also feed back the result of successful writing to the client.

In an optional implementation manner of this embodiment, as shown in fig. 4, the step S302, that is, the step of determining whether the content to be written has been written into the target file according to the starting position of the content to be written into the target file and the current length, further includes the following steps S401 to S402:

in step S401, when the current length is equal to the length of the target file at the start position plus the length of the content to be written, determining whether the content to be written is consistent with the existing content; the existing content is the content which begins from the starting position in the target file and has the length equal to that of the content to be written;

in step S402, when the content to be written is consistent with the existing content, it is determined that the content to be written has been written into the target file.

In this optional implementation manner, in a case where the content to be written has already been written in the target file, the current length of the target file should be equal to the length of the target file at the starting position in the retry write request plus the length of the content to be written, and therefore in this case, by determining whether existing content of the target file starting from the starting position and having the same length as the content to be written is consistent with the content to be written, it may be determined that the content to be written has already been written in the target file in a consistent case. Whether the content to be written is consistent with the existing content can be determined by directly matching the content or by matching a check code generated according to the content.

In an optional implementation manner of this embodiment, the step S302, that is, the step of determining whether the content to be written has been written into the target file according to the starting position of the content to be written into the target file and the current length, further includes the following steps:

In this alternative implementation, if the content to be written is not written in the target file, the current length of the target file should be the same as the length at the start position in the retry write request, because the distributed file system supports an additional write mode, and the start position determined when the client initiates the write request is the last position of the target file, so when the current length of the target file is equal to the length at the start position, it may be determined that no content has been written in the target file after the write request is initiated, and therefore the content to be written is not written in the target file.

In this optional implementation manner, when the current length of the target file is not equal to the length of the target file at the starting position plus the length of the content to be written, or is not equal to the length at the starting position, it may be considered that the target file and the client initiate a write request in different states, and it is not determined whether the content to be written has been written in the target file, and another error may occur, so the second server may send a result of a retry write request execution failure to the client. In this case, the client may perform subsequent operations according to actual situations, for example, prompt the user of the current situation, and reopen the target file at the client under the instruction of the user.

In an optional implementation manner of this embodiment, as shown in fig. 5, after the step of writing the content to be written into the target file according to the start position of the content to be written, the method further includes the following steps:

in step S501, it is determined whether the content to be written is successfully written into the target file;

in step S502, when the content to be written is not successfully written into the target file and the retry number does not exceed a preset threshold, a retry write request for the target file is generated.

In the optional implementation manner, the second server may write the content to be written into the target file through the write operation of the distributed file system when it is determined that the content to be written is not written into the target file and no other error occurs; if the content to be written is not successfully written into the target file due to other reasons in the writing process, the second server can initiate a retry writing request so as to execute the writing operation again. And under the condition that the frequency of sending the retry write request by the second server exceeds a preset threshold value, the retry write request can be stopped from being sent, and the result of operation failure is directly returned to the client. It should be noted that, when initiating the retry write request, the second server may also carry a second write lock and/or a second unique identifier of the target file that is obtained again by the second server, in addition to information necessary for the write operation, such as the content to be written. The retry write request may be responded by the second server, that is, the second server responds to the retry write request again from step S201 shown in fig. 2 based on the retry write request; of course, in some special cases, for example, the second server has a limited load, the retry write request may also be sent to a third server in the server cluster, and the third server responds the retry write request, which may be determined according to the actual situation, and is not limited herein.

Fig. 6 illustrates a flow chart of a file access method according to another embodiment of the present disclosure. The file access method runs on the client shown in fig. 1. As shown in fig. 6, the file access method includes the following steps S601-S602:

in step S601, sending a write request of a target file to a first server in the distributed file system;

in step S602, when a feedback result of the first server is not received within a preset time, sending a retry write request of the target file to a second server in the distributed file system; wherein the first server is different from the second server.

In this embodiment, a user may operate a target file in the distributed file system through a client. When a user prepares to write to a target file, the target file can be opened through a client, the client can send an opening request to a first server in a server cluster, the first server executes the opening request, and after the first server opens the target file, a management server in a distributed file system can automatically distribute a first write lock of the target file to the client so as to ensure that the target file is only written by the client; the first server also returns the first write lock to the client so that the client can use the target file when operating next time. The client may then send a write request to the first server to write the content to be written to the target file, and after the first server completes the write request of the target file, a result (success or failure) of the write request may be returned to the client. If the client cannot know whether the write request is successful or not due to network, software, hardware and other faults, the client can try to retry, namely, the retry write request is sent to a second server in the server cluster, so that the continuity of data writing is guaranteed.

In some embodiments, the first server and the second server may be different. After the client initiates the write request to the first server, if the feedback result of the first server is not received within the preset time, the client may initiate a retry write request. One of the reasons for not receiving the feedback result of the first server may be that the first server itself fails, or a network failure occurs, and the like, so that the client may select a second server in the server cluster of the distributed file system and send a retry write request to the second server, so as to improve the success rate of retry write requests. In this way, when a server, a network and the like of the distributed file system fail, the selection of a non-failure server through a retry strategy can guarantee the continuity and the availability of services.

In an optional implementation manner of this embodiment, before step S601, that is, before the step of sending the write request of the target file to the first server in the distributed file system, the method further includes the following steps:

In this alternative implementation, the client may obtain the first write lock and the first unique identifier of the target file before sending the write request to the first server. After acquiring the first write lock of the target file, the client may exclusively write data to the target file; and the unique identification of the target file may be a distributed file system allocation and used to distinguish between different files. After obtaining the first unique identifier and the first write lock, the client may carry the first unique identifier and the first write lock in the write request and/or the retry write request, so that the server in the distributed file system can accurately write the content to be written into the target file.

In an optional implementation manner of this embodiment, the retry write request includes the first unique identifier and a first write lock.

In this optional implementation manner, when the client performs the retry write request, if a second server different from the first server is selected to perform the retry write request, the second server does not store the file information of the target file, so that the retry write request carries the first unique identifier and the first write lock, the second server can release the first write lock and reopen the target file, so that the second server can obtain the relevant information of the target file when reopening the target file, and the uniqueness and accuracy of the data can be ensured when writing the file.

Fig. 7 illustrates a flowchart of a file access method according to another embodiment of the present disclosure. The file access method runs on the client shown in fig. 1. As shown in fig. 7, the file access method includes the following steps:

in step S701, a write operation of a user to a target file is detected;

in step S702, sending a write request of the target file to a first server in a distributed file system;

in step S703, when the feedback result of the first server is not received within a preset time, sending a retry write request of the target file to a second server in the distributed file system; wherein the first server is different from the second server.

In this embodiment, a user may operate a target file in the distributed file system through a client. When a user prepares to write to a target file, the target file can be opened through a client, after the client detects the opening operation of the user on the target file, the opening request can be sent to a first server in a server cluster, the first server executes the opening request, and after the first server opens the target file, a management server in a distributed file system can automatically distribute a first write lock of the target file to the client so as to ensure that the target file is only written into the client; the first server also returns the first write lock to the client so that the client can use the target file when operating next time. After detecting that the user writes to the open target file, the client may send a write request to the first server to write the content to be written into the target file, and after the first server completes the write request of the target file, a result (success or failure) of the write request may be returned to the client. If the client cannot know whether the write request is successful or not due to network, software, hardware and other faults, the client can try to retry, namely, the retry write request is sent to a second server in the server cluster, so that the continuity of data writing is guaranteed.

The following are embodiments of the disclosed apparatus that may be used to perform embodiments of the disclosed methods.

Fig. 8 shows a block diagram of a file access apparatus according to an embodiment of the present disclosure, which may be implemented as part or all of an electronic device by software, hardware, or a combination of the two. The file access device is located on a server in the server cluster shown in fig. 1. As shown in fig. 8, the file access apparatus includes:

a receiving module 801 configured to receive a retry write request for a target file; the retry writing request comprises a first write lock of the target file and content to be written;

a releasing module 802 configured to release the first write lock of the target file and reopen the target file;

a determining module 803, configured to determine whether the content to be written in the retry write request has been written into the target file according to the target file reopened and the retry write request.

In an optional implementation manner of this embodiment, after the releasing module 802, the apparatus further includes at least one of the following:

In an optional implementation manner of this embodiment, after the first obtaining module, the apparatus further includes:

In an optional implementation manner of this embodiment, as shown in fig. 9, the determining module 803 includes:

a first determining sub-module 901 configured to determine a current length of the target file;

a second determining sub-module 902, configured to determine whether the content to be written has been written into the target file according to a starting position where the content to be written is to be written into the target file and the current length.

In an optional implementation manner of this embodiment, the apparatus further includes:

In an optional implementation manner of this embodiment, as shown in fig. 10, the second determining sub-module 902 includes:

a third determining sub-module 1001 configured to determine whether the content to be written is consistent with the existing content when the current length is equal to the length of the target file at the start position plus the length of the content to be written; the existing content is the content which begins from the starting position in the target file and has the length equal to that of the content to be written;

a fourth determining sub-module 1002, configured to determine that the content to be written has been written into the target file when the content to be written is consistent with the existing content.

In an optional implementation manner of this embodiment, the second determining sub-module 902 further includes:

In an optional implementation manner of this embodiment, as shown in fig. 11, after the writing module, the apparatus further includes:

a sixth determining sub-module 1101 configured to determine whether the content to be written is successfully written into the target file;

the generating sub-module 1102 is configured to generate a retry write request for the target file when the content to be written is not successfully written into the target file and the retry number does not exceed a preset threshold.

In the optional implementation manner, the second server may write the content to be written into the target file through the write operation of the distributed file system when it is determined that the content to be written is not written into the target file and no other error occurs; if the content to be written is not successfully written into the target file due to other reasons in the writing process, the second server can initiate a retry writing request so as to execute the writing operation again. And under the condition that the frequency of sending the retry write request by the second server exceeds a preset threshold value, the retry write request can be stopped from being sent, and the result of operation failure is directly returned to the client. It should be noted that, when initiating the retry write request, the second server may also carry a second write lock and/or a second unique identifier of the target file that is obtained again by the second server, in addition to information necessary for the write operation, such as the content to be written. The retry write request may be responded by the second server, that is, the second server responds to the retry write request again from the receiving module 801 shown in fig. 8 based on the retry write request; of course, in some special cases, for example, the second server has a limited load, the retry write request may also be sent to a third server in the server cluster, and the third server responds the retry write request, which may be determined according to the actual situation, and is not limited herein.

Fig. 12 shows a block diagram of a file access apparatus according to another embodiment of the present disclosure, which may be implemented as part or all of an electronic device by software, hardware, or a combination of both. The file access device is located at the client shown in fig. 1. As shown in fig. 12, the file access apparatus includes:

a write request module 1201 configured to send a write request of a target file to a first server in a distributed file system;

a retry write request module 1202, configured to send a retry write request of the target file to a second server in the distributed file system when a feedback result of the first server is not received within a preset time; wherein the first server is different from the second server.

In an optional implementation manner of this embodiment, before the write request module 1201, the method further includes:

Fig. 13 shows a block diagram of a file access apparatus according to another embodiment of the present disclosure, which may be implemented as part or all of an electronic device by software, hardware, or a combination of both. The file access device is located at the client shown in fig. 1. As shown in fig. 13, the file access apparatus includes:

a detection module 1301 configured to detect a write operation of a user on a target file;

a first sending module 1302 configured to send a write request of the target file to a first server in a distributed file system;

a second sending module 1303, configured to send a retry write request of the target file to a second server in the distributed file system when a feedback result of the first server is not received within a preset time; wherein the first server is different from the second server.

As shown in fig. 14, the electronic apparatus 1400 includes a Central Processing Unit (CPU)1401 that can execute various processes of the file access method in the embodiments of the present disclosure according to a program stored in a Read Only Memory (ROM)1402 or a program loaded from a storage portion 1408 into a Random Access Memory (RAM) 1403. In the RAM1403, various programs and data necessary for the operation of the electronic device 1400 are also stored. The CPU1401, ROM1402, and RAM1403 are connected to each other via a bus 1404. An input/output (I/O) interface 1405 is also connected to bus 1404.

The following components are connected to the I/O interface 1405: an input portion 1406 including a keyboard, a mouse, and the like; an output portion 1407 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker and the like; a storage portion 1408 including a hard disk and the like; and a communication portion 1409 including a network interface card such as a LAN card, a modem, or the like. The communication section 1409 performs communication processing via a network such as the internet. The driver 1410 is also connected to the I/O interface 1405 as necessary. A removable medium 1411 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 1410 as necessary, so that a computer program read out therefrom is installed into the storage section 1408 as necessary.

In particular, according to embodiments of the present disclosure, the methods in the embodiments above with reference to the present disclosure may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program tangibly embodied on a medium readable thereby, the computer program comprising program code for performing the methods of embodiments of the present disclosure. In such an embodiment, the computer program may be downloaded and installed from a network via the communication portion 1409 and/or installed from the removable media 1411.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowcharts or block diagrams may represent a module, a program segment, or a portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units or modules described in the embodiments of the present disclosure may be implemented by software or hardware. The units or modules described may also be provided in a processor, and the names of the units or modules do not in some cases constitute a limitation of the units or modules themselves.

As another aspect, the present disclosure also provides a computer-readable storage medium, which may be the computer-readable storage medium included in the apparatus in the above-described embodiment; or it may be a separate computer readable storage medium not incorporated into the device. The computer readable storage medium stores one or more programs for use by one or more processors in performing the methods described in the present disclosure.

The foregoing description is only exemplary of the preferred embodiments of the disclosure and is illustrative of the principles of the technology employed. It will be appreciated by those skilled in the art that the scope of the invention in the present disclosure is not limited to the specific combination of the above-mentioned features, but also encompasses other embodiments in which any combination of the above-mentioned features or their equivalents is possible without departing from the inventive concept. For example, the above features and (but not limited to) the features disclosed in this disclosure having similar functions are replaced with each other to form the technical solution.

Claims

1. A method for accessing a file, comprising:

2. The method of claim 1, wherein the retry write request further includes a first unique identification of the target file.

3. The method of claim 2, wherein after said target file is reopened, the method further comprises at least one of:

obtaining a second unique identifier assigned to the reopened target file;

a second write lock assigned to reopen the target file is obtained.

4. The method of claim 3, wherein after obtaining the second unique identification assigned to the reopened target file, the method further comprises:

5. The method according to any one of claims 1-4, wherein determining whether the content to be written in the retry write request has been written into the target file according to the target file being reopened and the retry write request comprises:

determining the current length of the target file;

6. The method of claim 5, further comprising:

7. The method of claim 5, wherein determining whether the content to be written has been written into the target file according to a starting position of the content to be written into the target file and the current length comprises:

8. The method of claim 5, wherein determining whether the content to be written has been written into the target file according to a starting position at which the content to be written is to be written into the target file and the current length further comprises:

9. The method of claim 5, wherein determining whether the content to be written has been written into the target file according to a starting position at which the content to be written is to be written into the target file and the current length further comprises:

10. The method according to claim 6, further comprising, after writing the content to be written into the target file according to the start position of the content to be written:

11. A method for accessing a file, comprising:

12. The method of claim 11, wherein prior to sending the write request for the target file to the first server in the distributed file system, further comprising:

13. The method of claim 12, wherein the retry write request comprises the first unique identifier and a first write lock.

14. A method for accessing a file, comprising:

detecting the write operation of a user on a target file;

15. A file access apparatus, comprising:

16. The apparatus of claim 15, wherein the retry write request further comprises a first unique identification of the target file.

17. The apparatus of claim 16, wherein after releasing the module, the apparatus further comprises at least one of:

18. The apparatus of claim 17, wherein after the first obtaining module, the apparatus further comprises:

19. The apparatus according to any of claims 15-18, wherein the determining means comprises:

20. The apparatus of claim 19, further comprising:

21. The apparatus of claim 19, wherein the second determining submodule comprises:

22. The apparatus of claim 19, wherein the second determination submodule further comprises:

23. The apparatus of claim 19, wherein the second determination submodule further comprises:

24. The apparatus of claim 20, wherein after the writing module, the apparatus further comprises:

25. A file access apparatus, comprising:

26. The apparatus of claim 25, wherein the write request module is preceded by:

27. The apparatus of claim 26, wherein the retry write request comprises the first unique identifier and a first write lock.

28. A file access apparatus, comprising:

29. An electronic device comprising a memory and a processor; wherein the content of the first and second substances,

the memory is to store one or more computer instructions, wherein the one or more computer instructions are to be executed by the processor to implement the method of any one of claims 1-14.

30. A computer-readable storage medium having computer instructions stored thereon, wherein the computer instructions, when executed by a processor, implement the method of any one of claims 1-14.