CN110334072A - 一种分布式文件系统、文件更新方法及装置 - Google Patents

一种分布式文件系统、文件更新方法及装置 Download PDF

Info

Publication number
CN110334072A
CN110334072A CN201810241049.4A CN201810241049A CN110334072A CN 110334072 A CN110334072 A CN 110334072A CN 201810241049 A CN201810241049 A CN 201810241049A CN 110334072 A CN110334072 A CN 110334072A
Authority
CN
China
Prior art keywords
file
data server
version
new
sent
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.)
Pending
Application number
CN201810241049.4A
Other languages
English (en)
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.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co 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 Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN201810241049.4A priority Critical patent/CN110334072A/zh
Publication of CN110334072A publication Critical patent/CN110334072A/zh
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/17Details of further file system functions
    • G06F16/178Techniques for file synchronisation in file systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/18File system types
    • G06F16/182Distributed file systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/18File system types
    • G06F16/1873Versioning file systems, temporal file systems, e.g. file system supporting different historic versions of files

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)
  • Information Transfer Between Computers (AREA)

Abstract

本发明涉及计算机技术领域,尤其涉及一种分布式文件系统、文件更新方法及装置,该系统包括客户端、元数据服务器和多个数据服务器,客户端将需要更新的文件的更新版本写入到文件对应的数据服务器中,并向元数据服务器发送针对文件的更新指令,元数据服务器接收客户端发送的更新指令,并确定对应的数据服务器,向对应的数据服务器发送对该文件进行更新的指示;对应的数据服务器接收到元数据服务器发送的指示时,对该文件进行更新,这样,每次更新时,由数据服务器完成更新计算,减少了大量数据的传输,提高更新效率。

Description

