WO2017084520A1 - 一种云环境下数据文件同步的方法和装置 - Google Patents

一种云环境下数据文件同步的方法和装置 Download PDF

Info

Publication number
WO2017084520A1
WO2017084520A1 PCT/CN2016/105136 CN2016105136W WO2017084520A1 WO 2017084520 A1 WO2017084520 A1 WO 2017084520A1 CN 2016105136 W CN2016105136 W CN 2016105136W WO 2017084520 A1 WO2017084520 A1 WO 2017084520A1
Authority
WO
WIPO (PCT)
Prior art keywords
update
server
data file
record
information
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/CN2016/105136
Other languages
English (en)
French (fr)
Inventor
杨林
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Group Holding Ltd
Original Assignee
Alibaba Group Holding Ltd
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 Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Publication of WO2017084520A1 publication Critical patent/WO2017084520A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06F16/1824—Distributed file systems implemented using Network-attached Storage [NAS] architecture
    • G06F16/183—Provision of network file services by network file servers, e.g. by using NFS, CIFS
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/178—Techniques for file synchronisation in file systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2358—Change logging, detection, and notification

Definitions

  • the present application relates to the field of Internet technologies, and in particular, to a method for synchronizing data files in a cloud environment and a device for synchronizing data files in a cloud environment.
  • the application server needs to synchronize the update operations of local data files in multiple instance environments. Understandably, in a large cloud environment, it is usually a distributed cluster environment composed of many servers. It is no longer possible to consider the synchronization of data files from the perspective of a single server.
  • the application server should have higher availability and stability. , performance, scalability.
  • the technical solutions for realizing data file synchronization in a cloud environment have the following disadvantages: 1.
  • the application server can only update the large data files in a full amount, but not in the incremental update. Since only one data file can be replaced to implement the update, the update efficiency of the larger data files will be linear. reduce.
  • embodiments of the present application have been made in order to provide a method for synchronizing data files in a cloud environment and a corresponding device for synchronizing data files in a cloud environment, which overcome the above problems or at least partially solve the above problems.
  • the embodiment of the present application discloses a method for synchronizing data files in a cloud environment.
  • a first server, a second server, and a third server are disposed, the first server stores a first update record, and the second server stores a second update record, where the first server is configured.
  • a data file is stored, and the latest data file is stored in the third server, and the method includes:
  • the latest data file in the third server is invoked to update the data file in the first server.
  • the step of acquiring the second update record in the second server is:
  • the first update record includes first update information corresponding to the data file
  • the second update record includes second update information corresponding to the latest data file
  • the first update record and the second Updating the record to determine whether the need to update the data file in the first server includes:
  • the first update information and the second update information are used to determine whether the data file in the first server needs to be updated.
  • the first update information and the second update information correspond to each other, and the step of updating the data file in the first server by using the latest data file in the third server includes:
  • the first update information includes a first update time corresponding to the data file
  • the second update information includes a second update time corresponding to the data file
  • the step of invoking the latest data file in the third server to update the data file in the first server comprises:
  • the second update information includes an operation type corresponding to the data file and a rename target file name
  • the method further includes:
  • the first server changes the file name of the data file to a rename target file name.
  • the second update information includes directory operation information
  • the method further includes:
  • the directory on the first server is updated by using the directory operation information.
  • the method further comprises:
  • the first server is an application server
  • the second server is an OCS open cache server
  • the third server is an OSS distributed storage server.
  • the embodiment of the present application further discloses an apparatus for synchronizing data files in a cloud environment, where a first server, a second server, and a third server are disposed in the cloud environment, and the first update record is stored in the first server. And storing, by the second server, a second update record, where the first server stores a data file, and the third server stores the latest data file, where the device includes:
  • An obtaining module configured to acquire a second update record in the second server
  • a determining module configured to determine whether the data file in the first server needs to be updated by using the first update record and the second update record;
  • an update module configured to: when the data file in the first server needs to be updated, invoke the latest data file in the third server to update the data file in the first server.
  • the obtaining module comprises:
  • a second update record obtaining submodule configured to acquire a second update record in the second server before the first server processes any request.
  • the first update record includes first update information corresponding to the data file
  • the second update record includes second update information corresponding to the latest data file
  • the determining module includes:
  • a first update determining submodule configured to determine, when the first update record is inconsistent with the second update record, that the data file in the first server needs to be updated
  • a second update determining submodule configured to determine, by using the first update information and the second update information, whether to update the first server when the first update record is consistent with the second update record Data file.
  • the first update information and the second update information correspond to each other, and the update module includes:
  • An update information determining submodule configured to find, from the first update record and the second update record, first update information and/or second update information that do not correspond to each other;
  • a data file processing sub-module configured to delete the data file corresponding to the first update information that does not correspond to each other in the first server, and/or add the second corresponding to the first server Update the data file corresponding to the information.
  • the first update information includes a first update time corresponding to the data file
  • the second update information includes a second update time corresponding to the data file
  • the second update determination sub-module includes:
  • a first update determining unit configured to determine, when the first update time is later than the second update time, that the data file in the first server needs to be updated
  • the second update determining unit is configured to determine that the data file in the first server does not need to be updated when the first update time is earlier than or equal to the second update time.
  • the determining module comprises:
  • a latest data file obtaining submodule configured to acquire, from the third server, the latest data file corresponding to the second update time
  • a data file update submodule configured to update the data file corresponding to the first update time in the first server by using the latest data file corresponding to the second update time.
  • the second update information includes an operation type corresponding to the data file and a rename target file name
  • the device further includes:
  • An operation type determining module configured to determine whether an operation type corresponding to the data file in the second update record is a rename operation; if yes, calling a file name modification module;
  • a file name modification module configured to modify, at the first server, a file name of the data file to a rename target file name.
  • the second update information includes directory operation information
  • the device further includes:
  • a directory operation information determining module configured to determine whether directory operation information exists in the second update record; Yes, the directory update module;
  • a directory update module configured to update a directory on the first server by using the directory operation information.
  • the device further comprises:
  • An update record update module for updating the first update record on the first server with the second update record.
  • a server that stores a data file and a server that stores an update record corresponding to the data file are disposed in a cloud environment, and the application server in the cloud environment may first obtain an update record on the server, and update the local device. The records are compared to determine if the local data files need to be updated and which data files need to be updated.
  • the embodiment of the present application can read and write data files in a stand-alone environment, and can synchronize data files of a single machine environment to all other servers in all clusters, thereby maintaining consistency of data files.
  • the embodiment of the present application since it is determined according to the update record specifically stored in the cloud environment whether the data file needs to be updated, multiple servers may be simultaneously updated, and since it is a distributed cloud environment, Even if the file size is large, the updates between the servers do not affect each other, which can effectively improve the update efficiency.
  • the embodiment of the present application also has a fault tolerance mechanism, and even if the local update fails, the data file update operation is not hindered again.
  • the processing efficiency can be improved for the updated form of the data file on the server.
  • FIG. 1 is a flow chart of steps of a method for synchronizing data files in a cloud environment according to the present application
  • FIG. 2 is a schematic diagram of multi-instance synchronization in a cloud environment of the present application
  • FIG. 3 is a structural block diagram of an apparatus embodiment for data file synchronization in a cloud environment according to the present application.
  • the first server, the second server, and the third server may be disposed in the cloud environment, where the first server may store a first update record, and the second server stores a second update record, A data file is stored in the first server, and the latest data file is stored in the third server.
  • the method may include the following steps:
  • Step 101 Acquire a second update record in the second server.
  • a cloud server is usually provided with a plurality of servers, which is an elastic and distributed application hosting cloud environment.
  • the first server refers to an arbitrary application server in a cloud environment
  • the second server refers to an open cache server that provides an Open Cache Service (OCS) in a cloud environment, which can be implemented.
  • OCS Open Cache Service
  • Online cache provides high-speed response service for access to hot data.
  • the third server is a distributed storage server that provides Object Storage Service (OSS) in a cloud environment, providing a massive, secure, and highly reliable cloud. Storage service.
  • OSS Object Storage Service
  • the function of synchronizing data files can be determined according to the user-defined configuration.
  • the data files in each application server in the cloud environment are synchronized in real time.
  • the behavior of reading and writing the file is completely intercepted and redefined.
  • the behavior of the PHP language parsing engine is re-customized, and the weight is added.
  • the defined cloud engine defines the request processing flow, which requires synchronization of data files in the application server in the cloud environment. Since the PHP language itself has the ability to read and write files in a stand-alone environment, the embodiment of the present application can start to synchronize the file update behavior in a stand-alone environment to all other application servers in all clusters, and maintain file data consistency.
  • the latest data file is stored in the distributed storage server, and the update record related to the latest data file in the object storage service is stored in the open cache server.
  • the data file in the application server changes, a double write operation is performed, that is, the data file changed in the application server is uploaded to the distributed storage server, and the corresponding update record of the data file is stored in the open cache server. This ensures that the data file in the distributed storage server is the latest data file, and the corresponding update record data is stored in the open cache server.
  • the related records of which data files are updated are stored in the serialized array mode.
  • the step 101 may be as follows:
  • Sub-step S11 acquiring a second update record in the second server before the first server processes any request.
  • the application server before processing the request, the application server will firstly pull the second update record in the development cache server based on the cloud engine definition request processing flow defined in the embodiment of the present application.
  • the data files used in the application server are the latest data files before processing any request.
  • the application server may be set to remind the application server whether the update record changes by time interval, or is set to remind the application server to pull when the update record in the open cache server changes.
  • the update record in the open cache server is not limited in this embodiment of the present application.
  • Step 102 Determine, by using the first update record and the second update record, whether the data file in the first server needs to be updated;
  • Step 103 When it is determined that the data file in the first server needs to be updated, the data file in the third server is invoked to update the data file in the first server.
  • the application server first pulls the second update record in the open cache server, and then compares the first update record cached locally by the temporary file mode, if It is found that the first update record is different from the second update record, indicating that the data file in the application server and the distributed storage server are inconsistent, then the application server obtains the corresponding data file from the distributed storage server for local use. Update.
  • the update operations performed on the server may include updates to the directory of data files in addition to updates to the data files.
  • the update record may be stored in a serialized manner, that is, the update record is sequentially divided into pieces of update information for recording, and each time an update is performed, an update information is generated.
  • the update information may specifically include the content of Table 1 as follows:
  • the content of the update information includes the operation type (Type), the file path (Path), the update version number (Ver), the update time (T), whether it is a directory operation (isdir), and a full name object file. Name (To) and so on.
  • the update information may also include other fields in the actual application, which is not limited by the embodiment of the present application.
  • the type of change may be determined according to a field in the update information, thereby performing a corresponding update operation according to the type of change.
  • the first update record includes first update information corresponding to the data file
  • the second update record includes second update information corresponding to the latest data file
  • Sub-step S21 when the first update record is inconsistent with the second update record, it is determined that it needs to be more Newly described data files in the first server;
  • Sub-step S22 when the first update record is consistent with the second update record, the first update information and the second update information are used to determine whether the data file in the first server needs to be updated.
  • the first update information and the second update information correspond to each other, and the step 103 may include the following sub-steps:
  • Sub-step S31 searching, from the first update record and the second update record, first update information and/or second update information that do not correspond to each other;
  • Sub-step S32 deleting the data files corresponding to the first update information that are not corresponding to each other in the first server, and/or adding the second update information that does not correspond to each other in the first server. data files.
  • each data file may correspond to an update information, and is stored in the update record in a serialized manner.
  • the specific content in the update information may be referred to Table 1.
  • the first update information in the first update record and the second update information in the second update record correspond to each other, and may collectively refer to the same data file.
  • the data file in the application server and the open cache server are The data file maintains a one-to-one correspondence, and then it is necessary to further determine whether the data file needs to be updated according to the specific content in the update information.
  • the first update information in the first update record in the local application server cannot be in one-to-one correspondence with the second update information in the second update record in the open cache server
  • the data file in the application server and the open cache server are indicated.
  • the data files in the data are not one-to-one correspondence. It is possible to delete and/or add data files in the open cache server. Then, the corresponding data files need to be determined according to the update information that does not correspond to each other, so as to be added in the local application server. And / or delete the corresponding data file.
  • the first update information that exists in the first update record in the local application server does not exist in the open cache server, it indicates that the data file corresponding to the first update information has been deleted by the other application server, Delete the data file in the local application server.
  • the second update information that exists in the second update record in the open cache server does not exist in the local application server, it indicates that the data file corresponding to the second update information has been newly added to the other application server, and may be locally Add the data file to the application server.
  • the first update information may include a first update time corresponding to the data file
  • the second update information may include a second update time corresponding to the data file
  • Sub-step S22-1 when the first update time is later than the second update time, determining that the data file in the first server needs to be updated;
  • Sub-step S22-2 when the first update time is earlier than or equal to the second update time, determining that the data file in the first server does not need to be updated.
  • the step 103 may include the following sub-steps:
  • Sub-step S41 acquiring the latest data file corresponding to the second update time from the third server
  • Sub-step S42 the data file corresponding to the first update time in the first server is updated by using the latest data file corresponding to the second update time.
  • the items in the update information may be further compared one by one to determine whether the content of the data file changes.
  • the fields in the update information may include an update time (T) and a path (Path).
  • T update time
  • Path path
  • it may be determined by the update time whether the data file has changed, and if it is determined that the occurrence has occurred. If the change is made, the corresponding data file can be obtained through the path of the file for updating.
  • Update if it is found that the first update time on the first update record is later than the second update time on the second update record, indicating that the data file on the other application server is changed, it may be determined that the data file of the local application server needs to be performed. Update, if it is found that the first update time on the first update record is earlier than or equal to the second update time on the second update record, it may be determined that the data file on the local application server is up to date, then it may be determined that Update the data files of the local application server.
  • the data file is obtained from the distributed storage server for updating the data file in the local application server.
  • the data file should be uploaded to the distributed storage server, and the data file related update is updated.
  • the records are uploaded to the open cache server, so other application servers can be updated based on the uploaded new data files.
  • the first update record is compared with the second update record, and the data file is determined to be updated according to the comparison result.
  • the comparison of the update record may include Ver. Value (update version number) comparison.
  • Ver. Value update version number
  • the second update information may include an operation type corresponding to the data file and a rename target file name
  • the method may further include the following steps:
  • the first server changes the file name of the data file to a rename target file name.
  • the fields in the update information may include an operation type (Type), a file, a directory, a rename operation (rename), and a full-name target file name (To), which may be adopted in the embodiment of the present application.
  • the operation type determines whether the file name of the data file has changed. For example, if the operation type is file, directory, or rename operation, it can be determined that the file name or directory name of the file or directory needs to be updated, and it is determined that the update is required. At the time, the full name of the target file name is added to update the file name.
  • the second update information may include directory operation information
  • the method may further include the following steps:
  • the directory on the first server is updated by using the directory operation information.
  • the fields in the update information may further include whether it is a directory operation (isdir). If it is determined that a directory operation is included, such as creating a directory, the directory is created according to specific information in the directory operation.
  • the method may further include the following steps:
  • the local first update record will be updated, so that it is not necessary to update the updated content again next time.
  • step c) After the update operation on the application server is completed in step c), which data files are updated and stored in the serialized array mode.
  • the local application server storage it needs to be stored in the distributed cache of the OCS.
  • the CAS algorithm is used to avoid the write conflict when writing OCS, and the final consistency is guaranteed.
  • the main implementation principle based on CAS is: based on the OCS CAS feature, the application server reads a CAS key before performing an update record in the open cache server, and carries the CAS key when updating, if the update fails. If it is a CAS conflict, it is considered that the write conflict needs to re-read the CAS key, and read the latest update record on the OCS, and then update the latest update record to the local application server, and then submit the update record processed by the current process to OCS until the submission is successful. Finally, the submitted update records are also cached in the local application server for the next comparison and update. In this way, when multiple application servers in the cluster simultaneously write the same data file, the problem of data coverage loss can be avoided.
  • the application server Before processing any request, the application server will update the record based on the defined PHP engine running process (from the data submitted by CAS get on OCS), and compare the local cache (temporary file mode) update. Record, if a new update is found, the application will update the corresponding (add, delete, change) data files from the OSS. The latest update record will also be cached locally for comparison with the next update record on OCS.
  • FIG. 2 a schematic diagram of multi-instance synchronization in a cloud environment of the present application, the process of synchronizing data files in a cloud environment may be specifically:
  • the application server checks the local update record and the update record on the OCS before processing the request (Request) to determine the changed data file to download the changed data file from the OSS to the local application server. Update.
  • processing the local data file may specifically include:
  • Delete file Delete the related record of the file on the OCS.
  • Rename directory Modify related records in OCS. For example, the file and subdirectory records under the directory are currently modified.
  • Delete directory delete related records in OCS. For example, the file and subdirectory records under the directory are currently deleted.
  • Reading and writing multimedia files gif/mp3/doc/zip, etc. When the file is added, it is only written to the OSS. The original file is not retained locally; when the file does not exist, the OSS is read, and the original file is not retained locally.
  • a server that stores a data file and a server that stores an update record corresponding to the data file are disposed in a cloud environment, and the application server in the cloud environment may first obtain an update record on the server, and update the local device. The records are compared to determine if the local data files need to be updated and which data files need to be updated.
  • the embodiment of the present application can read and write data files in a stand-alone environment, and can synchronize data files of a single machine environment to all other servers in all clusters, thereby maintaining consistency of data files.
  • the embodiment of the present application since it is determined according to the update record specifically stored in the cloud environment whether the data file needs to be updated, multiple servers may be simultaneously updated, and since it is a distributed cloud environment, Even if the file size is large, the updates between the servers do not affect each other, which can effectively improve the update efficiency.
  • the embodiment of the present application also has a fault tolerance mechanism, and even if the local update fails, the data file update operation is not hindered again.
  • the processing efficiency can be improved for the updated form of the data file on the server.
  • the first server, the second server, and the third server may be disposed in the cloud environment, where the first server may store a first update record, and the second server stores a second update record, A data file is stored in the first server, a latest data file is stored in the third server, and a latest data file is stored in the third server, and the specific may include the following modules:
  • the first server is an application server
  • the second server is an OCS open cache server
  • the third server is an OSS distributed storage server.
  • the obtaining module 201 is configured to acquire a second update record in the second server.
  • the obtaining module 201 may include the following modules:
  • a second update record obtaining submodule configured to acquire a second update record in the second server before the first server processes any request.
  • the determining module 202 is configured to determine whether the data file in the first server needs to be updated by using the first update record and the second update record;
  • the updating module 203 is configured to, when it is determined that the data file in the first server needs to be updated, invoke the latest data file in the third server to update the data file in the first server.
  • the first update record includes first update information corresponding to the data file
  • the second update record includes second update information corresponding to the latest data file
  • the determining module 202 can include the following modules:
  • a first update determining submodule configured to, in the inconsistency between the first update record and the second update record, determining that the data file in the first server needs to be updated
  • a second update determining submodule configured to determine, by using the first update information and the second update information, whether to update the first server when the first update record is consistent with the second update record Data file.
  • the first update information and the second update information correspond to each other, and the update module 203 may include the following modules:
  • An update information determining submodule configured to find, from the first update record and the second update record, first update information and/or second update information that do not correspond to each other;
  • a data file processing sub-module configured to delete the data file corresponding to the first update information that does not correspond to each other in the first server, and/or add the second corresponding to the first server Update the data file corresponding to the information.
  • the first update information includes a first update time corresponding to the data file.
  • the second update information includes a second update time corresponding to the data file, and the second update determination submodule may include the following modules:
  • a first update determining unit configured to determine, when the first update time is later than the second update time, that the data file in the first server needs to be updated
  • the second update determining unit is configured to determine that the data file in the first server does not need to be updated when the first update time is earlier than or equal to the second update time.
  • the update module 203 may include the following modules:
  • a latest data file obtaining submodule configured to acquire, from the third server, the latest data file corresponding to the second update time
  • a data file update submodule configured to update the data file corresponding to the first update time in the first server by using the latest data file corresponding to the second update time.
  • the second update information includes an operation type corresponding to the data file and a rename target file name
  • the device may further include the following modules:
  • An operation type determining module configured to determine whether an operation type corresponding to the data file in the second update record is a rename operation; if yes, calling a file name modification module;
  • a file name modification module configured to modify, at the first server, a file name of the data file to a rename target file name.
  • the second update information includes directory operation information
  • the device further includes:
  • a directory operation information determining module configured to determine whether directory operation information exists in the second update record; if yes, a directory update module;
  • a directory update module configured to update a directory on the first server by using the directory operation information.
  • the apparatus may further include the following modules:
  • An update record update module for updating the first update record on the first server with the second update record.
  • the second server is an OCS open cache server
  • the third server is an OSS distributed storage server.
  • the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.
  • embodiments of the embodiments of the present application can be provided as a method, apparatus, or computer program product. Therefore, the embodiments of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Moreover, embodiments of the present application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • the computer device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • the memory may include non-persistent memory, random access memory (RAM), and/or non-volatile memory in a computer readable medium, such as read only memory (ROM) or flash memory.
  • RAM random access memory
  • ROM read only memory
  • Memory is an example of a computer readable medium.
  • Computer readable media includes both permanent and non-persistent, removable and non-removable media.
  • Information storage can be implemented by any method or technology. The information can be computer readable instructions, data structures, modules of programs, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory. (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disk read only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, Magnetic tape cartridges, magnetic tape storage or other magnetic storage devices or any other non-transportable media can be used to store information that can be accessed by a computing device.
  • computer readable media does not include non-persistent computer readable media, such as modulated data signals and carrier waves.
  • Embodiments of the present application are described with reference to flowcharts and/or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the present application. It will be understood that each flow and/or block of the flowchart illustrations and/or FIG.
  • These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processor or other programmable data processing terminal device to produce a machine such that instructions are executed by a processor of a computer or other programmable data processing terminal device
  • Means are provided for implementing the functions specified in one or more of the flow or in one or more blocks of the flow chart.
  • the computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device.
  • the instruction device implements the functions specified in one or more blocks of the flowchart or in a flow or block of the flowchart.

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

一种云环境下数据文件同步的方法和装置，在所述云环境下设置有第一服务器，第二服务器和第三服务器，所述第一服务器中存储有第一更新记录，所述第二服务器中存储有第二更新记录，所述第一服务器中存储有数据文件，所述第三服务器中存储有最新数据文件，所述方法包括：获取所述第二服务器中的第二更新记录（101）；采用所述第一更新记录和所述第二更新记录，确定是否需要更新所述第一服务器中的数据文件（102）；当确定为需要更新所述第一服务器中的数据文件时，调用所述第三服务器中的最新数据文件更新所述第一服务器中的数据文件（103）。本方法可以在单机环境读写数据文件，保持数据文件的一致性。

Description

一种云环境下数据文件同步的方法和装置
本申请要求2015年11月18日递交的申请号为201510801737.8、发明名称为“一种云环境下数据文件同步的方法和装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及互联网技术领域，特别是涉及一种云环境下数据文件同步的方法和一种云环境下数据文件同步的装置。
背景技术
现在的互联网随着用户访问量的不断增加，单一的服务器无法承担巨大的访问量，故需要实现各个服务器之间数据文件的同步，以分散访问量。然而，在互联网中传输的数据文件，有些大小可达十几甚至上百兆，很可能由于延时或者网络故障等其他情况，导致在互联网中各个网元的数据文件并非都是最新的。针对分布式、集群的PHP(Hypertext Preprocessor，超文本预处理语言)运行环境而言，应用服务器对于本地数据文件的更新操作，需要在多个实例环境中同步。可以理解，在大型云环境下，通常是使用由许多服务器组成的分布式集群环境，已经不能仅从单台服务器的角度去考虑数据文件的同步问题，应用服务器应有更高的可用性、稳定性、性能、扩展性。
目前，在云环境下实现数据文件同步的技术方案的缺点是：1、并发写冲突的问题。当集群内多个应用服务器同时写同一个数据文件时，可能产生数据覆盖丢失的问题。2、写性能相对不高的问题。应用服务器对于较大的数据文件的更新，只能进行全量更新，而不能进行增量更新，由于只能将一个数据文件全部替换来实现更新，那么对于较大的数据文件的更新效率会呈线性降低。
发明内容
鉴于上述问题，提出了本申请实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种云环境下数据文件同步的方法和相应的一种云环境下数据文件同步的装置。
为了解决上述问题，本申请实施例公开了一种云环境下数据文件同步的方法，在所 述云环境下设置有第一服务器，第二服务器和第三服务器，所述第一服务器中存储有第一更新记录，所述第二服务器中存储有第二更新记录，所述第一服务器中存储有数据文件，所述第三服务器中存储有最新数据文件，所述方法包括：
获取所述第二服务器中的第二更新记录；
采用所述第一更新记录和所述第二更新记录，确定是否需要更新所述第一服务器中的数据文件；
当确定为需要更新所述第一服务器中的数据文件时，调用所述第三服务器中的最新数据文件更新所述第一服务器中的数据文件。
优选地，所述获取第二服务器中的第二更新记录的步骤为：
在所述第一服务器处理任何请求之前，获取所述第二服务器中的第二更新记录。
优选地，所述第一更新记录中包括数据文件对应的第一更新信息，所述第二更新记录中包括最新数据文件对应的第二更新信息，所述采用第一更新记录和所述第二更新记录，确定是否需要更新所述第一服务器中的数据文件的步骤包括：
当所述第一更新记录与所述第二更新记录不一致时，确定为需要更新所述第一服务器中的数据文件；
当所述第一更新记录与所述第二更新记录一致时，采用所述第一更新信息和所述第二更新信息确定是否需要更新所述第一服务器中的数据文件。
优选地，所述第一更新信息与所述第二更新信息互相对应，所述采用第三服务器中的最新数据文件更新所述第一服务器中的数据文件的步骤包括：
从所述第一更新记录和所述第二更新记录中，查找出没有互相对应的第一更新信息和/或第二更新信息；
删除所述第一服务器中所述没有互相对应的第一更新信息对应的数据文件，和/或，在所述第一服务器中增加所述没有互相对应的第二更新信息对应的数据文件。
优选地，所述第一更新信息包括数据文件对应的第一更新时间，所述第二更新信息包括数据文件对应的第二更新时间，所述采用第一更新信息和所述第二更新信息确定是否需要更新所述第一服务器中的数据文件的步骤包括：
当所述第一更新时间晚于所述第二更新时间时，确定为需要更新所述第一服务器中的数据文件；
当所述第一更新时间早于或等于所述第二更新时间时，确定为无需更新所述第一服务器中的数据文件。
优选地，所述调用第三服务器中的最新数据文件更新所述第一服务器中的数据文件的步骤包括：
从所述第三服务器中获取所述第二更新时间对应的最新数据文件；
采用所述第二更新时间对应的最新数据文件，更新所述第一服务器中第一更新时间对应的数据文件。
优选地，所述第二更新信息包括数据文件对应的操作类型和重命名目标文件名，所述方法还包括：
确定所述第二更新记录中数据文件对应的操作类型是否为重命名操作；
若是，则在所述第一服务器将所述数据文件的文件名修改为重命名目标文件名。
优选地，所述第二更新信息包括目录操作信息，所述方法还包括：
确定所述第二更新记录中是否存在目录操作信息；
若是，则采用所述目录操作信息更新所述第一服务器上的目录。
优选地，所述的方法还包括：
采用所述第二更新记录更新所述第一服务器上的第一更新记录。
优选地，所述第一服务器为应用服务器，所述第二服务器为OCS开放缓存服务器，所述第三服务器为OSS分布存储服务器。
本申请实施例还公开了一种云环境下数据文件同步的装置，在所述云环境下设置有第一服务器，第二服务器和第三服务器，所述第一服务器中存储有第一更新记录，所述第二服务器中存储有第二更新记录，所述第一服务器中存储有数据文件，所述第三服务器中存储有最新数据文件，所述装置包括：
获取模块，用于获取所述第二服务器中的第二更新记录；
确定模块，用于采用所述第一更新记录和所述第二更新记录，确定是否需要更新所述第一服务器中的数据文件；
更新模块，用于当确定为需要更新所述第一服务器中的数据文件时，调用所述第三服务器中的最新数据文件更新所述第一服务器中的数据文件。
优选地，所述获取模块包括：
第二更新记录获取子模块，用于在所述第一服务器处理任何请求之前，获取所述第二服务器中的第二更新记录。
优选地，所述第一更新记录中包括数据文件对应的第一更新信息，所述第二更新记录中包括最新数据文件对应的第二更新信息，所述确定模块包括：
第一更新确定子模块，用于在所述第一更新记录与所述第二更新记录不一致时，确定为需要更新所述第一服务器中的数据文件；
第二更新确定子模块，用于在所述第一更新记录与所述第二更新记录一致时，采用所述第一更新信息和所述第二更新信息确定是否需要更新所述第一服务器中的数据文件。
优选地，所述第一更新信息与所述第二更新信息互相对应，所述更新模块包括：
更新信息确定子模块，用于从所述第一更新记录和所述第二更新记录中，查找出没有互相对应的第一更新信息和/或第二更新信息；
数据文件处理子模块，用于删除所述第一服务器中所述没有互相对应的第一更新信息对应的数据文件，和/或，在所述第一服务器中增加所述没有互相对应的第二更新信息对应的数据文件。
优选地，所述第一更新信息包括数据文件对应的第一更新时间，所述第二更新信息包括数据文件对应的第二更新时间，所述第二更新确定子模块包括：
第一更新确定单元，用于在所述第一更新时间晚于所述第二更新时间时，确定为需要更新所述第一服务器中的数据文件；
第二更新确定单元，用于在所述第一更新时间早于或等于所述第二更新时间时，确定为无需更新所述第一服务器中的数据文件。
优选地，所述确定模块包括：
最新数据文件获取子模块，用于从所述第三服务器中获取所述第二更新时间对应的最新数据文件；
数据文件更新子模块，用于采用所述第二更新时间对应的最新数据文件，更新所述第一服务器中第一更新时间对应的数据文件。
优选地，所述第二更新信息包括数据文件对应的操作类型和重命名目标文件名，所述装置还包括：
操作类型确定模块，用于确定所述第二更新记录中数据文件对应的操作类型是否为重命名操作；若是，则调用文件名修改模块；
文件名修改模块，用于在所述第一服务器将所述数据文件的文件名修改为重命名目标文件名。
优选地，所述第二更新信息包括目录操作信息，所述装置还包括：
目录操作信息确定模块，用于确定所述第二更新记录中是否存在目录操作信息；若 是，则目录更新模块；
目录更新模块，用于采用所述目录操作信息更新所述第一服务器上的目录。
优选地，所述的装置还包括：
更新记录更新模块，用于采用所述第二更新记录更新所述第一服务器上的第一更新记录。
本申请实施例包括以下优点：
本申请实施例中，云环境下设置有存储数据文件的服务器，以及存储有数据文件对应的更新记录的服务器，在云环境下的应用服务器可以首先通过获取服务器上的更新记录，与本地的更新记录进行比对，以判断是否需要更新本地的数据文件以及需要更新哪些数据文件。本申请实施例可以在单机环境读写数据文件，可以将单机环境的数据文件同步到所有集群中所有其它的服务器上，从而保持数据文件的一致性。
需要说明的是，在本申请实施例中，由于是根据云环境下专门存储的更新记录确定是否需要进行数据文件的更新，因此可以多个服务器同时进行更新，且由于是分布式的云环境，即使文件较大，各个服务器之间的更新也互不影响，可以有效提高更新效率。另外，本申请实施例还具有容错机制，即使本地更新失败，也不妨碍再次进行数据文件的更新操作。在本申请实施例中，针对服务器上数据文件的更新形式，例如更改数据文件中内容，删除数据文件，增加数据文件这些更新形式，分别设置相应更新方式，可以提高处理效率。
附图说明
图1是本申请的一种云环境下数据文件同步的方法实施例的步骤流程图；
图2是本申请的一种云环境下多实例同步的示意图；
图3是本申请的一种云环境下数据文件同步的装置实施例的结构框图。
具体实施方式
为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。
参照图1，示出了本申请的一种云环境下数据文件同步的方法实施例的步骤流程图， 在所述云环境下可以设置有第一服务器，第二服务器和第三服务器，所述第一服务器中可以存储有第一更新记录，所述第二服务器中存储有第二更新记录，所述第一服务器中存储有数据文件，所述第三服务器中存储有最新数据文件，所述方法具体可以包括如下步骤：
步骤101，获取所述第二服务器中的第二更新记录；
在具体实现中，在云环境下通常设置有许多个服务器，是一个能够实现弹性、分布式的应用托管云环境。
在本申请的一种优选示例中，第一服务器是指云环境下任意的应用服务器，第二服务器是指云环境下提供开放缓存服务(Open Cache Service，简称OCS)的开放缓存服务器，能够实现在线缓存，为热点数据的访问提供高速响应服务，第三服务器则是指云环境下提供对象存储服务(Object Storage Service，简称OSS)的分布存储服务器，能够对外提供海量、安全和高可靠的云存储服务。开放缓存服务器与分布存储服务器搭配能大幅提高应用的响应速度，极大缓解后端存储的压力。
在本申请的具体应用中，可以根据用户自定义配置，决定是否启用数据文件同步的功能，当启用数据文件同步的功能时，将实时同步在云环境下各个应用服务器中的数据文件。
以PHP运行环境为例，基于PHP streamWrapper(PHP语言中对特定流操作的封装接口)全面拦截和重定义文件的读写操作行为，在本申请实施例中重新定制PHP语言解析引擎行为，加入重定义的云引擎定义请求处理流程，要求同步在云环境下应用服务器中的数据文件。由于PHP语言本身具备在单机环境读写文件的能力，本申请实施例可着手于在单机环境的文件更新行为同步到所有集群中所有其它的应用服务器上，保持文件数据的一致性。
在本申请实施例中，在分布存储服务器中存储有最新数据文件，在开放缓存服务器中则存储有针对对象存储服务中最新数据文件相关的更新记录。当应用服务器中的数据文件发生变更时，将进行双写操作，即同时会将在应用服务器中发生变更的数据文件上传至分布存储服务器，并且在开放缓存服务器中存储该数据文件相应的更新记录，这样就保证了在分布存储服务器中的数据文件是最新的数据文件，并且在开放缓存服务器中存储了相应的更新记录数据。
当应用服务器在本地完成针对数据文件相关更新操作后，将哪些数据文件被更新的相关记录，以序列化的数组模式进行存储。
在本申请的一种优选实施例中，所述步骤101可以为如下子步骤：
子步骤S11，在所述第一服务器处理任何请求之前，获取所述第二服务器中的第二更新记录。
在本申请实施例中，应用服务器在处理任何一次的请求之前，将会基于本申请实施例中已定义的云引擎定义请求处理流程，先去拉取开发缓存服务器中的第二更新记录，这样在处理任何一次的请求之前，应用服务器中所使用的数据文件都是最新的数据文件。
当然，在实施本申请实施例时，也可以设定为按时间间隔向应用服务器提醒更新记录是否发生变化，或者设置为在开放缓存服务器中的更新记录发生变化时，就提醒应用服务器去拉取开放缓存服务器中的更新记录，本申请实施例对此不加以限制。
步骤102，采用所述第一更新记录和所述第二更新记录，确定是否需要更新所述第一服务器中的数据文件；
步骤103，当确定为需要更新所述第一服务器中的数据文件时，调用所述第三服务器中的数据文件更新所述第一服务器中的数据文件。
在本申请实施例中，基于已定义的云引擎定义请求处理流程，应用服务器会先去拉取开放缓存服务器中的第二更新记录，然后对比本地以临时文件方式缓存的第一更新记录，如果发现有第一更新记录与第二更新记录有所不同，说明在应用服务器与分布存储服务器中的数据文件不一致，那么此时应用服务器就会从分布存储服务器上获取相应的数据文件用于本地的更新。
在本申请实施例中，可以根据更新记录中的字段判断需要更新哪些数据文件，以及如何进行数据文件的更新。此外，在服务器上进行的更新操作除了包括针对数据文件的更新之外，还可以包括针对数据文件的目录的更新。
在具体实现中，更新记录可以以序列化的方式进行存储，即将更新记录按序分为一条条的更新信息进行记录，可以每更新一次，就生成一条更新信息。
在本申请的一种具体示例中，更新信息具体可以包括如下表1的内容：
表1
Figure PCTCN2016105136-appb-000001
Figure PCTCN2016105136-appb-000002
在本示例中，更新信息的内容包括有操作类型(Type)，文件所在路径(Path)，更新版本号(Ver)，更新时间(T)，是否是目录操作(isdir)，重全名目标文件名(To)等等。当然，在实际应用中更新信息也可以包括其他字段，本申请实施例对此不加以限制。
当确定为需要进行更新时，可以根据更新记录中的更新信息，来确定进行如何的更新操作。在本申请的一种示例中，可以根据更新信息中的字段确定变更类型，从而根据变更类型去进行相应的更新操作。
具体来说，变更类型以及变更类型的更新说明，可以参照表2所示的一种更新情况说明表：
表2
Figure PCTCN2016105136-appb-000003
在本申请的一种优选实施例中，所述第一更新记录中包括数据文件对应的第一更新信息，所述第二更新记录中包括最新数据文件对应的第二更新信息，所述步骤102可以包括如下子步骤：
子步骤S21，当所述第一更新记录中与所述第二更新记录不一致时，确定为需要更 新所述第一服务器中的数据文件；
子步骤S22，当所述第一更新记录与所述第二更新记录一致时，采用所述第一更新信息和所述第二更新信息确定是否需要更新所述第一服务器中的数据文件。
在本申请的一种优选实施例中，所述第一更新信息与所述第二更新信息互相对应，所述步骤103可以包括如下子步骤：
子步骤S31，从所述第一更新记录和所述第二更新记录中，查找出没有互相对应的第一更新信息和/或第二更新信息；
；
子步骤S32，删除所述第一服务器中所述没有互相对应的第一更新信息对应的数据文件，和/或，在所述第一服务器中增加所述没有互相对应的第二更新信息对应的数据文件。
在具体实现中，每个数据文件都可以对应了一条更新信息，以序列化方式保存在更新记录中，更新信息中的具体内容可参考表1所示。另外，第一更新记录中的第一更新信息与第二更新记录中的第二更新信息是互相对应的，可共同指代同一个数据文件。
如果本地应用服务器中第一更新记录中的第一更新信息，能够与开放缓存服务器中第二更新记录的第二更新信息一一对应，则说明在应用服务器中的数据文件与开放缓存服务器中的数据文件保持了一一对应的关系，则此时需要根据更新信息中的具体内容来进一步确定是否需要更新数据文件。反之，如果本地应用服务器中第一更新记录中的第一更新信息，不能够与开放缓存服务器中第二更新记录的第二更新信息一一对应，则说明应用服务器中的数据文件与开放缓存服务器中的数据文件不是一一对应的关系，有可能在开放缓存服务器中删除和/或增加了数据文件，那么就需要根据没有互相对应的更新信息确定对应的数据文件，以在本地应用服务器中增加和/或删除相应的数据文件。
具体地，如果发现本地应用服务器中第一更新记录中存在的第一更新信息，在开放缓存服务器中不存在，则说明在其他应用服务器已经删除了该第一更新信息对应的数据文件，则可以在本地应用服务器中删除该数据文件。如果发现开放缓存服务器中第二更新记录中存在的第二更新信息，在本地应用服务器中不存在，则说明在其他应用服务器已经新增加了该第二更新信息对应的数据文件，则可以在本地应用服务器中增加该数据文件。
在本申请的一种优选实施例中，所述第一更新信息可以包括数据文件对应的第一更新时间，所述第二更新信息可以包括数据文件对应的第二更新时间，所述子步骤S22可 以包括如下子步骤：
子步骤S22-1，当所述第一更新时间晚于所述第二更新时间时，确定为需要更新所述第一服务器中的数据文件；
子步骤S22-2，当所述第一更新时间早于或等于所述第二更新时间时，确定为无需更新所述第一服务器中的数据文件。
在本申请的一种优选实施例中，所述步骤103可以包括如下子步骤：
子步骤S41，从所述第三服务器中获取所述第二更新时间对应的最新数据文件；
子步骤S42，采用所述第二更新时间对应的最新数据文件，更新所述第一服务器中第一更新时间对应的数据文件。
在本申请实施例中，当第一更新记录与第二更新记录一致时，可以进一步将更新信息中的各项内容一一进行比对，以确定数据文件的内容是否发生变化。
参照表1和表2可知，更新信息中的字段可以包括更新时间(T)和文件所在路径(Path)，在本申请实施例中可以通过更新时间判断数据文件是否发生了变更，若确定发生了变更，则可以通过文件所在路径获取相应的数据文件进行更新。
如果发现在第一更新记录上的第一更新时间晚于第二更新记录上的第二更新时间，则说明其他应用服务器上的数据文件发生变更，那么可以确定需要对于本地应用服务器的数据文件进行更新，如果发现在第一更新记录上的第一更新时间早于或者等于第二更新记录上的第二更新时间，则可以确定本地应用服务器上的数据文件是最新的，那么此时可以确定无需对于本地应用服务器的数据文件进行更新。
当确定需要进行本地应用服务器中数据文件的更新时，则从分布存储服务器获取到该数据文件，用于本地应用服务器中数据文件的更新。
需要说明的是，如果第一更新时间早于第二更新时间，说明该本地应用服务器中的数据文件发生过变更，那么应当将该数据文件上传至分布存储服务器，以及将该数据文件相关的更新记录上传至开放缓存服务器，那么其他应用服务器就可以根据上传的新的数据文件进行更新。
在本申请实施例中，是讲第一更新记录与第二更新记录进行对比，根据比对结果来确定数据文件是否发生更新，在本申请的一种示例中，更新记录的对比可以包含有Ver值(更新版本号)对比。在本申请实施例中，如果一个数据文件可以为其设置Ver值，当该数据文件更新后，会将当前的Ver值加1，这样就能够根据Ver值获知该数据文件的更改次数，以及用于确定是否需要更新该数据文件。
在本申请的一种优选实施例中，所述第二更新信息可以包括数据文件对应的操作类型和重命名目标文件名，所述方法还可以包括如下步骤：
确定所述第二更新记录中数据文件对应的操作类型是否为重命名操作；
若是，则在所述第一服务器将所述数据文件的文件名修改为重命名目标文件名。
参照表1和表2可知，更新信息中的字段可以包括操作类型(Type)、文件、目录、重命名操作(rename)和重全名目标文件名(To)，在本申请实施例中可以通过操作类型判断数据文件的文件名是否发生了变更，例如，如果操作类型是文件、目录、重命名操作，则可以确定是需要对于文件或目录的文件名或者目录名进行更新，当确定需要进行更新时，则重全名目标文件名来对于文件名进行更新。
在本申请的一种优选实施例中，所述第二更新信息可以包括目录操作信息，所述方法还可以包括如下步骤：
确定所述第二更新记录中是否存在目录操作信息；
若是，则采用所述目录操作信息更新所述第一服务器上的目录。
参照表1和表2可知，更新信息中的字段还可以包括是否是目录操作(isdir)，如果确定包括有目录操作，比如创建目录，则会根据目录操作中的具体信息进行目录的创建。
在本申请的一种优选实施例中，所述方法还可以包括如下步骤：
采用所述第二更新记录更新所述第一服务器上的第一更新记录。
在本申请实施例中，当在应用服务器完成对于数据文件的更新之后，将更新本地的第一更新记录，这样下次就无需再次更新已更新的内容。
为了使本领域技术人员更好地理解本申请实施例，以下采用一个具体的示例来说明在大型云计算平台环境下实现数据文件同步的技术方案：
a)首先根据用户自定义配置，决定是否在应用服务器中启用文件同步功能，在启用同步功能的情况下，应用服务器将实现在云环境下数据文件的同步。
b)基于PHP streamWrapper(是指PHP语言中对特定流操作的封装接口)全面拦截和重定义文件的读写操作行为，重新定制PHP语言解析引擎行为，加入云引擎定义请求处理流程。
c)对于数据文件的更新，基于大型云环境下的OSS的分布式存储，进行双写，即在本地应用服务器写数据文件的同时，会将数据文件更新到OSS上存储。对于OSS写， 会在基于streamWrapper::stream_open打开OSS连接，创建套接字，此后在应用服务器写完本地的数据文件后，同时写入的数据文件会通过streamWrapper::stream_open再写一次到远程OSS上。在streamWrapper::stream_flush中定义刷新写缓冲。最后在streamWrapper::stream_close关闭OSS连接。这样就可以保证在OSS上的数据文件是最新的数据文件。
d)在步骤c)完成在应用服务器上的更新操作后，将哪些数据文件被更新，以序列化的数组模式进行存储。除了在本地应用服务器存储之外，还需要存放于OCS的分布式缓存上，同时写OCS时使用CAS算法避免写冲突，保证最终一致性。
基于CAS的主要实现原理是：基于OCS CAS特征，应用服务器每次执行获取开放缓存服务器中的更新记录前读取一个无锁密钥(CAS key)，在更新时带上CAS key，若更新失败且是CAS冲突，则认为写冲突，需要重新读取CAS key，以及读取OCS上最新的更新记录，并且再更新一次最新更新记录到本地的应用服务器，再将当前进程处理的更新记录提交到OCS，直到提交成功为止。最后再把提交的更新记录在本地的应用服务器中也缓存一份，用作下一次比较和更新。这样，当集群内多个应用服务器同时写同一个数据文件时，可以避免产生数据覆盖丢失的问题。
e)应用服务器在处理任何一次请求前，都会基于已定义的PHP引擎运行流程，先去拉取(从OCS上CAS get此前提交的数据)更新记录，同时对比本地缓存(临时文件方式)的更新记录，如果发现有新的更新，那么应用程序就会从OSS上更新相应的(增、删、改)数据文件。同时会将最新的更新记录缓存到本地，以便于下一次和OCS上的更新记录做对比。
参照图2所示的本申请的一种云环境下多实例同步的示意图，实现云环境下数据文件同步的过程具体可以为：
1、创建用户独立的OCS空间，用于存放更新记录。
2、应用服务器在处理请求(Request)前，检测(check)本地的更新记录以及OCS上的更新记录，从而确定有变化的数据文件，以从OSS上下载有变化的数据文件到本地应用服务器进行更新。
3、处理request中，处理本地的数据文件，如果本地的数据文件发生变化，则发送相关更新数据到OCS和OSS。具体来说，处理本地的数据文件具体可以包括：
1)新增文件：上传新增文件的更新记录到OCS。
2)修改文件：上传修改文件的更新记录到OCS。
3)删除文件：删除OCS上该文件的相关记录。
4)重命名目录：修改OCS中的相关记录。如：当前要修改目录下的文件和子目录记录。
5)删除目录：删除OCS中的相关记录。如：当前要删除目录下的文件和子目录记录。
6)读写多媒体文件gif/mp3/doc/zip等处理：文件增加时只向OSS里写，本地不保留原文件；文件不存在时读取OSS，本地不保留原文件。
4、处理request中，判断删除OSS上的数据文件，或者，将修改后的数据文件提交到OSS上。
5、处理request后，将最新的更新记录保存到本地的应用服务器。
本申请实施例中，云环境下设置有存储数据文件的服务器，以及存储有数据文件对应的更新记录的服务器，在云环境下的应用服务器可以首先通过获取服务器上的更新记录，与本地的更新记录进行比对，以判断是否需要更新本地的数据文件以及需要更新哪些数据文件。本申请实施例可以在单机环境读写数据文件，可以将单机环境的数据文件同步到所有集群中所有其它的服务器上，从而保持数据文件的一致性。
需要说明的是，在本申请实施例中，由于是根据云环境下专门存储的更新记录确定是否需要进行数据文件的更新，因此可以多个服务器同时进行更新，且由于是分布式的云环境，即使文件较大，各个服务器之间的更新也互不影响，可以有效提高更新效率。另外，本申请实施例还具有容错机制，即使本地更新失败，也不妨碍再次进行数据文件的更新操作。在本申请实施例中，针对服务器上数据文件的更新形式，例如更改数据文件中内容，删除数据文件，增加数据文件这些更新形式，分别设置相应更新方式，可以提高处理效率。
需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。
参照图3，示出了本申请的一种云环境下数据文件同步的装置实施例的结构框图， 在所述云环境下可以设置有第一服务器，第二服务器和第三服务器，所述第一服务器中可以存储有第一更新记录，所述第二服务器中存储有第二更新记录，所述第一服务器中存储有数据文件，所述第三服务器中存储有最新数据文件，所述第三服务器中存储有最新数据文件，所述具体可以包括如下模块：
在本申请的一种优选实施例中，所述第一服务器为应用服务器，所述第二服务器为OCS开放缓存服务器，所述第三服务器为OSS分布存储服务器。
获取模块201，用于获取所述第二服务器中的第二更新记录；
在本申请的一种优选实施例中，所述获取模块201可以包括如下模块：
第二更新记录获取子模块，用于在所述第一服务器处理任何请求之前，获取所述第二服务器中的第二更新记录。
确定模块202，用于采用所述第一更新记录和所述第二更新记录，确定是否需要更新所述第一服务器中的数据文件；
更新模块203，用于当确定为需要更新所述第一服务器中的数据文件时，调用所述第三服务器中的最新数据文件更新所述第一服务器中的数据文件。
在本申请的一种优选实施例中，所述第一更新记录中包括数据文件对应的第一更新信息，所述第二更新记录中包括最新数据文件对应的第二更新信息，所述确定模块202可以包括如下模块：
第一更新确定子模块，用于在所述第一更新记录与所述第二更新记录不一致，确定为需要更新所述第一服务器中的数据文件；
第二更新确定子模块，用于在所述第一更新记录与所述第二更新记录一致时，采用所述第一更新信息和所述第二更新信息确定是否需要更新所述第一服务器中的数据文件。
在本申请的一种优选实施例中，所述第一更新信息与所述第二更新信息互相对应，所述更新模块203可以包括如下模块：
更新信息确定子模块，用于从所述第一更新记录和所述第二更新记录中，查找出没有互相对应的第一更新信息和/或第二更新信息；
数据文件处理子模块，用于删除所述第一服务器中所述没有互相对应的第一更新信息对应的数据文件，和/或，在所述第一服务器中增加所述没有互相对应的第二更新信息对应的数据文件。
在本申请的一种优选实施例中，所述第一更新信息包括数据文件对应的第一更新时 间，所述第二更新信息包括数据文件对应的第二更新时间，所述第二更新确定子模块可以包括如下模块：
第一更新确定单元，用于在所述第一更新时间晚于所述第二更新时间时，确定为需要更新所述第一服务器中的数据文件；
第二更新确定单元，用于在所述第一更新时间早于或等于所述第二更新时间时，确定为无需更新所述第一服务器中的数据文件。
在本申请的一种优选实施例中，所述更新模块203可以包括如下模块：
最新数据文件获取子模块，用于从所述第三服务器中获取所述第二更新时间对应的最新数据文件；
数据文件更新子模块，用于采用所述第二更新时间对应的最新数据文件，更新所述第一服务器中第一更新时间对应的数据文件。
在本申请的一种优选实施例中，所述第二更新信息包括数据文件对应的操作类型和重命名目标文件名，所述装置还可以包括如下模块：
操作类型确定模块，用于确定所述第二更新记录中数据文件对应的操作类型是否为重命名操作；若是，则调用文件名修改模块；
文件名修改模块，用于在所述第一服务器将所述数据文件的文件名修改为重命名目标文件名。
在本申请的一种优选实施例中，所述第二更新信息包括目录操作信息，所述装置还包括：
目录操作信息确定模块，用于确定所述第二更新记录中是否存在目录操作信息；若是，则目录更新模块；
目录更新模块，用于采用所述目录操作信息更新所述第一服务器上的目录。
在本申请的一种优选实施例中，所述装置还可以包括如下模块：
更新记录更新模块，用于采用所述第二更新记录更新所述第一服务器上的第一更新记录。
在本申请的一种优选实施例中，所述第二服务器为OCS开放缓存服务器，所述第三服务器为OSS分布存储服务器。
对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
在一个典型的配置中，所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitory media)，如调制的数据信号和载波。
本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
以上对本申请所提供的一种云环境下数据文件同步的方法和一种云环境下数据文件同步的装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (19)

  1. 一种云环境下数据文件同步的方法，其特征在于，在所述云环境下设置有第一服务器，第二服务器和第三服务器，所述第一服务器中存储有第一更新记录，所述第二服务器中存储有第二更新记录，所述第一服务器中存储有数据文件，所述第三服务器中存储有最新数据文件，所述方法包括：
    获取所述第二服务器中的第二更新记录；
    采用所述第一更新记录和所述第二更新记录，确定是否需要更新所述第一服务器中的数据文件；
    当确定为需要更新所述第一服务器中的数据文件时，调用所述第三服务器中的最新数据文件更新所述第一服务器中的数据文件。
  2. 根据权利要求1所述的方法，其特征在于，所述获取第二服务器中的第二更新记录的步骤为：
    在所述第一服务器处理任何请求之前，获取所述第二服务器中的第二更新记录。
  3. 根据权利要求1所述的方法，其特征在于，所述第一更新记录中包括数据文件对应的第一更新信息，所述第二更新记录中包括最新数据文件对应的第二更新信息，所述采用第一更新记录和所述第二更新记录，确定是否需要更新所述第一服务器中的数据文件的步骤包括：
    当所述第一更新记录与所述第二更新记录不一致时，确定为需要更新所述第一服务器中的数据文件；
    当所述第一更新记录与所述第二更新记录一致时，采用所述第一更新信息和所述第二更新信息确定是否需要更新所述第一服务器中的数据文件。
  4. 根据权利要求1或3所述的方法，其特征在于，所述第一更新信息与所述第二更新信息互相对应，所述采用第三服务器中的最新数据文件更新所述第一服务器中的数据文件的步骤包括：
    从所述第一更新记录和所述第二更新记录中，查找出没有互相对应的第一更新信息和/或第二更新信息；
    删除所述第一服务器中所述没有互相对应的第一更新信息对应的数据文件，和/或，在所述第一服务器中增加所述没有互相对应的第二更新信息对应的数据文件。
  5. 根据权利要求1或3所述的方法，其特征在于，所述第一更新信息包括数据文件对应的第一更新时间，所述第二更新信息包括数据文件对应的第二更新时间，所述采 用第一更新信息和所述第二更新信息确定是否需要更新所述第一服务器中的数据文件的步骤包括：
    当所述第一更新时间晚于所述第二更新时间时，确定为需要更新所述第一服务器中的数据文件；
    当所述第一更新时间早于或等于所述第二更新时间时，确定为无需更新所述第一服务器中的数据文件。
  6. 根据权利要求5所述的方法，其特征在于，所述调用第三服务器中的最新数据文件更新所述第一服务器中的数据文件的步骤包括：
    从所述第三服务器中获取所述第二更新时间对应的最新数据文件；
    采用所述第二更新时间对应的最新数据文件，更新所述第一服务器中第一更新时间对应的数据文件。
  7. 根据权利要求1或3所述的方法，其特征在于，所述第二更新信息包括数据文件对应的操作类型和重命名目标文件名，所述方法还包括：
    确定所述第二更新记录中数据文件对应的操作类型是否为重命名操作；
    若是，则在所述第一服务器将所述数据文件的文件名修改为重命名目标文件名。
  8. 根据权利要求1所述的方法，其特征在于，所述第二更新信息包括目录操作信息，所述方法还包括：
    确定所述第二更新记录中是否存在目录操作信息；
    若是，则采用所述目录操作信息更新所述第一服务器上的目录。
  9. 根据权利要求1所述的方法，其特征在于，还包括：
    采用所述第二更新记录更新所述第一服务器上的第一更新记录。
  10. 根据权利要求1所述的方法，其特征在于，所述第一服务器为应用服务器，所述第二服务器为OCS开放缓存服务器，所述第三服务器为OSS分布存储服务器。
  11. 一种云环境下数据文件同步的装置，其特征在于，在所述云环境下设置有第一服务器，第二服务器和第三服务器，所述第一服务器中存储有第一更新记录，所述第二服务器中存储有第二更新记录，所述第一服务器中存储有数据文件，所述第三服务器中存储有最新数据文件，所述装置包括：
    获取模块，用于获取所述第二服务器中的第二更新记录；
    确定模块，用于采用所述第一更新记录和所述第二更新记录，确定是否需要更新所 述第一服务器中的数据文件；
    更新模块，用于当确定为需要更新所述第一服务器中的数据文件时，调用所述第三服务器中的最新数据文件更新所述第一服务器中的数据文件。
  12. 根据权利要求11所述的装置，其特征在于，所述获取模块包括：
    第二更新记录获取子模块，用于在所述第一服务器处理任何请求之前，获取所述第二服务器中的第二更新记录。
  13. 根据权利要求11所述的装置，其特征在于，所述第一更新记录中包括数据文件对应的第一更新信息，所述第二更新记录中包括最新数据文件对应的第二更新信息，所述确定模块包括：
    第一更新确定子模块，用于在所述第一更新记录与所述第二更新记录不一致时，确定为需要更新所述第一服务器中的数据文件；
    第二更新确定子模块，用于在所述第一更新记录与所述第二更新记录一致时，采用所述第一更新信息和所述第二更新信息确定是否需要更新所述第一服务器中的数据文件。
  14. 根据权利要求11或13所述的装置，其特征在于，所述第一更新信息与所述第二更新信息互相对应，所述更新模块包括：
    更新信息确定子模块，用于从所述第一更新记录和所述第二更新记录中，查找出没有互相对应的第一更新信息和/或第二更新信息；
    数据文件处理子模块，用于删除所述第一服务器中所述没有互相对应的第一更新信息对应的数据文件，和/或，在所述第一服务器中增加所述没有互相对应的第二更新信息对应的数据文件。
  15. 根据权利要求11或13所述的装置，其特征在于，所述第一更新信息包括数据文件对应的第一更新时间，所述第二更新信息包括数据文件对应的第二更新时间，所述第二更新确定子模块包括：
    第一更新确定单元，用于在所述第一更新时间晚于所述第二更新时间时，确定为需要更新所述第一服务器中的数据文件；
    第二更新确定单元，用于在所述第一更新时间早于或等于所述第二更新时间时，确定为无需更新所述第一服务器中的数据文件。
  16. 根据权利要求15所述的装置其特征在于，所述确定模块包括：
    最新数据文件获取子模块，用于从所述第三服务器中获取所述第二更新时间对应的 最新数据文件；
    数据文件更新子模块，用于采用所述第二更新时间对应的最新数据文件，更新所述第一服务器中第一更新时间对应的数据文件。
  17. 根据权利要求11或13所述的装置，其特征在于，所述第二更新信息包括数据文件对应的操作类型和重命名目标文件名，所述装置还包括：
    操作类型确定模块，用于确定所述第二更新记录中数据文件对应的操作类型是否为重命名操作；若是，则调用文件名修改模块；
    文件名修改模块，用于在所述第一服务器将所述数据文件的文件名修改为重命名目标文件名。
  18. 根据权利要求11所述的装置，其特征在于，所述第二更新信息包括目录操作信息，所述装置还包括：
    目录操作信息确定模块，用于确定所述第二更新记录中是否存在目录操作信息；若是，则目录更新模块；
    目录更新模块，用于采用所述目录操作信息更新所述第一服务器上的目录。
  19. 根据权利要求11所述的装置，其特征在于，还包括：
    更新记录更新模块，用于采用所述第二更新记录更新所述第一服务器上的第一更新记录。
