CN104391930A - 分布式文件存储装置和方法 - Google Patents
分布式文件存储装置和方法 Download PDFInfo
- Publication number
- CN104391930A CN104391930A CN201410673276.6A CN201410673276A CN104391930A CN 104391930 A CN104391930 A CN 104391930A CN 201410673276 A CN201410673276 A CN 201410673276A CN 104391930 A CN104391930 A CN 104391930A
- Authority
- CN
- China
- Prior art keywords
- file
- service
- node
- message
- request
- 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
Links
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/18—File system types
- G06F16/182—Distributed file systems
- G06F16/1824—Distributed file systems implemented using Network-attached Storage [NAS] architecture
Abstract
本发明提供了一种分布式文件存储装置，包括：客户端，用于管理应用各个请求以及请求所涉及到的文件；存储节点，用于获取服务请求消息进行与文件相关的各项操作并反馈；资源管理节点，用于保存集群的网络拓扑图和各个存储节点的状态，调整集群的服务侧重点，定期做扫描；分布式消息队列，用于根据请求种类，建立相应的FIFO队列；元数据存储子系统，用于存储各个请求涉及文件的元数据、文件与副本集所在节点的对应关系。本发明还提供了一种分布式文件存储方法。通过本发明的技术方案，可以在现有的文件存储方式基础上，充分利用单对象类型完成多对象类型的文件存储，建立多对象类型参与的面向分布式文件的通用、统一存储思路。
Description
技术领域
本发明涉及计算机技术领域，具体地，涉及一种分布式文件存储装置和一种分布式文件存储方法。
背景技术
当前海量文件存储的需求越来越多，除了高价格的专用存储方案之外，越来越多的IT企业，特别是互联网企业选择了使用廉价的不太可靠的硬件，通过良好的架构设计，来搭建可靠的分布式文件存储系统这种方式来降低成本。如淘宝的TFS，京东的JINGDONG FS，以及开源的FastDFS等。但这样的解决方案大多针对特定的业务和环境，运维困难，面对多样的生产环境，很多时候需要大量的人工干预，无形中在降低了硬件成本的同时，也增加了人工成本，并增加了人工干预不及时而出现问题的可能性。还有，目前的分布式文件系统大多使用了同步存储的方式，客户端和服务端步调需要保持一致，也就是说在某一方操作的时候，另一方需要等待，这无疑浪费了很多宝贵的系统资源。最后，目前的分布式文件系统，大多由一个主节点来管理和分配集群中的所有资源，所有的增、删、改、查询操作都要与主节点进行决策，增加了主节点的压力和出问题的可能性。
因此，需要一种新的文件存储技术，可以在现有的文件存储方式基础上，充分利用单对象类型元数据和文档描述类型完成多对象类型元数据的文件存储，建立多对象类型元数据参与的面向分布式文件存储的通用、统一存储思路。
发明内容
本发明正是基于上述问题，提出了一种新的文件存储技术，可以在现有的文件存储方式基础上，充分利用单对象类型元数据和文档描述类型完成多对象类型元数据的文件存储，建立多对象类型元数据参与的面向分布式文件存储的通用、统一存储思路。
有鉴于此，本发明提出了一种分布式文件存储装置，包括：客户端，用于守护进程，管理应用各个请求以及请求所涉及到的文件，以消息的形式发送服务请求，并接收反馈信息；存储节点，用于获取服务请求消息，基于服务请求消息，进行与文件相关的各项操作并反馈；资源管理节点，用于保存文件的存储节点所构成集群的网络拓扑图和各个存储节点的状态，根据分布式队列每个队列中的积压元素个数调整该集群的服务侧重点，定期对元数据存储子系统的数据做扫描；分布式消息队列，用于根据相应的服务请求的种类，为每个操作建立一个FIFO队列；元数据存储子系统，用于存储各个请求涉及文件的元数据，以及各个请求涉及文件与副本集所在节点的对应关系。在该技术方案中，通过资源管理节点，管理系统的网络拓扑，以及对系统整体负载作出判断，对存储节点的工作进行调节，使其工作量大大降低，避免瓶颈的产生；通过元数据存储子系统也保障了系统的安全和可靠性，为其实现的技术选型提供了更大的空间，可以在云计算环境下实现高性能、高可靠性的海量文件存取。
在上述技术方案中，优选地，所述存储节点进行的与文件相关的各项操作，具体包括：存储文件、判断自身是否具备服务条件、获取能够提供服务存储节点列表、选择服务节点、向客户端提供服务、提供本节点存储文件的列表、判断文件是否损坏并处理、文件副本集操作、调整自身服务策略、合并小文件。在该技术方案中，在应用调用客户端方法后立即返回，无需等待操作结束，从而节省了应用系统的线程资源，客户端也不是一个阻塞线程，因此提升了系统的资源利用率。
在上述技术方案中，优选地，所述客户端，具体包括：服务请求模块，用于管理应用各个请求以及请求所涉及到的文件，以消息的形式发送服务请求；服务接收模块，用于接收相应服务请求的反馈信息。
在上述技术方案中，优选地，所述存储节点，具体包括：获取请求模块，用于主动获取服务请求消息，如果节点自身能够提供服务，则节点自身主动连接客户端提供服务；如果节点自身不能提供服务，则与其他存储节点进行协商，让其他节点为客户端提供服务；协商服务模块，用于如果节点自身不能为客户端提供服务，那么该节点需要知道哪个节点能够为客户端提供服务，这就需要存储节点与元数据存储子系统或者资源管理节点进行沟通，具体的沟通方式与哪种类型的服务相关；获取一个能够提供服务的节点列表，根据需要与其进行沟通，沟通完成后，由有能力提供服务的节点主动连接客户端，为其提供服务；提供服务模块，用于在协商完毕后，最后由能提供服务的节点主动连接客户端，为其提供服务；该服务包括拉取要存储的文件、推送文件、通知删除处理结果；心跳模块，用于定时向资源管理节点发布自己的资源使用情况，能在存储节点无法自己提供服务时，为其寻找协商节点提供依据；也能在元数据存储子系统相应服务能力不足时，通知存储节点把那种类型服务的优先级提高，动态调整集群的服务侧重点，以提升服务能力；同步元数据模块，用于在元数据存储子系统进行包含新增、删除、增加文件复制份数的操作时，存储节点需要将操作后的文件存储状态通知元数据存储子系统将其更新。在该技术方案中，采用基于好莱坞原则的处理方式，能够将操作的压力从主节点平均的转移到各个存储节点，在所有存储节点中分担这些压力，从而避免主节点的性能瓶颈。
在上述技术方案中，优选地，所述资源管理节点，具体包括：网络拓扑图和状态保存模块，用于保存文件的存储节点所构成集群的网络拓扑图和各个存储节点的状态；服务侧重点调整模块，用于根据分布式队列每个队列中的积压元素个数，判断元数据存储子系统在哪种服务上处于瓶颈，通过保存的存储节点状态，计算出对哪些节点的服务侧重点进行调整，改变整个集群的服务侧重点；定期扫描模块，用于定期对元数据存储子系统的数据做扫描，如果有文件缺少副本，就向“文件复制消息队列”中放入消息，消息的数量等于元数据存储子系统要求的复制数量减去目前已有的复制数量；如果一个文件被标记为删除，就向“文件删除消息队列”中放入消息，消息中带有所有保存该文件的存储节点信息；如果文件在元数据存储子系统中没有副本存在，说明此文件已经被删除完成或失效，则删除这条元数据记录；如果文件的副本数量比元数据存储子系统配置的要多，就发出一个删除消息到“文件物理删除消息队列”。在该技术方案中，资源管理节点很像主流分布式文件系统的主节点，但他不负责具体的操作，所以资源消耗也很少，不会造成系统瓶颈。
根据本发明的又一个方面，还提出了一种分布式文件存储方法，包括：步骤202：守护进程，管理应用各个请求以及请求所涉及到的文件，以消息的形式发送服务请求，并接收反馈信息；步骤204：获取服务请求消息，基于服务请求消息，进行与文件相关的各项操作并反馈；步骤206：保存文件的存储节点所构成集群的网络拓扑图和各个存储节点的状态，根据分布式队列每个队列中的积压元素个数调整该集群的服务侧重点，定期对元数据存储子系统的数据做扫描；步骤208：根据相应的服务请求的种类，为每个操作建立一个FIFO队列；步骤210：存储各个请求涉及文件的元数据，以及各个请求涉及文件与副本集所在节点的对应关系。在该技术方案中，通过资源管理节点，管理系统的网络拓扑，以及对系统整体负载作出判断，对存储节点的工作进行调节，使其工作量大大降低，避免瓶颈的产生；通过元数据存储子系统也保障了系统的安全和可靠性，为其实现的技术选型提供了更大的空间，可以在云计算环境下实现高性能、高可靠性的海量文件存取。
在上述技术方案中，优选地，所述步骤204进行的与文件相关的各项操作，具体包括：存储文件、判断自身是否具备服务条件、获取能够提供服务存储节点列表、选择服务节点、向客户端提供服务、提供本节点存储文件的列表、判断文件是否损坏并处理、文件副本集操作、调整自身服务策略、合并小文件。在该技术方案中，在应用调用客户端方法后立即返回，无需等待操作结束，从而节省了应用系统的线程资源，客户端也不是一个阻塞线程，因此提升了系统的资源利用率。
在上述技术方案中，优选地，所述步骤202，具体包括：步骤302：管理应用各个请求以及请求所涉及到的文件，以消息的形式发送服务请求；步骤304：接收相应服务请求的反馈信息。
在上述技术方案中，优选地，所述步骤204，具体包括：步骤402：主动获取服务请求消息，如果节点自身能够提供服务，则节点自身主动连接客户端提供服务；如果节点自身不能提供服务，则与其他存储节点进行协商，让其他节点为客户端提供服务；步骤404：如果节点自身不能为客户端提供服务，那么该节点需要知道哪个节点能够为客户端提供服务，这就需要存储节点与元数据存储子系统或者资源管理节点进行沟通，具体的沟通方式与哪种类型的服务相关；获取一个能够提供服务的节点列表，根据需要与其进行沟通，沟通完成后，由有能力提供服务的节点主动连接客户端，为其提供服务；步骤406：在协商完毕后，最后由能提供服务的节点主动连接客户端，为其提供服务；该服务包括拉取要存储的文件、推送文件、通知删除处理结果；步骤408：定时向资源管理节点发布自己的资源使用情况，能在存储节点无法自己提供服务时，为其寻找协商节点提供依据；也能在元数据存储子系统相应服务能力不足时，通知存储节点把那种类型服务的优先级提高，动态调整集群的服务侧重点，以提升服务能力；步骤410：在元数据存储子系统新增、删除、增加文件复制份数等操作时，存储节点需要将操作后的文件存储状态通知元数据存储子系统将其更新。在该技术方案中，采用基于好莱坞原则的处理方式，能够将操作的压力从主节点平均的转移到各个存储节点，在所有存储节点中分担这些压力，从而避免主节点的性能瓶颈。
在上述技术方案中，优选地，所述步骤206，具体包括：步骤502：保存文件的存储节点所构成集群的网络拓扑图和各个存储节点的状态；步骤504：根据分布式队列每个队列中的积压元素个数，判断元数据存储子系统在哪种服务上处于瓶颈，通过保存的存储节点状态，计算出对哪些节点的服务侧重点进行调整，改变整个集群的服务侧重点；步骤506：定期对元数据存储子系统的数据做扫描，如果有文件缺少副本，就向“文件复制消息队列”中放入消息，消息的数量等于元数据存储子系统要求的复制数量减去目前已有的复制数量；如果一个文件被标记为删除，就向“文件删除消息队列”中放入消息，消息中带有所有保存该文件的存储节点信息；如果文件在元数据存储子系统中没有副本存在，说明此文件已经被删除完成或失效，则删除这条元数据记录；如果文件的副本数量比元数据存储子系统配置的要多，就发出一个删除消息到“文件物理删除消息队列”。在该技术方案中，资源管理节点很像主流分布式文件系统的主节点，但他不负责具体的操作，所以资源消耗也很少，不会造成系统瓶颈。
通过以上技术方案，可以在现有的文件存储方式基础上，充分利用单对象类型元数据和文档描述类型完成多对象类型元数据的文件存储，建立多对象类型元数据参与的面向分布式文件存储的通用、统一存储思路。
附图说明
图1示出了根据本发明的实施例的分布式文件存储装置的框图；
图2示出了根据本发明的实施例的分布式文件存储方法的流程图；
图3示出了根据本发明的实施例的客户端的原理示意图；
图4示出了根据本发明的实施例的存储节点的原理示意图；
图5示出了根据本发明的实施例的资源管理节点的原理示意图；
图6示出了根据本发明的实施例的分布式文件存储装置的系统架构图；
图7示出了根据本发明的实施例的客户端运行的时序图。
具体实施方式
为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。
在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明的保护范围并不受下面公开的具体实施例的限制。
图1示出了根据本发明的实施例的分布式文件存储装置的框图。
如图1所示，根据本发明的实施例的分布式文件存储装置100，包括：客户端102，用于守护进程，管理应用各个请求以及请求所涉及到的文件，以消息的形式发送服务请求，并接收反馈信息；存储节点104，用于获取服务请求消息，基于服务请求消息，进行与文件相关的各项操作并反馈；资源管理节点106，用于保存文件的存储节点所构成集群的网络拓扑图和各个存储节点的状态，根据分布式队列每个队列中的积压元素个数调整该集群的服务侧重点，定期对元数据存储子系统的数据做扫描；分布式消息队列108，用于根据相应的服务请求的种类，为每个操作建立一个FIFO队列；元数据存储子系统110，用于存储各个请求涉及文件的元数据，以及各个请求涉及文件与副本集所在节点的对应关系。在该技术方案中，通过资源管理节点，管理系统的网络拓扑，以及对系统整体负载作出判断，对存储节点的工作进行调节，使其工作量大大降低，避免瓶颈的产生；通过元数据存储子系统也保障了系统的安全和可靠性，为其实现的技术选型提供了更大的空间，可以在云计算环境下实现高性能、高可靠性的海量文件存取。
在上述技术方案中，优选地，存储节点104进行的与文件相关的各项操作，具体包括：存储文件、判断自身是否具备服务条件、获取能够提供服务存储节点列表、选择服务节点、向客户端提供服务、提供本节点存储文件的列表、判断文件是否损坏并处理、文件副本集操作、调整自身服务策略、合并小文件。在该技术方案中，在应用调用客户端方法后立即返回，无需等待操作结束，从而节省了应用系统的线程资源，客户端也不是一个阻塞线程，因此提升了系统的资源利用率。
在上述技术方案中，优选地，客户端102，具体包括：服务请求模块1022，用于管理应用各个请求以及请求所涉及到的文件，以消息的形式发送服务请求；服务接收模块1024，用于接收相应服务请求的反馈信息。
在上述技术方案中，优选地，存储节点104，具体包括：获取请求模块1042，用于主动获取服务请求消息，如果节点自身能够提供服务，则节点自身主动连接客户端提供服务；如果节点自身不能提供服务，则与其他存储节点进行协商，让其他节点为客户端提供服务；协商服务模块1044，用于如果节点自身不能为客户端提供服务，那么该节点需要知道哪个节点能够为客户端提供服务，这就需要存储节点与元数据存储子系统或者资源管理节点进行沟通，具体的沟通方式与哪种类型的服务相关；获取一个能够提供服务的节点列表，根据需要与其进行沟通，沟通完成后，由有能力提供服务的节点主动连接客户端，为其提供服务；提供服务模块1046，用于在协商完毕后，最后由能提供服务的节点主动连接客户端，为其提供服务；该服务包括拉取要存储的文件、推送文件、通知删除处理结果；心跳模块1048，用于定时向资源管理节点发布自己的资源使用情况，能在存储节点无法自己提供服务时，为其寻找协商节点提供依据；也能在元数据存储子系统相应服务能力不足时，通知存储节点把那种类型服务的优先级提高，动态调整集群的服务侧重点，以提升服务能力；同步元数据模块1050，用于在元数据存储子系统进行包含新增、删除、增加文件复制份数的操作时，存储节点需要将操作后的文件存储状态通知元数据存储子系统将其更新。在该技术方案中，采用基于好莱坞原则的处理方式，能够将操作的压力从主节点平均的转移到各个存储节点，在所有存储节点中分担这些压力，从而避免主节点的性能瓶颈。
在上述技术方案中，优选地，资源管理节点106，具体包括：网络拓扑图和状态保存模块1062，用于保存文件的存储节点所构成集群的网络拓扑图和各个存储节点的状态；服务侧重点调整模块1064，用于根据分布式队列每个队列中的积压元素个数，判断元数据存储子系统在哪种服务上处于瓶颈，通过保存的存储节点状态，计算出对哪些节点的服务侧重点进行调整，改变整个集群的服务侧重点；定期扫描模块1066，用于定期对元数据存储子系统的数据做扫描，如果有文件缺少副本，就向“文件复制消息队列”中放入消息，消息的数量等于元数据存储子系统要求的复制数量减去目前已有的复制数量；如果一个文件被标记为删除，就向“文件删除消息队列”中放入消息，消息中带有所有保存该文件的存储节点信息；如果文件在元数据存储子系统中没有副本存在，说明此文件已经被删除完成或失效，则删除这条元数据记录；如果文件的副本数量比元数据存储子系统配置的要多，就发出一个删除消息到“文件物理删除消息队列”。在该技术方案中，资源管理节点很像主流分布式文件系统的主节点，但他不负责具体的操作，所以资源消耗也很少，不会造成系统瓶颈。
图2示出了根据本发明的实施例的分布式文件存储方法的流程图。
如图2所示，根据本发明的实施例的分布式文件存储方法，包括：步骤202：守护进程，管理应用各个请求以及请求所涉及到的文件，以消息的形式发送服务请求，并接收反馈信息；步骤204：获取服务请求消息，基于服务请求消息，进行与文件相关的各项操作并反馈；步骤206：保存文件的存储节点所构成集群的网络拓扑图和各个存储节点的状态，根据分布式队列每个队列中的积压元素个数调整该集群的服务侧重点，定期对元数据存储子系统的数据做扫描；步骤208：根据相应的服务请求的种类，为每个操作建立一个FIFO队列；步骤210：存储各个请求涉及文件的元数据，以及各个请求涉及文件与副本集所在节点的对应关系。在该技术方案中，通过资源管理节点，管理系统的网络拓扑，以及对系统整体负载作出判断，对存储节点的工作进行调节，使其工作量大大降低，避免瓶颈的产生；通过元数据存储子系统也保障了系统的安全和可靠性，为其实现的技术选型提供了更大的空间，可以在云计算环境下实现高性能、高可靠性的海量文件存取。
在上述技术方案中，优选地，步骤204进行的与文件相关的各项操作，具体包括：存储文件、判断自身是否具备服务条件、获取能够提供服务存储节点列表、选择服务节点、向客户端提供服务、提供本节点存储文件的列表、判断文件是否损坏并处理、文件副本集操作、调整自身服务策略、合并小文件。在该技术方案中，在应用调用客户端方法后立即返回，无需等待操作结束，从而节省了应用系统的线程资源，客户端也不是一个阻塞线程，因此提升了系统的资源利用率。
在上述技术方案中，优选地，如图3所示，步骤202，具体包括：步骤302：管理应用各个请求以及请求所涉及到的文件，以消息的形式发送服务请求；步骤304：接收相应服务请求的反馈信息。
在上述技术方案中，优选地，如图4所示，步骤204，具体包括：步骤402：主动获取服务请求消息，如果节点自身能够提供服务，则节点自身主动连接客户端提供服务；如果节点自身不能提供服务，则与其他存储节点进行协商，让其他节点为客户端提供服务；步骤404：如果节点自身不能为客户端提供服务，那么该节点需要知道哪个节点能够为客户端提供服务，这就需要存储节点与元数据存储子系统或者资源管理节点进行沟通，具体的沟通方式与哪种类型的服务相关；获取一个能够提供服务的节点列表，根据需要与其进行沟通，沟通完成后，由有能力提供服务的节点主动连接客户端，为其提供服务；步骤406：在协商完毕后，最后由能提供服务的节点主动连接客户端，为其提供服务；该服务包括拉取要存储的文件、推送文件、通知删除处理结果；步骤408：定时向资源管理节点发布自己的资源使用情况，能在存储节点无法自己提供服务时，为其寻找协商节点提供依据；也能在元数据存储子系统相应服务能力不足时，通知存储节点把那种类型服务的优先级提高，动态调整集群的服务侧重点，以提升服务能力；步骤410：在元数据存储子系统新增、删除、增加文件复制份数等操作时，存储节点需要将操作后的文件存储状态通知元数据存储子系统将其更新。在该技术方案中，采用基于好莱坞原则的处理方式，能够将操作的压力从主节点平均的转移到各个存储节点，在所有存储节点中分担这些压力，从而避免主节点的性能瓶颈。
在上述技术方案中，优选地，如图5所示，步骤206，具体包括：步骤502：保存文件的存储节点所构成集群的网络拓扑图和各个存储节点的状态；步骤504：根据分布式队列每个队列中的积压元素个数，判断元数据存储子系统在哪种服务上处于瓶颈，通过保存的存储节点状态，计算出对哪些节点的服务侧重点进行调整，改变整个集群的服务侧重点；步骤506：定期对元数据存储子系统的数据做扫描，如果有文件缺少副本，就向“文件复制消息队列”中放入消息，消息的数量等于元数据存储子系统要求的复制数量减去目前已有的复制数量；如果一个文件被标记为删除，就向“文件删除消息队列”中放入消息，消息中带有所有保存该文件的存储节点信息；如果文件在元数据存储子系统中没有副本存在，说明此文件已经被删除完成或失效，则删除这条元数据记录；如果文件的副本数量比元数据存储子系统配置的要多，就发出一个删除消息到“文件物理删除消息队列”。在该技术方案中，资源管理节点很像主流分布式文件系统的主节点，但他不负责具体的操作，所以资源消耗也很少，不会造成系统瓶颈。
本发明的技术方案，提供了一种基于好莱坞原则的分布式文件存储系统架构，可以用于在云计算环境下实现高性能、高可靠性的海量文件存取。
本发明的技术方案，基于现有技术中提出的问题，计划在新的架构中，对下面三点做重点改进：
⑴以存储节点为核心，使其具备根据自身资源使用情况，动态调整自身服务策略的能力，并通过一个资源管理节点根据系统的运作情况对存储节点的服务策略进行微调，将系统服务质量和资源使用策略挂钩，动态调整，减少运维人员的参与程度；
⑵对于应用系统，使用异步非阻塞的方式进行操作，降低应用程序资源使用；
⑶降低主节点计算压力，提升系统性能和可用性。
本发明技术方案中，“Don’t call us，we’ll call you”，这就是著名的好莱坞原则。在软件工程中，“控制反转”（IOC）作为对这个原则的应用被广大IT人所熟知，在著名的Springframework中，所有组件的生命周期管理都由容器来负责，因此应用能够在透明的情况下，得到想要的组件为其服务，从而为更换服务组件提供了极大的灵活性。在本发明中，也是通过这种“主动权移交”的方式，在应用发出服务请求后，由系统选择服务节点，主动找到应用为其提供服务。这种方式有这样几个好处：1）选择最适合的服务节点，提升服务质量；2）主动权在系统，可以在某些极端情况下调整服务策略，提高系统的可用性；3）这种方式对于应用来说具有天然的异步非阻塞的特性，减少了应用系统资源利用。下面对这个架构设计做一个比较详细的介绍。
由图6可知，本架构的基本运作流程包括下面几个步骤：
⑴服务请求：客户端以消息的形式发送服务请求到分布式消息队列。当然，从下面的介绍可知，服务请求不一定由客户端发出，也可以由系统内部发出。
⑵获取请求：存储节点主动获取消息，如果自己能够提供服务，则自己主动连接客户端提供服务；如果自己不能提供服务，则与其他存储节点进行协商，让其他节点为客户端提供服务。
⑶协商服务：如果节点自身不能为客户端提供服务，那么该节点需要知道哪个节点能够为客户端提供服务，这就需要存储节点与元数据存储子系统或者资源管理节点进行沟通，具体的沟通方式与哪种类型的服务相关。获取一个能够提供服务的节点列表，根据需要与其进行沟通，沟通完成后，由有能力提供服务的节点主动连接客户端，为其提供服务。
⑷提供服务：在协商完毕后，最后由能提供服务的节点主动连接客户端，为其提供服务。该服务可能是：拉取要存储的文件、推送文件、通知删除处理结果等。
⑸心跳：存储节点定时向资源管理节点发布自己的资源使用情况，可以在存储节点无法自己提供服务时，为其寻找协商节点提供依据。也可以在系统某方面服务能力不足时，通知存储节点把那种类型服务的优先级提高，动态调整集群的服务侧重点，以提升服务能力。
⑹同步元数据：在系统新增、删除、增加文件复制份数等操作时，存储节点需要将操作后的文件存储状态通知元数据存储子系统将其更新。元数据存储的结构应该能够满足通过文件id查找存储该文件的所有存储节点列表的要求，同时也要能够通过存储节点名称，查找其下所有文件的功能，这在存储节点失效的情况下进行增加文件副本的操作中是很有用的。
下面介绍一下组成系统的几个子系统和组件：
⑴客户端
在本发明中，客户端是一个守护进程，负责管理应用发往系统的各个请求以及请求所涉及到的文件。比如，要上传文件的话，客户端的接口应该是这样的：
String upload(String path, GetFile(String path), SuccessBack(String fileId), FailBack(Exception e));
其中GetFile()是获取操作文件的方法，在调用upload方法后，应用实际上只是向文件系统发出了一个异步消息，客户端还需要等待存储结点主动来取走文件，因此应用需要提供一个获取文件的方法，能够通过传入的文件路径获取该文件。上面的例子是在语言不提供闭包的情况下的做法，如果提供闭包，可以直接把文件路径放在GetFile函数中即可。在应用调用完上传方法后，会得到一个任务id，应用可以通过这个id调用状态查询方法，实时获取任务状态。在上传任务完成后，如果成功，客户端会调用SuccessBack回调方法执行后续操作，并传回一个file id，应用需要记录这个id，以后要获取文件的时候需要使用这个id；如果失败就回调FailBack方法，并传回一个异常对象。当然应用也可以不指定成功和失败的回调方法，直接通过调用任务状态查询方法来查询文件上传的进度和是否成功的状态，这在需要知道上传进度和非实时上传的需求中是很有用的。
上面是对客户端操作用上传文件为例做的描述，下面用时序图（即图2）来说明客户端的运行流程。
从图7可以看出，在应用调用客户端方法后立即返回，无需等待操作结束，从而节省了应用系统的线程资源，客户端也不是一个阻塞线程，因此提升了系统的资源利用率。
⑵存储节点
存储节点是本系统的核心。在当前的主流分布式文件系统，如HDFS中，跟文件系统元数据相关的操作大都在主节点中进行，这样就可能在服务高峰期遇到单点的瓶颈，本发明中基于好莱坞原则的处理方式，能够将操作的压力从主节点平均的转移到各个存储节点，在所有存储节点中分担这些压力，从而避免主节点的性能瓶颈。
存储节点除了具有存储文件的功能之外，还要担负起获取服务请求消息、判断自身是否具备服务条件、获取能够提供服务存储节点列表、选择服务节点、向客户端提供服务、提供本节点存储文件的列表、判断文件是否损坏并处理、文件副本集操作、调整自身服务策略、合并小文件等大部分与文件系统核心功能相关的各项操作。针对每个操作的具体说明会在系统流程说明部分进行介绍。
存储节点不将大文件分为小块进行存储，因此保存的文件大小不能超过一个磁盘的容量，因为本系统不是为数据计算准备，因此基本不会发生超大文件的情况。让操作系统直接管理其IO也有助于提升性能。对于海量的小文件，会将其合并为一个大文件，这在下面的“海量小文件的处理”章节中介绍。
存储节点提供的服务应该包括“上传文件”、“删除文件”、“下载文件”、“复制文件”、“获取文件状态”等操作。这些操作都是针对应用来说的，所以在这里“上传文件”是指从应用来的文件保存到存储节点的过程，对于存储节点来说，这个过程可能更像“下载”，但为了保持统一，我们所说的具体操作都已应用为主体。有多少种服务，就应该有多少个分布式队列与其对应，针对这些队列消息的获取，存储节点会根据自身状况做一个优先级的排列，通过调整这个优先级来调整该节点的服务侧重。例如，如果存储节点磁盘空间超过了警戒线，那么他就不应该再从“上传文件消息队列”和“文件复制消息队列”获取消息了；当分布式队列中上传文件队列消息积压过多，资源管理节点应该通过心跳告诉某些存储节点把服务重点放在处理文件上传上，而这些存储节点应该调整自己的服务侧重，专注于上传服务。服务策略的调整会在服务流程章节进行介绍。
此外，存储节点将其自身存储的文件列表保存在内存中，以提高外部的“节点存储文件”查询的响应速度。存储节点也可以通过这个列表检查本身存储文件的完整性，如果有文件损坏，就会做相应的处理。如果存储节点重新启动，会首先从磁盘恢复这个列表，然后与元数据存储子系统的数据做比对，以检查存储文件的完整性。
如果集群规模不大，存储节点也可以通过心跳获取整个集群的视图，其中包括其他存储节点的资源使用信息，这样就不用到资源管理节点中查找符合服务要求的节点，在自身的内存中就可判断了。
为了提升系统的响应时间，存储节点可以将一部分热数据放在缓存中，以提升响应速度。
⑶资源管理节点
资源管理节点应具有的功能如下：
1）保存集群的网络拓扑图，和各个存储节点的状态，供存储节点协商服务时找到满足服务要求的存储节点。
2）根据分布式队列每个队列中的积压元素个数，来判断目前系统在哪种服务上处于瓶颈，通过保存的存储节点状态，来计算出对哪些节点的服务侧重点进行调整，从而改变整个集群的服务侧重点。这种自动调节的方式能够减少人工干预，降低运维成本。
3）定期对元数据存储子系统的数据做扫描，如果有文件缺少副本，就像“文件复制消息队列”中放入消息，消息的数量等于系统要求的复制数量减去目前已有的复制数量；如果一个文件被标记为删除，就向“文件删除消息队列”中放入消息，消息中带有所有保存该文件的存储节点信息；如果文件在系统中没有副本存在，说明此文件已经被删除完成或失效，则删除这条元数据记录；如果文件的副本数量比系统配置的要多，就发出一个删除消息到“文件物理删除消息队列”。
从上面的功能可以看出，资源管理节点很像主流分布式文件系统的主节点，但他不负责具体的操作，所以资源消耗也很少，不会造成系统瓶颈。另外他的职能不包括任何持久化数据的部分，可以实时的从系统其他部分获取，例如：网络拓扑图可以随存储节点的心跳和元数据存储节点收集、系统运作情况可以实时的从分布式队列获得、文件操作的数据都是存放在元数据存储子系统中。因此一旦它出了问题，切换也是非常简单的，不需要同步任何数据，只需要在另外一台机器上启动一个实例即可。这个热备的过程用自动化实现也非常简单，例如zookeeper就可以很好的完成这个工作。
⑷分布式消息队列
根据系统提供的服务种类，为每个操作建立一个FIFO队列。如果系统运转良好，那么每个队列中的消息数应该不会太多，如果超过了一定数量，或者某个消息在队列中的时间过长，说明系统在某个服务上遇到了瓶颈，资源管理节点会通过这个判断对系统的服务策略进行调整。
因为应用可能有实时性需求，队列需要为每个消息设置一个超时机制，在消息进入队列时，要扫描其接收到的时间，消息中还要带有应用设置的超时时间，在超时情况发生时，队列应该向客户端返回一个超时异常，并将消息从队列中移除。如果应用没有设置超时，则一直保留在队列中直到被处理，这在系统内部消息中是非常有用的。例如文件物理删除消息，删除操作是异步操作，采用先标记，后由资源管理节点扫描元数据，针对标记为删除的文件发出消息。在文件被标记为删除后，客户端实际上已经无法获取该文件了，因此在系统繁忙时，可以先处理“上传”、“下载”等对实时性有要求的操作，像删除物理文件这种系统发起的操作可以延后再处理，“删除”消息也就可以长时间的保持在队列中，等系统不忙的时候再做处理。可以看得出来，这种超时的机制也是异步的，没有任何其他程序在超时的过程中处于“等待”状态，从而也节省了系统资源。
另外，分布式消息队列应该对外提供查询接口，这个查询接口的主要用户是资源管理节点，提供队列的运行状态，供资源管理节点判断目前整个系统的运作情况，调整运行策略。
⑸元数据存储子系统
该子系统存储着文件的元数据，以及文件与副本集所在节点的对应关系。存储的结构应该适应两种查询方式：1）通过文件id查找所有副本所在存储节点；2）通过存储节点名称查找其上存储的所有文件。第一种操作主要为获取文件服务使用；第二种操作是在存储节点检查自身存储数据完整性，以及资源管理节点进行整个系统的文件完整性校验中使用。
存储节点存储文件时，应提供两种存储结构，一种适用于文件直接存放在存储节点中的情况，一种适用于小文件作为某个大文件（下称文件块）的一部分存在于存储节点中的情况。这是本系统对于单机存在海量小文件存储的一种优化方式，在系统不是很繁忙的时候，对小文件进行整合，整合后变更其元数据存储子系统中的数据结构，用新的文件块id加上原来的小文件id作为标识，新的文件块会在头部有一个索引，用于标识小文件在文件块中的位置。
下面对系统的一些处理流程和策略进行介绍：
⑴系统服务运行时策略
本系统的文件存储使用简单的key-file方式，目前大部分互联网公司的文件存储系统，像阿里的TFS、京东的JINGDONG FS，以及应用比较广泛的开源的FastDFS等都采用了这种方式。这种方式的好处是存储方式简单，操作便捷，性能优越。如果想要更复杂的，例如目录式的树形结构，可以在应用层增加逻辑，例如通过扩展Hadoop Filesystem的方式对其进行扩展。
系统的操作分为用户操作、系统操作和运维操作三种。用户操作包括：上传文件、下载文件、删除文件；系统操作包括：新增副本、物理删除文件；运维操作包括：存储节点完整性校验、文件元数据校验、节点失效处理、海量小文件处理、文件损坏处理、集群扩容等操作。其中用户操作和系统操作是通过消息传递给存储节点的，用户操作由应用方的客户端发送，系统操作由系统内部的子系统发送。而运维操作是针对系统运行状况进行自动化处理的一些策略，它会利用系统操作来完成。系统在通常情况下采用用户操作优先级大于系统操作优先级的策略，但可以通过一些策略进行微调，因为有些由运维操作产生的系统操作会影响系统数据的完整性，所以还是应该在保证应用实时性的基础上，适当提高系统操作的优先级。
系统的优先级采用对某个服务队列消息的获取次数占比的大小来表示，用该服务的优先级数值除以所有服务优先级数值之和再乘以100，即为该存储节点执行100个服务里面，该服务所占的个数。系统存储节点服务能力之和是一定的，一种服务的供给量多，那么为其他服务分配的供给量就少。例如起初如果集群对每个服务采用平均优先级的方式，突然上传文件的服务请求突然增加，那么服务请求可能会在队列里造成积压，在队列中等待的时间越长，就会导致系统对应用请求的响应时间越长，这时资源管理节点就会感知这种情况，选出一些节点把处理上传服务的优先级提升，就会加快上传服务消息的消费，从而提升响应时间。相反，如果新增服务消息在队列中的时间与预期的少，就可以把其他服务的优先级提升，在保证响应时间的同时，提升其他服务的速度。
另外，最好对每种操作所消耗的资源对系统性能的影响做一个评估，在处理某种服务过多导致资源下降到警戒值时就应该降低这种服务的优先级。
最了解存储节点运作情况的还是存储节点自己，因此，存储节点的服务处理优先级还是要以存储节点自身的判断为主。例如，当磁盘空间不足时，就应该将文件上传服务的优先级锁定为0，即使资源管理节点因为心跳的延时，给出提升文件上传服务优先级的建议后，也不应该对其作出响应。
这里给出了如何设计优先级策略的一些基本方法，具体该如何做，还需要在设计阶段分门别类的给出。
还有一点要说明的是，存储节点除了本身从分布式队列中获取的消息之外，还可能接受其他存储节点发送的协商消息，协商消息是无法拒绝的，因此存储节点的资源不能处于过载状态，需要通过调整线程池数量、减少单位时间允许处理最大服务数等手段减少单位时间内的服务供给量，空出一定的资源以备不时之需。空出一部分资源一方面能为协商消息所使用，也可以保障服务质量。
⑵文件上传
在文件上传操作中，如果节点本身具有足够的存储空间，就会按照节点自身的优先级数值，按一定比例在“文件上传消息队列”中获取消息，如果自身磁盘空间不足，就会修改自身的服务策略，不再从“文件上传消息队列”和“文件复制消息队列”中获取消息，而只从删除、获取文件等队列中获取消息。这个关于磁盘空间的数据存储节点要在每个文件操作后在内存中更新，也要在发送心跳包时发送给资源管理节点。
“文件上传消息”应该包括客户端信息、文件的大小和其他元数据。一般来说，只要能够从“上传消息队列”中获取消息，说明存储节点本身具有足够的剩余空间，但也可能发生剩余磁盘空间小于上传文件大小的情况。为了性能考虑，也为了给处理小文件合并流出额外的磁盘空间，存储节点应该设置磁盘空间的两个警戒线：第一个值为预警值，如果超过了这个值，就把上传和复制文件服务的优先级锁定为0,；第二个值为最小剩余空间值，如果当前剩余空间大小减去要上传文件的大小的值小于这个值，就不为客户端提供服务，通过协商找到另外的存储节点为其提供服务。协商的策略是通过找到其他符合条件的存储节点，即没有达到第一个警戒值，存储文件后也没有超过第二个警戒值的存储节点，把文件上传消息直接发送给它，并且这个存储节点不能拒绝这个消息，如果发生资源管理节点信息延迟，导致第二个节点收到消息后，已经处于不满足服务要求的状态，它再通过相同的方法传递给第三个存储节点。在查找满足条件的节点时，如果找不到，就主动连接客户端，向其抛出文件过大，无法存储的异常。找到协商节点的方式可能通过两种，需要根据系统部署的环境而定，一是大规模集群，节点太多，存储节点无法将所有网络拓扑存储在本地内存中，就在资源管理节点上发布一个获取协商节点的服务，通过资源管理节点计算得出；如果集群规模不大，每个存储节点都可以保存整个网络拓扑，就在本身节点计算就行了，存储节点本身存储的集群拓扑图是在发往资源管理节点的心跳中返回的。当然，如果寻找协商节点的过程一直进行下去，客户端等待的时间过长也是不好的，因此系统可以设定一个跳跃最大次数，超过这个次数，就向客户端报告超时异常，这种情况发生的几率应该很小。
在存储文件元数据时，根据需求的不同，元数据的存储也可以采用不同的形式。在需要根据元数据查询文件时，元数据存储子系统应该选择能够针对元数据字段建立索引，将文件的元数据存储在元数据存储子系统中。如果只是要求通过id获取文件，可以将元数据存储放在源文件的头部，一起存储在存储节点中，实际上目前互联网企业的大部分针对文件存储的需求都是后一种。
为了校验数据完整性，需要为文件选择一种摘要算法，如MD5，也将其校验值连同元数据一起，存储在整个文件的头部。
⑶文件下载
文件下载即把文件从存储节点传送给客户端的过程，由于是存储节点主动连接客户端，对于存储节点来说，这更像是一个“文件上传”过程。同样，文件下载首先要存储节点从“文件下载消息队列”中获得消息，这个消息应该包含客户端信息和文件的id，用于让存储节点找到客户端，并将文件传送给它。
与文件上传不同，文件下载过程中，取得的文件id通常不在本节点，这时就需要通过查询元数据存储子系统来获得保存该文件的存储节点列表。因为存储节点随时都会保留一部分资源为“协商消息”服务，因此不必再检查其资源使用情况，挑选出一个节点，直接将消息发送给它既可。
由于存储方式的不同（原始文件或被合并的小文件），消息所传递的参数可能被更改，就是改成文件块id加小文件id的形式。
持有该文件的存储节点根据文件id的形式，获取文件，并解析出其校验码和元数据，如果校验成功，就把文件和元数据一起发送给客户端；如果文件校验失败，说明文件损坏了，这时要经过一个处理文件损坏的流程来处理。这个流程是这样的：首先修改元数据存储子系统的数据，在文件存储节点列表中，将自己的名称删除，然后找到另一个节点，把消息发送出去，然后再删除本地文件。由于可能发生该文件所有副本全部损坏的情况，所以该节点先不发出复制该文件的消息；二是在消息中的“损坏文件个数”加1，待下一个持有该文件的节点来处理，如果下一个节点中的文件依然损坏，那么该节点再找到剩余的持有该文件的节点，并把“损坏文件个数”加1，再次发送出去。如果到最后，所有该文件的副本都损坏了，那么就向客户端抛出“文件损坏”异常，然后将该文件在元数据存储子系统中的记录置为“损坏”。如果后续节点的文件完好，就把文件发送给响应的客户端，并向“文件复制消息队列”队列发出“损坏文件个数”这么多个消息。“文件复制消息”请见下面的“新增副本”章节。
为了在下载文件时起到负载均衡的作用，获取消息的存储节点在获取持有该文件的存储节点列表后，需要随机从n个节点中选一个，而不是按某个固定规则选取。
还需要考虑一种情况，就是要下载的文件就在拿到消息的存储节点中，这时不能直接将文件发送出去，因为要发送的文件可能已经被删除，由于系统采用异步删除的方式，删除只是在元数据存储子系统中加了一个标记，存储节点上的文件可能还存在。所以这种情况需要查询一下元数据存储子系统，该文件是否被删除，如果被删除，就抛出“文件不存在”异常。没有被删除，才将文件发出。
⑷新增副本
在文件上传后，需要为其增加副本份数，以保证文件的高可用。
在一个存储节点保存了文件之后，就要向“文件复制消息队列”发送文件复制消息。这个消息应该包含文件id和本节点名称，那样在复制机器拿到消息后，就知道该到哪个存储节点去取数据，而不用查询元数据存储子系统了。
一般一个集群中文件的复制份数一般是三份或三份以上，因此有可能发生文件复制消息被源节点拿到的情况，因此需要指定一个策略降低这样的可能性。可以采取的策略是，文件复制队列的个数是文件复制份数减1，在新增文件后，将文件复制消息每个队列发送一个，然后每个存储节点只固定到其中一个队列中取消息。但是这样并不能100%阻止源节点拿到复制消息，如果真的源文件节点拿到了消息，就直接通过协商将消息直接发送给一个符合存储条件的节点。这个协商的过程跟上传文件的过程是一样的。再次发出的协商消息会加上源文件节点的名称，如果接收协商消息的节点依然有这个文件，会重复这个过程，找到一个节点并将消息发送出去，只是在筛选节点时会排除之前的节点，并将该消息中加上自己的名称。
为什么不直接通过协商的方式把消息给满足条件的节点呢？主要是考虑到延迟复制的策略，这样可以在系统负载过大的情况下，暂不把服务供给量分给新增副本操作，而提升其他服务的质量。当然了，如果担心在此期间文件损坏，要求以最快的速度增加副本，还可以采取以下两种方式：1）在上传成功反馈给客户端后，立即将复制消息以协商的方式发送给满足条件的节点；2）先通过协商的方式让其他存储节点将文件复制并反馈后，再给客户端反馈，这样就能保证强一致性。第二种方式在实现上可以模仿HDFS的操作方式，以数据流的方式将文件传递到其他节点后再返回。
在完成了复制过程后，存储节点需要将新增文件的数据同步到元数据存储子系统中。
⑸删除文件
删除文件采用异步的方式，即先在元数据存储子系统中对该文件加一个“已删除”标记，等到资源管理节点校验文件系统完整性的时候，看到有删除标记的文件，再做物理删除。
这个操作可能由客户端直接连接元数据存储子系统来操作，也可能采用客户端向“文件删除消息队列”发出消息，再由存储节点获取消息并修改文件元数据的方式来完成。为了提升系统的安全性，最好不要让客户端直接访问到元数据存储子系统，所以最好采用后一种方式。
文件删除消息只需要包含文件的id即可。
⑹存储节点的完整性校验
在当前主流分布式文件系统中，数据存储节点一般是把自己拥有的文件或块上报给主节点，由主节点来判断该集群中文件的完整性。在本发明中，这个过程分两个步骤来完成，一是由存储节点发起的校验本地文件是否完好，然后与文件元数据存储子系统存储的元数据进行比对，按照本地存储文件的实际情况同步文件元数据存储子系统；二是由资源管理节点发起的，根据集群中完整的元数据校验来检查文件的完整性，以及备份数是否满足系统的备份策略等。
存储节点的文件完整性校验应该在系统启动时进行一次，之后存储节点应该根据自身的资源使用情况在负载比较低的时候来执行。硬件的可靠性是比较高的，因此也不需要太过频繁的执行这个操作，在低负载时执行的策略基础上，还应该加上“每小时最多执行一次”这样的限制。如果一个存储节点太长时间没有执行这个操作，那么他应该降低其对其他服务的供给量，主动降低负载，来执行完整性校验。
为了让完整性校验和造成文件增减的操作不互相干扰，应该在完整性校验期间停止文件上传、复制、物理删除等操作。如果在同一时间进行完整性校验的存储节点数量过多，也可能影响系统整体对服务的供给量，其中影响最大的是文件上传操作，因为这是直接对用户提供的服务，应该保证其质量。所以资源管理节点应该能够根据文件上传服务的需求量，来调节同时进行完整性校验操作的存储节点数量，强制其退出完整性校验过程。同时存储节点也应该将进入完整性校验的状态及时通过心跳发送给资源管理节点，并通过以后的心跳实时报告其执行进度。
首先，存储节点应该扫描本机存储的所有文件和文件块，并在内存中形成一个内存视图。因为在加载内存视图时，校验过程可能被强制退出，所以这时原来的视图还需要保留，以对外提供查询节点中文件列表的服务。在视图加载完成后，实际上这就是该节点的最新状态了，就可以将服务切换到新的内存视图上，把原来的视图移除。
加载完内存视图后，需要对每个文件进行文件是否损坏的校验，并对内存视图中的文件进行标记。
标记完成后，需要从元数据存储子系统获取一个本机所有文件列表的数据。
并对每一个文件进行比对。如果本机有的文件，元数据存储子系统中没有，就在元数据存储中增加本机的副本记录；如果本机没有，而元数据存储中有，就删除在元数据存储中的副本记录；如果本机文件损坏，按照本机没有处理，这时不需要进行文件副本增加的操作，因为可能与其他节点的操作重叠，留给资源管理节点校验整体元数据完整性的时候再做处理。
进度表示可以分为三部分，一是加载内存视图，二是文件校验，三是元数据校验。第一部分工作量较少，可以占10%的比重；第二和第三部分各占45%，由于已经知道了文件的数量，因此可以使用已完成文件数量比上文件总数来表示执行进度。
⑺文件元数据校验
该流程是由资源管理节点发起，在前面的存储节点发起的文件完整性校验可以保证元数据和实际存储的文件之间的正确性。通过对元数据整体的完整性校验，可以确保系统的文件存储策略的正确执行。在校验期间，会执行变更副本数量、异步删除物理存储的文件等操作。
这个过程应该是针对每一个文件进行的，资源管理节点按顺序扫描元数据存储中记录的所有文件，至于扫描过后重新插入到前头的记录，可以先不管，等下一次执行的时候再对其进行校验。
首先取出一条记录，检查其副本数量是否与系统设置的一样，如果存在副本数量多，就向“物理删除文件消息队列”中发出一个消息，这里也可以采用直接通过心跳将删除文件的命令发送给存储节点，存储节点完成删除后，从元数据存储中把副本所在节点列表中把自己删除的方法，但这样物理删除文件的操作会占用存储节点为处理协商消息而空出的资源，脱离了系统整体的资源管理框架之外，可能会影响其他服务的质量，所以建议使用比较复杂，但能更好的管理系统整体服务质量的方法，既发送消息的方法。
如果存在副本的数量不足，就像“文件复制消息队列”中发送消息，增加副本数量。如果文件不存在副本，说明此文件已失效，简单将其删除。如果文件被标记为“已删除”，则向“物理删除文件消息队列”发送消息，将文件从存储节点中删除，但这时还不能将元数据删除，因为物理删除可能会失败，元数据还要作为将来再次执行删除的依据。需要说明的是只需要发出一个物理删除文件的消息即可，消息中包含所有要删除数据的存储节点和文件id。
按照这个过程依次扫描系统中所有的文件元数据，直到完成最后一个结束退出。资源管理节点压力应该是不大的，因此这个扫做可以定时执行，不需要根据本身的资源做太多的参考。但在系统负载大的时候，元数据存储子系统的压力可能是很大的，因此还需要参考元数据存储子系统的负载来判断是否执行此操作。
如何判断元数据存储子系统的压力是否过大呢？可以总结一下系统中每个服务需要调用元数据存储的数目，通过分布式队列中单位时间内消费这些操作的数量来计算出元数据存储子系统单位时间内的操作次数，来判断其负载大小。
⑻节点失效
在存储节点失效时，其上存储的文件在系统中的备份数量就会下降，因此应该将这些文件进行新增副本数量的操作。
节点失效是通过存储节点是否向资源管理节点发送心跳，由资源管理节点来判断的，系统可以设置一个节点失效超时时间，超过这个时间资源管理节点没有收到心跳，就判定其为失效。
资源管理节点中的网络拓扑图的数据来源应该有两个：一是元数据存储节点中所有存储文件的节点名称；二是集群中可能存在还没有存储文件的节点，也会发出心跳，资源管理节点也要把这样的存储节点纳入到拓扑图中。一旦将节点纳入到拓扑管理，就应该将其作为节点是否失效的判断依据来使用。
当某个节点被判定为失效后，就应该立刻扫描元数据存储中该节点所存储文件的信息。针对每一个文件，如果该文件的副本只有失效节点，那么设置该文件状态为失效，并不删除，因为也有可能在节点失效前，文件复制已经完成，只是存储节点还没来得及同步到元数据存储中，等元数据同步过来后，还需要将文件状态设置为正常；如果还有其他的存储节点存储着副本，就向“文件复制消息队列”中发出一个消息，新增这个文件的副本；如果该文件的副本数量已经满足要求，就只把失效节点从存储节点列表中删除；如果文件被设置为“已删除”，也是只把失效节点从存储节点列表中删除，待将来的元数据完整性校验时再做物理删除。
如果将来失效的节点会重新启用了，就开启“存储节点的文件完整性校验”流程来处理。
⑼海量小文件
单个存储节点上存在的海量小文件可能产生过多的磁盘碎片，降低磁盘的IO性能，因此本系统也对如何处理海量小文件提出了解决方案。
首先需要定义什么是小文件？文件系统中存储的文件大小各异，可能存在上百兆，甚至上G大小的文件；也有可能大多是几K到几十K这样大小的文件。对于大文件，系统不需要额外处理它；对于小文件就需要将多个合并为一个大文件，获取它的时候采用二级索引，首先找到大文件，再通过文件中的索引找到小文件。可以采用的策略是设置一个判断是大文件还是小文件的边界值，例如128K，那么小于128K的文件我们就要对其进行合并处理。还需要设置一个合并后文件的大小范围，这个范围应该大于判断文件大小的边界值乘以2，并小于一个比较大的值。例如只要小文件合并后尺寸大于256K，小于128M，就可以将其合并。当然256K可能太小了，因此可以设置其值为64M-128M，也就是说小文件合并后的文件尺寸不能小于64M，不能大于128M。
如何判断系统中产生了海量的小文件？就需要对尺寸小于边界值的文件进行计数，计数可以在两个过程中进行：一是在文件存储在存储节点的时候，可能是上传文件过程中，也可能是新增副本过程中；二是在“存储节点文件完整性校验”过程中，这时是对系统中的小文件进行重新计数。
系统中需要设置一个判断小文件数量何时达到“海量”的这样一个边界值，如果小文件数量大于了这个数值，就应该减少其他服务的供给量，来做小文件的合并。
首先根据内存中的文件视图，将要合并的小文件的名称记下，并将其尺寸相加，当总尺寸达到了不超过文件块最大值的时候，就将这些文件进行合并。正在合并的时候，原文件是要保留的，因此存储节点要始终保留一定的剩余磁盘空间。原来的小文件中包含有文件的id、应用元数据和校验和等信息，在合并时保留这些信息。合并后需要对合并的文件做一个索引，放在文件块的头部，并对整个文件做一个检验和，将校验和放在文件块的头部保存起来。
保存后的文件块实际上就可以被使用了，但还需要修改元数据存储中的文件索引结构，将其指向文件块中的小文件。在这期间，实际上有两份文件为获取操作提供服务，元数据存储中索引结构没被更改的，找原来的独立小文件，更改完成的，找文件块中的小文件。在完成所有小文件的索引结构转变后，就可以将合并前的小文件全部删除了。
元数据存储中的索引结构可以是“${机器名称}:${文件块id}:${文件id}”这种形式，如果格式为两段，说明是单独存储的文件，如果是三段，说明是存储在文件块中的小文件。
⑽删除物理文件
删除物理文件跟下载文件的流程差不多，由一个存储节点获取“删除物理文件消息队列”中的消息，消息中包含所有要删除文件的存储节点名称和文件id。由该存储节点向其他所有节点发出删除物理文件的协商消息，其他存储节点处理完毕后，将处理结果同步到元数据存储子系统。同步的最后结果就是该文件对应的存储节点列表为空。该条记录会在由资源管理节点发起的“元数据完整性校验”过程中删除。
⑾扩容
采用这种架构的系统，只需要在物理主机或虚拟机上安装一个存储节点守护进程，连上集群网络即可。至于运行时的各种策略，会随着系统的需要而改变。
在现有技术中，一般采用单一主节点来存储网络的拓扑和文件的元数据，以及对除物理IO之外的几乎所有元数据操作进行执行。这样不但增加了主节点的存储压力，并且在高并发的情况下可能引发错误。本发明技术方案中，主节点的变种为“资源管理节点”，只负责管理系统的网络拓扑，以及对系统整体负载作出判断，对存储节点的工作进行调节；使其工作量大大降低，避免瓶颈的产生；而采用单独的元数据存储子系统也保障了系统的安全和可靠性，为其实现的技术选型提供了更大的空间。
本发明技术方案提出了“服务供给量”这一概念，即单位时间内提供服务的次数只有保持在一定的数值之内，才能保证服务的质量，如果超过了这个峰值，就应该控制提供服务的数量。在现有技术中，一般是客户端具有主动权，不管系统的承载量有多大，都会不断的向系统施加压力，造成系统负载过高，升高发生故障的可能性，也对提供服务的质量造成影响。本发明通过对服务供给量的调节，当外部压力达到峰值时，减少内部服务的供给量，提升外部服务的供给量来调节资源的分配。通过对各方面系统服务压力的判断，提供调节策略，使系统资源的使用可以做到有的放矢，随需应变。
以上结合附图详细说明了本发明的技术方案，考虑到相关技术中没有简便的、统一的针对复杂类型元数据存储的解决办法。现有的文件存储无法完成有复杂类型参与的文件存储过程。因此，本发明提出了一种分布式文件存储装置和一种分布式文件存储方法，可以在现有的文件存储方式基础上，充分利用单对象类型元数据和文档描述类型完成多对象类型元数据的文件存储，建立多对象类型元数据参与的面向分布式文件存储的通用、统一存储思路。
以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
Claims (10)
1.一种分布式文件存储装置，其特征在于，包括：
客户端，用于守护进程，管理应用各个请求以及请求所涉及到的文件，以消息的形式发送服务请求，并接收反馈信息；
存储节点，用于获取服务请求消息，基于服务请求消息，进行与文件相关的各项操作并反馈；
资源管理节点，用于保存文件的存储节点所构成集群的网络拓扑图和各个存储节点的状态，根据分布式队列每个队列中的积压元素个数调整该集群的服务侧重点，定期对元数据存储子系统的数据做扫描；
分布式消息队列，用于根据相应的服务请求的种类，为每个操作建立一个FIFO队列；
元数据存储子系统，用于存储各个请求涉及文件的元数据，以及各个请求涉及文件与副本集所在节点的对应关系。
2.根据权利要求1所述的分布式文件存储装置，其特征在于，所述存储节点进行的与文件相关的各项操作，具体包括：存储文件、判断自身是否具备服务条件、获取能够提供服务存储节点列表、选择服务节点、向客户端提供服务、提供本节点存储文件的列表、判断文件是否损坏并处理、文件副本集操作、调整自身服务策略、合并小文件。
3.根据权利要求1或2所述的分布式文件存储装置，其特征在于，所述客户端，具体包括：
服务请求模块，用于管理应用各个请求以及请求所涉及到的文件，以消息的形式发送服务请求；
服务接收模块，用于接收相应服务请求的反馈信息。
4.根据权利要求1或2所述的分布式文件存储装置，其特征在于，所述存储节点，具体包括：
获取请求模块，用于主动获取服务请求消息，如果节点自身能够提供服务，则节点自身主动连接客户端提供服务；如果节点自身不能提供服务，则与其他存储节点进行协商，让其他节点为客户端提供服务；
协商服务模块，用于如果节点自身不能为客户端提供服务，那么该节点需要知道哪个节点能够为客户端提供服务，这就需要存储节点与元数据存储子系统或者资源管理节点进行沟通，具体的沟通方式与哪种类型的服务相关；获取一个能够提供服务的节点列表，根据需要与其进行沟通，沟通完成后，由有能力提供服务的节点主动连接客户端，为其提供服务；
提供服务模块，用于在协商完毕后，最后由能提供服务的节点主动连接客户端，为其提供服务；该服务包括拉取要存储的文件、推送文件、通知删除处理结果；
心跳模块，用于定时向资源管理节点发布自己的资源使用情况，能在存储节点无法自己提供服务时，为其寻找协商节点提供依据；也能在元数据存储子系统相应服务能力不足时，通知存储节点把那种类型服务的优先级提高，动态调整集群的服务侧重点，以提升服务能力；
同步元数据模块，用于在元数据存储子系统进行包含新增、删除、增加文件复制份数的操作时，存储节点需要将操作后的文件存储状态通知元数据存储子系统将其更新。
5.根据权利要求1或2所述的分布式文件存储装置，其特征在于，所述资源管理节点，具体包括：
网络拓扑图和状态保存模块，用于保存文件的存储节点所构成集群的网络拓扑图和各个存储节点的状态；
服务侧重点调整模块，用于根据分布式队列每个队列中的积压元素个数，判断元数据存储子系统在哪种服务上处于瓶颈，通过保存的存储节点状态，计算出对哪些节点的服务侧重点进行调整，改变整个集群的服务侧重点；
定期扫描模块，用于定期对元数据存储子系统的数据做扫描，如果有文件缺少副本，就向“文件复制消息队列”中放入消息，消息的数量等于元数据存储子系统要求的复制数量减去目前已有的复制数量；如果一个文件被标记为删除，就向“文件删除消息队列”中放入消息，消息中带有所有保存该文件的存储节点信息；如果文件在元数据存储子系统中没有副本存在，说明此文件已经被删除完成或失效，则删除这条元数据记录；如果文件的副本数量比元数据存储子系统配置的要多，就发出一个删除消息到“文件物理删除消息队列”。
6.一种分布式文件存储方法，其特征在于，包括：
步骤202：守护进程，管理应用各个请求以及请求所涉及到的文件，以消息的形式发送服务请求，并接收反馈信息；
步骤204：获取服务请求消息，基于服务请求消息，进行与文件相关的各项操作并反馈；
步骤206：保存文件的存储节点所构成集群的网络拓扑图和各个存储节点的状态，根据分布式队列每个队列中的积压元素个数调整该集群的服务侧重点，定期对元数据存储子系统的数据做扫描；
步骤208：根据相应的服务请求的种类，为每个操作建立一个FIFO队列；
步骤210：存储各个请求涉及文件的元数据，以及各个请求涉及文件与副本集所在节点的对应关系。
7.根据权利要求6所述的分布式文件存储方法，其特征在于，所述步骤204进行的与文件相关的各项操作，具体包括：存储文件、判断自身是否具备服务条件、获取能够提供服务存储节点列表、选择服务节点、向客户端提供服务、提供本节点存储文件的列表、判断文件是否损坏并处理、文件副本集操作、调整自身服务策略、合并小文件。
8.根据权利要求6或7所述的分布式文件存储方法，其特征在于，所述步骤202，具体包括：
步骤302：管理应用各个请求以及请求所涉及到的文件，以消息的形式发送服务请求；
步骤304：接收相应服务请求的反馈信息。
9.根据权利要求6或7所述的分布式文件存储方法，其特征在于，所述步骤204，具体包括：
步骤402：主动获取服务请求消息，如果节点自身能够提供服务，则节点自身主动连接客户端提供服务；如果节点自身不能提供服务，则与其他存储节点进行协商，让其他节点为客户端提供服务；
步骤404：如果节点自身不能为客户端提供服务，那么该节点需要知道哪个节点能够为客户端提供服务，这就需要存储节点与元数据存储子系统或者资源管理节点进行沟通，具体的沟通方式与哪种类型的服务相关；获取一个能够提供服务的节点列表，根据需要与其进行沟通，沟通完成后，由有能力提供服务的节点主动连接客户端，为其提供服务；
步骤406：在协商完毕后，最后由能提供服务的节点主动连接客户端，为其提供服务；该服务包括拉取要存储的文件、推送文件、通知删除处理结果；
步骤408：定时向资源管理节点发布自己的资源使用情况，能在存储节点无法自己提供服务时，为其寻找协商节点提供依据；也能在元数据存储子系统相应服务能力不足时，通知存储节点把那种类型服务的优先级提高，动态调整集群的服务侧重点，以提升服务能力；
步骤410：在元数据存储子系统新增、删除、增加文件复制份数等操作时，存储节点需要将操作后的文件存储状态通知元数据存储子系统将其更新。
10.根据权利要求6或7所述的分布式文件存储方法，其特征在于，所述步骤206，具体包括：
步骤502：保存文件的存储节点所构成集群的网络拓扑图和各个存储节点的状态；
步骤504：根据分布式队列每个队列中的积压元素个数，判断元数据存储子系统在哪种服务上处于瓶颈，通过保存的存储节点状态，计算出对哪些节点的服务侧重点进行调整，改变整个集群的服务侧重点；
步骤506：定期对元数据存储子系统的数据做扫描，如果有文件缺少副本，就向“文件复制消息队列”中放入消息，消息的数量等于元数据存储子系统要求的复制数量减去目前已有的复制数量；如果一个文件被标记为删除，就向“文件删除消息队列”中放入消息，消息中带有所有保存该文件的存储节点信息；如果文件在元数据存储子系统中没有副本存在，说明此文件已经被删除完成或失效，则删除这条元数据记录；如果文件的副本数量比元数据存储子系统配置的要多，就发出一个删除消息到“文件物理删除消息队列”。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410673276.6A CN104391930A (zh) | 2014-11-21 | 2014-11-21 | 分布式文件存储装置和方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410673276.6A CN104391930A (zh) | 2014-11-21 | 2014-11-21 | 分布式文件存储装置和方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN104391930A true CN104391930A (zh) | 2015-03-04 |
Family
ID=52609834
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201410673276.6A Pending CN104391930A (zh) | 2014-11-21 | 2014-11-21 | 分布式文件存储装置和方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN104391930A (zh) |
Cited By (33)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105119978A (zh) * | 2015-07-21 | 2015-12-02 | 浪潮(北京)电子信息产业有限公司 | 一种元数据集群并行分发处理方法和系统 |
| CN105450784A (zh) * | 2016-01-20 | 2016-03-30 | 北京京东尚科信息技术有限公司 | 向mq中的消息分配消费节点的装置及方法 |
| CN105589733A (zh) * | 2015-11-27 | 2016-05-18 | 杭州华三通信技术有限公司 | 一种数据处理方法和装置 |
| CN105701156A (zh) * | 2015-12-29 | 2016-06-22 | 青岛海信网络科技股份有限公司 | 一种分布式文件系统管理方法及装置 |
| CN106027638A (zh) * | 2016-05-18 | 2016-10-12 | 华中科技大学 | 一种基于混合编码的hadoop数据分发方法 |
| CN106027647A (zh) * | 2016-05-20 | 2016-10-12 | 云南云电同方科技有限公司 | Lxpfs集群分布式文件存储系统 |
| CN106294374A (zh) * | 2015-05-15 | 2017-01-04 | 北京国双科技有限公司 | 小文件合并的方法和数据查询系统 |
| CN106357452A (zh) * | 2016-09-29 | 2017-01-25 | 上海和付信息技术有限公司 | 一种单点异构数据存储的高可用框架系统及其实现方法 |
| CN106484542A (zh) * | 2016-09-06 | 2017-03-08 | 华为技术有限公司 | 一种处理分布式系统中重叠节点事件的方法与装置 |
| CN106776967A (zh) * | 2016-12-05 | 2017-05-31 | 哈尔滨工业大学（威海） | 基于时序聚合算法的海量小文件实时存储方法及装置 |
| CN107463577A (zh) * | 2016-06-06 | 2017-12-12 | 华为软件技术有限公司 | 一种数据存储系统以及数据查找方法 |
| CN107786358A (zh) * | 2016-08-29 | 2018-03-09 | 中兴通讯股份有限公司 | 分布式系统及该分布式系统的扩容方法 |
| WO2018045820A1 (zh) * | 2016-09-07 | 2018-03-15 | 华为技术有限公司 | 一种文件同步的方法、设备及系统 |
| CN108390771A (zh) * | 2018-01-25 | 2018-08-10 | 中国银联股份有限公司 | 一种网络拓扑重建方法和装置 |
| CN108737437A (zh) * | 2018-05-31 | 2018-11-02 | 广州大学 | 一种基于闭包运行环境的安全终端通信系统及方法 |
| CN109508324A (zh) * | 2018-10-22 | 2019-03-22 | 浪潮软件集团有限公司 | 一种基于对象存储组件的超大文件管理方法及系统 |
| CN109726600A (zh) * | 2017-10-31 | 2019-05-07 | 伊姆西Ip控股有限责任公司 | 针对超融合基础设施提供数据保护的系统和方法 |
| CN109815060A (zh) * | 2019-01-30 | 2019-05-28 | 北京百度网讯科技有限公司 | 用于备份信息的方法及装置 |
| CN109840166A (zh) * | 2019-01-14 | 2019-06-04 | 京东数字科技控股有限公司 | 一种跨集群对象存储异步备份方法、装置和系统 |
| CN110247949A (zh) * | 2019-04-26 | 2019-09-17 | 广东虎彩影像有限公司 | 一种无损照片上传方法及其系统 |
| CN110457265A (zh) * | 2019-08-20 | 2019-11-15 | 上海商汤智能科技有限公司 | 数据处理方法、装置及存储介质 |
| CN110661829A (zh) * | 2018-06-28 | 2020-01-07 | 杭州海康威视系统技术有限公司 | 文件下载方法及装置、客户端和计算机可读存储介质 |
| CN110955641A (zh) * | 2019-11-05 | 2020-04-03 | 上海海加网络科技有限公司 | 一种用于分布式文件共享系统的嵌入式存储终端装置 |
| CN110968259A (zh) * | 2018-09-30 | 2020-04-07 | 武汉斗鱼网络科技有限公司 | 分步式对象存储系统、对象储存方法及存储介质 |
| CN110990129A (zh) * | 2019-10-17 | 2020-04-10 | 上海海加网络科技有限公司 | 一种基于智能启发式算法的分布式存储系统调度方法 |
| CN111405020A (zh) * | 2020-03-10 | 2020-07-10 | 山东汇贸电子口岸有限公司 | 基于消息队列和fastDFS微服务架构的异步文件导出方法及系统 |
| CN106599096B (zh) * | 2016-11-24 | 2020-09-15 | 上海交通大学 | 基于非易失性内存的高性能文件系统设计方法 |
| CN111866178A (zh) * | 2020-08-04 | 2020-10-30 | 蝉鸣科技(西安)有限公司 | 一种分布式ftp/ftps文件传输方法、装置及计算机存储介质 |
| CN112925793A (zh) * | 2021-03-29 | 2021-06-08 | 北京赛博云睿智能科技有限公司 | 一种多种结构数据分布式混合存储方法和系统 |
| CN113485644A (zh) * | 2021-07-05 | 2021-10-08 | 深圳市杉岩数据技术有限公司 | 一种io数据存储方法和服务器 |
| CN113779349A (zh) * | 2021-08-11 | 2021-12-10 | 中央广播电视总台 | 数据检索系统、装置、电子设备和可读存储介质 |
| CN113806307A (zh) * | 2021-08-09 | 2021-12-17 | 阿里巴巴（中国）有限公司 | 数据处理方法及装置 |
| CN113923095A (zh) * | 2021-09-30 | 2022-01-11 | 济南浪潮数据技术有限公司 | 一种集群消息转发方法、系统及存储介质 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102143215A (zh) * | 2011-01-20 | 2011-08-03 | 中国人民解放军理工大学 | 一种基于网络的pb级云存储系统及其处理方法 |
| CN102546216A (zh) * | 2010-12-30 | 2012-07-04 | 中国移动通信集团山东有限公司 | 网络管理系统中的告警消息处理方法及网络管理系统 |
| CN104049916A (zh) * | 2014-06-24 | 2014-09-17 | 东南大学 | 一种基于节点角色切换机制的自组织分布式存储系统及其方法 |
-
2014
- 2014-11-21 CN CN201410673276.6A patent/CN104391930A/zh active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102546216A (zh) * | 2010-12-30 | 2012-07-04 | 中国移动通信集团山东有限公司 | 网络管理系统中的告警消息处理方法及网络管理系统 |
| CN102143215A (zh) * | 2011-01-20 | 2011-08-03 | 中国人民解放军理工大学 | 一种基于网络的pb级云存储系统及其处理方法 |
| CN104049916A (zh) * | 2014-06-24 | 2014-09-17 | 东南大学 | 一种基于节点角色切换机制的自组织分布式存储系统及其方法 |
Cited By (51)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106294374A (zh) * | 2015-05-15 | 2017-01-04 | 北京国双科技有限公司 | 小文件合并的方法和数据查询系统 |
| CN106294374B (zh) * | 2015-05-15 | 2019-06-04 | 北京国双科技有限公司 | 小文件合并的方法和数据查询系统 |
| CN105119978A (zh) * | 2015-07-21 | 2015-12-02 | 浪潮(北京)电子信息产业有限公司 | 一种元数据集群并行分发处理方法和系统 |
| CN105119978B (zh) * | 2015-07-21 | 2019-05-24 | 浪潮(北京)电子信息产业有限公司 | 一种元数据集群并行分发处理方法和系统 |
| CN105589733A (zh) * | 2015-11-27 | 2016-05-18 | 杭州华三通信技术有限公司 | 一种数据处理方法和装置 |
| CN105589733B (zh) * | 2015-11-27 | 2018-12-25 | 新华三技术有限公司 | 一种数据处理方法和装置 |
| CN105701156A (zh) * | 2015-12-29 | 2016-06-22 | 青岛海信网络科技股份有限公司 | 一种分布式文件系统管理方法及装置 |
| CN105701156B (zh) * | 2015-12-29 | 2019-06-14 | 青岛海信网络科技股份有限公司 | 一种分布式文件系统管理方法及装置 |
| CN105450784A (zh) * | 2016-01-20 | 2016-03-30 | 北京京东尚科信息技术有限公司 | 向mq中的消息分配消费节点的装置及方法 |
| CN105450784B (zh) * | 2016-01-20 | 2019-06-04 | 北京京东尚科信息技术有限公司 | 向mq中的消息分配消费节点的装置及方法 |
| CN106027638A (zh) * | 2016-05-18 | 2016-10-12 | 华中科技大学 | 一种基于混合编码的hadoop数据分发方法 |
| CN106027638B (zh) * | 2016-05-18 | 2019-04-12 | 华中科技大学 | 一种基于混合编码的hadoop数据分发方法 |
| CN106027647B (zh) * | 2016-05-20 | 2019-07-09 | 云南云电同方科技有限公司 | Lxpfs集群分布式文件存储系统 |
| CN106027647A (zh) * | 2016-05-20 | 2016-10-12 | 云南云电同方科技有限公司 | Lxpfs集群分布式文件存储系统 |
| CN107463577A (zh) * | 2016-06-06 | 2017-12-12 | 华为软件技术有限公司 | 一种数据存储系统以及数据查找方法 |
| CN107463577B (zh) * | 2016-06-06 | 2021-01-29 | 华为技术有限公司 | 一种数据存储系统以及数据查找方法 |
| CN107786358A (zh) * | 2016-08-29 | 2018-03-09 | 中兴通讯股份有限公司 | 分布式系统及该分布式系统的扩容方法 |
| CN106484542B (zh) * | 2016-09-06 | 2020-05-19 | 华为技术有限公司 | 一种处理分布式系统中重叠节点事件的方法与装置 |
| CN106484542A (zh) * | 2016-09-06 | 2017-03-08 | 华为技术有限公司 | 一种处理分布式系统中重叠节点事件的方法与装置 |
| WO2018045820A1 (zh) * | 2016-09-07 | 2018-03-15 | 华为技术有限公司 | 一种文件同步的方法、设备及系统 |
| CN106357452A (zh) * | 2016-09-29 | 2017-01-25 | 上海和付信息技术有限公司 | 一种单点异构数据存储的高可用框架系统及其实现方法 |
| CN106357452B (zh) * | 2016-09-29 | 2019-06-04 | 上海和付信息技术有限公司 | 一种单点异构数据存储的高可用框架系统及其实现方法 |
| CN106599096B (zh) * | 2016-11-24 | 2020-09-15 | 上海交通大学 | 基于非易失性内存的高性能文件系统设计方法 |
| CN106776967A (zh) * | 2016-12-05 | 2017-05-31 | 哈尔滨工业大学（威海） | 基于时序聚合算法的海量小文件实时存储方法及装置 |
| CN106776967B (zh) * | 2016-12-05 | 2020-03-27 | 哈尔滨工业大学（威海） | 基于时序聚合算法的海量小文件实时存储方法及装置 |
| CN109726600A (zh) * | 2017-10-31 | 2019-05-07 | 伊姆西Ip控股有限责任公司 | 针对超融合基础设施提供数据保护的系统和方法 |
| CN109726600B (zh) * | 2017-10-31 | 2023-07-14 | 伊姆西Ip控股有限责任公司 | 针对超融合基础设施提供数据保护的系统和方法 |
| CN108390771A (zh) * | 2018-01-25 | 2018-08-10 | 中国银联股份有限公司 | 一种网络拓扑重建方法和装置 |
| CN108390771B (zh) * | 2018-01-25 | 2021-04-16 | 中国银联股份有限公司 | 一种网络拓扑重建方法和装置 |
| CN108737437A (zh) * | 2018-05-31 | 2018-11-02 | 广州大学 | 一种基于闭包运行环境的安全终端通信系统及方法 |
| CN110661829A (zh) * | 2018-06-28 | 2020-01-07 | 杭州海康威视系统技术有限公司 | 文件下载方法及装置、客户端和计算机可读存储介质 |
| CN110968259A (zh) * | 2018-09-30 | 2020-04-07 | 武汉斗鱼网络科技有限公司 | 分步式对象存储系统、对象储存方法及存储介质 |
| CN109508324B (zh) * | 2018-10-22 | 2023-06-09 | 浪潮软件集团有限公司 | 一种基于对象存储组件的超大文件管理方法及系统 |
| CN109508324A (zh) * | 2018-10-22 | 2019-03-22 | 浪潮软件集团有限公司 | 一种基于对象存储组件的超大文件管理方法及系统 |
| CN109840166B (zh) * | 2019-01-14 | 2021-03-30 | 京东数字科技控股有限公司 | 一种跨集群对象存储异步备份方法、装置和系统 |
| CN109840166A (zh) * | 2019-01-14 | 2019-06-04 | 京东数字科技控股有限公司 | 一种跨集群对象存储异步备份方法、装置和系统 |
| CN109815060A (zh) * | 2019-01-30 | 2019-05-28 | 北京百度网讯科技有限公司 | 用于备份信息的方法及装置 |
| CN110247949A (zh) * | 2019-04-26 | 2019-09-17 | 广东虎彩影像有限公司 | 一种无损照片上传方法及其系统 |
| CN110247949B (zh) * | 2019-04-26 | 2022-04-01 | 广东虎彩影像有限公司 | 一种无损照片上传方法及其系统 |
| CN110457265A (zh) * | 2019-08-20 | 2019-11-15 | 上海商汤智能科技有限公司 | 数据处理方法、装置及存储介质 |
| CN110990129A (zh) * | 2019-10-17 | 2020-04-10 | 上海海加网络科技有限公司 | 一种基于智能启发式算法的分布式存储系统调度方法 |
| CN110955641A (zh) * | 2019-11-05 | 2020-04-03 | 上海海加网络科技有限公司 | 一种用于分布式文件共享系统的嵌入式存储终端装置 |
| CN111405020A (zh) * | 2020-03-10 | 2020-07-10 | 山东汇贸电子口岸有限公司 | 基于消息队列和fastDFS微服务架构的异步文件导出方法及系统 |
| CN111405020B (zh) * | 2020-03-10 | 2023-03-31 | 山东汇贸电子口岸有限公司 | 基于消息队列和fastDFS微服务架构的异步文件导出方法及系统 |
| CN111866178A (zh) * | 2020-08-04 | 2020-10-30 | 蝉鸣科技(西安)有限公司 | 一种分布式ftp/ftps文件传输方法、装置及计算机存储介质 |
| CN112925793A (zh) * | 2021-03-29 | 2021-06-08 | 北京赛博云睿智能科技有限公司 | 一种多种结构数据分布式混合存储方法和系统 |
| CN112925793B (zh) * | 2021-03-29 | 2023-12-29 | 北京赛博云睿智能科技有限公司 | 一种多种结构数据分布式混合存储方法和系统 |
| CN113485644A (zh) * | 2021-07-05 | 2021-10-08 | 深圳市杉岩数据技术有限公司 | 一种io数据存储方法和服务器 |
| CN113806307A (zh) * | 2021-08-09 | 2021-12-17 | 阿里巴巴（中国）有限公司 | 数据处理方法及装置 |
| CN113779349A (zh) * | 2021-08-11 | 2021-12-10 | 中央广播电视总台 | 数据检索系统、装置、电子设备和可读存储介质 |
| CN113923095A (zh) * | 2021-09-30 | 2022-01-11 | 济南浪潮数据技术有限公司 | 一种集群消息转发方法、系统及存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN104391930A (zh) | 分布式文件存储装置和方法 | |
| US11928029B2 (en) | Backup of partitioned database tables | |
| CN105959151B (zh) | 一种高可用的流式处理系统及方法 | |
| CN102411637B (zh) | 分布式文件系统的元数据管理方法 | |
| CN106294585B (zh) | 一种云计算平台下的存储方法 | |
| AU2015241457B2 (en) | Geographically-distributed file system using coordinated namespace replication | |
| CN106156359B (zh) | 一种云计算平台下的数据同步更新方法 | |
| CN104679772B (zh) | 分布式数据仓库中删除文件的方法、装置、设备及系统 | |
| CN104008152B (zh) | 支持海量数据访问的分布式文件系统的架构方法 | |
| CN104813321B (zh) | 在分布式对象存储生态系统中的去耦合的内容以及元数据 | |
| CN105940396A (zh) | 分布式存储系统中对象的层级组块 | |
| CN103207867B (zh) | 处理数据块的方法、发起恢复操作的方法和节点 | |
| CN103873501B (zh) | 一种云备份系统及其数据备份方法 | |
| CN101472166B (zh) | 一种内容缓存、查询方法及点对点媒体传输系统 | |
| CN104133882A (zh) | 一种基于hdfs的小文件处理方法 | |
| KR100946986B1 (ko) | 파일 저장 시스템 및 파일 저장 시스템에서의 중복 파일관리 방법 | |
| TW202111564A (zh) | 日誌結構儲存系統 | |
| CN105025053A (zh) | 基于云存储技术的分布式文件的上传方法及其系统 | |
| CN107045422A (zh) | 分布式存储方法和设备 | |
| US9445162B2 (en) | Interactive personal/internet protocol television reservation system, reservation plan management method and device | |
| CN104184812B (zh) | 一种基于私有云的多点数据传输方法 | |
| CN104081353A (zh) | 可缩放环境中的动态负载平衡 | |
| WO2008049353A1 (fr) | Système de mise en mémoire de données de réseau et procédé pour y accéder | |
| CN107667351A (zh) | 用于移动设备上的自动基于云的全数据备份和恢复的系统和方法 | |
| CN102640125A (zh) | 分布式内容存储和取回 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| CB02 | Change of applicant information |
Address after: 100094 Beijing city Haidian District North Road No. 68, UFIDA Software Park Applicant after: Yonyou Network Technology Co., Ltd. Address before: 100094 Beijing city Haidian District North Road No. 68, UFIDA Software Park Applicant before: UFIDA Software Co., Ltd. |
|
| COR | Change of bibliographic data | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20150304 |