一种分布式文件系统、文件更新方法及装置
技术领域
本发明涉及计算机技术领域,尤其涉及一种分布式文件系统、文件更新方法及装置。
背景技术
分布式文件系统可以有效解决数据的存储和管理的问题,适用于目前信息数据快速增长的趋势。目前对于各种应用程序,尤其是提供网络在线服务的应用程序,数据更新需求会比较频繁且数据量比较大。
现有技术中,分布式文件系统的文件更新方法,只能通过先从服务器将文件下载到客户端,然后由客户端更新,再由客户端重新向服务器上传更新后的文件,最后服务器接收更新后的文件并删除原来的文件。
但是,这种只能通过下载并重新上传完整的文件实现更新的方式,尤其对于更新数据量比较大或比较频繁的情况,占用的网络资源会比较多,耗费的时间较长,降低了更新效率,数据更新性能较差。
发明内容
本发明实施例提供一种分布式文件系统、文件更新方法及装置,以解决现有技术中分布式文件系统更新效率较低,更新性能较差的问题。
本发明实施例提供的具体技术方案如下:
根据本发明实施例的第一方面,提供了一种分布式文件系统,所述系统包括:客户端,元数据服务器,多个数据服务器:
所述客户端,用于将需要更新的文件的更新版本写入到所述文件对应的数据服务器中,并向所述元数据服务器发送针对所述文件的更新指令;
所述元数据服务器,用于接收所述客户端发送的针对所述文件的更新指令,确定所述文件对应的数据服务器,并向所述对应的数据服务器发送对所述文件进行更新的指示;
所述对应的数据服务器,用于接收到所述元数据服务器发送的所述指示时,根据所述文件的更新版本,对所述文件进行更新。
结合本发明实施例的第一方面,所述客户端还用于:将所述文件的更新版本进行分片,获得所述文件的更新版本的分片文件;将所述文件的更新版本的分片文件,分别写入到各分片文件对应的数据服务器中。这样,在发送更新指令之前,客户端将更新版本写入到各相应的数据服务器,并只写入更新版本,减少了数据的大量传输,并且将文件进行分片并分布式存储,对于一个完整的更新版本的更新也就可以分布到各数据服务器进行更新计算,提高更新计算效率。
结合本发明实施例的第一方面,所述对应的数据服务器具体用于:确定所述文件的更新版本和当前版本,将所述文件的当前版本和更新版本进行融合,获得所述文件的更新后的当前版本,其中,所述更新版本表示所述文件的当前版本和新版本之间差异的部分。
结合本发明实施例的第一方面,所述对应的数据服务器,还用于:在确定更新完成后,将所述更新后的当前版本的文件信息发送给所述元数据服务器,其中,所述文件信息中至少包括所述更新后的当前版本的文件的哈希值。这样,可以由元数据服务器对更新后的当前版本进行统一管理,进行元数据更新和对更新后的当前版本进行检测,提高更新性能。
结合本发明实施例的第一方面,所述元数据服务器还用于:若所述对应的数据服务器有多个,则分别接收每个所述对应的数据服务器发送的所述更新后的当前版本的文件信息;检测每个所述对应的数据服务器发送的所述更新后的当前版本的文件信息中的哈希值是否均相同,若确定均相同,则分别向每个所述对应的数据服务器发送更新正常消息,若确定不是均相同,则根据预设的异常恢复方法,分别向每个所述对应的数据服务器发送异常恢复指示。这样,元数据服务器各对应的数据服务器中更新后的当前版本进行检测,保证各对应的数据服务器更新的一致性。
结合本发明实施例的第一方面,进一步包括:元数据监控服务器;所述元数据监控服务器,用于监控所述元数据服务器是否发生异常,若确定所述元数据服务器发生异常,则重新选择一个新的元数据服务器,并将所述新的元数据服务器的地址发送给所述多个数据服务器,以使所述多个数据服务器根据所述新的元数据服务器的地址,与所述新的元数据服务器建立通信连接。这样,通过元数据监控服务器对元数据服务器进行监控,避免元数据服务器的单点故障问题。
根据本发明实施例的第二方面,一种分布式文件系统中文件更新方法,包括:
元数据服务器接收客户端发送的针对文件的更新指令时,确定所述文件对应的数据服务器,并向所述对应的数据服务器发送对所述文件进行更新的指示,其中,所述针对文件的更新指令是所述客户端在将需要更新的文件的更新版本写入到所述文件对应的数据服务器后,向所述元数据服务器发送的;
所述对应的数据服务器接收到所述元数据服务器发送的所述指示时,根据所述文件的更新版本,对所述文件进行更新。
结合本发明实施例的第二方面,所述更新版本为所述客户端将完整的更新版本进行分片后,获得的所述对应的数据服务器对应的所述完整的更新版本的分片文件。
结合本发明实施例的第二方面,对所述文件进行更新,具体包括:确定所述文件的当前版本和更新版本,将所述文件的当前版本和更新版本进行融合,获得所述文件的更新后的当前版本,其中,所述更新版本表示所述文件的当前版本和新版本之间差异的部分。
结合本发明实施例的第二方面,进一步包括:所述对应的数据服务器在确定更新完成后,将所述更新后的当前版本的文件信息发送给所述元数据服务器,其中,所述文件信息中至少包括所述更新后的当前版本的文件的哈希值。
结合本发明实施例的第二方面,进一步包括:若所述对应的数据服务器有多个,则所述元数据服务器分别接收每个所述对应的数据服务器发送的所述更新后的当前版本的文件信息;检测每个所述对应的数据服务器发送的所述更新后的当前版本的文件信息中的哈希值是否均相同;其中,所述更新后的当前版本的文件信息是所述对应的数据服务器在确定更新完成后发送给所述元数据服务器的;若确定均相同,则分别向每个所述对应的数据服务器发送更新正常消息,若确定不是均相同,则根据预设的异常恢复方法,分别向每个所述对应的数据服务器发送异常恢复指示。
根据本发明实施例的第三方面,一种分布式文件系统中文件更新装置,包括:
确定模块,用于接收客户端发送的针对文件的更新指令时,确定所述文件的存储位置;其中,所述针对文件的更新指令是所述客户端在将需要更新的文件的更新版本写入到所述装置后发送的;
发送模块,用于发送对所述文件进行更新的指示;
更新模块,用于接收到所述指示时,根据所述文件的更新版本,对所述文件进行更新。
结合本发明实施例的第三方面,对所述文件进行更新,所述更新模块,具体用于:确定所述文件的当前版本和更新版本,将所述文件的当前版本和更新版本进行融合,获得所述文件的更新后的当前版本,其中,所述更新版本表示所述文件的当前版本和新版本之间差异的部分。
结合本发明实施例的第三方面,所述更新模块进一步用于:在确定更新完成后,发送所述更新后的当前版本的文件信息,其中,所述文件信息中至少包括所述更新后的当前版本的文件的哈希值。
结合本发明实施例的第三方面,进一步包括,检测模块,用于:若接收到多个所述更新模块发送的所述更新后的当前版本的文件信息;分别检测每个所述更新后的当前版本的文件信息中的哈希值是否均相同;其中,所述更新后的当前版本的文件信息是所述更新模块在确定更新完成后发送的;若确定均相同,则发送更新正常消息,若确定不是均相同,则根据预设的异常恢复方法,发送异常恢复指示。
本发明实施例中,分布式文件系统包括:客户端、元数据服务器,多个数据服务器,客户端,用于将需要更新的文件的更新版本写入到所述文件对应的数据服务器中,并向所述元数据服务器发送针对所述文件的更新指令;所述元数据服务器,用于接收所述客户端发送的针对所述文件的更新指令,确定所述文件对应的数据服务器,并向所述对应的数据服务器发送对所述文件进行更新的指示;所述对应的数据服务器,用于接收到所述元数据服务器发送的所述指示时,根据所述文件的更新版本,对所述文件进行更新,这样,通过元数据服务器对更新进行统一管理,由相应的数据服务器进行更新计算,利用数据服务器的存储和计算资源,进行文件更新,减少了大量数据的传输和交互,提高了更新效率和性能。
附图说明
图1为本发明实施例中提供的一种分布式文件系统结构示意图;
图2为本发明实施例中元数据服务器同步的设计示意图;
图3为本发明实施例中提供的另一种分布式文件系统结构示意图;
图4为本发明实施例中分布式文件系统中文件写方法流程图;
图5为本发明实施例中分布式文件系统中文件读方法流程图;
图6为本发明实施例中提供的一种分布式文件系统的文件更新方法流程图;
图7为本发明实施例中提供的另一种分布式文件系统的文件更新方法流程图;
图8为本发明实施例中分布式文件系统的分布式存储和分布式计算更新效果示意图;
图9为本发明实施例中分布式文件系统中文件更新装置结构示意图;
图10为本发明实施例中服务器结构示意图;
图11为本发明实施例中客户端结构示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,并不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
为便于对本发明实施例的理解,下面先对几个概念进行简单介绍:
分布式文件系统:是指文件系统管理的物理存储资源不一定直接连接在本地节点上,而是通过计算机网络与节点相连。
分布式存储:是将数据分散存储在多台独立的数据服务器上,分布式存储的优点在于利用多台数据服务器分担存储负荷,多台数据服务器可以分布在不同的地理位置,可以使用多个小容量的数据服务器,要求较低并易于扩展。
元数据服务器的单点故障(Single Point of Failure,SPOF):整个分布式文件系统严重依赖于元数据服务器,一旦元数据服务器出现问题,系统将变得完全不可用,直接导致应用中断并影响业务连续性。
元数据(Metadata):又称中介数据、中继数据,为描述数据的数据(data aboutdata),主要是描述数据属性的信息,用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。
杂凑算法:又称为摘要算法、哈希算法,是把任意长的输入消息串变化成固定长的输出串;其中,消息摘要算法第五版(Message Digest Algorithm 5,MD5):用于确保信息传输完整一致,是计算机广泛使用的杂凑算法之一,将数据运算为另一固定长度值,具有强抗修改性和强抗碰撞,可以作为数据的身份信息,唯一标识该数据。
抽取、转换和加载(Extract-Transform-Load,ETL):用来描述将数据从来源端经过抽取(extract)、转换(transform)、加载(load)至目的端的过程。
参阅图1所示,为本发明实施例中提供的一种分布式文件系统结构示意图。该系统包括客户端、元数据监控服务器、元数据服务器、多个数据服务器。
客户端可以是智能手机、平板电脑、便携式个人计算机、智能电视等任何智能设备,客户端上可以收集数据,例如收集游戏数据,可以包括游戏用户状态数据、游戏用户流水数据等,客户端可以将游戏数据通过元数据服务器写入到数据服务器中。
客户端与数据服务器、元数据服务器之间通过互联网相连,实现相互之间的通信。
元数据监控服务器、元数据服务器以及多个数据服务器可以构成一个三层的分布式存储集群。
为了解决现有技术中分布式文件系统更新效率较低,更新性能较差的问题,本发明实施例中,基于上述分布式文件系统,提供了一种可能的实施方式,客户端,用于将需要更新的文件的更新版本写入到文件对应的数据服务器中,并向元数据服务器发送针对该文件的更新指令;元数据服务器,用于接收客户端发送的针对所述文件的更新指令,确定文件对应的数据服务器,并向对应的数据服务器发送对文件进行更新的指示;对应的数据服务器,用于接收到元数据服务器发送的指示时,根据文件的更新版本,对文件进行更新,其中,所述更新版本表示所述文件的当前版本和新版本之间差异的部分。这样,本发明实施例中,由客户端预先将更新版本写入到数据服务器中,然后通过元数据服务器的调度,由数据服务器根据更新版本进行计算更新,实现了可以在数据服务器对文件直接进行更新,并且利用了集群即元数据服务器和数据服务器本身的资源,节省了集群之外大量的数据存储和计算资源,并且只上传差异部分的更新版本,不需要上传完整的文件,也节省了网络资源,提高了更新效率和性能。
为进一步提高更新准确性,本发明实施例中,还提供了一种检测实施方式,对应的数据服务器用于在确定更新完成后,将更新后的当前版本的文件信息发送给元数据服务器,其中,文件信息中至少包括所述更新后的当前版本的文件的哈希值;元数据服务器还用于:若对应的数据服务器有多个,则分别接收每个对应的数据服务器发送的更新后的当前版本的文件信息,并检测每个对应的数据服务器发送的更新后的当前版本的文件信息中的哈希值是否均相同,若确定均相同,则分别向每个对应的数据服务器发送更新正常消息,若确定不是均相同,则根据预设的异常恢复方法,分别向每个对应的数据服务器发送异常恢复指示,这样,由元数据服务器对更新后的文件进行各对应的数据服务器之间的检测,保证各对应的数据服务器中更新后的文件也是一致的。
为保证分布式文件系统中元数据服务器的可用性,避免元数据服务器的单点故障问题,本发明实施例中,提供了一种可能的实施方式,元数据监控服务器,用于监控元数据服务器是否发生异常,若确定元数据服务器发生异常,则重新选择一个新的元数据服务器,并将新的元数据服务器的地址发送给多个数据服务器,以使多个数据服务器根据新的元数据服务器的地址,与新的元数据服务器建立通信连接,这样,可以保证服务的元数据服务器是正常的,提高分布式文件系统的可靠性。
下面对该分布式文件系统中各服务器的设置进行具体说明。
其中,元数据监控服务器用于监控元数据服务器是否发生异常,本发明实施例中,为了元数据监控服务器的稳定性和可用性,采用主节点+冷备的方式,部署两个元数据监控节点,分别为主元数据监控节点和冷备元数据监控节点,其中,这两个元数据监控节点可以部署在一个元数据监控服务器中,也可以分别部署在两个不同的元数据监控服务器中,较佳的,参阅图1所示,本发明实施例中,是分别部署在了两个元数据监控服务器中,即分别为主元数据监控服务器和冷备元数据监控服务器。
元数据服务器用于存储元数据,对多个数据服务器进行统一管理。为保证元数据的一致性和服务的稳定性,采用主+同步+异步节点的方式,部署三个元数据节点,分别为一个主元数据节点、一个同步元数据节点,一个异步元数据节点,并且这三个元数据节点可以同时部署在一个元数据服务器中,也可以分别部署在三个不同的元数据服务器,较佳的,参阅图1所示,本发明实施例中,是分别部署在三个不同的元数据服务器中,即分别为主元数据服务器、同步元数据服务器和异步元数据服务器,这样,这三个元数据服务器中的元数据可以互为备份,较佳的,主元数据服务器提供服务,三个元数据服务器中的元数据需保持同步,即三个元数据服务器中的元数据是一致的。
本发明实施例中,提供了一种主元数据节点和同步元数据节点保持同步的实施方式,主元数据节点和同步元数据节点之间可以采用预设的两阶段提交算法,即用户提交的一次修改在主元数据节点和同步元数据节点中的修改结果是相同的,使得主元数据节点和同步元数据节点中的元数据保持强一致性。
本发明实施例中,还提供了一种主元数据节点和异步元数据节点保持同步的实施方式,异步元数据节点向主元数据节点发送数据获取请求,主元数据节点接收到数据获取请求后,向异步元数据节点返回当前记录的数据,异步元数据节点接收的主元数据节点返回的数据后,更新自身保存的数据,这样异步元数据节点可以获知到主元数据节点中数据的变更,保证主元数据节点和异步元数据节点中数据的一致性,可选的,异步元数据节点可以按照预设的周期向主元数据节点发送数据获取请求,使得异步元数据节点可以在一段时间内学习到主元数据节点中数据的变化,异步元数据节点和主元数据节点可以保持相对的一致性。
也就是说,参阅图2所示,为本发明实施例中元数据服务器同步的设计示意图。用户向主元数据节点提交修改请求,主元数据节点接收到修改请求后,会将修改请求主动push给同步元数据节点,使得同步元数据节点和主元数据节点针对此次修改请求的修改结果是相同的,而异步元数据节点则通过pull方式来请求主元数据节点进行日志学习,可能不能及时和主元数据节点保持一致,但是可以保证在一定时间段内和主元数据节点保持一致。
数据服务器用于存储实际的数据,提供实际对客户端的数据写入和读取。为保证数据的安全性和容灾性,会将数据保存为预设份数,本发明实施例中,较佳的保存为3份,即一份数据分别存储在3个数据服务器上,并且,本发明实施例中,为了实现分布式文件系统中数据的更新,采用位图存储,数据存储单位为文件。例如,针对游戏数据,采用位图存储,还可以支持在线操作数据的存储和更新。数据服务器可以只与主元数据服务器进行通信,并且一个主元数据服务器可以管理多个数据服务器,即与多个数据服务进行通信连接。
进一步地,本发明实施例中,为提高分布式文件系统的数据管理性能,数据服务器还需具有以下功能:1)本地资源的监控。数据服务器对本地资源进行监控,并将本地资源的使用情况上报给元数据服务器,以使元数据服务器根据该数据服务器的本地资源的使用情况,对各数据服务器的本地资源进行管理,其中,本地资源例如为CPU、内存、磁盘等的使用情况。这样,可以保证元数据服务器对各数据服务器进行负载均衡。2)带宽控制。在文件读取任务并发时,数据服务器能够控制数据传输,使得带宽能相对均匀地分配到各传输链路中。3)数据恢复。元数据服务器若检测到数据服务器中的文件异常,则该数据服务器根据元数据服务器的指示,能够从其它数据服务器中获取相应的备份的文件,根据获取到的相应的备份的文件,进行更新替换来恢复自身存储的文件。4)数据验证。数据服务器能够对自身存储的文件的版本信息进行计算检测。5)脏数据清理。数据服务器能够对脏数据进行清理。例如,数据服务器可以按照一定的周期来清理脏数据,其中,脏数据为无效数据、临时文件等。
基于上述实施例中,参阅图3所示,为本发明实施例中提供的另一种分布式文件系统结构示意图。包括两个元数据监控节点(MetaNodeMonitor),冷备MetaNodeMonitor通过向主MetaNodeMonitor发送心跳检测,实时检测主MetaNodeMonitor是否异常;三个元数据节点(MetaNode),分别为同步MetaNode、异步MetaNode和主MetaNode;多个数据节点(DataNode)和客户端(Client)。本发明实施例中,还提供了一种监控实施方式,基于图3的分布式文件系统,MetaNodeMonitor与主MetaNode进行通信,用于监控MetaNode,并若检测到主MetaNode发生异常,则重新选择一个新的主MetaNode,并将新的主MetaNode的IP地址通知给DataNode,以使DataNode与新的主MetaNode建立通信连接。
并且本发明实施例中,为解决MetaNode的单点故障问题,保证MetaNode的元数据的正确性和服务的稳定性,MetaNodeMonitor和MetaNode之间可以采用简单被动心跳和被动状态切换的方式进行监控和异常切换,也就是说,MetaNodeMonitor主动向主MetaNode发送心跳检测信号,并判断是否接收到主MetaNode返回的心跳检测响应信号,若没有接收到,可以认为该主MetaNode发生故障,并可以根据配置信息,选择其它正常的主MetaNode进行切换。
本发明实施例中,还提供了一种分布式文件系统的分布式存储方法,1、客户端向元数据服务器发送创建文件请求,并获取由元数据服务器返回的3个数据服务器的地址;2、根据返回的3个数据服务器的地址,分别将文件写入到这3个数据服务器中;3、数据服务器确定写完后,将写入的文件的文件信息上报给元数据服务器;元数据服务器分别接收该3个数据服务器发送的文件信息,更新相应的元数据并对这3个数据服务器发送的文件信息进行检测,确定是否是一致的。其中,文件信息可以表征文件的元数据,例如,文件存储路径、写入时间、文件的MD5值等。
可选的,本发明实施例中,客户端在向数据服务器写入文件时,还提供了一种实施方式,客户端将文件进行分片,获得该文件对应的分片文件,并分别将每一个分片文件写入相应的数据服务器中,并且同样地,为保证文件存储的可靠性,每一个分片文件存储3份,这样,由客户端进行分片,在各数据服务器中存储分片文件,实现文件的分布式存储。
例如,客户端将一个大文件经过分片后,分为4个小的分片文件,每一个分片文件在数据服务器中以文件为存储单位单独存储,并且每一个分片文件存储3份,即同一个分片文件分别在3个不同的数据服务器中进行存储。
具体地以针对一份文件进行写为例,进行详细介绍,参阅图4所示,为本发明实施例中分布式文件系统中文件写方法流程图,该方法包括:
步骤400:客户端向元数据服务器发送文件写请求。
步骤401:元数据服务器接收到文件写请求后,选取数据服务器。
较佳的,选取3个不同的数据服务器。
步骤402:元数据服务器将选取的数据服务器的IP地址发送给客户端。
步骤403:客户端根据元数据服务器发送的数据服务器的IP地址,将文件发送到相应的数据服务器。
步骤404:数据服务器接收客户端发送的文件并进行写入。
步骤405:数据服务器确定文件写入后,将文件的文件信息上传到元数据服务器。
步骤406:元数据服务器接收数据服务器发送的文件信息。
步骤407:元数据服务器根据数据服务器发送的文件信息,进行检测并更新和保存该文件相应的元数据。
具体地,若客户端将文件写入到了3个不同的数据服务器中,则根据文件信息,判断这3个数据服务器中写入的文件是否是一致的,若一致,则确定更新完成。
步骤408:元数据服务器向数据服务器返回更新完成消息。
步骤409:数据服务器接收到元数据服务器返回的更新完成消息后,向客户端返回写入完成消息。
这样,在文件写时,由客户端直接将文件写入到相应的数据服务器,并由元数据服务器进行核对,可以保证各数据服务中保存的文件的一致性和可靠性。
并且,本发明实施例中,数据服务器在存储文件时,判断当前存储区域的当前存储空间的已存储量占比是否小于预设阈值,若确定小于,则将文件存储在该当前存储区域中,若确定不小于,则从本地其它存储区域中,重新选择其中存储空间最大的存储区域作为当前存储区域,并将文件存储在重新选择的当前存储区域,并且,若确定已存储量与所有存储区域的存储空间之和的占比不小于第一设定阈值,则进行告警,并在不小于第二设定阈值时,拒绝存储文件。
例如,数据服务器在初始化时,分析本地文件系统磁盘,优先使用存储空间最大的磁盘作为当前存储盘,即当前存储区域,在该存储盘中存储量到达一定量时,再重新选择其它存储空间最大的磁盘作为当前存储盘,在确定整体存储量占比不小于第一设定阈值,例如80%时进行告警,不小于第二设定阈值,例如90%时拒绝存储文件。
相应地,本发明实施例中还提供了一种分布式文件系统中文件读方法流程图,参阅图5所示,该方法包括:
步骤500:客户端向元数据服务器请求获取文件读取的数据服务器信息。
步骤501:元数据服务器接收客户端发送的请求。
步骤502:元数据服务器查找对应的数据服务器,并返回给客户端。
步骤502:客户端接收元数据服务器返回的数据服务器的IP地址。
步骤503:客户端从元数据服务器返回的数据服务器的IP地址中,选择任意一个数据服务器,并向选择的任意一个数据服务器发送文件读请求。
步骤504:数据服务器接收客户端发送的文件读请求。
步骤505:数据服务器将相应的文件发送给客户端。
本发明各个实施例中,以文件更新方法用于图1或图3所示的分布式文件系统为例进行示意性说明。
为了解决现有技术中分布式文件系统更新效率较低,更新性能较差的问题,本发明实施例中,采用文件分布式存储和分布式计算更新结合的方式,使用数据服务器本身的资源进行文件计算更新,提高了更新效率,基于上述实施例,参阅图6所示,为本发明实施例中提供的分布式文件系统的文件更新方法的流程图。
步骤600:客户端将文件的更新版本写入到对应的数据服务器中。
其中,更新版本表示所述文件的当前版本和新版本之间差异的部分。
本发明实施例中,对文件进行分布式存储,对于一个大文件,可以分片为若干个小的分片文件分别进行存储,因此,本发明实施例中,该更新版本为客户端将完整的更新版本进行分片后,获得的所述对应的数据服务器对应的完整的更新版本的分片文件,也就是说,客户端上传需要更新的文件的更新版本时,将文件的更新版本进行分片,获得文件的更新版本的分片文件,并将更新版本的分片文件分别写入到各分片文件对应的数据服务器中。其中,数据服务器中存储的文件的当前版本也为客户端上传的分片文件,即实现了文件在文件分布式系统中的分片存储。
具体地,客户端向数据服务器写更新版本的过程可以参阅图5所示的文件写方法流程,客户端通过元数据服务器返回的更新版本对应的数据服务器的IP地址,将更新版本写入到对应的数据服务器中。
可选的,客户端可以按照预设周期,将更新版本写入到数据服务器中。
例如,对于游戏数据的游戏用户状态数据和游戏用户流水数据,可以每天上传一次。
步骤601:客户端向元数据服务器发送更新指令。
执行步骤601时,本发明实施例中可以提供以下两种实施方式:
第一种方式:更新指令中至少包括文件存储路径。
例如,客户端发送的更新指令中指示的文件存储路径为:“游戏名称/01号大区”,即客户端告知元数据服务器需要更新该游戏名称对应的游戏的01号大区下的所有文件。
这样,本发明实施例中,根据文件存储路径,可以只对某个指定的文件进行更新,也可以对某个路径下的所有文件进行更新,对此本发明实施例中并不进行限制。
第二种方式:客户端向元数据服务器发送针对需要更新的文件的更新指令。这样,元数据服务器检测到更新时,可以查找需要更新的文件的存储位置,找到对应的数据服务器,进行调度更新。
可选的,本发明实施例中,客户端发送更新指令的触发条件,可以为在接收到用户输入的更新指令时,也可以在确定更新版本写入完成时,对此,本发明实施例中并不进行限制。
步骤602:元数据服务器接收客户端发送的更新指令。
步骤603:元数据服务器确定对应的数据服务器。
在本发明实施例中,提供了一种可能的实施方式,元数据服务器查找更新指令中包括的文件存储路径对应的数据服务器。
例如,若文件存储路径为“游戏名称/01号大区”,通常对于一个游戏的大区下会有多个文件,则查找所有含有该文件存储路径的数据服务器。
又例如,若文件存储路径为“游戏名称/01号大区/A”,并文件存储备份有3份,则元数据服务器会查找到3个存储有文件A的数据服务器。
在本发明实施例中,提供了另一种可能的实施方式,元数据服务器根据需要更新的文件,确定需要更新的文件的存储位置,即确定出需要更新的文件对应的存储位置。
步骤604:元数据服务器向对应的数据服务器发送对文件进行更新的指示。
步骤605:数据服务器接收元数据服务器发送的指示。
步骤606:数据服务器对文件进行更新。
执行步骤606时,具体包括:
确定文件的当前版本和更新版本,将文件的当前版本和更新版本进行融合,获得文件的更新后的当前版本。
其中,更新版本是客户端在发送更新指令之前写入到对应的数据服务器中的。
具体地,数据服务器可以根据预设的更新算法进行更新,其中,预设的更新算法本发明实施例中,并不进行限制,也可以采用其它的更新算法对文件进行更新。
可选的,为提高文件存储和更新的可靠性,本发明实施例中,数据服务器中保存有一个文件对应的当前版本和上一个版本,数据服务器在生成文件的更新后的当前版本后,将更新后的当前版本作为文件的新的当前版本,并将更新之前的当前版本替换更新之前的上一个版本,这样,若发生更新异常的情况,也可以不丢失更新之前的版本,能够准确恢复到更新之前的版本。
步骤607:数据服务器在确定更新完成后,将更新后的当前版本的文件信息发送给元数据服务器。
其中,文件信息中至少包括更新后的当前版本的文件的哈希值。较佳的,为MD5值。
本发明实施例中,文件信息中还可以包括其它信息,例如更新时间、文件存储路径等,本发明实施例中并不进行限制。
本发明实施例中,在执行步骤607时,数据服务器还需先根据预设的哈希算法,计算文件的更新后的当前版本的哈希值。
步骤608:元数据服务器接收每个对应的数据服务器发送的更新后的当前版本的文件信息。
步骤609:元数据服务器检测每个对应的数据服务器发送的更新后的当前版本的文件信息中的哈希值是否均相同。
这是因为,本发明实施例中,针对一份文件会存储多份,例如,若存储了3份,分别存储在3个不同的数据服务器中,并且分别进行更新,这样,元数据服务器会接收到3个对应的数据服务器发送的更新后的当前版本的文件信息,为保证数据服务器中更新后的文件也是一致的,因此,需要对这3个数据服务器中更新后的当前版本之间进行检测。
步骤610:元数据服务器若确定均相同,则分别向每个对应的数据服务器发送更新正常消息,若确定不是均相同,则根据预设的异常恢复方法,分别向每个对应的数据服务器发送异常恢复指示。
可选的,本发明实施例中提供了一种异常恢复方法,以文件存储路径对应有3个数据服务器为例,可以分为以下两种情况:第一种情况:元数据服务器若确定3个数据服务器发送的更新后的当前版本的文件信息中的哈希值均相同,则确定更新正常;第二种情况:若确定其中2个数据服务器发送的更新后的当前版本的文件信息中的哈希值相同并与另一个不相同,则指示不相同的数据服务器从其它2个相同的数据服务器中任一个数据服务器中获取文件的更新后的当前版本,并根据获得到的文件的更新后的当前版本来替换自身存储的更新后的当前版本;第三种情况:若确定3个数据服务器发送的更新后的当前版本的文件信息中的哈希值均不相同,则指示这3个数据服务器将文件更新后的当前版本恢复到更新之前的当前版本,并删除更新后的当前版本。
进一步地,本发明实施例中,数据服务器在接收到元数据服务器发送的更新正常消息后,向客户端发送更新完成消息,这样可以使得客户端得到更新已经完成。
参阅图7所示,为本发明实施例中提供的另一种分布式文件系统中文件更新过程示意图,图7以对存储有3份的文件A进行更新为例。
客户端上部署有ETL功能,客户端上还部署JobSubmit节点,元数据服务器上部署JobScheduler节点,同样在数据服务器上部署TaskExecutor节点。元数据监控服务器、元数据服务器和数据服务器构成一个集群。其中,JobSubmit用于提交更新命令,JobScheduler用于执行并调度更新任务到相应的TaskExecutor上,TaskExecutor用于根据预设的更新算法,执行更新任务。
其中,本发明实施例中,还可以将JobSubmit节点和ETL功能部署在两个不同的客户端,或者,ETL功能还可以使用独立的服务器来实现,对此,并不进行限制。
1)ETL将更新版本写入到数据服务器中。
2)JobSubmit向JobScheduler发送更新指令,JobScheduler接收到更新指令后,将更新任务调度到相应的数据服务器中的TaskExecutor上,指示TaskExecutor对文件A进行更新。
3)TaskExecutor接收到JobScheduler的指示后,调用相应的应用程序(Application,APP)对文件A进行更新。
其中,APP为数据服务器中用于执行文件更新的更新逻辑。
4)TaskExecutor执行更新任务完成后,通过数据服务器将更新后的文件A的文件信息上报给元数据服务器。其中,文件信息中可以包括文件A的存储路径、更新时间、更新后的文件A的MD5值。
5)元数据服务器可以根据3个数据服务器上报的更新后的文件A的MD5值,进行检测确定更新是否正常。
本发明实施例中,通过元数据服务器对更新进行统一管理,并由多个数据服务器进行分布式计算更新,客户端只需预先将更新版本上传到相应的数据服务器中,利用数据服务器的存储和计算资源,进行文件更新,这样,进行文件更新时,客户端只需发送更新指令,之后由集群,即元数据服务器和数据服务器进行调度更新,提高了更新效率和时间,并且数据服务器更新完成后,由元数据服务器对更新结果进行检测,实现了元数据服务器对文件更新的统一管理,更加高效。
这样,基于上述实施例,本发明实施例中,参阅图8所示,为分布式存储和分布式计算更新效果示意图,将文件的分布式存储和分布式计算更新结合,来实现分布式文件系统的文件更新,通过将文件进行分布式存储,节省资源和存储可靠性,并通过调度多个数据服务器分别进行文件更新,解决了大量数据更新效率低的问题,实现了分布式文件系统中文件的高效更新,并且减少了在集群外进行数据计算和存储设备数量,提高了文件更新效率和性能。
基于上述实施例,参阅图9所示,本发明实施例中分布式文件系统中文件更新装置,包括:
确定模块90,用于接收客户端发送的针对文件的更新指令时,确定所述文件的存储位置;其中,所述针对文件的更新指令是所述客户端在将需要更新的文件的更新版本写入到所述装置后发送的;
发送模块91,用于发送对所述文件进行更新的指示;
更新模块92,用于接收到所述指示时,根据所述文件的更新版本,对所述文件进行更新。
可选的,对所述文件进行更新,所述更新模块92,具体用于:
确定所述文件的当前版本和更新版本,将所述文件的当前版本和更新版本进行融合,获得所述文件的更新后的当前版本,其中,所述更新版本表示所述文件的当前版本和新版本之间差异的部分。
可选的,所述更新模块92进一步用于:
在确定更新完成后,发送所述更新后的当前版本的文件信息,其中,所述文件信息中至少包括所述更新后的当前版本的文件的哈希值。
可选的,进一步包括,检测模块93,用于:
若接收到多个所述更新模块发送的所述更新后的当前版本的文件信息;
分别检测每个所述更新后的当前版本的文件信息中的哈希值是否均相同;其中,所述更新后的当前版本的文件信息是所述更新模块在确定更新完成后发送的;
若确定均相同,则发送更新正常消息,若确定不是均相同,则根据预设的异常恢复方法,发送异常恢复指示。
基于上述实施例,参阅图10所示,本发明实施例中,一种服务器的结构示意图。
本发明实施例提供了一种服务器,该服务器可以包括处理器1110(CenterProcessing Unit,CPU)、存储器1120、输入设备1130和输出设备1140等,输入设备1130可以包括键盘、鼠标、触摸屏等,输出设备1140可以包括显示设备,如液晶显示器(LiquidCrystal Display,LCD)、阴极射线管(Cathode Ray Tube,CRT)等。
存储器1120可以包括只读存储器(ROM)和随机存取存储器(RAM),并向处理器1110提供存储器1120中存储的程序指令和数据。在本发明实施例中,存储器1120可以用于存储文件更新方法的程序。
处理器1110通过调用存储器1120存储的程序指令,处理器1110用于按照获得的程序指令执行本发明实施例中的文件更新方法。
基于上述实施例,具体地,针对数据服务器、元数据服务器,处理器1110执行相应的文件更新方法的流程。
基于上述实施例,参阅图11所示,本发明实施例中,一种客户端的结构示意图。
本发明实施例提供了一种客户端,客户端可以为但不限于手机、平板电脑等。该客户端可以包括:存储器1210、输入模块1220、发送模块1230、接收模块1240、输出模块1250、无线通信模块1260和处理器1270等。具体为:
存储器1210可以包括只读存储器(ROM)和随机存取存储器(RAM),并向处理器1270提供存储器1210中存储的程序指令和数据,还可以存储客户端的操作系统、应用程序(Application,APP)、模块和客户端所使用的各种数据等。
输入模块1220可以包括键盘、鼠标、触摸屏等,用于接收用户输入的数字、字符信息或触摸操作,以及产生与客户端的用户设置以及功能控制有关的键信号的输入等。
发送模块1230可以提供客户端与服务器之间的接口。例如,本发明实施例中,用于向元数据服务器发送更新指令等。
接收模块1240同样提供客户端与服务器之间的接口,例如,本发明实施例中,用于接收元数据服务器返回的数据服务器的IP地址等。
输出模块1250可以包括显示模块,如液晶显示器(Liquid Crystal Display,LCD)、阴极射线管(Cathode Ray Tube,CRT)等,其中,显示模块可以用于显示由用户输入的信息或提供给用户的信息,或各种客户端的操作界面等。
无线通信模块1260包括但不限于无线保真(wireless fidelity,WiFi)模块、蓝牙模块、红外通信模块等。
处理器1270是客户端的控制中心,利用各种接口和线路连接整个客户端的各个部分,通过运行或执行存储在存储器1210内的软件程序和/或模块,以及调用存储在存储器1210内的数据,执行客户端的各种功能和处理数据,从而对客户端进行整体监控。
当然,图11中所示的客户端的结构,仅仅是其中一种示例,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本发明的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
显然,本领域的技术人员可以对本发明实施例进行各种改动和变型而不脱离本发明实施例的精神和范围。这样,倘若本发明实施例的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。

