Resource file access method and device and storage medium

By dividing resource files into hot data and cold data and storing them in FastDFS and NAS systems respectively, and combining anti-hotlinking verification and caching mechanisms, the problem of bandwidth consumption and access pressure during resource file loading is solved, achieving efficient file access and service response.

CN121996637APending Publication Date: 2026-05-08RICHFIT INFORMATION TECH +1
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411581885.9
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-11-07
Publication Date
2026-05-08

AI Technical Summary

Technical Problem

In existing technologies, loading resource files consumes a large amount of network bandwidth, and the FastDFS distributed file system and NAS network-attached storage system experience access pressure during peak periods, affecting service performance and response efficiency.

Method used

By dividing resource files into hot data and cold data, hot data is stored in the FastDFS distributed file system and cold data is stored in the NAS network auxiliary storage system. Optimized data storage is achieved through periodic file data transfer. Combined with anti-hotlinking verification and caching mechanisms, the process of obtaining and accessing resource files is optimized.

Benefits of technology

It improves file storage performance and service response efficiency, reduces network bandwidth consumption and database I/O interaction, and achieves efficient access to resource files.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121996637A_ABST
    Figure CN121996637A_ABST
Patent Text Reader

Abstract

The invention provides a resource file access method and device and a storage medium, and the acquisition method comprises the steps: receiving a resource file acquisition request, generating a Redis cache record for a Group address unique identifier generated after a resource file is uploaded to a FastDFS distributed file system, storing a hotspot resource file in the FastDFS distributed file system, and storing the hotspot resource file in the FastDFS distributed file system. Wherein the data which are not commonly used are periodically scanned and migrated into the NAS network attached storage system, and after migration is completed, Redis cache records of the corresponding resource files are emptied. According to the method, the advantage of parallel storage of the FastDFS and the NAS network attached storage system is considered, hot data can be obtained through the FastDFS and cold data can be obtained through the NAS network attached storage system during file preview, and the file storage performance and service response are improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention belongs to the field of computer technology, and in particular relates to a method, apparatus and storage medium for accessing resource files. Background Technology

[0002] Currently, applications integrate more and more functions. Opening various function pages of an application will trigger numerous requests to load resource files, which consumes a significant amount of network bandwidth. Furthermore, resource files can typically be stored in the FastDFS distributed file system or a NAS network-attached storage system. The input / output (I / O) of the NAS network-attached storage system experiences access pressure during peak periods. Summary of the Invention

[0003] The inventors discovered in practical applications that retrieving resource files currently consumes a significant amount of network bandwidth, and that there is room for improvement in service performance and response efficiency. After extensive research, the inventors creatively developed a new method for accessing resource files. Specifically:

[0004] In a first aspect, the present invention discloses a method for accessing resource files, comprising the following steps:

[0005] Receive the uploaded resource file, determine the business type of the resource file, and use the business type identifier of the resource file to generate the first part of the preview address of the resource file;

[0006] Upload the original resource file to the FastDFS distributed file system, use the unique identifier of the Group address of the resource file returned by the FastDFS distributed file system as the second part of the preview address, and combine it with the first part to generate the preview address of the resource file.

[0007] Write the resource file metadata to the database table, write the unique identifier of the resource file's Group address to the cache library, and return the resource file information;

[0008] Periodically filter resource file metadata stored in the database table for a duration longer than a preset period, send the original resource file corresponding to the filtered resource file metadata to the NAS network auxiliary storage system via the FastDFS distributed file system, and delete the unique identifier of the Group address corresponding to the filtered resource file metadata in the cache.

[0009] Furthermore, it receives a resource acquisition request from the client, the resource acquisition request including at least the target resource preview address;

[0010] The unique identifier of the Group address of the resource file is obtained based on the target resource preview address;

[0011] Determine whether the cache library contains a unique identifier for the Group address. If it does, retrieve the target resource file from the FastDFS distributed file system; otherwise, retrieve the target file from the NAS network auxiliary storage system.

