WO2021068740A1 - 一种文件管理方法及装置 - Google Patents

一种文件管理方法及装置 Download PDF

Info

Publication number
WO2021068740A1
WO2021068740A1 PCT/CN2020/116859 CN2020116859W WO2021068740A1 WO 2021068740 A1 WO2021068740 A1 WO 2021068740A1 CN 2020116859 W CN2020116859 W CN 2020116859W WO 2021068740 A1 WO2021068740 A1 WO 2021068740A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
download
version
identifier
resource table
Prior art date
Application number
PCT/CN2020/116859
Other languages
English (en)
French (fr)
Inventor
杨峙岳
尹强
刘有
王和平
黄山
邸帅
卢道和
Original Assignee
深圳前海微众银行股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 深圳前海微众银行股份有限公司 filed Critical 深圳前海微众银行股份有限公司
Publication of WO2021068740A1 publication Critical patent/WO2021068740A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/13—File access structures, e.g. distributed indices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/1873—Versioning file systems, temporal file systems, e.g. file system supporting different historic versions of files

Definitions

  • This application relates to the big data field of Fintech, and in particular to a file management method and device.
  • HDFS Hadoop Distribution File System
  • the system is a system used to control the different revision content of one or several versions of various documents.
  • the combination of the two systems can easily check and update the detailed content of any specified version of the document.
  • the file version control system generally uses an open source method to connect with the HDFS system to call various file data. Therefore, when it is convenient for users to query and update, they do not have too much access to related operations for users to download. Pay more attention, such as the download time, the downloaded file version, whether the download result is a success or failure, etc. There is no record. This method is for financial companies that classify the record of operating data as an important network security management category. Related information when a file is downloaded is not easy.
  • the processing method of the prior art is a problem to be solved urgently in terms of how to trace the download history of various versions of files.
  • the embodiments of the present application provide a file management method and device, which solves the problem of how to trace the download history of various versions of files in the prior art.
  • the embodiment of the present application provides a file management method, which specifically includes:
  • the first file version queries a second resource table to determine the first start byte and the first end byte of the first file corresponding to the first file version;
  • the first record is stored in a third resource table, the third resource table is used to record the download operation of the file in the HDFS, and the first record is used to mark the download The first file mentioned is successful.
  • a possible implementation manner, before querying the second resource table according to the first file version, further includes:
  • a possible implementation manner after obtaining the first request of the first user to download the first file, further includes:
  • a first instance with a light load is selected from at least one instance; the first request is processed through the first instance, and the first instance is used to process the upload, update, and download of files by the first user for the first time request.
  • a possible implementation method also includes:
  • a possible implementation method also includes:
  • the first identifier marks the writing status as the failure, obtain the first reason for the file stream writing failure of the second file; delete the basic information of the second file in the first resource table Information and the file stream of the second file in the HDFS;
  • the second file identifier and the first reason are stored in a first management table, and the first management table is used to record the first upload and update failed operations of the file in the HDFS.
  • a possible implementation method also includes:
  • the position of the second end byte plus M is the writing start position of the file stream of the second file to the HDFS, where M is An integer greater than 0;
  • a possible implementation manner after obtaining the first identifier, further includes:
  • the fourth storage location is added, and the fourth storage location is to continue writing to the first The location of the file stream of the second file.
  • the embodiment of the present application provides a file management device, which specifically includes:
  • the obtaining unit is configured to obtain the first request of the first user to download the first file
  • the processing unit is configured to obtain the first file identifier and the first file version requested to be downloaded by the first user according to the first request; query the first resource table according to the first file identifier to determine that the first file is in The first storage location of the distributed file system HDFS, the first resource table is used to record the basic information of the files in the HDFS; the second resource table is queried according to the first file version to determine that the first file version corresponds to The first start byte and the first end byte of the first file;
  • the processing unit is configured to determine the download start position and the download end position of the first file in the HDFS according to the first storage location, the first start byte, and the first end byte ;
  • the processing unit is further configured to download the first file according to the download start position and the download end position; when the download of the first file is successful, store the first record in a third resource table, and
  • the third resource table is used to record the download operation of the file in the HDFS, and the first record is used to mark the successful download of the first file.
  • the processing unit is specifically configured to:
  • the processing unit is specifically configured to:
  • a first instance with a light load is selected from at least one instance; the first request is processed through the first instance, and the first instance is used to process the upload, update, and download of files by the first user for the first time request.
  • Utilizing a file management method and device provided by this application has the following beneficial effects: the database called by the file version control system is designed, and a data table recording file download history is added to it to trace the download history of various versions of files .
  • an embodiment of the present application also provides a computing device, including:
  • processor, memory, and communication interface among them, the processor, memory and communication interface are connected by a bus;
  • the processor is configured to read the program in the memory and execute the above-mentioned file management method
  • the memory is used to store one or more executable programs, and can store data used by the processor when performing operations.
  • an embodiment of the present application also provides a non-transitory computer-readable storage medium, which stores computer instructions, which when run on a computer, causes the computer to execute the above-mentioned file management method.
  • an embodiment of the present application also provides a computer program product containing instructions.
  • the computer program product includes a calculation program stored on a non-transitory computer-readable storage medium.
  • the computer program includes program instructions. When the program instructions are executed by a computer, the computer executes the above-mentioned file management method.
  • Figure 1 is a flowchart of a file management method in an embodiment of the application
  • FIG. 2 is a flowchart of the first upload of a file management method in an embodiment of the application
  • FIG. 3 is a flowchart of an updated version of a file management method in an embodiment of the application
  • FIG. 4 is a schematic diagram of an example structure of a file management in an embodiment of the application.
  • Fig. 5 is a schematic structural diagram of a computing device in an embodiment of the application.
  • FIG. 1 is a flowchart of a file management method in an embodiment of the application, as shown in the figure, and the specific steps are described as follows.
  • Step 101 Obtain a first request from a first user to download a first file; obtain a first file identifier and a first file version requested by the first user to download according to the first request.
  • the first request for downloading the first file is sent to the file version control system, and the file version control system obtains the first request, where the first file refers to support
  • the file types that can be supported include text format, binary format, etc., especially when it comes to the field of big data, file types such as script files and material compression packages are also applicable to the file management methods in this application.
  • each instance is a small file version control system.
  • the file version control system receives the first request, it selects at least one instance from at least one instance according to the load balancing algorithm.
  • the first instance with light load; through the first instance to process the first request, the first instance can process the first user's request for uploading, updating, and downloading files for the first time.
  • the states of the 3 instances are: The CPU usage rate of the first instance is 40%, and the CPU usage rate of the second instance is 40%.
  • the CPU occupancy rate of the third instance is 50%, and the CPU usage of the third instance is 75%.
  • the first instance with a light load is selected to receive the first request from the first user and process it; if there are two instances with the same load, it can be random Choose one of the examples, other situations will not be repeated.
  • Step 102 Query a first resource table according to the first file identifier to determine the first storage location of the first file in HDFS, and the first resource table is used to record basic information of the file in the HDFS;
  • the first file version queries the second resource table to determine the first start byte and the first end byte of the first file corresponding to the first file version.
  • a first resource table when the database called by the file version control system is designed in advance, four data tables are designed, including: a first resource table, a second resource table, a third resource table, and a first management table.
  • the first resource table is used to record the basic information of the file in HDFS.
  • the basic information includes the file identifier, the storage location of the file, the owner of the file, the file authority, etc.
  • the file identifier and the storage location of the file are in the first resource table The two most important fields are shown in Table 1.
  • the second resource table is used to record the version information of the file in the HDFS.
  • the version information includes the file identifier, the file version, the file start byte, the file end byte, etc., as shown in Table 2 for details.
  • the third resource table is used to record the download history information of the files in HDFS.
  • the download history information includes file identification, file version, file download time, whether the file download is successful, etc., as shown in Table III.
  • the first management table is used to record the failed operation information of the first upload and update of the file in the HDFS, including the file identifier, the file version, the update time, the reason for the update failure, etc., as shown in Table IV.
  • the above 4 data tables stored in the database are used for the file version control system when receiving various requests for files from users, calling the contents of the data tables to query, update and record related operations, and the specific contents of the files It is stored in HDFS.
  • the first resource table is queried according to the first file identifier to determine the first storage location of the first file in the HDFS.
  • the first resource table for the first operation authority of the first user on the first file according to the first file identifier; when the first operation authority records that the first user has the download authority for the first file, then according to The first file version queries the second resource table, otherwise the first user has no right to download the first file.
  • Step 103 Determine the download start location and download end location of the first file in the HDFS according to the first storage location, the first start byte, and the first end byte.
  • the first storage location marks the location of the file in HDFS. According to this location, the corresponding storage location of the first file to be downloaded in HDFS is obtained, and the first starting byte is determined according to the first file version. And the first end byte obtains the accurate download start position and download end position of the first file to be downloaded.
  • the content of each version of the file can be stored in HDFS as follows: the file content of the second version and the file of the first version The content is stored in the first storage location. More specifically, the file content of the second version may be stored immediately after the content of the file of the first version. Therefore, the first starting byte corresponding to the second version is determined according to the second version. And the first end byte guarantees the accuracy of the content of the first file of this version that needs to be downloaded.
  • Step 104 Download the first file according to the download start location and the download end location.
  • Step 105 When the download of the first file is successful, the first record is stored in a third resource table, the third resource table is used to record the download operation of the file in the HDFS, and the first record is used to Mark that the download of the first file is successful.
  • the first record is stored in the third resource table, and in this way, the relevant information of each file download operation is recorded, so as to trace the download history of various versions of the file.
  • the second record is stored in the third resource table, and the second record is used to mark the failure of downloading the first file.
  • the failed operation information is also recorded in the third resource table, so as to ensure that when tracing the download history of various versions of files, we can more objectively and comprehensively understand the different situations at different times and when different users are downloading, and it is also convenient to troubleshoot failures. There are more detailed reference clues for the reason.
  • the above steps describe the processing method when downloading multiple versions of files. Before downloading the files, users will have to upload the files for the first time, as well as to update the version of the files that have been stored in HDFS. The following is further expanded in the processing The specific steps when the file is uploaded for the first time and the version is updated.
  • FIG. 2 is a flowchart of the first upload of a file management method in an embodiment of the application, as shown in FIG. 2, and the specific steps are described as follows.
  • Step 201 Obtain a second request from a first user to upload a second file; obtain the second file and a second file identifier requested by the first user to upload according to the second request.
  • Step 202 When the content of the second file identifier is empty, configure the second file identifier and the second storage location of the second file; store the second file identifier and the second storage location to The first resource table.
  • the second file uploaded by the user is the file uploaded by the user for the first time
  • the second file identification content carried in the second request is empty
  • the file version control system recognizes the second file after receiving the second request
  • configure the second file identification and the second storage location of the second file for the second file add the basic information of the second file, the second file identification and the second file in the first resource table of the database
  • the second storage location of is stored in the first resource table as an important field.
  • Step 203 Write the file stream of the second file into the HDFS according to the second storage location.
  • Step 204 Obtain a first identifier returned by the HDFS, where the first identifier is used to mark the writing status of the file stream of the second file, including success, failure, and incomplete writing.
  • different return values of HDFS are preset to correspond to different writing status and reasons. For example, if the return value is equal to 0, it means the write status is successful; the return value is less than 0, it means the write status is failed; the return value is greater than 0, it means the write status is incomplete. Among them, the return value is less than 0, and there are many different values corresponding to different reasons for failure. For example, the return value is -1 indicating that the storage function of HDFS is affected by network interruption, and the return value is -2 indicating that it has not been written and has reached the storage location. Capacity limit, etc.
  • Step 205 When the first identifier marks the writing status as the success, configure the first version of the second file; store the second file identifier and the first version to the second Resource table.
  • the file stream writing status of the second file will be different, namely: success, failure, and incomplete writing, where the success status means that the second file is all uploaded to In HDFS; the failed state means that the second file was not uploaded to HDFS due to some reasons, such as network interruption affecting the storage function of HDFS, etc.; there are two types of uncompleted states, one is that there are not all of them due to some reasons Successfully uploaded to HDFS. This situation is equivalent to a failed state.
  • the other is that when the expanded version is updated below, when the latest version is uploaded and appended to the file content of the previous version, the storage location has an upper limit.
  • the upper limit is set as the first threshold, such as 1G capacity.
  • the file version control system when the file version control system obtains that the write status of the first identification mark returned by HDFS is successful, configure the first version of the second file; add the second file's version to the second resource table of the database Version information, the second file identifier and the second file version are stored as important fields in the second resource table, and the second file identifier is returned to the user at the same time, so that when the user initiates a file version update request next time, the request carries the file identifier .
  • the first management table is used to record the data to the HDFS The first upload of the file and the failed operation of the update.
  • the file version control system when the file version control system obtains that the write status of the first identification mark returned by HDFS is failed, it learns the specific reason for the file stream write failure according to the specific value of the HDFS return value; the second file identification and the first reason Store it in the first management table, and delete the basic information of the second file in the first resource table and the file stream of the second file in HDFS.
  • this application uses two methods when obtaining abnormal messages and notifying users: Rest interface And SDK, SDK is used to capture exception messages. If writing fails, the Rest interface is the front-end interface when the user needs to notify the user of the failure after the back-end SDK captures the exception message. The user can choose whether to re-upload after receiving the failure information notification. Wait for processing.
  • the first management table can be used to record information about failed operations for the first upload and update of files in HDFS, and can also be used for life cycle management of file upload, update, and download operations. And the file identification, file version, start time, end time, success or failure reason when downloading, in order to more comprehensively record each operation of the file, so as to control the various operations of the file as a whole.
  • FIG. 3 a flowchart of an updated version of a file management method provided by an embodiment of this application, and the specific steps are described in the following description.
  • Step 301 When the content of the second file identifier is not empty, query the first resource table according to the second file identifier to determine the second storage location; and query the store according to the second file identifier.
  • the second resource table determines the second version of the second file, the second start byte of the second file corresponding to the second version, and the first byte of the second file corresponding to the second version The second end byte.
  • the second file identifier when the content of the second file identifier obtained by the file version control system is not empty, it means that the second file uploaded by the user this time has records in both the first resource table and the second resource table.
  • the second file identifier queries the first resource table to obtain the second storage location, and queries the second resource table to obtain the existing version of the second file, the start byte of the second file corresponding to the existing version, and the end byte of the second file.
  • Step 302 According to the second storage location and the second end byte, determine that the position of the second end byte plus M is the writing start position of the file stream of the second file to the HDFS , M is an integer greater than 0.
  • the value of M is 1Kb
  • the version in the second resource table is found to be 3 according to the second file identifier in step 301
  • the start byte corresponding to the second file of the third version is 1Mb
  • the end word The section is 2Mb
  • the start position of the newly uploaded second file is the end byte 2Mb+1Kb of the third version, that is, the position of 1025Kb is the start writing position of the second file uploaded this time.
  • Step 303 When the second end byte plus M is greater than or equal to the first threshold, a third storage location of the second file is added, and the third storage location is the writing start location.
  • the upper limit of the capacity of the second storage location is the first threshold, and the value is 1G.
  • the start position of the newly uploaded second file is 1G+ 1Kb, which has exceeded the upper limit of the capacity of the second storage location.
  • a third storage location needs to be added as the writing start location of the latest version of the second file.
  • Step 304 Write the second file according to the writing start position.
  • Step 305 Obtain the first identifier; when the first identifier marks the writing status as the successful, configure a third version of the second file, and the value of the third version is the The value of the second version plus N, where N is an integer greater than 0; the second file identifier and the third version are stored in the second resource table.
  • the value of N is 1. It can be seen from the example in step 302 that the value of the latest version of the configured second file is version 3+1, that is, version 4.
  • the first identifier is obtained; when the first identifier marks the writing status as the incomplete writing, and a system exception message is obtained, it is determined that the file stream writing of the second file has failed.
  • the fourth storage location is added, and the fourth storage location is continued writing.
  • the file version control system obtains that the write status of the first identification tag returned by HDFS is not finished, and obtains a system exception message, for example, the return value is -1 to determine the file stream of the second file
  • the return value is -1 to determine the file stream of the second file
  • the reason for the writing failure is that the storage function of HDFS is affected by the network interruption.
  • the reason for the failure and the file identification are stored in the first management table, and the user is notified of the failure information through the Rest interface for the user to choose whether to upload again.
  • the file version control system obtains that the write status of the first identification tag returned by HDFS is not finished, and the system exception message is not obtained, for example, the return value is -2, it is determined that the file stream writing of the second file failed The reason is that the capacity of the storage location has not been completed, and the storage location information needs to be added is fed back to HDFS. After the storage location is added, the file stream of the second file is continued to be written.
  • FIG. 4 is a schematic diagram of an example structure of a file management in an embodiment of the application.
  • the system structure includes: a file version control system 401, a database 402, and a file system HDFS403.
  • the file version control system 401 includes three types of control operations, namely: the user uploads the file 404 for the first time, the user update file 405, and the user downloads the file 406.
  • the database 402 includes a first resource table 407, a second resource table 408, a third resource table 409, and a first management table 410.
  • the file system HDFS403 includes a first file storage 411, a second file storage 412, a third file storage 413, and so on.
  • the method flow shown in Figure 1 to Figure 3 can be applied to the example structure of file management shown in Figure 4 when controlling the first upload, update and download of various file versions.
  • this application also provides a computing device.
  • the computing device includes at least one processor 520 for implementing the method in FIG. Either method.
  • the computing device 500 may also include at least one memory 530 for storing program instructions and/or data.
  • the memory 530 and the processor 520 are coupled.
  • the coupling in the embodiments of the present application is an indirect coupling or communication connection between devices, units or modules, and may be in electrical, mechanical or other forms, and is used for information exchange between devices, units or modules.
  • the processor 520 may cooperate with the memory 530 to operate.
  • the processor 520 may execute program instructions stored in the memory 530. At least one of the at least one memory may be included in the processor.
  • each step of the above method can be completed by an integrated logic circuit of hardware in the processor or instructions in the form of software.
  • the steps of the method disclosed in the embodiments of the present application may be directly embodied as being executed and completed by a hardware processor, or executed and completed by a combination of hardware and software modules in the processor.
  • the software module can be located in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, or electrically erasable programmable memory, registers.
  • the storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware. To avoid repetition, it will not be described in detail here.
  • the processor in the embodiment of the present application may be an integrated circuit chip with signal processing capability.
  • the steps of the foregoing method embodiments can be completed by hardware integrated logic circuits in the processor or instructions in the form of software.
  • the above-mentioned processor may be a general-purpose processor, a digital signal processing circuit (digital signal processor, DSP), a dedicated integrated circuit (application specific integrated circuit, ASIC), a field programmable gate array (field programmable gate array, FPGA) or other Programming logic devices, discrete gates or transistor logic devices, discrete hardware components.
  • DSP digital signal processing circuit
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • Programming logic devices discrete gates or transistor logic devices, discrete hardware components.
  • the general-purpose processor may be a microprocessor or the processor may also be any conventional processor or the like.
  • the steps of the method disclosed in the embodiments of the present application can be directly embodied as being executed and completed by a hardware decoding processor, or executed and completed by a combination of hardware and software modules in the decoding processor.
  • the software module can be located in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, or electrically erasable programmable memory, registers.
  • the storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.
  • the memory in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memory.
  • the non-volatile memory can be read-only memory (ROM), programmable read-only memory (programmable ROM, PROM), erasable programmable read-only memory (erasable PROM, EPROM), and electrically available Erase programmable read-only memory (electrically EPROM, EEPROM) or flash memory.
  • the volatile memory may be random access memory (RAM), which is used as an external cache.
  • RAM random access memory
  • static random access memory static random access memory
  • dynamic RAM dynamic RAM
  • DRAM dynamic random access memory
  • synchronous dynamic random access memory synchronous DRAM, SDRAM
  • double data rate synchronous dynamic random access memory double data rate SDRAM, DDR SDRAM
  • enhanced synchronous dynamic random access memory enhanced SDRAM, ESDRAM
  • synchronous connection dynamic random access memory serial DRAM, SLDRAM
  • direct rambus RAM direct rambus RAM
  • the computing device 500 may further include a communication interface 510 for communicating with other devices through a transmission medium, so that the device used in the computing device 500 can communicate with other devices.
  • the communication interface may be a transceiver, circuit, bus, module, or other type of communication interface.
  • the transceiver when the communication interface is a transceiver, the transceiver may include an independent receiver and an independent transmitter; it may also be a transceiver with integrated transceiver functions, or an interface circuit.
  • the computing device 500 may also include a communication line 540.
  • the communication interface 510, the processor 520, and the memory 530 may be connected to each other through a communication line 540;
  • the communication line 540 may be a peripheral component interconnection standard (peripheral component interconnect, PCI for short) bus or an extended industry standard architecture (extended industry standard architecture) , Referred to as EISA) bus and so on.
  • the communication line 540 can be divided into an address bus, a data bus, a control bus, and the like. For ease of presentation, only one thick line is used to represent in FIG. 5, but it does not mean that there is only one bus or one type of bus.
  • the embodiments of the present application also provide a non-transitory computer-readable storage medium.
  • the non-transitory computer-readable storage medium stores computer instructions. When it runs on a computer, the computer executes the above-mentioned file management. method.
  • inventions of the present application provide a computer program product.
  • the computer program product includes a calculation program stored on a non-transitory computer-readable storage medium.
  • the computer program includes program instructions. When executed by a computer, the computer is caused to execute the above-mentioned file management method.
  • These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction device.
  • the device implements the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种文件管理方法及装置，涉及金融科技(Fintech)的数据管理领域，其中方法为：获取第一用户下载第一文件的第一请求；根据所述第一请求获取所述第一用户请求下载的第一文件标识和第一文件版本；确定所述第一文件在分布式文件系统HDFS的第一存储位置，以及确定所述第一文件版本对应的所述第一文件的第一开始字节和第一结束字节；根据所述第一存储位置、所述第一开始字节以及所述第一结束字节，确定所述第一文件在所述HDFS中的下载开始位置和下载结束位置；当下载所述第一文件成功时，将第一记录存储至第三资源表，该方法可应用于金融科技(Fintech)。