Claims (15)

1.一种分布式文件系统,其特征在于,所述系统包括:客户端,元数据服务器,多个数据服务器:
所述客户端,用于将需要更新的文件的更新版本写入到所述文件对应的数据服务器中,并向所述元数据服务器发送针对所述文件的更新指令;
所述元数据服务器,用于接收所述客户端发送的针对所述文件的更新指令,确定所述文件对应的数据服务器,并向所述对应的数据服务器发送对所述文件进行更新的指示;
所述对应的数据服务器,用于接收到所述元数据服务器发送的所述指示时,根据所述文件的更新版本,对所述文件进行更新。
2.如权利要求1所述的系统,其特征在于,所述客户端还用于:
将所述文件的更新版本进行分片,获得所述文件的更新版本的分片文件;
将所述文件的更新版本的分片文件,分别写入到各分片文件对应的数据服务器中。
3.如权利要求1或2所述的系统,其特征在于,所述对应的数据服务器具体用于:
确定所述文件的更新版本和当前版本,将所述文件的当前版本和更新版本进行融合,获得所述文件的更新后的当前版本,其中,所述更新版本表示所述文件的当前版本和新版本之间差异的部分。
4.如权利要求3所述的系统,其特征在于,所述对应的数据服务器,还用于:
在确定更新完成后,将所述更新后的当前版本的文件信息发送给所述元数据服务器,其中,所述文件信息中至少包括所述更新后的当前版本的文件的哈希值。
5.如权利要求4所述的系统,其特征在于,所述元数据服务器还用于:
若所述对应的数据服务器有多个,则分别接收每个所述对应的数据服务器发送的所述更新后的当前版本的文件信息;
检测每个所述对应的数据服务器发送的所述更新后的当前版本的文件信息中的哈希值是否均相同,若确定均相同,则分别向每个所述对应的数据服务器发送更新正常消息,若确定不是均相同,则根据预设的异常恢复方法,分别向每个所述对应的数据服务器发送异常恢复指示。
6.如权利要求1所述的系统,其特征在于,进一步包括:元数据监控服务器;
所述元数据监控服务器,用于监控所述元数据服务器是否发生异常,若确定所述元数据服务器发生异常,则重新选择一个新的元数据服务器,并将所述新的元数据服务器的地址发送给所述多个数据服务器,以使所述多个数据服务器根据所述新的元数据服务器的地址,与所述新的元数据服务器建立通信连接。
7.一种分布式文件系统中文件更新方法,其特征在于,包括:
元数据服务器接收客户端发送的针对文件的更新指令时,确定所述文件对应的数据服务器,并向所述对应的数据服务器发送对所述文件进行更新的指示,其中,所述针对文件的更新指令是所述客户端在将需要更新的文件的更新版本写入到所述文件对应的数据服务器后,向所述元数据服务器发送的;
所述对应的数据服务器接收到所述元数据服务器发送的所述指示时,根据所述文件的更新版本,对所述文件进行更新。
8.如权利要求7所述的方法,其特征在于,所述更新版本为所述客户端将完整的更新版本进行分片后,获得的所述对应的数据服务器对应的所述完整的更新版本的分片文件。
9.如权利要求7或8所述的方法,其特征在于,对所述文件进行更新,具体包括:
确定所述文件的当前版本和更新版本,将所述文件的当前版本和更新版本进行融合,获得所述文件的更新后的当前版本,其中,所述更新版本表示所述文件的当前版本和新版本之间差异的部分。
10.如权利要求9所述的方法,其特征在于,进一步包括:
所述对应的数据服务器在确定更新完成后,将所述更新后的当前版本的文件信息发送给所述元数据服务器,其中,所述文件信息中至少包括所述更新后的当前版本的文件的哈希值。
11.如权利要求10所述的方法,其特征在于,进一步包括:
若所述对应的数据服务器有多个,则所述元数据服务器分别接收每个所述对应的数据服务器发送的所述更新后的当前版本的文件信息;
检测每个所述对应的数据服务器发送的所述更新后的当前版本的文件信息中的哈希值是否均相同;其中,所述更新后的当前版本的文件信息是所述对应的数据服务器在确定更新完成后发送给所述元数据服务器的;
若确定均相同,则分别向每个所述对应的数据服务器发送更新正常消息,若确定不是均相同,则根据预设的异常恢复方法,分别向每个所述对应的数据服务器发送异常恢复指示。
12.一种分布式文件系统中文件更新装置,其特征在于,包括:
确定模块,用于接收客户端发送的针对文件的更新指令时,确定所述文件的存储位置;其中,所述针对文件的更新指令是所述客户端在将需要更新的文件的更新版本写入到所述装置后发送的;
发送模块,用于发送对所述文件进行更新的指示;
更新模块,用于接收到所述指示时,根据所述文件的更新版本,对所述文件进行更新。
13.如权利要求12所述的装置,其特征在于,对所述文件进行更新,所述更新模块,具体用于:
确定所述文件的当前版本和更新版本,将所述文件的当前版本和更新版本进行融合,获得所述文件的更新后的当前版本,其中,所述更新版本表示所述文件的当前版本和新版本之间差异的部分。
14.如权利要求13所述的装置,其特征在于,所述更新模块进一步用于:
在确定更新完成后,发送所述更新后的当前版本的文件信息,其中,所述文件信息中至少包括所述更新后的当前版本的文件的哈希值。
15.如权利要求14所述的装置,其特征在于,进一步包括,检测模块,用于:
若接收到多个所述更新模块发送的所述更新后的当前版本的文件信息;
分别检测每个所述更新后的当前版本的文件信息中的哈希值是否均相同;其中,所述更新后的当前版本的文件信息是所述更新模块在确定更新完成后发送的;
若确定均相同,则发送更新正常消息,若确定不是均相同,则根据预设的异常恢复方法,发送异常恢复指示。
CN201810241049.4A 2018-03-22 2018-03-22 一种分布式文件系统、文件更新方法及装置 Pending CN110334072A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810241049.4A CN110334072A (zh) 2018-03-22 2018-03-22 一种分布式文件系统、文件更新方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810241049.4A CN110334072A (zh) 2018-03-22 2018-03-22 一种分布式文件系统、文件更新方法及装置