[0012] Furthermore, after writing the resource file metadata into the database table and writing the unique identifier of the resource file's Group address into the cache database, it is necessary to sequentially determine whether FastDFS has successfully written the resource file, whether the resource file metadata has successfully been written into the database, and whether the unique identifier of the resource file's Group address has successfully been written. Only after all these steps are successful will the resource file information be returned.

[0013] Furthermore, the database table periodically filters resource file metadata with a storage duration exceeding a preset period, and the resource file originals corresponding to the filtered resource file metadata are sent by the FastDFS distributed file system to the NAS network auxiliary storage system for storage, including:

[0014] The scheduled task filters out the metadata of resource files in the database table that are older than a preset period, and sets the archive flag field stored in the database table to be archived.

[0015] The resource files corresponding to the selected resource file metadata are sent to the NAS network auxiliary storage system via the FastDFS distributed file system using the HTTP protocol, and the archive flag stored in the database table is set to archived.

[0016] Furthermore, after receiving the resource retrieval request from the client, it first determines whether the target resource file corresponding to the target resource preview address has been cached on the client;

[0017] If the target resource file is already cached on the client and has not expired, a response to continue using the cache is returned to the client, and the client then retrieves the target resource file from its local cache without performing any further steps.

[0018] Furthermore, the response to continue using the cache sent to the client also includes returning the cache expiration time and cache verification information.

[0019] Furthermore, the resource acquisition request also includes a request source address. Before determining whether the target resource file corresponding to the target resource preview address has been cached on the client, it is also verified whether the request source address meets the anti-hotlinking filtering address. If it does not meet the requirement, access is directly prohibited.

[0020] Furthermore, it determines whether the cache contains a unique identifier for the Group address. If it does, the target resource file is retrieved from the FastDFS distributed file system; otherwise, the target file is retrieved from the NAS network-attached storage system, including:

[0021] Check if the cache contains a unique identifier for the Group address. If it does, use the unique Group address to search for the resource file in the FastDFS distributed file system; otherwise...

[0022] Query the database table to see if the resource file metadata corresponding to the unique identifier of the Group address exists. If it exists and the stored field "archived" is "archived", then retrieve the target resource file from the NAS network auxiliary storage system via an HTTP request based on the resource file metadata.

[0023] Secondly, the present invention also provides a resource file management system, which includes at least a file management microservice, a scheduling microservice, an archiving microservice, a FastDFS distributed file system, a NAS network auxiliary storage system, a database, and a cache library, wherein:

[0024] The FastDFS distributed file system is used to store original resource files; the database is used to store resource file metadata; and the cache library is used to store unique identifiers for the Group address of resource files.

[0025] The timed microservice is used to generate timed expiration notifications for the file management microservice;

[0026] The file management microservice is used to receive uploaded resource files, determine the business type of the resource files, and generate the first part of the preview address of the resource files using the business type identifier of the resource files; it is also used to upload the original resource files to the FastDFS distributed file system, use the unique identifier of the Group address of the resource files returned by the FastDFS distributed file system as the second part of the preview address, and combine it with the first part to generate the preview address of the resource files; it is also used to write the resource file metadata into a database table, write the unique identifier of the Group address of the resource files into a cache, and return file information; it is also used to, after receiving a timed expiration notification generated by the timed microservice, filter the resource file metadata stored in the database table with a storage duration greater than a preset period, send the original resource files corresponding to the filtered resource file metadata to the NAS network auxiliary storage system for storage by the FastDFS distributed file system, and then delete the unique identifier of the Group address corresponding to the filtered resource file metadata from the cache.

[0027] Based on the above technical solution, the beneficial effects of the present invention compared with the prior art are as follows:

[0028] This invention changes the existing technology of storing data separately in the FastDFS distributed file system and the NAS network auxiliary storage system. It achieves this by periodically transferring files between the FastDFS distributed file system and the NAS network auxiliary storage system, storing hot data in the FastDFS distributed file system and cold data in the NAS network auxiliary storage system. In the long run, most resource files will be stored in the NAS network auxiliary storage system, while a small portion of frequently accessed resource files will be stored in the FastDFS distributed file system. Therefore, this embodiment combines the advantages of parallel storage using both the FastDFS distributed file system and the NAS network auxiliary storage system. During file preview, hot data can be obtained through the FastDFS distributed file system and cold data through the NAS network auxiliary storage system, improving file storage performance and service response. Attached Figure Description