Description

一种文件管理方法及装置
相关申请的交叉引用
本申请要求在2019年10月10日提交中国专利局、申请号为201910957957.8、申请名称为“一种文件管理方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及金融科技(Fintech)的大数据领域，尤其涉及一种文件管理方法及装置。
背景技术
随着计算机技术的发展，越来越多的技术(大数据、分布式、区块链(Blockchain)、人工智能等)应用在金融领域，传统金融业正在逐步向金融科技(Fintech)转变。目前，金融科技领域中，越来越多的数据被产生，也被越来越多的用于各种信息处理中，由此也对应产生各种文件，对这些文件的管理就显得愈发重要，现有技术中一般采用分布式文件系统(Hadoop Distribution File System，HDFS)对文件进行存储管理，再结合文件版本控制系统一并管理各种版本文件的查询、更新等操作。其中，HDFS是基于流数据模式访问和处理超大文件的需求开发的系统，可以运行在廉价的商用服务器上，它具备高容错、高可靠性、高扩展性以及高获得性等特征；文件版本控制系统是用于控制各种文件的一个或若干版本的不同修订内容的系统，两种系统结合使用可以方便的查阅、更新任一指定版本文件的详细内容。
现有技术的这种处理方式中，文件版本控制系统一般采用开源的方式与HDFS系统连接以调用各种文件数据，因此在方便用户查询、更新等操作时，对用户下载的相关操作并没有太多关心，比如下载的时间、下载的文件版本、下载的结果是成功还是失败等没有记录，这种方式对于将操作数据的记录划为重要网络安全管理范畴的金融公司来说，若需要追溯某一文件下载时的相关信息并不容易。
因此，现有技术的处理方式在如何追溯各种版本文件的下载历史方面是一个亟待解决的问题。
发明内容
本申请实施例提供一种文件管理方法及装置，解决了现有技术中如何追溯各种版本文件的下载历史问题。
本申请实施例提供一种文件管理方法，具体包括：
获取第一用户下载第一文件的第一请求；根据所述第一请求获取所述第一用户请求下载的第一文件标识和第一文件版本；
根据所述第一文件标识查询第一资源表，确定所述第一文件在分布式文件系统HDFS的第一存储位置，所述第一资源表用于记录所述HDFS中文件的基本信息；根据所述第一文件版本查询第二资源表，确定所述第一文件版本对应的所述第一文件的第一开始字节和第一结束字节；
根据所述第一存储位置、所述第一开始字节以及所述第一结束字节，确定所述第一文件在所述HDFS中的下载开始位置和下载结束位置；
根据所述下载开始位置和所述下载结束位置下载所述第一文件；
当下载所述第一文件成功时，将第一记录存储至第三资源表，所述第三资源表用于记录对所述HDFS中文件的下载操作，所述第一记录用于标记下载所述第一文件成功。
一种可能的实现方式，根据所述第一文件版本查询第二资源表之前，还包括：
根据所述第一文件标识查询所述第一资源表中所述第一用户对所述第一文件的第一操作权限；
当所述第一操作权限记录所述第一用户对所述第一文件有下载权限时，根据所述第一文件版本查询所述第二资源表。
一种可能的实现方式，获取第一用户下载第一文件的第一请求之后，还包括：
按照负载均衡算法从至少一个实例中选取负载轻的第一实例；通过第一实例对所述第一请求处理，所述第一实例用于处理所述第一用户首次上传、更新以及下载文件的请求。
一种可能的实现方式，还包括：
获取第一用户上传第二文件的第二请求；根据所述第二请求获取所述第一用户请求上传的所述第二文件和第二文件标识；
当所述第二文件标识的内容为空时，配置所述第二文件标识以及所述第二文件的第二存储位置；存储所述第二文件标识和所述第二存储位置至所述第一资源表；
根据所述第二存储位置，将所述第二文件的文件流写入所述HDFS；
获取所述HDFS返回的第一标识，所述第一标识用于标记所述第二文件的文件流的写入状态，包括成功、失败以及未写完；
当所述第一标识标记所述写入状态为所述成功时，配置所述第二文件的第一版本；存储所述第二文件标识和所述第一版本至所述第二资源表。
一种可能的实现方式，还包括：
当所述第一标识标记所述写入状态为所述失败时，获取所述第二文件的文件流写入失败的第一原因；删除所述第一资源表中所述第二文件的基本信息以及所述HDFS中的所述第二文件的文件流；
存储所述第二文件标识和所述第一原因至第一管理表，所述第一管理表用于记录对HDFS中文件的首次上传以及更新的失败操作。
一种可能的实现方式，还包括：
当所述第二文件标识的内容为非空时，根据所述第二文件标识查询所述第一资源表，确定所述第二存储位置；且根据所述第二文件标识查询所述第二资源表，确定所述第二文件的第二版本、所述第二版本对应的所述第二文件的第二开始字节以及所述第二版本对应的所述第二文件的第二结束字节；
根据所述第二存储位置以及所述第二结束字节，确定所述第二结束字节加M的位置为所述第二文件的文件流写入所述HDFS的写入开始位置，M为大于0的整数；
当所述第二结束字节加M大于或等于第一阈值时，新增所述第二文件的第三存储位置，所述第三存储位置为所述写入开始位置；
根据所述写入开始位置写入所述第二文件；
获取所述第一标识；当所述第一标识标记所述写入状态为所述成功时，配置所述第二文件的第三版本，所述第三版本的取值为所述第二版本的取值加N，N为大于0的整数；存储所述第二文件标识和所述第三版本至所述第二资源表。
一种可能的实现方式，获取所述第一标识之后，还包括：
当所述第一标识标记所述写入状态为所述未写完，且未获取到系统异常消息时，新增所述第四存储位置，所述第四存储位置为继续写入所述第二文件的文件流的位置。
本申请实施例提供一种文件管理装置，具体包括：
获取单元，用于获取第一用户下载第一文件的第一请求；
处理单元，用于根据所述第一请求获取所述第一用户请求下载的第一文件标识和第一文件版本；根据所述第一文件标识查询第一资源表，确定所述 第一文件在分布式文件系统HDFS的第一存储位置，所述第一资源表用于记录所述HDFS中文件的基本信息；根据所述第一文件版本查询第二资源表，确定所述第一文件版本对应的所述第一文件的第一开始字节和第一结束字节；
所述处理单元，用于根据所述第一存储位置、所述第一开始字节以及所述第一结束字节，确定所述第一文件在所述HDFS中的下载开始位置和下载结束位置；
所述处理单元，还用于根据所述下载开始位置和所述下载结束位置下载所述第一文件；当下载所述第一文件成功时，将第一记录存储至第三资源表，所述第三资源表用于记录对所述HDFS中文件的下载操作，所述第一记录用于标记下载所述第一文件成功。
一种可能的实现方式，所述处理单元具体用于：
根据所述第一文件标识查询所述第一资源表中所述第一用户对所述第一文件的第一操作权限；
当所述第一操作权限记录所述第一用户对所述第一文件有下载权限时，根据所述第一文件版本查询所述第二资源表。
一种可能的实现方式，所述处理单元具体用于：
按照负载均衡算法从至少一个实例中选取负载轻的第一实例；通过第一实例对所述第一请求处理，所述第一实例用于处理所述第一用户首次上传、更新以及下载文件的请求。
利用本申请提供的一种文件管理方法及装置，具有以下有益效果：通过对文件版本控制系统调用的数据库进行设计，在其中增加记录文件下载历史的数据表以便于追溯各种版本文件的下载历史。
相应的，本申请实施例还提供了一种计算设备，包括：
处理器、存储器、通信接口；其中，处理器、存储器与通信接口之间通过总线连接；
所述处理器，用于读取所述存储器中的程序，执行上述文件管理方法；
所述存储器，用于存储一个或多个可执行程序，可以存储所述处理器在执行操作时所使用的数据。
相应的，本申请实施例还提供了一种非暂态计算机可读存储介质，非暂态计算机可读存储介质中存储计算机指令，当其在计算机上运行时，使得计算机执行上述文件管理方法。
相应的，本申请实施例还提供一种包含指令的计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算程序，所述计 算机程序包括程序指令，当所述程序指令被计算机执行时，使所述计算机执行上述文件管理方法。
附图说明
图1为本申请实施例中一种文件管理方法流程图；
图2为本申请实施例中一种文件管理方法的首次上传流程图；
图3为本申请实施例中一种文件管理方法的更新版本流程图；
图4为本申请实施例中一种文件管理的实例结构示意图；
图5为本申请实施例中一种计算设备的结构示意图。
具体实施方式
为了更好的理解上述技术方案，下面将结合说明书附图及具体的实施方式对上述技术方案进行详细的说明，应当理解本申请实施例以及实施例中的具体特征是对本申请技术方案的详细的说明，而不是对本申请技术方案的限定，在不冲突的情况下，本申请实施例以及实施例中的技术特征可以相互结合。
随着计算机技术的发展，越来越多的技术(大数据、分布式、区块链(Blockchain)、人工智能等)应用在金融领域，传统金融业正在逐步向金融科技(Fintech)转变。图1为本申请实施例中一种文件管理方法流程图，如图所示，具体步骤描述如下。
步骤101：获取第一用户下载第一文件的第一请求；根据所述第一请求获取所述第一用户请求下载的第一文件标识和第一文件版本。
具体的，当第一用户有下载第一文件的需求时，将下载第一文件的第一请求发送给文件版本控制系统，文件版本控制系统获取到第一请求，其中，第一文件是指支持各种类型的文件，可以支持的文件类型有文本形式、二进制形式等，尤其在涉及大数据领域时，脚本文件、物料压缩包等文件类型也都适用本申请中的文件管理方法。
进一步具体的，文件版本控制系统中部署有多个实例，每个实例都是一个小型的文件版本控制系统，当文件版本控制系统获取到第一请求时，按照负载均衡算法从至少一个实例中选取负载轻的第一实例；通过第一实例对第一请求进行处理，第一实例可以处理第一用户首次上传、更新以及下载文件的请求。
举例来说，文件版本控制系统中部署有3个实例，3个实例的状态分别是： 第一实例的中央处理器(Central Processing Unit，CPU)占用率为40％、第二实例的CPU占用率为50％、第三实例的CPU占用率为75％，按照负载均衡算法，选取负载轻的第一实例接收第一用户的第一请求并进行处理；若其中有2个实例负载相同时可随机选取其中1个实例，其它情况不再赘述。根据第一请求获取其中携带的第一文件标识和第一文件版本。
步骤102：根据所述第一文件标识查询第一资源表，确定所述第一文件在HDFS的第一存储位置，所述第一资源表用于记录所述HDFS中文件的基本信息；根据所述第一文件版本查询第二资源表，确定所述第一文件版本对应的所述第一文件的第一开始字节和第一结束字节。
具体的，预先对文件版本控制系统调用的数据库进行设计时，设计有4张数据表，包括：第一资源表、第二资源表、第三资源表以及第一管理表。
其中，第一资源表用于记录HDFS中文件的基本信息，基本信息包括文件标识、文件的存储位置、文件的所属者、文件的权限等，文件标识和文件的存储位置是第一资源表中最重要的两个字段，具体如表一所示。
表一
Figure PCTCN2020116859-appb-000001
第二资源表用于记录HDFS中文件的版本信息，版本信息包括文件标识、文件版本、文件开始字节、文件结束字节等，具体如表二所示。
表二
Figure PCTCN2020116859-appb-000002
第三资源表用于记录HDFS中文件的下载历史信息，下载历史信息包括文件标识、文件版本、文件下载时间、文件下载是否成功等，具体如表三所示。
表三
字段 作用 备注
resource_id 记录下载资源的resource_id  
version 记录下载资源的version  
downloader 记录下载的用户  
start_time 记录下载时间  
end_time 记录结束时间  
status 记录是否成功 0表示成功，1表示失败
err_msg 记录失败原因 null表示成功，否则记录失败原因
第一管理表用于记录对HDFS中文件的首次上传以及更新的失败操作信息，包括文件标识、文件版本、更新的时间、更新失败的原因等，具体如表四所示。
表四
Figure PCTCN2020116859-appb-000003
上述4张存储在数据库中的数据表用于文件版本控制系统在收到用户提出的对文件的各种请求时，调用数据表中的内容进行查询、更新以及记录的相关操作，文件的具体内容则存储在HDFS中。
因此，本步骤中根据第一文件标识查询第一资源表，确定第一文件在HDFS中的第一存储位置。
进一步具体的，根据所述第一文件标识查询第一资源表中第一用户对第一文件的第一操作权限；当第一操作权限记录第一用户对第一文件有下载权限时，再根据第一文件版本查询第二资源表，否则第一用户没有权限对第一文件进行下载。
步骤103：根据所述第一存储位置、所述第一开始字节以及所述第一结束字节，确定所述第一文件在所述HDFS中的下载开始位置和下载结束位置。
具体的，第一存储位置标记的是文件在HDFS中的位置，根据这一位置得到待下载的第一文件在HDFS中对应的存储位置，再根据第一文件版本确定出的第一开始字节以及第一结束字节得到待下载的第一文件的准确的下载开始位置和下载结束位置。
举例来说，第一用户请求下载的是第一文件的第二版本文件内容，本申请中文件各版本的内容在HDFS中的存储方式可以是：第二版本的文件内容和第一版本的文件内容都存储在第一存储位置，进一步具体的，第二版本文件内容可以是紧接在第一版本文件内容之后存储的，因此根据第二版本确定出的第二版本对应的第一开始字节和第一结束字节保证了所需下载的这一版本的第一文件内容的准确性。
步骤104：根据所述下载开始位置和所述下载结束位置下载所述第一文件。
步骤105：当下载所述第一文件成功时，将第一记录存储至第三资源表，所述第三资源表用于记录对所述HDFS中文件的下载操作，所述第一记录用于标记下载所述第一文件成功。
具体的，当下载第一文件成功时，将第一记录存储至第三资源表中，通过这种方式记录每次对文件的下载操作的相关信息，以便于追溯各种版本文件的下载历史。
进一步具体的，当下载第一文件失败时，将第二记录存储至第三资源表，第二记录用于标记下载第一文件失败。将失败的操作信息也记录在第三资源表中，从而确保在追溯各种版本文件的下载历史时能更加客观、全面地了解到不同时间、不同用户下载时的不同情况，也便于在排查失败原因时有更多详细的参考线索。
上述步骤内容描述的是多版本文件下载时的处理方法，在下载文件之前，用户对文件会有首次上传的需求，以及对已经存储在HDFS中的文件进行版本更新的需求，下面进一步展开在处理文件首次上传和版本更新时的具体步骤情况。
图2为本申请实施例中一种文件管理方法的首次上传流程图，如图2所示，具体步骤描述如下。
步骤201：获取第一用户上传第二文件的第二请求；根据所述第二请求获取所述第一用户请求上传的所述第二文件和第二文件标识。
步骤202：当所述第二文件标识的内容为空时，配置所述第二文件标识以及所述第二文件的第二存储位置；存储所述第二文件标识和所述第二存储位置至所述第一资源表。
具体的，当用户上传的第二文件为用户首次上传的文件时，第二请求中携带的第二文件标识内容是为空的，文件版本控制系统在接收到第二请求，识别出第二文件标识内容为空时，为第二文件配置第二文件标识和第二文件的第二存储位置；在数据库的第一资源表中新增第二文件的基本信息，第二文件标识和第二文件的第二存储位置作为重要字段存储在第一资源表中。
步骤203：根据所述第二存储位置，将所述第二文件的文件流写入所述HDFS。
步骤204：获取所述HDFS返回的第一标识，所述第一标识用于标记所述第二文件的文件流的写入状态，包括成功、失败以及未写完。
具体的，预先设定HDFS不同的返回值对应着不同的写入状态以及原因。比如：返回值等于0，表示写入状态为成功；返回值小于0，表示写入状态为 失败；返回值大于0，表示写入状态为未写完。其中，返回值小于0又分多种不同值对应失败时的不同原因，比如返回值为-1表示因网络中断影响HDFS的存储功能，返回值为-2表示未写完，已到存储位置的容量上限等。
步骤205：当所述第一标识标记所述写入状态为所述成功时，配置所述第二文件的第一版本；存储所述第二文件标识和所述第一版本至所述第二资源表。
具体的，在上传第二文件至HDFS中时，第二文件的文件流写入状态会有不同的情况，分别是：成功、失败以及未写完，其中，成功状态表示第二文件全部上传至HDFS中；失败状态表示第二文件因一些原因没有全部成功上传至HDFS中，比如，原因有网络中断影响HDFS的存储功能等；未写完状态分有两种，一种是因一些原因没有全部成功上传至HDFS中，这种情况等同于失败状态，另一种是在下文将展开的版本更新时，最新版本上传追加至前一版本的文件内容之后时，所在存储位置的容量有上限，设定上限为第一阈值，比如1G的容量，当超过该上限时，需要存储在新的位置上，这两种未写完的情况是需要区分处理的，但在首次上传文件的情况中，未写完状态下一般不存在超过上限的情况，因此首次上传文件的情况中，文件的写入状态只分两种：成功和失败。文件版本控制系统通过HDFS返回的标记文件写入状态的第一标识，获知文件的上传情况以判断下一步的处理。
在本步骤中，当文件版本控制系统获取到HDFS返回的第一标识标记的写入状态为成功时，配置第二文件的第一版本；在数据库的第二资源表中新增第二文件的版本信息，第二文件标识和第二文件版本作为重要字段存储在第二资源表中，同时将第二文件标识返回给用户，以使用户在下次发起更新文件版本请求时，请求中携带文件标识。
进一步具体的，当所述第一标识标记所述写入状态为所述失败时，获取所述第二文件的文件流写入失败的第一原因；删除所述第一资源表中所述第二文件的基本信息以及所述HDFS中的所述第二文件的文件流；存储所述第二文件标识和所述第一原因至第一管理表，所述第一管理表用于记录对HDFS中文件的首次上传以及更新的失败操作。
其中，当文件版本控制系统获取到HDFS返回的第一标识标记的写入状态为失败时，根据HDFS返回值的具体数值获知文件流写入失败的具体原因；将第二文件标识和第一原因存储至第一管理表中，并删除第一资源表中第二文件的基本信息以及HDFS中的第二文件的文件流，同时本申请在获取消息异常和通知用户时使用两种方式：Rest接口和SDK，SDK用于捕获异常消息， 如写入失败，Rest接口则是在后端的SDK捕获异常消息后需要通知用户失败信息时的前端接口，用户在接收到失败信息通知后可选择是否重新上传等处理。
进一步具体的，第一管理表可以用于记录对HDFS中文件的首次上传以及更新的失败操作信息，也可以用于文件的上传、更新以及下载等操作的生命周期管理，记录文件在上传、更新以及下载时的文件标识、文件版本、开始时间、结束时间、是否成功、失败原因，以更全面地记录文件的每次操作，从而能整体管控文件的各类操作。
上述步骤是文件首次上传时的情况，在文件首次上传后，若用户有更新文件版本请求的需求，则可以根据图3所示的步骤执行。如图3所示，为本申请实施例提供的一种文件管理方法的更新版本流程图，具体步骤详见如下描述。
步骤301：当所述第二文件标识的内容为非空时，根据所述第二文件标识查询所述第一资源表，确定所述第二存储位置；且根据所述第二文件标识查询所述第二资源表，确定所述第二文件的第二版本、所述第二版本对应的所述第二文件的第二开始字节以及所述第二版本对应的所述第二文件的第二结束字节。
具体的，当文件版本控制系统获取到的第二文件标识的内容为非空时，表示本次用户上传的第二文件在第一资源表中和第二资源表中都已有记录，根据第二文件标识查询第一资源表得到第二存储位置，查询第二资源表得到第二文件的已有版本、已有版本对应的第二文件的开始字节以及第二文件的结束字节。
步骤302：根据所述第二存储位置以及所述第二结束字节，确定所述第二结束字节加M的位置为所述第二文件的文件流写入所述HDFS的写入开始位置，M为大于0的整数。
具体的，举例来说，M取值为1Kb，根据步骤301中第二文件标识查询到第二资源表中的版本为3，第3版本的第二文件对应的开始字节是1Mb，结束字节是2Mb，新上传的第二文件的开始位置为第3版本的结束字节2Mb+1Kb，即1025Kb的位置为本次上传的第二文件的开始写入位置。
步骤303：当所述第二结束字节加M大于或等于第一阈值时，新增所述第二文件的第三存储位置，所述第三存储位置为所述写入开始位置。
举例来说，第二存储位置的容量上限为第一阈值，取值为1G，当第3版本的第二文件对应的结束字节是1G时，新上传的第二文件的开始位置为 1G+1Kb，已超出第二存储位置的容量上限，这时需要新增第三存储位置以作为第二文件的最新版本的写入开始位置。
步骤304：根据所述写入开始位置写入所述第二文件。
步骤305：获取所述第一标识；当所述第一标识标记所述写入状态为所述成功时，配置所述第二文件的第三版本，所述第三版本的取值为所述第二版本的取值加N，N为大于0的整数；存储所述第二文件标识和所述第三版本至所述第二资源表。
举例来说，N取值为1，结合步骤302中例子可知，配置的第二文件的最新版本的取值为第3版本+1，即第4版本。
进一步具体的，获取所述第一标识；当所述第一标识标记所述写入状态为所述未写完，且获取到系统异常消息时，确定所述第二文件的文件流写入失败的第二原因，存储所述第二文件标识和所述第二原因至所述第一管理表。
进一步具体的，当所述第一标识标记所述写入状态为所述未写完，且未获取到系统异常消息时，新增所述第四存储位置，所述第四存储位置为继续写入所述第二文件的文件流的位置。
举例来说，当文件版本控制系统获取到HDFS返回的第一标识标记的写入状态为未写完，且获取到系统异常消息时，比如，返回值为-1，确定第二文件的文件流写入失败的原因为因网络中断影响HDFS的存储功能，将这一失败原因和文件标识存储至第一管理表中，同时通过Rest接口通知用户失败信息以供用户选择是否重新上传。
当文件版本控制系统获取到HDFS返回的第一标识标记的写入状态为未写完，且未获取到系统异常消息时，比如，返回值为-2，确定第二文件的文件流写入失败的原因为未写完，已到存储位置的容量上限，将需新增存储位置消息反馈给HDFS，在新增存储位置后继续写入第二文件的文件流。
图4为本申请实施例中一种文件管理的实例结构示意图，如图4所示，系统结构包括：文件版本控制系统401、数据库402以及文件系统HDFS403。
其中，文件版本控制系统401包括3种控制操作，分别是：用户首次上传文件404、用户更新文件405以及用户下载文件406。
数据库402包括第一资源表407、第二资源表408、第三资源表409、第一管理表410。
文件系统HDFS403包括第一文件存储411、第二文件存储412以及第三文件存储413等。
图1-图3所示的方法流程在控制各种文件版本的首次上传、更新以及下 载时可以应用到图4所示的文件管理的实例结构中。
基于与上述图1所示的方法相同的构思，本申请还提供一种计算设备，如图5所示，该计算设备包括至少一个处理器520，用于实现本申请实施例提供的图1中任一方法。
计算设备500还可以包括至少一个存储器530，用于存储程序指令和/或数据。存储器530和处理器520耦合。本申请实施例中的耦合是装置、单元或模块之间的间接耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。处理器520可能和存储器530协同操作。处理器520可能执行存储器530中存储的程序指令。所述至少一个存储器中的至少一个可以包括于处理器中。
在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。
应注意，本申请实施例中的处理器可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理电路(digital signal processor，DSP)、专用集成芯片(application specific integrated circuit，ASIC)、现场可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
可以理解，本申请实施例中的存储器可以是易失性存储器或非易失性存 储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。应注意，本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
计算设备500还可以包括通信接口510，用于通过传输介质和其它设备进行通信，从而用于计算设备500中的装置可以和其它设备进行通信。在本申请实施例中，通信接口可以是收发器、电路、总线、模块或其它类型的通信接口。在本申请实施例中，通信接口为收发器时，收发器可以包括独立的接收器、独立的发射器；也可以集成收发功能的收发器、或者是接口电路。
计算设备500还可以包括通信线路540。其中，通信接口510、处理器520以及存储器530可以通过通信线路540相互连接；通信线路540可以是外设部件互连标准(peripheral component interconnect，简称PCI)总线或扩展工业标准结构(extended industry standard architecture，简称EISA)总线等。所述通信线路540可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
基于同一发明构思，本申请实施例还提供了一种非暂态计算机可读存储介质，非暂态计算机可读存储介质中存储计算机指令，当其在计算机上运行时，使得计算机执行上述文件管理方法。
基于同一发明构思，本申请实施例提供一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，使所述计算机执行上述文件管理方法。
本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或 方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (13)

  1. 一种文件管理方法，其特征在于，包括：
    获取第一用户下载第一文件的第一请求；根据所述第一请求获取所述第一用户请求下载的第一文件标识和第一文件版本；
    根据所述第一文件标识查询第一资源表，确定所述第一文件在分布式文件系统HDFS的第一存储位置，所述第一资源表用于记录所述HDFS中文件的基本信息；根据所述第一文件版本查询第二资源表，确定所述第一文件版本对应的所述第一文件的第一开始字节和第一结束字节；
    根据所述第一存储位置、所述第一开始字节以及所述第一结束字节，确定所述第一文件在所述HDFS中的下载开始位置和下载结束位置；
    根据所述下载开始位置和所述下载结束位置下载所述第一文件；
    当下载所述第一文件成功时，将第一记录存储至第三资源表，所述第三资源表用于记录对所述HDFS中文件的下载操作，所述第一记录用于标记下载所述第一文件成功。
  2. 如权利要求1所述的方法，其特征在于，根据所述第一文件版本查询第二资源表之前，还包括：
    根据所述第一文件标识查询所述第一资源表中所述第一用户对所述第一文件的第一操作权限；
    当所述第一操作权限记录所述第一用户对所述第一文件有下载权限时，根据所述第一文件版本查询所述第二资源表。
  3. 如权利要求1所述的方法，其特征在于，获取第一用户下载第一文件的第一请求之后，还包括：
    按照负载均衡算法从至少一个实例中选取负载轻的第一实例；通过第一实例对所述第一请求处理，所述第一实例用于处理所述第一用户首次上传、更新以及下载文件的请求。
  4. 如权利要求1所述的方法，其特征在于，还包括：
    获取第一用户上传第二文件的第二请求；根据所述第二请求获取所述第一用户请求上传的所述第二文件和第二文件标识；
    当所述第二文件标识的内容为空时，配置所述第二文件标识以及所述第二文件的第二存储位置；存储所述第二文件标识和所述第二存储位置至所述第一资源表；
    根据所述第二存储位置，将所述第二文件的文件流写入所述HDFS；
    获取所述HDFS返回的第一标识，所述第一标识用于标记所述第二文件的文件流的写入状态，包括成功、失败以及未写完；
    当所述第一标识标记所述写入状态为所述成功时，配置所述第二文件的第一版本；存储所述第二文件标识和所述第一版本至所述第二资源表。
  5. 如权利要求4所述的方法，其特征在于，还包括：
    当所述第一标识标记所述写入状态为所述失败时，获取所述第二文件的文件流写入失败的第一原因；删除所述第一资源表中所述第二文件的基本信息以及所述HDFS中的所述第二文件的文件流；
    存储所述第二文件标识和所述第一原因至第一管理表，所述第一管理表用于记录对HDFS中文件的首次上传以及更新的失败操作。
  6. 如权利要求5所述的方法，其特征在于，还包括：
    当所述第二文件标识的内容为非空时，根据所述第二文件标识查询所述第一资源表，确定所述第二存储位置；且根据所述第二文件标识查询所述第二资源表，确定所述第二文件的第二版本、所述第二版本对应的所述第二文件的第二开始字节以及所述第二版本对应的所述第二文件的第二结束字节；
    根据所述第二存储位置以及所述第二结束字节，确定所述第二结束字节加M的位置为所述第二文件的文件流写入所述HDFS的写入开始位置，M为大于0的整数；
    当所述第二结束字节加M大于或等于第一阈值时，新增所述第二文件的第三存储位置，所述第三存储位置为所述写入开始位置；
    根据所述写入开始位置写入所述第二文件；
    获取所述第一标识；当所述第一标识标记所述写入状态为所述成功时，配置所述第二文件的第三版本，所述第三版本的取值为所述第二版本的取值加N，N为大于0的整数；存储所述第二文件标识和所述第三版本至所述第二资源表。
  7. 如权利要求6所述的方法，其特征在于，获取所述第一标识之后，还包括：
    当所述第一标识标记所述写入状态为所述未写完，且未获取到系统异常消息时，新增所述第四存储位置，所述第四存储位置为继续写入所述第二文件的文件流的位置。
  8. 一种文件管理装置，其特征在于，包括：
    获取单元，用于获取第一用户下载第一文件的第一请求；
    处理单元，用于根据所述第一请求获取所述第一用户请求下载的第一文 件标识和第一文件版本；根据所述第一文件标识查询第一资源表，确定所述第一文件在分布式文件系统HDFS的第一存储位置，所述第一资源表用于记录所述HDFS中文件的基本信息；根据所述第一文件版本查询第二资源表，确定所述第一文件版本对应的所述第一文件的第一开始字节和第一结束字节；
    所述处理单元，用于根据所述第一存储位置、所述第一开始字节以及所述第一结束字节，确定所述第一文件在所述HDFS中的下载开始位置和下载结束位置；
    所述处理单元，还用于根据所述下载开始位置和所述下载结束位置下载所述第一文件；当下载所述第一文件成功时，将第一记录存储至第三资源表，所述第三资源表用于记录对所述HDFS中文件的下载操作，所述第一记录用于标记下载所述第一文件成功。
  9. 如权利要求8所述的装置，其特征在于，所述处理单元具体用于：
    根据所述第一文件标识查询所述第一资源表中所述第一用户对所述第一文件的第一操作权限；
    当所述第一操作权限记录所述第一用户对所述第一文件有下载权限时，根据所述第一文件版本查询所述第二资源表。
  10. 如权利要求8所述的装置，其特征在于，所述处理单元具体用于：
    按照负载均衡算法从至少一个实例中选取负载轻的第一实例；通过第一实例对所述第一请求处理，所述第一实例用于处理所述第一用户首次上传、更新以及下载文件的请求。
  11. 一种计算设备，其特征在于，包括处理器、存储器、通信接口，其中处理器、存储器与通信接口之间通过总线连接；
    所述处理器，用于读取所述存储器中的程序，执行权利要求1至7任一所述方法；
    所述存储器，用于存储一个或多个可执行程序，以及存储所述处理器在执行操作时所使用的数据。
  12. 一种非暂态计算机可读存储介质，其特征在于，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行权利要求1至7任一所述方法。
  13. 一种计算机程序产品，其特征在于，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，使所述计算机执行权利要求1至7任一所述方法。