Publications (1)

Publication Number Publication Date
CN110334072A true CN110334072A (zh) 2019-10-15

Family

ID=68138799

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810241049.4A Pending CN110334072A (zh) 2018-03-22 2018-03-22 一种分布式文件系统、文件更新方法及装置

Country Status (1)

Country Link
CN (1) CN110334072A (zh)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111310260A (zh) * 2020-01-21 2020-06-19 中国建筑股份有限公司 基于分布式存储架构的bim模型版本存贮转换方法
CN112100152A (zh) * 2020-09-14 2020-12-18 广州华多网络科技有限公司 业务数据处理方法、系统、服务器和可读存储介质
CN112256316A (zh) * 2020-11-13 2021-01-22 北京玩蟹科技有限公司 客户端应用更新方法及客户端
CN112395469A (zh) * 2020-11-27 2021-02-23 中国银联股份有限公司 生物特征存储方法、装置、设备及存储介质
CN113760830A (zh) * 2021-09-22 2021-12-07 国网信息通信产业集团有限公司 一种分布式文件存储可编辑系统和方法
CN114564450A (zh) * 2022-03-04 2022-05-31 北京宇信科技集团股份有限公司 分布式文件系统的处理方法、装置、系统、介质和设备
CN116467037A (zh) * 2023-06-09 2023-07-21 成都融见软件科技有限公司 一种图形用户界面工作状态的恢复方法
CN117112525A (zh) * 2023-08-21 2023-11-24 北京志凌海纳科技有限公司 分布式文件系统及分布式文件系统中维护文件一致性方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140019405A1 (en) * 2012-07-13 2014-01-16 Facebook Inc. Automated failover of a metadata node in a distributed file system
CN103729225A (zh) * 2014-01-22 2014-04-16 中国人民解放军国防科学技术大学 一种基于内容分块的远程文件实时更新方法
CN104731516A (zh) * 2013-12-18 2015-06-24 腾讯科技(深圳)有限公司 一种存取文件的方法、装置及分布式存储系统
CN105718484A (zh) * 2014-12-04 2016-06-29 中兴通讯股份有限公司 写文件、读文件、删除文件、查询文件的方法及客户端
CN107332918A (zh) * 2017-07-07 2017-11-07 上海斐讯数据通信技术有限公司 一种云端‑本地文件同步实现方法及系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140019405A1 (en) * 2012-07-13 2014-01-16 Facebook Inc. Automated failover of a metadata node in a distributed file system
CN104731516A (zh) * 2013-12-18 2015-06-24 腾讯科技(深圳)有限公司 一种存取文件的方法、装置及分布式存储系统
CN103729225A (zh) * 2014-01-22 2014-04-16 中国人民解放军国防科学技术大学 一种基于内容分块的远程文件实时更新方法
CN105718484A (zh) * 2014-12-04 2016-06-29 中兴通讯股份有限公司 写文件、读文件、删除文件、查询文件的方法及客户端
CN107332918A (zh) * 2017-07-07 2017-11-07 上海斐讯数据通信技术有限公司 一种云端‑本地文件同步实现方法及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
战科宇等: "分布式文件系统元数据服务器高可用性设计", 《小型微型计算机系统》 *

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111310260A (zh) * 2020-01-21 2020-06-19 中国建筑股份有限公司 基于分布式存储架构的bim模型版本存贮转换方法
CN112100152A (zh) * 2020-09-14 2020-12-18 广州华多网络科技有限公司 业务数据处理方法、系统、服务器和可读存储介质
CN112256316A (zh) * 2020-11-13 2021-01-22 北京玩蟹科技有限公司 客户端应用更新方法及客户端
CN112395469A (zh) * 2020-11-27 2021-02-23 中国银联股份有限公司 生物特征存储方法、装置、设备及存储介质
CN113760830A (zh) * 2021-09-22 2021-12-07 国网信息通信产业集团有限公司 一种分布式文件存储可编辑系统和方法
CN113760830B (zh) * 2021-09-22 2024-01-30 国网信息通信产业集团有限公司 一种分布式文件存储可编辑系统和方法
CN114564450A (zh) * 2022-03-04 2022-05-31 北京宇信科技集团股份有限公司 分布式文件系统的处理方法、装置、系统、介质和设备
CN116467037A (zh) * 2023-06-09 2023-07-21 成都融见软件科技有限公司 一种图形用户界面工作状态的恢复方法
CN116467037B (zh) * 2023-06-09 2023-09-22 成都融见软件科技有限公司 一种图形用户界面工作状态的恢复方法
CN117112525A (zh) * 2023-08-21 2023-11-24 北京志凌海纳科技有限公司 分布式文件系统及分布式文件系统中维护文件一致性方法