[0029] 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.

[0030] Figure 1 This is a flowchart illustrating a resource file access method according to Embodiment 1 of the present invention.

[0031] Figure 2 This is a flowchart illustrating step S103 in Embodiment 1 of the present invention;

[0032] Figure 3 This is a flowchart illustrating steps S105-S107 in Embodiment 1 of the present invention.

[0033] Figure 4 This is a schematic diagram of the resource file management system in Embodiment 3 of the present invention. Detailed Implementation

[0034] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0035] Example 1

[0036] Specifically, a method for accessing resource files, such as Figure 1 As shown, it includes the following steps:

[0037] S101: Receive the uploaded resource file, determine the service type of the resource file, and generate the first part of the preview address of the resource file using the service type identifier of the resource file.

[0038] File uploads require corresponding caching, so different preview addresses can be provided for different file types. Specifically, the system receives resource files uploaded by clients, primarily referring to their browsers or mobile applications. Resource files generally fall into four main categories: documents, images, audio, and video. Different business type identifiers can be set for different resource file types, which facilitates setting different access paths for different file types later. For example, the business type identifier can be used to generate a prefix for the preview address of that resource file.

[0039] S102, upload the original resource file to the FastDFS distributed file system, use the unique identifier of the Group address of the resource file returned by the FastDFS distributed file system as the second part of the preview address, and combine it with the first part to generate the preview address of the resource file.

[0040] The original resource file is uploaded to the FastDFS distributed file system. Once the upload is complete, a unique identifier for the Group file address is returned, which serves as the suffix of the resource file preview address. Therefore, the preview address of the resource file can be constructed by concatenating the resource file's business type identifier and the unique Group address identifier.

[0041] S103: Write the resource file metadata to the database table, write the unique identifier of the resource file's Group address to the cache library, and return the resource file information.

[0042] After organizing the complete resource file data, generating resource file metadata, and writing it to the Oracle database table, the unique identifier of the Group is written to the Redis cache. This step requires checking if FastDFS successfully wrote the resource file, if the resource file data was successfully written to the database, and if the unique identifier in the resource file cache was successfully written. Only if all three are successful is the resource file information returned. If any one fails, an exception is thrown, this step ends, and you must return to step S101. (Appendix) Figure 2This demonstrates the specific process of this step. In this embodiment, the metadata written to the Oracle database table may include: a unique Group identifier, file name, file type, file size, file preview domain name address, file upload time, file archive status (archive identifier), file FastDFS address, and file NAS address. Once the FastDFS write to the resource file is successful, the resource file metadata is successfully written to the database, and the unique Group identifier of the resource file is successfully written, the unique Group identifier, file name, file type, file size, and other information are returned to the calling client for display.

[0043] S104, periodically filter resource file metadata stored in the database table for a duration longer than a preset period, send the original resource file corresponding to the filtered resource file metadata to the NAS network auxiliary storage system for storage by the FastDFS distributed file system, and delete the unique identifier of the Group address corresponding to the filtered resource file metadata in the cache database.

[0044] Specifically, a scheduled task can scan the resource file data information stored in Oracle tables and update the data within a predetermined timeframe, marking the archive marker for data that meets the time requirement as "pending archive." The `filing_status` field in the Oracle-stored data table is also marked as "pending archive." Every day, a scheduled task scans the resource file data information stored in Oracle tables, and data with a storage duration greater than 93 days after updates is also marked as "pending archive." Then, via HTTP, a request is sent from the FastDFS distributed file system to the NAS network auxiliary storage system to request the original resource file corresponding to the selected resource file metadata. The `filing_status` field in the database table is then set to "archived." Additionally, cold data in the FastDFS distributed file system is scanned and migrated to the NAS network auxiliary storage system daily. After migration, the unique Group address identifier in the corresponding resource file's Redis cache record is cleared. That is, the Redis cache only stores the unique Group address identifier of hot data.