PCT/CN2020/116859 2019-10-10 2020-09-22 一种文件管理方法及装置 WO2021068740A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910957957.8 2019-10-10
CN201910957957.8A CN110597764B (zh) 2019-10-10 2019-10-10 一种文件下载、版本管理方法及装置

Publications (1)

Publication Number Publication Date
WO2021068740A1 true WO2021068740A1 (zh) 2021-04-15

Family

ID=68866095

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/116859 WO2021068740A1 (zh) 2019-10-10 2020-09-22 一种文件管理方法及装置

Country Status (2)

Country Link
CN (1) CN110597764B (zh)
WO (1) WO2021068740A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110597764B (zh) * 2019-10-10 2024-05-07 深圳前海微众银行股份有限公司 一种文件下载、版本管理方法及装置
CN111427614B (zh) * 2020-03-20 2023-08-22 中国银行股份有限公司 文件版本管理方法及装置
CN113378119B (zh) * 2021-06-25 2023-04-07 成都卫士通信息产业股份有限公司 一种软件授权方法、装置、设备及存储介质

Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060288056A1 (en) * 2005-06-17 2006-12-21 Nec Corporation File version management device, method, and program
CN103281394A (zh) * 2013-06-07 2013-09-04 北京奇虎科技有限公司 文件获取方法、节点服务器和系统
CN103475687A (zh) * 2013-05-24 2013-12-25 北京网秦天下科技有限公司 用于下载网站数据的分布式方法和系统
CN103595770A (zh) * 2013-10-29 2014-02-19 北京奇虎科技有限公司 Sdk实现文件下载的方法与装置
CN103986747A (zh) * 2014-04-14 2014-08-13 曦威胜科技开发（深圳）有限公司 P2p协议中文件共享下载方法
CN104572845A (zh) * 2014-12-12 2015-04-29 百度在线网络技术（北京）有限公司 文件分发方法、装置、设备及系统
US20150205979A1 (en) * 2012-06-19 2015-07-23 Beijing Qihoo Technology Company Limited Method and system for repairing file at user terminal
CN106027647A (zh) * 2016-05-20 2016-10-12 云南云电同方科技有限公司 Lxpfs集群分布式文件存储系统
CN106294585A (zh) * 2016-07-28 2017-01-04 四川新环佳科技发展有限公司 一种云计算平台下的存储方法
US20180321932A1 (en) * 2015-11-02 2018-11-08 Guangzhou UCWEB Computer Technology Co.,Ltd. Method, device and related system for dynamically repairing application
CN109086071A (zh) * 2018-08-22 2018-12-25 平安普惠企业管理有限公司 一种管理软件版本信息的方法及服务器
CN109684414A (zh) * 2018-12-26 2019-04-26 百度在线网络技术（北京）有限公司 区块数据的同步方法、装置、设备及存储介质
CN110597764A (zh) * 2019-10-10 2019-12-20 深圳前海微众银行股份有限公司 一种文件管理方法及装置

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102195802B (zh) * 2010-03-18 2014-08-20 中兴通讯股份有限公司 一种终端软件下发方法、服务器和终端
CN104902022B (zh) * 2015-05-27 2019-02-26 北京集奥聚合科技有限公司 一种分布式文件获取方法和分布式文件获取系统
CN105357280B (zh) * 2015-10-19 2019-02-19 福建新大陆软件工程有限公司 一种基于hdfs的文件溯源ftp系统
CN106776720A (zh) * 2016-11-18 2017-05-31 北京奇虎科技有限公司 一种文件处理方法和装置
CN108289126A (zh) * 2018-01-28 2018-07-17 丁超 用于上传或下载文件的方法、装置及计算机存储介质
CN108270871A (zh) * 2018-01-29 2018-07-10 广东五科技股份有限公司 一种客户端的文件分块下载方法和装置
CN109460531B (zh) * 2018-11-07 2020-11-13 北京金山云网络技术有限公司 网页管理方法、装置及智能终端
CN110177154B (zh) * 2019-06-17 2021-07-02 深圳前海微众银行股份有限公司 一种文件交互处理方法、装置及系统