PCT/CN2016/105136 2015-11-18 2016-11-09 一种云环境下数据文件同步的方法和装置 Ceased WO2017084520A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510801737.8 2015-11-18
CN201510801737.8A CN106708911A (zh) 2015-11-18 2015-11-18 一种云环境下数据文件同步的方法和装置

Publications (1)

Publication Number Publication Date
WO2017084520A1 true WO2017084520A1 (zh) 2017-05-26

Family

ID=58717374

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/105136 Ceased WO2017084520A1 (zh) 2015-11-18 2016-11-09 一种云环境下数据文件同步的方法和装置

Country Status (2)

Country Link
CN (1) CN106708911A (zh)
WO (1) WO2017084520A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111193787A (zh) * 2019-12-24 2020-05-22 国铁吉讯科技有限公司 同步方法及装置
CN116418588A (zh) * 2023-04-18 2023-07-11 科舸物联科技有限公司 一种文件上传方法、电子设备及存储介质

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110602168B (zh) * 2019-08-13 2022-03-01 平安科技（深圳）有限公司 数据同步方法、装置、计算机设备和存储介质
CN110912979B (zh) * 2019-11-16 2022-06-10 杭州安恒信息技术股份有限公司 一种解决多服务器资源同步冲突方法
US12058244B2 (en) 2021-09-09 2024-08-06 International Business Machines Corporation Prevention of race conditions in a dual-server storage system for generation of encryption key
CN114035985A (zh) * 2021-11-11 2022-02-11 深圳乐信软件技术有限公司 一种微服务架构下数据传输方法、装置、服务器及介质
CN115510158B (zh) * 2022-09-26 2026-03-13 中国建设银行股份有限公司 一种银保行业数据同步方法及系统
CN118827696A (zh) * 2024-05-30 2024-10-22 中移物联网有限公司 数据同步方法、装置、设备、存储介质及产品

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101741830A (zh) * 2009-11-09 2010-06-16 深圳市同洲电子股份有限公司 实现多客户端数据同步的方法、系统、客户端及服务器
CN101937467A (zh) * 2010-09-17 2011-01-05 北京开心人信息技术有限公司 一种服务器的高效缓存方法与系统
CN102724319A (zh) * 2012-06-20 2012-10-10 新浪网技术(中国)有限公司 一种数据同步方法、相关存储服务器及系统
CN104506643A (zh) * 2014-12-30 2015-04-08 北京奇虎科技有限公司 分布式存储系统的服务器及服务器之间的数据同步方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1261877C (zh) * 2002-10-11 2006-06-28 鸿富锦精密工业（深圳）有限公司 多节点文件同步系统及方法
CN103152398B (zh) * 2013-02-07 2016-05-11 中国科学院计算技术研究所 一种多终端文件间的文件同步方法及系统
CN103198100B (zh) * 2013-03-13 2016-05-18 中国科学院计算技术研究所 一种多设备间文件同步的重命名处理方法及系统
CN104158897B (zh) * 2014-08-25 2017-06-23 曙光信息产业股份有限公司 一种分布式文件系统中文件布局的更新方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101741830A (zh) * 2009-11-09 2010-06-16 深圳市同洲电子股份有限公司 实现多客户端数据同步的方法、系统、客户端及服务器
CN101937467A (zh) * 2010-09-17 2011-01-05 北京开心人信息技术有限公司 一种服务器的高效缓存方法与系统
CN102724319A (zh) * 2012-06-20 2012-10-10 新浪网技术(中国)有限公司 一种数据同步方法、相关存储服务器及系统
CN104506643A (zh) * 2014-12-30 2015-04-08 北京奇虎科技有限公司 分布式存储系统的服务器及服务器之间的数据同步方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111193787A (zh) * 2019-12-24 2020-05-22 国铁吉讯科技有限公司 同步方法及装置
CN116418588A (zh) * 2023-04-18 2023-07-11 科舸物联科技有限公司 一种文件上传方法、电子设备及存储介质