[0045] This achieves the shared storage of resource files on both the FastDFS distributed file system and the NAS network auxiliary storage system. The FastDFS distributed file system stores resource files that are frequently used in the short term (referred to as "hot data"), while the NAS network auxiliary storage system stores resource files that have not been updated for a long time (referred to as "cold data"). FastDFS is a lightweight, open-source, high-performance distributed file system that solves the problems of large-capacity file storage and high-concurrency access. The NAS network auxiliary storage system offers advantages such as high flexibility, large storage capacity, data residing within a local area network, and fast access speed. This embodiment changes the existing technology of storing data separately on the FastDFS distributed file system and the NAS network auxiliary storage system. By periodically transferring file data between the FastDFS distributed file system and the NAS network auxiliary storage system, hot data is stored on the FastDFS distributed file system, and cold data is stored on the NAS network auxiliary storage system. In the long run, most resource files will be stored on the NAS network auxiliary storage system, while a small portion of frequently accessed resource files will be stored on the FastDFS distributed file system. Therefore, this embodiment combines the advantages of parallel storage using both the FastDFS distributed file system and the NAS network auxiliary storage system. When previewing files, hot data can be obtained through the FastDFS distributed file system and cold data can be obtained through the NAS network-attached storage system, which improves file storage performance and service response.

[0046] Example 2

[0047] In other embodiments, in order to further improve the efficiency of accessing resource files, the inventors have further studied the technical solutions after receiving resource acquisition requests from clients.

[0048] Specifically, such as Figure 1 As shown, the resource file access method of the present invention further includes the following steps compared to Embodiment 1:

[0049] S105, Receive a resource acquisition request sent by the client, wherein the resource acquisition request includes at least the target resource preview address.

[0050] The corresponding resource file can be found using the preview address with the domain name and the unique identifier of the group address.

[0051] S106. Obtain the unique identifier of the Group address of the resource file based on the target resource preview address.

[0052] S107. Determine whether the cache library contains a unique identifier for the Group address. If it does, obtain the target resource file from the FastDFS distributed file system; otherwise, obtain the target resource file from the NAS network auxiliary storage system.

[0053] Specifically, it checks whether the cache contains a unique identifier for the Group address. If it does, it uses the unique identifier for the Group address to search for the resource file in the FastDFS distributed file system.

[0054] If not found, query the database table to see if the resource file metadata corresponding to the unique identifier of the Group address exists. If it does not exist, return directly. If it exists and the stored field "archived" indicates that it has been archived, retrieve the target resource file from the NAS network auxiliary storage system via an HTTP request based on the resource file metadata.

[0055] This embodiment can quickly determine the target resource file in the FastDFS distributed file system or NAS network auxiliary storage system based on whether the cache library contains a unique identifier for the Group address, thereby further improving the access efficiency of resource files.

[0056] Understandably, if the corresponding resource file is missing in the NAS network auxiliary storage system, an error will be returned directly. Figure 3 The specific process of steps S105-S107 is illustrated, in which "file archiving service" implements the content of step S107.

[0057] Example 3

[0058] In other embodiments, to further free up storage space for the FastDFS distributed file system and provide secure and efficient access, the following processing measures can be performed between steps S105 and S106 in Embodiment 2:

[0059] Specifically, a resource file access method further includes the following steps: In step S105, the resource acquisition request also includes a request source address. Before determining whether the target resource file corresponding to the target resource preview address has been cached on the client, it is also verified whether the request source address meets the anti-hotlinking filtering address. If it does not meet the requirement, it means that the request source address is dangerous and unauthorized, and access can be directly prohibited. If it meets the requirement, then step S106 is executed. Specifically, the client initiates a preview request, the request interface goes to the backend service, the backend service first verifies the anti-hotlinking information, if it fails, it directly returns a message to the client prohibiting access; only after it passes the verification does it obtain the resource file.

[0060] Verifying the source address of the request to be included in the specified anti-leeching list can intercept malicious requests and reduce the bandwidth consumption of the server by third parties.

[0061] In other embodiments, after step S105, i.e., after receiving the resource retrieval request from the client, a resource file access method may first determine whether the target resource file corresponding to the target resource preview address has been cached on the client's website. If the target resource file is already cached on the client and has not expired, a 304 status code is returned to the client, and the client then retrieves the target resource file from its local cache without executing subsequent steps. If the client does not have a cache, then step S106 is executed.