Patent Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060288056A1 (en) * 2005-06-17 2006-12-21 Nec Corporation File version management device, method, and program
US20150205979A1 (en) * 2012-06-19 2015-07-23 Beijing Qihoo Technology Company Limited Method and system for repairing file at user terminal
CN103475687A (zh) * 2013-05-24 2013-12-25 北京网秦天下科技有限公司 用于下载网站数据的分布式方法和系统
CN103281394A (zh) * 2013-06-07 2013-09-04 北京奇虎科技有限公司 文件获取方法、节点服务器和系统
CN103595770A (zh) * 2013-10-29 2014-02-19 北京奇虎科技有限公司 Sdk实现文件下载的方法与装置
CN103986747A (zh) * 2014-04-14 2014-08-13 曦威胜科技开发（深圳）有限公司 P2p协议中文件共享下载方法
CN104572845A (zh) * 2014-12-12 2015-04-29 百度在线网络技术（北京）有限公司 文件分发方法、装置、设备及系统
US20180321932A1 (en) * 2015-11-02 2018-11-08 Guangzhou UCWEB Computer Technology Co.,Ltd. Method, device and related system for dynamically repairing application
CN106027647A (zh) * 2016-05-20 2016-10-12 云南云电同方科技有限公司 Lxpfs集群分布式文件存储系统
CN106294585A (zh) * 2016-07-28 2017-01-04 四川新环佳科技发展有限公司 一种云计算平台下的存储方法
CN109086071A (zh) * 2018-08-22 2018-12-25 平安普惠企业管理有限公司 一种管理软件版本信息的方法及服务器
CN109684414A (zh) * 2018-12-26 2019-04-26 百度在线网络技术（北京）有限公司 区块数据的同步方法、装置、设备及存储介质
CN110597764A (zh) * 2019-10-10 2019-12-20 深圳前海微众银行股份有限公司 一种文件管理方法及装置