Also Published As

Publication number Publication date
CN106708911A (zh) 2017-05-24

Similar Documents

Publication Publication Date Title
WO2017084520A1 (zh) 一种云环境下数据文件同步的方法和装置
US20230101958A1 (en) File journal interface for synchronizing content
US9218405B2 (en) Batch processing and data synchronization in cloud-based systems
US11221995B2 (en) Data replication from a cloud-based storage resource
US20220188273A1 (en) Per-node metadata for custom node behaviors across platforms
CN111290826B (zh) 分布式文件系统、计算机系统和介质
WO2018161760A1 (zh) 区块链数据存储系统和方法
CN111737265B (zh) 区块数据访问方法、区块数据存储方法及装置
CN106815218B (zh) 数据库访问方法、装置和数据库系统
CN110457385B (zh) 多租户环境中的可实体化的数据库对象
US10261996B2 (en) Content localization using fallback translations
US20160088077A1 (en) Seamless binary object and metadata sync
US10152493B1 (en) Dynamic ephemeral point-in-time snapshots for consistent reads to HDFS clients
WO2015070674A1 (zh) 一种操作数据的方法和系统
US11496552B2 (en) Intent tracking for asynchronous operations
CN104281673A (zh) 一种数据库的缓存构建系统及对应的构建方法
CN105808451B (zh) 一种数据缓存方法以及相关装置
US11789971B1 (en) Adding replicas to a multi-leader replica group for a data set
CN105022779A (zh) 一种利用Filesystem API实现HDFS文件存取方法
US10684992B1 (en) Causally ordering distributed file system events
CN106940660B (zh) 缓存的实现的方法和装置
CN115421856A (zh) 一种数据恢复方法及装置
CN110147359B (zh) 一种增量生成方法、装置以及一种数据更新方法、装置
CN109522053A (zh) 一种大规模并行处理系统及数据处理方法
JP7703652B2 (ja) 非同期動作のための意図トラッキング

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: 16865697

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16865697

Country of ref document: EP

Kind code of ref document: A1