[0062] Specifically, if the file has not been modified, a status code of 304 is returned; if it has been modified, a status code of 200 is returned. The front end then receives a message based on the status code of 304, indicating that it can retrieve the previously loaded preview information from the current client cache.

[0063] HTTP status code 304 means "not modified," which is a caching mechanism. When a client already has a cached response, and the content of that response has not changed on the server side, the server can return a 304 status code to tell the client to continue using the cached response.

[0064] In this embodiment, if the target resource file is already cached on the client and has not expired, a 304 status code is returned to the client, which then retrieves the target resource file from its local cache. Common HTTP status codes include 200, 201, 404, 504, 500, etc. 304 indicates that the requested content has not been modified; it's a caching mechanism that allows direct use of the page cache (if the page cache hasn't expired). When the client already has a cached response, and the content of that response hasn't changed on the server side, the server can return a 304 status code, instructing the client to continue using the cached response. In this embodiment, if the target resource file is already cached in the client's browser and has not expired, a 304 status code is returned, along with the cache expiration time, cache verification information, and other relevant information. Upon receiving the 304 status code, the browser directly retrieves the resource from the cache. This design directly utilizes page-level 304 caching, reducing backend interface interactions and improving website performance.

[0065] In practical applications, conditional caching is used here: The HTTP request header contains two identifiers: ETag and last-modified. The ETag algorithm is related to the resource content; the server generates a unique ETag based on the resource content. When the resource is modified, the changed ETag is regenerated. The last-modified value is the timestamp of the first request, which is returned with the response header. Subsequent requests include an If-Modified-Since header, whose value is the last-modified value from the previous request. This allows the server to know the time of the last request and compare it with the last modification time of the resource on the server to determine if the resource has changed during that period. After a resource request, the browser returns an ETag value via the response header. Subsequent requests include an If-None-Match header, whose value is the ETag value, for comparison with the server.

[0066] The server uses conditional caching. If the file hasn't been updated during a request (meaning the ETag hasn't changed), a 304 error is returned. Each request returns the ETag and last-modified headers. Subsequent requests include If-Modified-Since (corresponding to last-modified) and the ETag in the request header. The server compares these identifiers to determine if the resource has changed. If it has, the server returns the new resource and updates the corresponding ETag and last-modified headers. If the resource hasn't changed, the ETag and last-modified remain unchanged. In this case, the client experiences conditional caching on every request. In this embodiment, it's preferable for both ETag and last-modified to be present. When a file is modified too quickly (e.g., taking 100ms), If-Modified-Since can only detect time differences measured in seconds, so it won't detect the change. However, ETag generates a new hash value every time the file is modified, solving the problem with last-modified.

[0067] This invention utilizes both the FastDFS distributed file system and a NAS (Network Attached Storage) system for storage, storing hot and cold data separately. It accepts resource acquisition requests and intercepts and verifies them based on pre-defined anti-hotlinking measures to prevent malicious access and bandwidth consumption. It controls the verification of hot and cold data, allowing hot data to access the FastDFS distributed file system and cold data to access the NAS system. Data without modification requests is cached with a 304 error, reducing bandwidth consumption. In this embodiment, resource file preview access first undergoes anti-hotlinking processing, then cache access, and finally database access, effectively reducing database I / O interactions and improving service performance and response efficiency.

[0068] Example 4

[0069] To implement the resource file access methods of Embodiments 1, 2, and 3, this invention also discloses a resource file management system, combined with... Figure 4 As shown, this resource file management system includes at least a file management microservice, a scheduling microservice, a FastDFS distributed file system, a NAS network auxiliary storage system, a database, and a cache library, wherein:

[0070] The FastDFS distributed file system is used to store original resource files; the database is used to store resource file metadata; and the cache library is used to store unique identifiers for the group addresses of resource files.

[0071] The scheduled microservice is used to generate timed expiration notifications for the file management microservice.