Similar Documents

Publication Publication Date Title
CN110334072A (zh) 一种分布式文件系统、文件更新方法及装置
US20220335034A1 (en) Multi-master architectures for distributed databases
CN109034993A (zh) 对账方法、设备、系统及计算机可读存储介质
CN110784498B (zh) 一种个性化数据容灾方法及装置
CN113254466B (zh) 一种数据处理方法、装置、电子设备和存储介质
CN111459986B (zh) 数据计算系统及方法
CN103973725B (zh) 一种分布式协同方法和协同器
CN102779185A (zh) 一种高可用分布式全文索引方法
CN105653425A (zh) 基于复杂事件处理引擎的监控系统
US10432703B2 (en) On-demand session upgrade in a coordination service
CN105069152A (zh) 数据处理方法及装置
CN109062697A (zh) 一种提供空间分析服务的方法和装置
CN103166980A (zh) 互联网数据拉取方法和系统
CN105872110A (zh) 一种云平台服务管理方法及装置
CN105138691A (zh) 分析用户业务量的方法和系统
CN110099084A (zh) 一种保证存储服务可用性的方法、系统及计算机可读介质
CN108881379A (zh) 一种服务器集群间数据同步的方法和装置
CN113014608A (zh) 一种流量分发控制方法、装置、电子设备及存储介质
CN115665263A (zh) 一种流量调拨方法、装置、服务器及存储介质
CN115238006A (zh) 检索数据同步方法、装置、设备及计算机存储介质
JP2020038421A (ja) ボリューム配置管理装置、ボリューム配置管理方法、及びボリューム配置管理プログラム
CN114945026A (zh) 数据处理方法、装置和系统
CN114584576A (zh) 数据存储方法、装置、设备、存储介质及计算机程序产品
CN113360689A (zh) 图像检索系统、方法、相关装置及计算机程序产品
CN110266564A (zh) 探测装置及其执行的方法、以及控制装置及其执行的方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication

Application publication date: 20191015

RJ01 Rejection of invention patent application after publication