Also Published As

Publication number Publication date
CN110597764B (zh) 2024-05-07
CN110597764A (zh) 2019-12-20

Similar Documents

Publication Publication Date Title
WO2021068740A1 (zh) 一种文件管理方法及装置
CN107395665B (zh) 一种区块链业务受理及业务共识方法及装置
TWI695318B (zh) 用戶端上應用程式的更新方法、裝置及電子設備
CN110825420B (zh) 分布式集群的配置参数更新方法、装置、设备及存储介质
CN111858727B (zh) 一种基于模板配置的多数据源数据导出系统及方法
WO2022247316A1 (zh) 存储对象处理系统、请求处理方法、网关和存储介质
CN110493336A (zh) 一种灰度发布过程中确定目标用户端的方法和装置
CN112087530B (zh) 一种将数据上传至区块链系统的方法、装置、设备及介质
CN103294742A (zh) 用于在便携式终端中确定内容重复的装置和方法
CN112650729B (zh) 一种分布式文件系统的权限管理方法、系统以及存储介质
CN111176666B (zh) 一种bios+me镜像的刷新方法、系统、设备及可读介质
CN112631833A (zh) 一种数据归档查询方法、系统、存储介质及设备
US10152490B2 (en) Sequential replication with limited number of objects
CN115510161A (zh) 数据同步方法、装置、设备及存储介质
CN113987089A (zh) 一种系统级联方法、数据处理方法及装置
CN117149220A (zh) 资源更新方法、电子设备及系统
CN114138711A (zh) 文件迁移方法、装置、存储介质及电子设备
CN112199529A (zh) 图片处理方法、装置、电子设备及存储介质
CN107784040B (zh) 一种文件下发方法及装置
CN110888643A (zh) 页面处理方法及装置
CN114448803B (zh) 一种配置下发方法、电子设备及存储介质
CN114443713A (zh) 数据写入方法、装置、存储介质以及电子设备
CN116974734A (zh) 一种对象存储系统、对象修改方法及相关设备
CN114422577A (zh) 一种业务变更消息的处理方法及装置
CN116483426A (zh) 一种业务流程编排实现方法、装置及电子设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20873697

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 180822)

122 Ep: pct application non-entry in european phase

Ref document number: 20873697

Country of ref document: EP

Kind code of ref document: A1