[0072] The file management microservice is used to receive uploaded resource files, determine the business type of the resource files, and generate the first part of the preview address of the resource files using the business type identifier of the resource files; it is also used to upload the original resource files to the FastDFS distributed file system, use the unique Group address identifier of the resource files returned by the FastDFS distributed file system as the second part of the preview address, and combine it with the first part to generate the preview address of the resource files; it is also used to write resource file metadata into a database table, write the unique Group address identifier of the resource files into a cache, and return file information; and it is also used to, after receiving a timed expiration notification generated by the timed microservice, filter resource file metadata stored in the database table with a storage duration greater than a preset period, send the original resource files corresponding to the filtered resource file metadata to the NAS network auxiliary storage system for storage by the FastDFS distributed file system, and then delete the unique Group address identifier corresponding to the filtered resource file metadata from the cache.

[0073] To facilitate understanding, a more detailed explanation is provided below with reference to the accompanying diagram. Specifically, the scheduled microservice calls the file management microservice to organize the data in the `filing_status` field of the Oracle table that is to be archived, and then sends the archived data to the NAS network auxiliary storage system via an HTTP request. The file management microservice executes the following steps:

[0074] S301, the file management microservice determines the interface address and input parameters of the uploaded resource file, and selects the corresponding FastDFS middleware and group.

[0075] S302, determine whether the uploaded resource file original has been successfully written to the FastDFS distributed file system.

[0076] Specifically, the uploaded resource file is verified to determine its file type, a prefix preview address corresponding to the file type is generated, and then it is uploaded to the FastDFS distributed file system. Resource file metadata is generated and written to an Oracle database table.

[0077] The process checks whether writing the resource file to the FastDFS distributed file system was successful, whether the resource file data was successfully written to the database, and whether the unique identifier of the resource file cache was successfully written. If any of these steps fail, an exception is thrown, and the process ends. Once the original resource file, resource file metadata, and resource file cache unique identifier have all been successfully written, file information is returned.

[0078] S303 executes a scheduled task daily to organize the metadata of resource files in Oracle database tables. Data with a create_time greater than 93 days is modified to have a status pending archiving.

[0079] S304 queries the resource file metadata in the file management microservice and finds it to be archived. Then, it sends an HTTP request to the NAS network auxiliary storage system to store the resource file.

[0080] S305: When writing resource files to the NAS network auxiliary storage system, if it fails or times out, it directly returns the corresponding status. Upon success, the NAS network auxiliary storage system's storage address is provided to the file management microservice, which then updates the resource file metadata status and the NAS network auxiliary storage system's storage address in the Oracle database table.

[0081] In some embodiments, the file management microservice is also used to receive a resource acquisition request from a client, obtain the unique identifier of the Group address of the resource file based on the target resource preview address, determine whether the cache library contains the unique identifier of the Group address, and if it does, obtain the target resource file from the FastDFS distributed file system; otherwise, obtain the target resource file from the NAS network auxiliary storage system.

[0082] Specifically, after completing step S305 above, the file management microservice can also perform the following steps:

[0083] When a resource file retrieval request is received, the system first enters the file management microservice to verify whether the source address (request interface) of the resource file request is within the set anti-hotlinking filtering conditions. If it does not exist, a 403 Access Denied response is returned. If it exists, the system then checks whether the resource has been cached in the browser. If it has been cached in the browser and has not expired, a 304 status code is returned, along with the cache expiration time and cache verification information. Upon receiving a 304 status code, the browser will retrieve the resource from the cache.

[0084] If the browser does not have cached information for the resource, continue to check if the Group address exists in the Redis cache. If it exists, retrieve the original resource file through the FastDFS distributed file system; if it does not exist, retrieve the original resource file through the NAS network auxiliary storage system.

[0085] The query process retrieves detailed information from the Oracle table. If the data does not exist, the search ends immediately. If it exists, the file data status indicator `filing_status` is set to "archived". If archived, the process uses an HTTP request to call a standalone Spring Boot service to locate the original resource file with the corresponding file path and name in the NAS network auxiliary storage system, based on the resource file metadata, and returns the file byte stream. Otherwise, the process uses the API address or the `businessType` parameter passed to the API to determine the corresponding FastDFS middleware, uses `storage_group` to determine the group in which the original resource file belongs, and then returns the file byte stream.

[0086] In practical applications, the preview address entered by the user is processed by nginx and then enters the file management microservice. The process checks if the unique identifier "Group" exists in Redis. If it does, the Group address is directly extracted to search for the resource file in the FastDFS distributed file system. If it doesn't exist in the cache, the resource file metadata in the Oracle database is checked; if it doesn't exist, the query is returned directly. Next, the nas_location identifier in the resource file metadata is checked. If it exists, an HTTP request is made to access the NAS network auxiliary storage system; otherwise, an error is returned. The original resource file in the NAS network auxiliary storage system is then checked. If it exists, the query is returned normally; otherwise, the query is terminated. Finally, based on the file preview address, if the original resource file exists, the query is returned normally; otherwise, the query is terminated.

[0087] This invention utilizes both the FastDFS distributed file system and a NAS (Network Attached Storage) system for storage, storing hot and cold data separately. It accepts resource acquisition requests and intercepts and verifies them based on pre-defined anti-hotlinking measures to prevent malicious access and bandwidth consumption. It controls the verification of hot and cold data, allowing hot data to access the FastDFS distributed file system and cold data to access the NAS system. Data without modification requests is cached with a 304 error, reducing bandwidth consumption. In this embodiment, resource file preview access first undergoes anti-hotlinking processing, then cache access, and finally database access, effectively reducing database I / O interactions and improving service performance and response efficiency.

[0088] Based on the same inventive concept, the present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the resource file access method of Embodiment 1 or Embodiment 2 described above, which will not be repeated here.

[0089] The present invention also provides a computer-readable storage medium storing a computer program that executes the resource file access method of Embodiment 1 or Embodiment 2 described above, which will not be described in detail here.

[0090] In the detailed description above, various features are combined together in a single embodiment to simplify this disclosure. This approach to disclosure should not be construed as reflecting an intention that embodiments of the claimed subject matter require more features than are explicitly stated in each claim. Rather, as reflected in the appended claims, the invention is presented with fewer features than all of the features in a single disclosed embodiment. Therefore, the appended claims are hereby explicitly incorporated into the detailed description, with each claim representing a separate preferred embodiment of the invention.

[0091] The foregoing description includes examples of one or more embodiments. It is certainly impossible to describe all possible combinations of components or methods in order to describe the above embodiments, but those skilled in the art will recognize that further combinations and arrangements of the various embodiments are possible. Therefore, the embodiments described herein are intended to cover all such changes, modifications, and variations that fall within the scope of the appended claims. Furthermore, the term “comprising” as used in the specification or claims is interpreted in a manner similar to the term “including,” just as “including,” is interpreted as a conjunction in the claims. Additionally, the use of any term “or” in the specification of the claims is intended to mean “non-exclusive or.”

Claims

1. A method for accessing resource files, characterized in that, Includes the following steps: Receive the uploaded resource file, determine the business type of the resource file, and use the business type identifier of the resource file to generate the first part of the preview address of the resource file; Upload the original resource file to the FastDFS distributed file system, use the unique identifier of the Group address of the resource file returned by the FastDFS distributed file system as the second part of the preview address, and combine it with the first part to generate the preview address of the resource file. Write the resource file metadata to the database table, write the unique identifier of the resource file's Group address to the cache library, and return the resource file information; Periodically filter resource file metadata stored in the database table for a duration longer than a preset period, send the original resource file corresponding to the filtered resource file metadata to the NAS network auxiliary storage system via the FastDFS distributed file system, and delete the unique identifier of the Group address corresponding to the filtered resource file metadata in the cache.

2. The resource file access method as described in claim 1, characterized in that, It also includes the following steps: Receive a resource acquisition request sent by the client, wherein the resource acquisition request includes at least the preview address of the target resource file; The unique identifier of the Group address of the target resource file is obtained from the preview address of the target resource file; Determine whether the cache library contains a unique identifier for the Group address. If it does, retrieve the target resource file from the FastDFS distributed file system; otherwise, retrieve the target resource file from the NAS network auxiliary storage system.

3. The resource file access method as described in claim 1 or 2, characterized in that, After writing the resource file metadata to the database table and writing the unique identifier of the resource file's Group address to the cache, it is necessary to sequentially determine whether FastDFS has successfully written the resource file, whether the resource file metadata has successfully been written to the database, and whether the unique identifier of the resource file's Group address has successfully been written. Only after all three are successful will the resource file information be returned.

4. The resource file access method as described in claim 1 or 2, characterized in that, Periodically filter resource file metadata in the database table that has a storage duration longer than a preset period, and send the original resource file corresponding to the filtered resource file metadata to the NAS network auxiliary storage system for storage by the FastDFS distributed file system, including: The scheduled task filters out the metadata of resource files in the database table that are older than a preset period, and sets the archive flag field stored in the database table to be archived. The resource files corresponding to the selected resource file metadata are sent to the NAS network auxiliary storage system via the FastDFS distributed file system using the HTTP protocol, and the archive flag stored in the database table is set to archived.

5. The resource file access method as described in claim 2, characterized in that, After receiving the resource retrieval request from the client, first determine whether the target resource file corresponding to the target resource preview address has been cached on the client; If the target resource file is already cached on the client and has not expired, a response to continue using the cache is returned to the client, and the client then retrieves the target resource file from its local cache without performing any further steps.

6. The resource file access method as described in claim 5, characterized in that, The response returned to the client to continue using the cache also includes returning the cache expiration time and cache verification information.

7. The resource file access method as described in claim 2, characterized in that, The resource acquisition request also includes a request source address. Before determining whether the target resource file corresponding to the target resource preview address has been cached on the client, it is also checked whether the request source address meets the anti-hotlinking filtering address. If it does not meet the requirement, access is directly prohibited.

8. The resource file access method as described in claim 2, characterized in that, Determine whether the cache contains a unique identifier for the Group address. If it does, retrieve the target resource file from the FastDFS distributed file system. Otherwise, retrieve the target file from the NAS network-attached storage system, including: Determine whether the cache contains a unique identifier for the Group address. If it does, use the unique identifier for the Group address to search for the resource file in the FastDFS distributed file system. otherwise, Query the database table to see if the resource file metadata corresponding to the unique identifier of the Group address exists. If it exists and the stored field "archived" is "archived", then retrieve the target resource file from the NAS network auxiliary storage system via an HTTP request based on the resource file metadata.

9. A resource file management system, characterized in that, The resource file management system includes at least a file management microservice, a scheduling microservice, an archiving microservice, a FastDFS distributed file system, a NAS network auxiliary storage system, a database, and a cache library, wherein: The FastDFS distributed file system is used to store original resource files; the database is used to store resource file metadata; and the cache library is used to store unique identifiers for the Group address of resource files. The timed microservice is used to generate timed expiration notifications for the file management microservice; The file management microservice is used to receive uploaded resource files, determine the business type of the resource files, and generate the first part of the preview address of the resource files using the business type identifier of the resource files; it is also used to upload the original resource files to the FastDFS distributed file system, use the unique identifier of the Group address of the resource files returned by the FastDFS distributed file system as the second part of the preview address, and combine it with the first part to generate the preview address of the resource files; it is also used to write the resource file metadata into a database table, write the unique identifier of the Group address of the resource files into a cache, and return file information; it is also used to, after receiving a timed expiration notification generated by the timed microservice, filter the resource file metadata stored in the database table with a storage duration greater than a preset period, send the original resource files corresponding to the filtered resource file metadata to the NAS network auxiliary storage system for storage by the FastDFS distributed file system, and then delete the unique identifier of the Group address corresponding to the filtered resource file metadata from the cache.

10. The resource file management system as described in claim 9, characterized in that, The file management microservice is also used to, after receiving a resource acquisition request from a client, obtain the unique identifier of the Group address of the resource file based on the preview address of the target resource file, determine whether the cache library contains the unique identifier of the Group address, and if it does, obtain the target resource file from the FastDFS distributed file system; otherwise, obtain the target resource file from the NAS network auxiliary storage system.

11. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 8.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that performs the method of any one of claims 1 to 8.