CN107295030B - 一种数据写入方法、装置、数据处理方法、装置及系统 - Google Patents
一种数据写入方法、装置、数据处理方法、装置及系统 Download PDFInfo
- Publication number
- CN107295030B CN107295030B CN201610192497.0A CN201610192497A CN107295030B CN 107295030 B CN107295030 B CN 107295030B CN 201610192497 A CN201610192497 A CN 201610192497A CN 107295030 B CN107295030 B CN 107295030B
- Authority
- CN
- China
- Prior art keywords
- request
- block data
- data
- client
- server
- 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.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
Abstract
本申请公开了一种客户端的数据写入方法、装置及电子设备、一种块数据服务器的数据处理方法、装备及电子设备以及一种分布式文件系统。其中,所述客户端的数据写入方法,包括:向存储对应文件的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据;在满足需求后,向存储对应文件的所有块数据服务器并行发送执行提交操作的请求。采用上述方法解决了写文件和提交的延迟非常高,代价太大的问题,使每个块数据服务器在相同时间同时将数据写入到本地硬盘中,节约了时间,提高了系统的运算处理速度,从而提升了系统的吞吐率。
Description
技术领域
本申请涉及计算机技术领域,具体涉及一种客户端的数据写入方法、一种块数据服务器的数据处理方法、一种分布式文件系统以及一种基于分布式文件系统的数据写入方法;本申请同时涉及一种客户端的数据写入装置及一种电子设备、一种块数据服务器的数据处理装置及另一种电子设备以及一种基于分布式文件系统的数据写入装置。
背景技术
随着信息技术的发展,存储数据在爆炸式的增长,本地的存储很难满足不断增长的海量存储的需要,加上个人移动计算和企业级的大规模计算对底层存储系统提出更高的要求,人们越来越多的使用分布式文件系统,例如:Google的核心存储平台GFS(googleFile System)。以GFS为典型代表的分布式文件系统采用的是服务器/客户端结构,主要组成部分包括主服务器master(元数据服务器)、块数据服务器chunk server和客户端client,三者之间通过各自的网络协议进行指令和数据通信。
GFS采用多文件副本的方式存储文件,即一个文件的数据拥有多个文件副本,分别存储在不同块数据服务器里。当一台或多台块数据服务器意外宕机时,这个文件的数据依然可用。多文件副本的方式大大提高了分布式文件系统的可靠性。当用户上传一个文件到分布式文件系统,只有指定的三个块数据服务器写入了文件副本。块数据服务器一般采用链式写文件的方法,客户端向第一台块数据服务器发送数据,第一台块数据服务器先把数据存储在缓冲区中,在把数据转发给下一台块数据服务器,然后等待下一台块数据服务器的响应。之后的所有数据服务器都是如此,数据逐个向后转发,直到最后一台块数据服务器把数据存储在缓冲区中后,创建接收成功的反馈信息并发给客户端,然后再由客户端向第一台块数据服务器发送提交命令,第一台块数据服务器接收到命令后把数据写到本地硬盘,然后把提交命令转发给下一台块数据服务器,直到最后一台块数据服务器把数据写到硬盘后,创建提交成功的反馈信息并发给上一台块数据服务器,上一台块数据服务器收到反馈信息并且自己已经写数据到硬盘,才能向上一台块数据服务器发送写成功的反馈信息。直到客户端收到写成功的反馈信息,则本次写操作完成。
由此可见,链式写文件的方式需要所有指定的块数据服务器都把文件数据写入到本地硬盘,然后由最后一台块数据服务器依次向前一台发送写成功与提交成功的反馈信息,直到客户端。虽然这种方式保证文件可以成功写入块数据服务器,但是写文件和提交的延迟非常高,代价太大,而且每个块数据服务器都在不同的时间写数据到本地硬盘,浪费时间,降低了系统的运算处理速度,影响系统的吞吐率。
发明内容
本申请提供一种客户端的数据写入方法、一种块数据服务器的数据处理方法、一种分布式文件系统以及一种基于分布式文件系统的数据写入方法,以解决现有技术中的上述问题。本申请同时涉及一种客户端的数据写入装置及一种电子设备、一种块数据服务器的数据处理装置及另一种电子设备以及一种基于分布式文件系统的数据写入装置。
本申请提供了一种客户端的数据写入方法,所述客户端的数据写入方法,包括:
向存储对应文件的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据;
在满足需求后,向存储对应文件的所有块数据服务器并行发送执行提交操作的请求。
可选的,在所述向存储对应文件的块数据服务器发送执行追加写操作的请求的步骤之前,还包括:
向主服务器发送需要写入数据的文件的名称;
接收所述主服务器发送的存储对应文件的所有块数据服务器的位置信息。
可选的,在所述接收所述主服务器发送的存储对应文件的所有块数据服务器的位置信息的步骤之后,包括:
在本地缓存中存储接收的所述主服务器发送的存储对应文件的所有块数据服务器的位置信息。
可选的,在所述向存储对应文件的块数据服务器发送执行追加写操作的请求的步骤之前,包括:
根据网络拓扑结构计算存储对应文件的所有块数据服务器的追加写入顺序。
可选的,在所述向存储对应文件的块数据服务器发送执行追加写操作的请求时,还包括:
向所述块数据服务器发送存储对应文件的所有块数据服务器的追加写入顺序。
可选的,在所述向存储对应文件的块数据服务器发送执行追加写操作的请求的步骤之后,包括:
接收块数据服务器基于所述数据的状态向所述客户端反馈所述数据的状态信息;
向对应的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
可选的,在所述向存储对应文件的所有块数据服务器并行发送执行提交操作的请求的步骤之后,包括:
接收各个块数据服务器基于执行提交操作的结果反馈的提交信息;
若所述提交信息为失败,则向主服务器发送复制对应的块数据服务器到其他块数据服务器的请求。
相应的,本申请还提供了一种客户端的数据写入装置,所述客户端的数据写入装置,包括:
追加写请求单元,用于向存储对应文件的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据;
提交单元,用于在满足需求后,向存储对应文件的所有块数据服务器并行发送执行提交操作的请求。
可选的,所述客户端的数据写入装置,还包括:
名称发送单元,用于在所述向存储对应文件的块数据服务器发送执行追加写操作的请求之前,向主服务器发送需要写入数据的文件的名称;
位置信息接收单元,用于接收所述主服务器发送的存储对应文件的所有块数据服务器的位置信息。
可选的,所述客户端的数据写入装置,还包括:
位置信息存储单元,用于在所述接收所述主服务器发送的存储对应文件的所有块数据服务器的位置信息之前,在本地缓存中存储接收的所述主服务器发送的存储对应文件的所有块数据服务器的位置信息。
可选的,所述客户端的数据写入装置,还包括:
顺序计算单元,用于在所述向存储对应文件的块数据服务器发送执行追加写操作的请求之前,根据网络拓扑结构计算存储对应文件的所有块数据服务器的追加写入顺序。
可选的,所述客户端的数据写入装置,所述追加写请求单元,还包括:
顺序发送子单元,用于向存储对应文件的块数据服务器发送执行追加写操作的请求时,向所述块数据服务器发送存储对应文件的所有块数据服务器的追加写入顺序。
可选的,所述客户端的数据写入装置,还包括:
状态信息接收单元,用于向存储对应文件的块数据服务器发送执行追加写操作的请求之后,接收块数据服务器基于所述数据的状态向所述客户端反馈所述数据的状态信息;
请求重发单元,用于向对应的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
可选的,所述客户端的数据写入装置,还包括:
提交信息接收单元,用于向存储对应文件的所有块数据服务器并行发送执行提交操作的请求之后,接收各个块数据服务器基于执行提交操作的结果反馈的提交信息;
块数据复制单元,用于若所述提交信息为失败,则向主服务器发送复制对应的块数据服务器到其他块数据服务器的请求。
此外,本申请还提供了一种电子设备,包括:
显示器;
处理器;
存储器,用于存储数据写入程序,所述程序在被所述处理器读取执行时,执行如下操作:向存储对应文件的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据;在满足需求后,向存储对应文件的所有块数据服务器并行发送执行提交操作的请求。
此外,本申请还提供了一种块数据服务器的数据处理方法,所述块数据服务器的数据处理方法,包括:
接收客户端或者块数据服务器发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据;
接收客户端发送的执行提交操作的请求;
将所述数据进行写入。
可选的,在所述接收客户端或者块数据服务器发送的执行追加写操作的请求时,还包括:
接收所述客户端或者块数据服务器发送的存储对应文件的所有块数据服务器的追加写入顺序。
可选的,在所述接收客户端或者块数据服务器发送的执行追加写操作的请求的步骤之后,包括:
在存储对应文件的所有块数据服务器的追加写入顺序中获取位于当前块数据服务器之后的块数据服务器的位置,向该块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
可选的,在所述接收客户端或者块数据服务器发送的执行追加写操作的请求的步骤之后,包括:
判断执行追加写操作的请求中的数据的状态;
若所述数据的状态为未收到数据,则基于所述数据的状态向所述客户端反馈所述数据的状态信息;
接收所述客户端基于所述数据的状态信息发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
可选的,在所述将所述数据进行写入的步骤之后,包括:
向客户端反馈基于执行提交操作的结果的提交信息。
相应的,本申请还提供了一种块数据服务器的数据处理装置,所述块数据服务器的数据处理装置,包括:
追加写请求接收单元,用于接收客户端或者块数据服务器发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据;
提交请求接收单元,用于接收客户端发送的执行提交操作的请求;
写入单元,用于将所述数据进行写入。
可选的,所述块数据服务器的数据处理装置,还包括:
顺序接收单元,用于在所述接收客户端或者块数据服务器发送的执行追加写操作的请求时,接收所述客户端或者块数据服务器发送的存储对应文件的所有块数据服务器的追加写入顺序。
可选的,所述块数据服务器的数据处理装置,还包括:
追加写请求发送单元,用于在所述接收客户端或者块数据服务器发送的执行追加写操作的请求之后,在存储对应文件的所有块数据服务器的追加写入顺序中获取位于当前块数据服务器之后的块数据服务器的位置,向该块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
可选的,所述块数据服务器的数据处理装置,还包括:
数据状态判断单元,用于在所述接收客户端或者块数据服务器发送的执行追加写操作的请求之后,判断执行追加写操作的请求中的数据的状态;
状态信息反馈单元,用于接收所述数据状态判断单元的判断结果,若所述数据的状态为未收到数据,则基于所述数据的状态向所述客户端反馈所述数据的状态信息;
追加写请求重新接收单元,用于接收所述客户端基于所述数据的状态信息发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
可选的,所述块数据服务器的数据处理装置,还包括:
提交信息反馈单元,用于在所述将所述数据进行写入之后,向客户端反馈基于执行提交操作的结果的提交信息。
此外,本申请还提供了一种电子设备,包括:
显示器;
处理器;
存储器,用于存储数据处理程序,所述程序在被所述处理器读取执行时,执行如下操作:接收客户端或者块数据服务器发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据;接收客户端发送的执行提交操作的请求;将所述数据进行写入。
此外,本申请还提供了一种分布式文件系统,所述分布式文件系统,包括:
根据上述任一项所述的客户端的数据写入装置;以及
任一项所述的块数据服务器的数据处理装置。
此外,本申请还提供了一种基于分布式文件系统的数据写入方法,所述此外,本申请还提供了一种,包括:
客户端向存储对应文件的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据;
所述块数据服务器接收客户端或者块数据服务器发送的执行追加写操作的请求;
在满足需求后,所述客户端向存储对应文件的所有块数据服务器并行发送执行提交操作的请求;
存储对应文件的各个块数据服务器接收客户端发送的执行提交操作的请求;
接收到所述执行提交操作的请求的块数据服务器将所述执行追加写操作的请求携带的数据进行写入。
可选的,在所述块数据服务器接收客户端或者块数据服务器发送的执行追加写操作的请求的步骤之后,包括:
当前块数据服务器判断执行追加写操作的请求中的数据的状态;
若所述数据的状态为未收到数据,则基于所述数据的状态向所述客户端反馈所述数据的状态信息;
所述客户端接收块数据服务器基于所述数据的状态反馈的所述数据的状态信息;
向对应的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据;
块数据服务器接收所述客户端基于所述数据的状态信息发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
可选的,在所述接收到所述执行提交操作的请求的块数据服务器将所述执行追加写操作的请求携带的数据进行写入的步骤之后,包括:
接收到所述执行提交操作的请求的块数据服务器向客户端反馈基于执行提交操作的结果的提交信息;
所述客户端接收各个块数据服务器基于执行提交操作的结果反馈的提交信息;
若所述提交信息为失败,则向主服务器发送复制对应的块数据服务器到其他块数据服务器的请求。
相应的,本申请还提供了一种基于分布式文件系统的数据写入装置,所述基于分布式文件系统的数据写入装置,包括:
追加写请求发送单元,用于客户端向存储对应文件的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据;
追加写请求接收单元,用于所述块数据服务器接收客户端或者块数据服务器发送的执行追加写操作的请求;
提交请求发送单元,用于在满足需求后,所述客户端向存储对应文件的所有块数据服务器并行发送执行提交操作的请求;
提交请求接收单元,用于存储对应文件的各个块数据服务器接收客户端发送的执行提交操作的请求;
数据写入单元,用于接收到所述执行提交操作的请求的块数据服务器将所述执行追加写操作的请求携带的数据进行写入。
可选的,所述基于分布式文件系统的数据写入装置,包括:
数据状态判断单元,用于在所述块数据服务器接收客户端或者块数据服务器发送的执行追加写操作的请求之前,当前块数据服务器判断执行追加写操作的请求中的数据的状态;
状态反馈单元,用于若所述数据的状态为未收到数据,则基于所述数据的状态向所述客户端反馈所述数据的状态信息;
状态接收单元,用于所述客户端接收块数据服务器基于所述数据的状态反馈的所述数据的状态信息;
请求重发单元,用于向对应的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据;
重新接收单元,用于块数据服务器接收所述客户端基于所述数据的状态信息发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
可选的,所述基于分布式文件系统的数据写入装置,包括:
提交信息反馈单元,用于在所述接收到所述执行提交操作的请求的块数据服务器将所述执行追加写操作的请求携带的数据进行写入之后,接收到所述执行提交操作的请求的块数据服务器向客户端反馈基于执行提交操作的结果的提交信息;
提交信息接收单元,用于所述客户端接收各个块数据服务器基于执行提交操作的结果反馈的提交信息;
复制单元,用于若所述提交信息为失败,则向主服务器发送复制对应的块数据服务器到其他块数据服务器的请求。
与现有技术相比,本申请具有以下优点:
本申请提供的一种客户端的数据写入方法、装置以及电子设备,通过向存储对应文件的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据;在满足需求后,向存储对应文件的所有块数据服务器并行发送执行提交操作的请求。所述技术方案解决了写文件和提交的延迟非常高,代价太大的问题,使每个块数据服务器在相同时间同时将数据写入到本地硬盘中,节约了时间,提高了系统的运算处理速度,从而提升了系统的吞吐率。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请中记载的一些实施例,对于本领域普通技术人员来讲,还可以根据这些附图获得其他的附图。
图1示出了根据本申请的实施例提供的客户端的数据写入方法的流程图;
图2示出了根据本申请的实施例提供的客户端从主服务器中获取存储了对应文件的块数据服务器的位置的流程图;
图3示出了根据本申请的实施例提供的客户端再次调用追加写操作的流程图;
图4示出了根据本申请的实施例提供的客户端的数据写入装置的示意图;
图5示出了根据本申请的实施例提供的电子设备的示意图;
图6示出了根据本申请的实施例提供的块数据服务器的数据处理方法的流程图;
图7示出了根据本申请的实施例提供的判断执行追加写操作的请求中的数据的状态的流程图;
图8示出了根据本申请的实施例提供的块数据服务器的数据处理装置的示意图;
图9示出了根据本申请的实施例提供的电子设备的示意图;
图10示出了根据本申请的实施例提供的分布式文件系统的示意图;
图11示出了根据本申请的实施例提供的基于分布式文件系统的数据写入方法的流程图;
图12示出了根据本申请的实施例提供的块数据服务器判断执行追加写操作的请求中的数据的状态的流程图;
图13示出了根据本申请的实施例提供的基于分布式文件系统的数据写入装置的示意图。
具体实施方式
为了能够更清楚地理解本申请的上述目的、特征和优点,下面结合附图和具体实施方式对本申请进行进一步的详细描述。需要说明的是,在不冲突的情况下,本申请的实施例及实施例中的特征可以相互组合。
在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是,本申请能够以很多不同于在此描述的其它方式来实施,本领域技术人员可以在不违背本申请内涵的情况下做类似推广,因此,本申请不受下面公开的具体实施的限制。
本申请的实施例提供了一种客户端的数据写入方法、一种块数据服务器的数据处理方法、一种分布式文件系统以及一种基于分布式文件系统的数据写入方法;本申请同时涉及一种客户端的数据写入装置及一种电子设备、一种块数据服务器的数据处理装置及另一种电子设备以及一种基于分布式文件系统的数据写入装置。在下面的实施例中逐一进行详细说明。
目前,块数据服务器一般采用链式写文件的方法,客户端向第一台块数据服务器发送数据,第一台块数据服务器先把数据存储在缓冲区中,在把数据转发给下一台块数据服务器,然后等待下一台块数据服务器的响应。之后的所有数据服务器都是如此,数据逐个向后转发,直到最后一台块数据服务器把数据存储在缓冲区中后,创建接收成功的反馈信息并发给客户端,然后再由客户端向第一台块数据服务器发送提交命令,第一台块数据服务器接收到命令后把数据写到本地硬盘,然后把提交命令转发给下一台块数据服务器,直到最后一台块数据服务器把数据写到硬盘后,创建提交成功的反馈信息并发给上一台块数据服务器,上一台块数据服务器收到反馈信息并且自己已经写数据到硬盘,才能向上一台块数据服务器发送写成功的反馈信息。直到客户端收到写成功的反馈信息,则本次写操作完成。由此可见,链式写文件的方式需要所有指定的块数据服务器都把文件数据写入到本地硬盘,然后由最后一台块数据服务器依次向前一台发送写成功与提交成功的反馈信息,直到客户端。虽然这种方式保证文件可以成功写入块数据服务器,但是写文件和提交的延迟非常高,代价太大,而且每个块数据服务器都在不同的时间写数据到本地硬盘,浪费时间,降低了系统的运算处理速度,影响系统的吞吐率。针对这一问题,本申请的技术方案通过向对应文件的其中一个块数据服务器发送执行追加写操作的请求,不等待块数据服务器反馈的信息就返回;并在满足需求后,向对应文件的所有块数据服务器发送执行提交操作的请求,使每个块数据服务器在相同时间同时将数据写入到本地硬盘中,从而提升了系统的吞吐率。
在详细描述本实施例的具体步骤之前,为了方便对本技术方案的理解,先对现有的分布式文件系统作简要说明。
一个GFS系统由一个主服务器master和大量块服务器chunk server构成,并被许多客户端client访问,三者之间通过各自的网络协议进行指令和数据通信。主服务器和块服务器通常是运行用户层服务进程的Linux机器。只要资源和可靠性允许,块服务器和客户端可以运行在同一个机器上。
所有的元数据都存放在一个主服务器节点内。主服务器维护分布式文件系统所有的元数据,GFS物理上没有目录结构,也不支持链接操作,使用一张表来映射文件路径名和元数据。主服务器维护文件系统所有的元数据,包括名字空间、访问控制信息、从文件到块的映射以及块的当前位置,所有元数据都放在内存中。它也控制系统范围的活动,如块租约(lease)管理,孤儿块的垃圾收集,块服务器间的块迁移。
客户端可以看作是分布式文件系统的接口,负责应用程序与文件系统的沟通。文件划分成固定大小64MB的块,每个块由一个不变的、全局唯一的64bit的chunk handle唯一标识,由主服务器创建时分配,在划分时除了最后一各块,文件所有的块都是满的。所有的客户端读取文件的时候,都需要首先从主服务器上获取元数据信息(master与client之间的元数据传输),获取到元数据信息之后解析得到数据所在的块服务器的ip和块的唯一标识,根据这些信息进一步与块服务器进行交互,读取得到所需要的数据。
块服务器负责存储文件的块,根据客户端提供的块信息,读写块数据,周期性地向主服务器报告本地存储的块状态信息。并且块服务器之间可以相互复制块的副本,默认情况下,保存3个副本,这一点有利于提高系统的可靠性。
本申请的实施例提供了一种客户端的数据写入方法。所述客户端的数据写入方法实施例如下:
请参考图1,其示出了根据本申请的实施例提供的客户端的数据写入方法的流程图。
所述客户端的数据写入方法包括:
步骤S101,向存储对应文件的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
在本实施例中,所述向存储对应文件的块数据服务器发送执行追加写操作的请求,可以采用如下方式实现:客户端通过TCP/IP连接等网络协议与三个存储了对应文件的块数据服务器中的一个连接后进行信息交互,所述客户端向建立了连接的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据。例如:所述客户端通过以太网与所述块数据服务器进行连接。
需要说明的是,GFS提供了一个原子性的添加操作:追加写(append)。在传统的写操作中,客户端指定被写数据的偏移位置,向同一个区间的并发的写操作是不连续的。在append中,客户端只是指定数据,不会覆盖原有的内容,只是在后面添加内容。在分布式的应用中,不同机器上的许多客户端可能会同时向一个文件执行添加操作,添加操作被频繁使用。如果用传统的write操作,可能需要额外的、复杂的、开销较大的同步,例如通过分布式锁管理。在任何一个副本上执行append且操作失败时,客户端将重新尝试该操作。在执行追加写时,由于append只力求尽快返回不保证能写入磁盘,所以经常与提交(commit)操作一起使用保证数据能写入磁盘,所以一般执行写流程时法是多次调用append,然后执行一次commit,确保数据真正落盘。
在本实施例中,所述客户端只需向从所述主服务器中获取的三个存储了对应文件的块数据服务器中的一个块数据服务器发送执行追加写操作的请求后,就使所述客户端返回追加写操作成功,降低追加写的延迟。需要说明的是,现有的执行追加写操作是:所述客户端接收到三个存储了对应文件的块数据服务器都成功接收数据后,发送的确认信息,使所述客户端返回追加写操作成功。
由于执行追加写时是在现有文件的后面添加新的数据,且分布式文件系统的文件元数据信息和文件内容的块数据没有存储在一起,而文件的块数据又存储在不同的块数据服务器中;所以在对分布式文件系统进行追加写时,首先要获取客户端执行追加写的文件的元数据以获取与所述文件元数据相对应的文件的块数据的存放位置,本实施例的技术方案提供了一种优选实施方式,在优选方式下,所述客户端在向存储对应文件的块数据服务器发送执行追加写操作的请求之前,所述客户端需要先从主服务器中获取存储了对应文件的块数据服务器的位置,具体包括步骤S100-1至S100-2,下面结合附图2作进一步说明。
请参考图2,其示出了根据本申请的实施例提供的客户端从主服务器中获取存储了对应文件的块数据服务器的位置的流程图。
步骤S100-1,向主服务器发送需要写入数据的文件的名称。
在本实施例中,所述向主服务器发送需要写入数据的文件的名称,可以采用如下方式实现:客户端通过TCP/IP连接等网络协议与所述主服务器连接后进行信息交互,所述客户端将需要进行追加写的文件的名称发送给所述主服务器。例如:所述客户端通过以太网与所述主服务器进行连接。
需要说明的是,所述主服务器中保存着元数据,所述元数据包括:名字空间、访问控制信息、从文件到块数据的映射以及块数据的当前位置。
步骤S100-2,接收所述主服务器发送的存储对应文件的所有块数据服务器的位置信息。
在本实施例中,所述接收所述主服务器发送的存储对应文件的所有块数据服务器的位置信息,可以采用如下方式实现:所述主服务器通过接收到的文件的名称查询元数据中文件到块数据的映射,获取存储了所述文件对应的各个块数据的块数据服务器的位置后,向所述客户端进行发送,所述客户端通过TCP/IP连接等网络协议与所述主服务器连接后接收所述主服务器发送的存储对应文件的所有块数据服务器(3个块数据服务器)的位置信息,即:客户端从主服务器中获取文件对应的块数据的多个副本数据的ip地址集合。
需要说明的是,在分布式文件系统中,每个文件在存储时被划分为多个块数据(每个块数据64MB),且每个块数据有多个副本数据,分别存储在多个块数据服务器上,副本数据,也就是块数据的备份数据。
例如:文件A的数据被分割成块数据并分别存储在多台块数据服务器上,文件A有128MB大小,那么文件A被分割成2个大小为64MB的块数据,这2个块数据会根据一定策略存放到不同的块数据服务器中。为了提升分布式文件系统的可靠性,一个文件还会有2个相同的副本,防止一个副本损坏至无法读取时,还可以通过其他副本读取数据,在上面的例子中,文件A被分割成2个大小为64MB的块数据,且在分布式文件系统中为每个文件提供2个副本,即2个文件A的复制,共有4个块数据,这4个副本数据块也会根据一定的策略存放的不同的块数据服务器上。
可以理解的,GFS中执行追加写时是以数据为单元,每条数据的大小为几十KB到几MB,如果每次追加时都需要请求主服务器,那么会使所述主服务器的运行压力增大,成为系统中性能的瓶颈,为了解决这一问题,本实施例的技术方案提供了一种优选实施方式,在优选方式下,在所述客户端接收所述主服务器发送的存储对应文件的所有块数据服务器的位置信息的步骤之后,所述客户端在本地缓存中存储接收的所述主服务器发送的存储对应文件的所有块数据服务器的位置信息,由于本地内存或磁盘中缓存的所述主服务器发送的存储对应文件的所有块数据服务器的位置信息是具有时限的,如果客户端不出现故障,在时限内客户端再对该文件进行追加时,都不需要再次请求主服务器。
在执行步骤S101时,由于所述客户端只需向从所述主服务器中获取的三个存储了对应文件的块数据服务器中的一个块数据服务器发送了执行追加写操作的请求后,就使所述客户端返回追加写操作成功,所以在客户端发送执行追加写操作的请求前,需要从三个存储了对应文件的块数据服务器中进行选择,在本实施例中,是根据网络拓扑结构计算存储对应文件的所有块数据服务器的追加写入顺序,并选取位于追加写入顺序中最靠前的块数据服务器,向该块数据服务器发送执行追加写操作的请求。所述追加写入顺序是按照网络拓扑结构把块数据服务器的ip地址进行排序的序列。
例如:所述客户端根据获取的三个存储了对应文件的块数据服务器的位置信息查询该分布式文件系统的网络拓扑结构,根据三个块数据服务器与所述客户端之间的距离,按照距离由近至远的顺序,计算出存储对应文件的所有块数据服务器的追加写入顺序,找出最短路径。
需要说明的是,构成网络的拓扑结构有很多种。网络拓扑结构是指用传输媒体互连各种设备的物理布局,就是用什么方式把网络中的计算机等设备连接起来。它的结构主要有星型结构、环型结构、总线结构、分布式结构、树型结构、网状结构、蜂窝状结构等。分布式结构的网络是将分布在不同地点的计算机通过线路互连起来的一种网络形式。分布式结构的网络具有如下特点:由于采用分散控制,即使整个网络中的某个局部出现故障,也不会影响全网的操作,因而具有很高的可靠性;网中的路径选择最短路径算法,故网上延迟时间少,传输速率高,但控制复杂;各个结点间均可以直接建立数据链路,信息流程最短;便于全网范围内的资源共享。
为了使执行追加写操作的请求中携带的需要追加写入文件的数据在所有块数据服务器中以流水线的方式传递下去,在所述客户端计算出存储对应文件的所有块数据服务器的追加写入顺序后,在执行步骤S101向存储对应文件的块数据服务器发送执行追加写操作的请求的同时,还需向所述块数据服务器发送存储对应文件的所有块数据服务器的追加写入顺序,使所述执行追加写操作的请求中携带的需要追加写入文件的数据按照计算出的追加写入顺序在储对应文件的块数据服务器间进行传递。
步骤S103,在满足需求后,向存储对应文件的所有块数据服务器并行发送执行提交操作的请求。
在本实施例中,所述需求是:客户端向存储对应文件的块数据服务器发送出执行追加写操作的请求。可以理解的,所述满足需求就是指:客户端向存储对应文件的块数据服务器发送出执行追加写操作的请求后的状态,但是由于客户端在发出执行追加写操作的请求后,就使所述客户端返回追加写操作成功,所以用户不知道存储对应文件的三个块数据服务器什么时候将所述追加写操作的请求中携带的需要写入的数据,写入对应块数据服务器的LRU缓冲区中,也不需要等待存储对应文件的三个块数据服务器均将数据写入对应块数据服务器的LRU缓冲区后,在向存储对应文件的所有块数据服务器并行发送执行提交操作的请求,而是在满足需求状态后,在所述客户端业务逻辑需要时向存储对应文件的所有块数据服务器并行发送执行提交操作的请求即可。
需要说明的是,由于执行步骤S101时,所述客户端只需向从所述主服务器中获取的三个存储了对应文件的块数据服务器中的一个块数据服务器发送了执行追加写操作的请求后,就使所述客户端返回追加写操作成功,不能保证追加写操作将数据写入磁盘,所以在满足需求后,若所述块数据服务器没有接收到执行追加写操作的请求中携带的需要追加写入文件的数据或由于数据异常无法写入到磁盘时,所述客户端会再次调用追加写操作,向存储对应文件的块数据服务器发送执行追加写操作的请求,具体包括步骤S104-1至S104-2,下面结合附图3作进一步说明。
请参考图3,其示出了根据本申请的实施例提供的客户端再次调用追加写操作的流程图。
步骤S104-1,接收块数据服务器基于所述数据的状态向所述客户端反馈所述数据的状态信息。
在本实施例中,为了降低追加写操作的延迟,块数据服务器在接收到执行追加写操作的请求中携带的需要追加写入文件的数据后不会向所述客户端反馈所述数据的状态信息,所以在本步骤中,所述数据的状态信息为未收到数据,即:所述客户端若接收到块数据服务器基于所述数据的状态向所述客户端反馈所述数据的状态信息,则说明该块数据服务器没有接收到执行追加写操作的请求中携带的需要追加写入文件的数据或由于数据异常无法写入到磁盘。
需要说明的是,由于执行追加写操作的请求中携带的需要追加写入文件的数据会在存储对应文件的三个块数据服务器之间进行传递,所以在本步骤中,所述客户端接收的所述数据的状态信息可以是三个块数据服务器中的任意一个块数据服务器反馈的所述数据的状态信息。
步骤S104-2,向对应的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
由于本步骤与步骤S101的主要区别在于发送执行追加写操作的请求的时机不同,而发送执行追加写操作的请求的过程和发送的内容是相同的,由于在前面实施例中已经对此进行了比较详细的描述,所以此处不再赘述。
例如:存储对应文件的块数据服务器为块数据服务器A,块数据服务器B,块数据服务器C,若在步骤S102-1中是接收到块数据服务器B反馈的所述数据的状态信息,则在本步骤中是向块数据服务器B发送执行追加写操作的请求。
可以理解的,在满足需求后,由于追加写操作不能保证将数据写入磁盘,所以所述客户端可能还会向存储对应文件的块数据服务器发送多次执行追加写操作的请求。
需要说明的是,执行提交操作(commit)的请求的内部实现会确保等待存储对应文件的块数据服务器将所述追加写操作的请求中携带的需要写入的数据,写入对应块数据服务器的LRU缓冲区中后在执行提交操作(去主服务器提交当前文件的长度版本)。
此外,提交操作(commit)在等待存储对应文件的块数据服务器将所述追加写操作的请求的数据写入对应块数据服务器的LRU缓冲区时,在等待过程中可能会使请求失效,若在块数据服务器中的请求失效,则会向客户端反馈请求失效的信息,并触发客户端再次执行步骤S103向存储对应文件的所有块数据服务器并行发送执行提交操作的请求。
在本实施例中,所述需求是:对应文件的所有块数据服务器均成功通过追加写操作将所述追加写操作的请求中携带的需要写入的数据,写入对应块数据服务器的LRU缓冲区中,可以理解的,所述满足需求就是指:客户端接到对应文件的所有块数据服务器通过追加写操作将所述追加写操作的请求中携带的需要写入的数据成功写入的反馈信息。
所述向存储对应文件的所有块数据服务器并行发送执行提交操作的请求,可以采用如下方式实现:客户端通过TCP/IP连接等网络协议与三个存储了对应文件的块数据服务器同时进行连接后进行信息交互,所述客户端向建立了连接的三个块数据服务器并行发送执行提交操作的请求。例如:所述客户端通过以太网与所述块数据服务器进行连接。
需要说明的是,所述提交操作(commit)是力求数据安全的操作,在执行提交操作后,会将临时存储在块数据服务器的LRU缓冲区中的数据写入到该块数据服务器的磁盘中。
虽然提交操作能够确保将块数据服务器的LRU缓冲区中的数据写入到该块数据服务器的磁盘中,但是块数据服务器若出现硬件故障使块数据服务器不可用时,则客户端会向主服务器申请新的块数据服务器来替换不可用的块数据服务器。在所述向存储对应文件的所有块数据服务器并行发送执行提交操作的请求之后,具体包括如下步骤:
接收各个块数据服务器基于执行提交操作的结果反馈的提交信息;
若所述提交信息为失败,则向主服务器发送复制对应的块数据服务器到其他块数据服务器的请求。
具体的,块数据服务器出现丢失、宕机、损坏或某个磁盘故障都会使块数据服务器反馈内容为失败的提交信息。所述向主服务器发送复制对应的块数据服务器到其他块数据服务器的请求后,主服务器会将反馈提交信息为失败的块数据服务器复制到其它块数据服务器,从而确保块数据服务器连结一定的个数。
需要说明的是,在主服务器会将反馈提交信息为失败的块数据服务器复制到其它块数据服务器时,会继续执行使新的块数据服务器继续完成提交操作(commit)。
通过本申请实施例提供的一种客户端的数据写入方法,通过向存储对应文件的块数据服务器发送执行追加写操作的请求后,不等待各个块数据服务器的结果就使所述客户端返回追加写操作成功,降低追加写的延迟;并在满足需求后,向存储对应文件的所有块数据服务器并行发送执行提交操作的请求,节约了数据写入的时间,提高了系统的运算处理速度,从而提升了系统的吞吐率。
在上述的实施例中,提供了一种客户端的数据写入方法,与上述客户端的数据写入方法相对应的,本申请还提供了一种客户端的数据写入装置。由于装置的实施例基本相似于方法的实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。所述客户端的数据写入装置实施例如下:
请参考图4,其示出了根据本申请的实施例提供的客户端的数据写入装置的示意图。
所述客户端的数据写入装置,包括:追加写请求单元401以及提交单元403;
所述追加写请求单元401,用于向存储对应文件的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据;
所述提交单元403,用于在满足需求后,向存储对应文件的所有块数据服务器并行发送执行提交操作的请求。
可选的,所述客户端的数据写入装置,还包括:名称发送单元以及位置信息接收单元;
所述名称发送单元,用于在所述向存储对应文件的块数据服务器发送执行追加写操作的请求之前,向主服务器发送需要写入数据的文件的名称;
所述位置信息接收单元,用于接收所述主服务器发送的存储对应文件的所有块数据服务器的位置信息。
可选的,所述客户端的数据写入装置,还包括:位置信息存储单元;
所述位置信息存储单元,用于在所述接收所述主服务器发送的存储对应文件的所有块数据服务器的位置信息之前,在本地缓存中存储接收的所述主服务器发送的存储对应文件的所有块数据服务器的位置信息。
可选的,所述客户端的数据写入装置,还包括:顺序计算单元;
所述顺序计算单元,用于在所述向存储对应文件的块数据服务器发送执行追加写操作的请求之前,根据网络拓扑结构计算存储对应文件的所有块数据服务器的追加写入顺序。
可选的,所述追加写请求单元401,还包括:顺序发送子单元;
所述顺序发送子单元,用于向存储对应文件的块数据服务器发送执行追加写操作的请求时,向所述块数据服务器发送存储对应文件的所有块数据服务器的追加写入顺序。
可选的,所述客户端的数据写入装置,还包括:状态信息接收单元以及请求重发单元;
所述状态信息接收单元,用于向存储对应文件的块数据服务器发送执行追加写操作的请求之后,接收块数据服务器基于所述数据的状态向所述客户端反馈所述数据的状态信息;
所述请求重发单元,用于向对应的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
可选的,所述客户端的数据写入装置,还包括:提交信息接收单元以及块数据复制单元;
所述提交信息接收单元,用于向存储对应文件的所有块数据服务器并行发送执行提交操作的请求之后,接收各个块数据服务器基于执行提交操作的结果反馈的提交信息;
所述块数据复制单元,用于若所述提交信息为失败,则向主服务器发送复制对应的块数据服务器到其他块数据服务器的请求。
在上述的实施例中,提供了一种客户端的数据写入方法以及一种客户端的数据写入装置,此外,本申请还提供了一种电子设备;所述电子设备实施例如下:
请参考图5,其示出了根据本申请的实施例提供的电子设备的示意图。
所述电子设备,包括:显示器501;处理器503;存储器505;
所述存储器505,用于存储数据写入程序,所述程序在被所述处理器读取执行时,执行如下操作:向存储对应文件的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据;在满足需求后,向存储对应文件的所有块数据服务器并行发送执行提交操作的请求。
在上述的实施例中,提供了一种客户端的数据写入方法、一种客户端的数据写入装置以及一种电子设备,此外,本申请还提供了一种块数据服务器的数据处理方法;所述块数据服务器的数据处理方法实施例如下:
请参考图6,其示出了根据本申请的实施例提供的块数据服务器的数据处理方法的流程图。
所述块数据服务器的数据处理方法,包括:
步骤S601,接收客户端或者块数据服务器发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
在本实施例中,所述接收客户端或者块数据服务器发送的执行追加写操作的请求,可以采用如下方式实现:块数据服务器通过TCP/IP连接等网络协议与客户端或者其他块数据服务器连接后进行信息交互,接收所述客户端或者其他块数据服务器发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据。例如:所述客户端通过以太网与所述块数据服务器进行连接。
可以理解的,本步骤是由存储对应文件的块数据服务器执行,可以是三个块数据服务器中的任意一个。相对应的,若该块数据服务器在网络拓扑结构中与所述客户端的距离最近,则在本步骤中是接收客户端发送的执行追加写操作的请求;其他块数据服务器则是接收与所述客户端的距离最近的块数据服务器或另一块数据服务器转发的执行追加写操作的请求。
需要说明的是,所述块数据服务器再接收到执行追加写操作的请求后,会把所述请求中携带的需要追加写入文件的数据存储在本地LRU缓冲区中作为临时数据。LRU称为近期最少使用置换算法,是内存管理的一种页面置换算法,对于在内存中但又不用的块数据(内存块)叫做LRU,操作系统会根据哪些数据属于LRU而将其移出内存而腾出空间来加载另外的数据。
为了使执行追加写操作的请求中携带的需要追加写入文件的数据在所有块数据服务器中以流水线的方式传递下去,每个块数据服务器在接收执行追加写操作的请求的同时,还需接收存储对应文件的所有块数据服务器的追加写入顺序,使所述执行追加写操作的请求中携带的需要追加写入文件的数据按照计算出的追加写入顺序在储对应文件的块数据服务器间进行传递。所述追加写入顺序是根据网络拓扑结构中各块数据服务器的位置按照距离由近至远的顺序,按照块数据服务器的ip地址进行排序的序列。
在所述接收客户端或者块数据服务器发送的执行追加写操作的请求之后,块数据服务器根据追加写入顺序向下一个块数据服务器发送的执行追加写操作的请求,具体包括如下步骤:
在存储对应文件的所有块数据服务器的追加写入顺序中获取位于当前块数据服务器之后的块数据服务器的位置,向该块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
具体的,由于追加写入顺序中是按照块数据服务器的ip地址进行排序的序列,本地块数据服务器通过自己的ip获取在所述追加写入顺序中的位置,并判断在所述追加写入顺序中是否还有位于在所述位置之后的块数据服务器的ip地址,若是则向该ip地址的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
例如:所述追加写入顺序中存储的序列为ip1,ip2,ip3,则本地块数据服务器通过自己的ip2查询出自己位于所述写入顺序的第二位置,由于在第二位置后还有第三位置,则本地块数据服务器通过对应第三位置的ip3向该ip地址的块数据服务器发送执行追加写操作的请求。
由于在步骤S601中,接收的是执行追加写操作的请求,且追加写操作不能保证将数据写入磁盘,所以在步骤S601接收客户端或者块数据服务器发送的执行追加写操作的请求之后,各个块数据服务器需要判断执行追加写操作的请求中的数据的状态,具体包括步骤S602-1至S602-3,下面结合附图7作进一步说明。
请参考图7,其示出了根据本申请的实施例提供的判断执行追加写操作的请求中的数据的状态的流程图。
步骤S602-1,判断执行追加写操作的请求中的数据的状态。
在本实施例中,所述判断执行追加写操作的请求中的数据的状态,可以采用如下方式实现:在当前块数据服务器的LRU缓冲区中读取数据,判断是否有请求中携带的需要追加写入文件的数据,若是,则说明当前块数据服务器成功接收到需要追加写入文件的数据;若否,则说明当前块数据服务器未收到数据,所述数据的状态为未收到数据,触发步骤S602-2。
步骤S602-2,若所述数据的状态为未收到数据,则基于所述数据的状态向所述客户端反馈所述数据的状态信息。
当前块数据服务器通过TCP/IP连接等网络协议与客户端连接后,将内容为未收到数据的状态信息反馈给所述客户端。
步骤S602-3,接收所述客户端基于所述数据的状态信息发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
所述接收所述客户端基于所述数据的状态信息发送的执行追加写操作的请求,可以采用如下方式实现:块数据服务器通过TCP/IP连接等网络协议与客户端连接后进行信息交互,接收所述客户端发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据。例如:所述客户端通过以太网与所述块数据服务器进行连接。
下面以一个具体例子详细说明执行追加写操作的请求中携带的需要追加写入文件的数据在所有块数据服务器中以流水线的方式传递的过程。
存储对应文件的块数据服务器在网络拓扑结构中,与客户端的距离由近至远为:块数据服务器A,块数据服务器B,块数据服务器C,则块数据服务器A与客户端建立网络链接,接收客户端发送的存储对应文件的所有块数据服务器的追加写入顺序以及执行追加写操作的请求;所述请求携带需要追加写入文件的数据;块数据服务器A判断是否接收到所述数据,若是则把数据写入LRU缓冲区中,若否,则基于所述数据的状态向所述客户端反馈所述数据的状态信息,并接收所述客户端基于所述数据的状态信息发送的执行追加写操作的请求;重复上述判断步骤直至把数据写入LRU缓冲区中,块数据服务器A解析所述追加写入顺序从中提取下一台块数据服务器的ip地址,并向该ip地址的块数据服务器B发送存储对应文件的所有块数据服务器的追加写入顺序以及执行追加写操作的请求;块数据服务器B接收块数据服务器A发送的存储对应文件的所有块数据服务器的追加写入顺序以及执行追加写操作的请求;块数据服务器B判断是否接收到所述数据,若是则把数据写入LRU缓冲区中,若否,则基于所述数据的状态向所述客户端反馈所述数据的状态信息,并接收所述客户端基于所述数据的状态信息发送的执行追加写操作的请求;重复上述判断步骤直至把数据写入LRU缓冲区中,块数据服务器B解析所述追加写入顺序从中提取下一台块数据服务器的ip地址,并向该ip地址的块数据服务器C发送存储对应文件的所有块数据服务器的追加写入顺序以及执行追加写操作的请求;块数据服务器C接收块数据服务器B发送的存储对应文件的所有块数据服务器的追加写入顺序以及执行追加写操作的请求;块数据服务器C判断是否接收到所述数据,若是则把数据写入LRU缓冲区中,若否,则基于所述数据的状态向所述客户端反馈所述数据的状态信息,并接收所述客户端基于所述数据的状态信息发送的执行追加写操作的请求;重复上述判断步骤直至把数据写入LRU缓冲区中,块数据服务器C解析所述追加写入顺序判断所述追加写入顺序中没有为接收数据的ip地址后,即:在块数据服务器C的ip地址后没有其他的ip地址,则说明存储对应文件的所有块数据服务器完成了执行追加写操作。
步骤S603,接收客户端发送的执行提交操作的请求。
在本实施例中,所述接收客户端发送的执行提交操作的请求,可以采用如下方式实现:块数据服务器通过TCP/IP连接等网络协议与客户端进行连接后进行信息交互,当前块数据服务器接收客户端发送的执行提交操作的请求。例如:所述客户端通过以太网与所述块数据服务器进行连接。
需要说明的是,所述提交操作(commit)是力求数据安全的操作,在执行提交操作后,会将临时存储在块数据服务器的LRU缓冲区中的数据写入到该块数据服务器的磁盘中。
需要说明的是,在执行步骤S603所述接收客户端发送的执行提交操作的请求后,提交操作(commit)的请求的内部实现会判断存储对应文件的块数据服务器是否将所述追加写操作的请求中的数据写入对应块数据服务器的LRU缓冲区中,若是,则触发步骤S605;若否,则等待块数据服务器将所述追加写操作的请求中的数据写入对应块数据服务器的LRU缓冲区中。
此外,提交操作(commit)在等待存储对应文件的块数据服务器将所述追加写操作的请求的数据写入对应块数据服务器的LRU缓冲区时,在等待过程中可能会使请求失效,若在块数据服务器中的请求失效,则会向客户端反馈请求失效的信息。
可以理解的,本步骤是存储对应文件的三个块数据服务器直接接收所述客户端发送的执行提交操作的请求,将传统的提交操作的处理流程从客户端->块数据服务器A->块数据服务器B->块数据服务器C,替换为客户端->块数据服务器A,客户端->块数据服务器B,客户端->块数据服务器C,使每个块数据服务器在相同时间同时将数据写入到本地硬盘中,节约了时间,提高了系统的运算处理速度,从而提升了系统的吞吐率。
步骤S605,将所述数据进行写入。
在本实施例中,所述将所述数据进行写入,可以采用如下方式实现:通过执行在步骤S603接收到所述执行提交操作的请求,对当前块数据服务器执行临时存储在块数据服务器的LRU缓冲区中的数据写入到该块数据服务器的磁盘中的操作。
虽然提交操作能够确保将块数据服务器的LRU缓冲区中的数据写入到该块数据服务器的磁盘中,但是块数据服务器若出现硬件故障使块数据服务器不可用时,还是无法将数据进行写入,所以在步骤S605将所述数据进行写入之后,需要向客户端反馈基于执行提交操作的结果的提交信息。其中,若所述数据写入成功,则向客户端反馈内容为成功的提交信息;若所述数据写入失败,则向客户端反馈内容为失败的提交信息。
需要说明的是,所述块数据服务器无法将数据进行写入的情况包括:块数据服务器出现丢失、宕机、损坏或某个磁盘故障。
通过本申请实施例提供的一种块数据服务器的数据处理方法,通过使每个块数据服务器在相同时间同时将数据写入到本地硬盘中,节约了时间,提高了系统的运算处理速度,从而提升了系统的吞吐率。
在上述的实施例中,提供了一种块数据服务器的数据处理方法,与上述块数据服务器的数据处理方法相对应的,本申请还提供了一种块数据服务器的数据处理装置。由于装置的实施例基本相似于方法的实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。所述块数据服务器的数据处理装置实施例如下:
请参考图8,其示出了根据本申请的实施例提供的块数据服务器的数据处理装置的示意图。
所述块数据服务器的数据处理装置,包括:追加写请求接收单元801、提交请求接收单元803以及写入单元805;
所述追加写请求接收单元801,用于接收客户端或者块数据服务器发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据;
所述提交请求接收单元803,用于接收客户端发送的执行提交操作的请求;
所述写入单元805,用于将所述数据进行写入。
可选的,所述块数据服务器的数据处理装置,还包括:顺序接收单元;
所述顺序接收单元,用于在所述接收客户端或者块数据服务器发送的执行追加写操作的请求时,接收所述客户端或者块数据服务器发送的存储对应文件的所有块数据服务器的追加写入顺序。
可选的,所述块数据服务器的数据处理装置,还包括:追加写请求发送单元;
所述追加写请求发送单元,用于在所述接收客户端或者块数据服务器发送的执行追加写操作的请求之后,在存储对应文件的所有块数据服务器的追加写入顺序中获取位于当前块数据服务器之后的块数据服务器的位置,向该块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
可选的,所述块数据服务器的数据处理装置,还包括:数据状态判断单元、状态信息反馈单元以及追加写请求重新接收单元;
所述数据状态判断单元,用于在所述接收客户端或者块数据服务器发送的执行追加写操作的请求之后,判断执行追加写操作的请求中的数据的状态;
所述状态信息反馈单元,用于接收所述数据状态判断单元的判断结果,若所述数据的状态为未收到数据,则基于所述数据的状态向所述客户端反馈所述数据的状态信息;
所述追加写请求重新接收单元,用于接收所述客户端基于所述数据的状态信息发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
可选的,所述块数据服务器的数据处理装置,还包括:提交信息反馈单元;
所述提交信息反馈单元,用于在所述将所述数据进行写入之后,向客户端反馈基于执行提交操作的结果的提交信息。
在上述的实施例中,提供了一种客户端的数据写入方法、一种客户端的数据写入装置、一种电子设备、一种块数据服务器的数据处理方法以及一种块数据服务器的数据处理装置,此外,本申请还提供了另一种电子设备;所述电子设备实施例如下:
请参考图9,其示出了根据本申请的实施例提供的电子设备的示意图。
所述电子设备,包括:显示器901;处理器903;存储器905;
所述存储器905,用于存储数据处理程序,所述程序在被所述处理器读取执行时,执行如下操作:接收客户端或者块数据服务器发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据;接收客户端发送的执行提交操作的请求;将所述数据进行写入。
在上述的实施例中,提供了一种客户端的数据写入方法、一种客户端的数据写入装置、一种电子设备、一种块数据服务器的数据处理方法、一种块数据服务器的数据处理装置以及另一种电子设备,此外,本申请还提供了一种分布式文件系统;所述分布式文件系统实施例如下:
请参考图10,其示出了根据本申请的实施例提供的分布式文件系统的示意图。
所述分布式文件系统,包括:客户端的数据写入装置1001以及块数据服务器的数据处理装置1003;
其中,所述客户端的数据写入装置1001,用于向存储对应文件的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据,并在满足需求后,向存储对应文件的所有块数据服务器并行发送执行提交操作的请求;
所述块数据服务器的数据处理装置1003,用于接收客户端或者块数据服务器发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据,接收客户端发送的执行提交操作的请求,并将所述数据进行写入。
所述客户端的数据写入装置1001以及所述块数据服务器的数据处理装置1003均可以布置于计算机上,但并不局限于这种设备,可以是能够实现上述方法的任何设备,其中,所述客户端的数据写入装置1001和所述块数据服务器的数据处理装置1003通常是运行用户层服务进程的Linux机器。
在上述的实施例中,提供了一种客户端的数据写入方法、一种客户端的数据写入装置、一种电子设备、一种块数据服务器的数据处理方法、一种块数据服务器的数据处理装置、另一种电子设备以及一种分布式文件系统,此外,本申请还提供了一种基于分布式文件系统的数据写入方法;所述基于分布式文件系统的数据写入方法实施例如下:
请参考图11,其示出了根据本申请的实施例提供的基于分布式文件系统的数据写入方法的流程图。
所述基于分布式文件系统的数据写入方法,包括:
步骤S1101,客户端向存储对应文件的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
在本实施例中,所述客户端向存储对应文件的块数据服务器发送执行追加写操作的请求,可以采用如下方式实现:客户端通过TCP/IP连接等网络协议与三个存储了对应文件的块数据服务器中的一个连接后进行信息交互,所述客户端向建立了连接的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据。例如:所述客户端通过以太网与所述块数据服务器进行连接。
在本实施例中,所述客户端只需向从所述主服务器中获取的三个存储了对应文件的块数据服务器中的一个块数据服务器发送执行追加写操作的请求后,就使所述客户端返回追加写操作成功,降低追加写的延迟。需要说明的是,现有的执行追加写操作是:所述客户端接收到三个存储了对应文件的块数据服务器都成功接收数据后,发送的确认信息,使所述客户端返回追加写操作成功。
步骤S1103,所述块数据服务器接收客户端或者块数据服务器发送的执行追加写操作的请求。
在本实施例中,所述块数据服务器接收客户端或者块数据服务器发送的执行追加写操作的请求,可以采用如下方式实现:块数据服务器通过TCP/IP连接等网络协议与客户端或者其他块数据服务器连接后进行信息交互,接收所述客户端或者其他块数据服务器发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据。例如:所述客户端通过以太网与所述块数据服务器进行连接。
可以理解的,本步骤是由存储对应文件的块数据服务器执行,可以是三个块数据服务器中的任意一个。相对应的,若该块数据服务器在网络拓扑结构中与所述客户端的距离最近,则在本步骤中是接收客户端发送的执行追加写操作的请求;其他块数据服务器则是接收与所述客户端的距离最近的块数据服务器或另一块数据服务器转发的执行追加写操作的请求。
需要说明的是,所述块数据服务器再接收到执行追加写操作的请求后,会把所述请求中携带的需要追加写入文件的数据存储在本地LRU缓冲区中作为临时数据。LRU称为近期最少使用置换算法,是内存管理的一种页面置换算法,对于在内存中但又不用的块数据(内存块)叫做LRU,操作系统会根据哪些数据属于LRU而将其移出内存而腾出空间来加载另外的数据。
由于在步骤S1103中,接收的是执行追加写操作的请求,且追加写操作不能保证将数据写入磁盘,所以在步骤S1103块数据服务器接收客户端或者块数据服务器发送的执行追加写操作的请求之后,各个块数据服务器需要判断执行追加写操作的请求中的数据的状态,具体包括步骤S1104-1至S1104-5,下面结合附图12作进一步说明。
请参考图12,其示出了根据本申请的实施例提供的块数据服务器判断执行追加写操作的请求中的数据的状态的流程图。
步骤S1104-1,当前块数据服务器判断执行追加写操作的请求中的数据的状态。
在本实施例中,所述当前块数据服务器判断执行追加写操作的请求中的数据的状态,可以采用如下方式实现:在当前块数据服务器的LRU缓冲区中读取数据,判断是否有请求中携带的需要追加写入文件的数据,若是,则说明当前块数据服务器成功接收到需要追加写入文件的数据;若否,则说明当前块数据服务器未收到数据,所述数据的状态为未收到数据,触发步骤S1104-2。
步骤S1104-2,若所述数据的状态为未收到数据,则基于所述数据的状态向所述客户端反馈所述数据的状态信息。
当前块数据服务器通过TCP/IP连接等网络协议与客户端连接后,将内容为未收到数据的状态信息反馈给所述客户端。
步骤S1104-3,所述客户端接收块数据服务器基于所述数据的状态反馈的所述数据的状态信息。
在本实施例中,所述数据的状态信息为未收到数据,即:所述客户端若接收到块数据服务器基于所述数据的状态向所述客户端反馈所述数据的状态信息,则说明该块数据服务器没有接收到执行追加写操作的请求中携带的需要追加写入文件的数据或由于数据异常无法写入到磁盘。
需要说明的是,由于执行追加写操作的请求中携带的需要追加写入文件的数据会在存储对应文件的三个块数据服务器之间进行传递,所以在本步骤中,所述客户端接收的所述数据的状态信息可以是三个块数据服务器中的任意一个块数据服务器反馈的所述数据的状态信息。
步骤S1104-4,向对应的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
由于本步骤与步骤S1101的主要区别在于发送执行追加写操作的请求的时机不同,而发送执行追加写操作的请求的过程和发送的内容是相同的,由于在前面实施例中已经对此进行了比较详细的描述,所以此处不再赘述。
例如:存储对应文件的块数据服务器为块数据服务器A,块数据服务器B,块数据服务器C,若在步骤S1104-3中是接收到块数据服务器B反馈的所述数据的状态信息,则在本步骤中是向块数据服务器B发送执行追加写操作的请求。
步骤S1104-5,块数据服务器接收所述客户端基于所述数据的状态信息发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
由于本步骤与步骤S1103中的接收执行追加写操作的请求的过程和发送的内容是相同的,由于在前面实施例中已经对此进行了比较详细的描述,所以此处不再赘述。
步骤S1105,在满足需求后,所述客户端向存储对应文件的所有块数据服务器并行发送执行提交操作的请求。
在本实施例中,所述需求是:客户端向存储对应文件的块数据服务器发送出执行追加写操作的请求。可以理解的,所述满足需求就是指:客户端向存储对应文件的块数据服务器发送出执行追加写操作的请求后的状态,但是由于客户端在发出执行追加写操作的请求后,就使所述客户端返回追加写操作成功,所以用户不知道存储对应文件的三个块数据服务器什么时候将所述追加写操作的请求中携带的需要写入的数据,写入对应块数据服务器的LRU缓冲区中,也不需要等待存储对应文件的三个块数据服务器均将数据写入对应块数据服务器的LRU缓冲区后,在向存储对应文件的所有块数据服务器并行发送执行提交操作的请求,而是在满足需求状态后,在所述客户端业务逻辑需要时向存储对应文件的所有块数据服务器并行发送执行提交操作的请求即可。
所述客户端向存储对应文件的所有块数据服务器并行发送执行提交操作的请求,可以采用如下方式实现:客户端通过TCP/IP连接等网络协议与三个存储了对应文件的块数据服务器同时进行连接后进行信息交互,所述客户端向建立了连接的三个块数据服务器并行发送执行提交操作的请求。例如:所述客户端通过以太网与所述块数据服务器进行连接。
步骤S1107,存储对应文件的各个块数据服务器接收客户端发送的执行提交操作的请求。
在本实施例中,所述存储对应文件的各个块数据服务器接收客户端发送的执行提交操作的请求,可以采用如下方式实现:各个块数据服务器通过TCP/IP连接等网络协议与客户端进行连接后进行信息交互,各个块数据服务器接收客户端发送的执行提交操作的请求。例如:所述客户端通过以太网与所述块数据服务器进行连接。
可以理解的,本步骤是存储对应文件的三个块数据服务器直接接收所述客户端发送的执行提交操作的请求,将传统的提交操作的处理流程从客户端->块数据服务器A->块数据服务器B->块数据服务器C,替换为客户端->块数据服务器A,客户端->块数据服务器B,客户端->块数据服务器C。
步骤S1109,接收到所述执行提交操作的请求的块数据服务器将所述执行追加写操作的请求携带的数据进行写入。
在本实施例中,所述将所述数据进行写入,可以采用如下方式实现:通过执行在步骤S1107接收到所述执行提交操作的请求,对当前块数据服务器执行临时存储在块数据服务器的LRU缓冲区中的数据写入到该块数据服务器的磁盘中的操作。
虽然提交操作能够确保将块数据服务器的LRU缓冲区中的数据写入到该块数据服务器的磁盘中,但是块数据服务器若出现硬件故障使块数据服务器不可用时,还是无法将数据进行写入,所以在步骤S1109,接收到所述执行提交操作的请求的块数据服务器将所述执行追加写操作的请求携带的数据进行写入之后,需要向客户端反馈基于执行提交操作的结果的提交信息,具体包括如下步骤:
接收到所述执行提交操作的请求的块数据服务器向客户端反馈基于执行提交操作的结果的提交信息;
所述客户端接收各个块数据服务器基于执行提交操作的结果反馈的提交信息;
若所述提交信息为失败,则向主服务器发送复制对应的块数据服务器到其他块数据服务器的请求。
可以理解的,若所述数据写入成功,则向客户端反馈内容为成功的提交信息;若所述数据写入失败,则向客户端反馈内容为失败的提交信息。所述向主服务器发送复制对应的块数据服务器到其他块数据服务器的请求后,主服务器会将反馈提交信息为失败的块数据服务器复制到其它块数据服务器,从而确保块数据服务器连结一定的个数。
需要说明的是,所述块数据服务器无法将数据进行写入的情况包括:块数据服务器出现丢失、宕机、损坏或某个磁盘故障。
在上述的实施例中,提供了一种基于分布式文件系统的数据写入方法,与上述基于分布式文件系统的数据写入方法相对应的,本申请还提供了一种基于分布式文件系统的数据写入装置。由于装置的实施例基本相似于方法的实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。所述基于分布式文件系统的数据写入装置实施例如下:
请参考图13,其示出了根据本申请的实施例提供的基于分布式文件系统的数据写入装置的示意图。
所述基于分布式文件系统的数据写入装置,包括:追加写请求发送单元1301、追加写请求接收单元1303、提交请求发送单元1305、提交请求接收单元1307以及数据写入单元1309;
所述追加写请求发送单元1301,用于客户端向存储对应文件的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据;
所述追加写请求接收单元1303,用于所述块数据服务器接收客户端或者块数据服务器发送的执行追加写操作的请求;
所述提交请求发送单元1305,用于在满足需求后,所述客户端向存储对应文件的所有块数据服务器并行发送执行提交操作的请求;
所述提交请求接收单元1307,用于存储对应文件的各个块数据服务器接收客户端发送的执行提交操作的请求;
所述数据写入单元1309,用于接收到所述执行提交操作的请求的块数据服务器将所述执行追加写操作的请求携带的数据进行写入。
可选的,所述基于分布式文件系统的数据写入装置,包括:
所述数据状态判断单元,用于在所述块数据服务器接收客户端或者块数据服务器发送的执行追加写操作的请求之前,当前块数据服务器判断执行追加写操作的请求中的数据的状态;
所述状态反馈单元,用于若所述数据的状态为未收到数据,则基于所述数据的状态向所述客户端反馈所述数据的状态信息;
所述状态接收单元,用于所述客户端接收块数据服务器基于所述数据的状态反馈的所述数据的状态信息;
所述请求重发单元,用于向对应的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据;
所述重新接收单元,用于块数据服务器接收所述客户端基于所述数据的状态信息发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
可选的,所述基于分布式文件系统的数据写入装置,包括:
所述提交信息反馈单元,用于在所述接收到所述执行提交操作的请求的块数据服务器将所述执行追加写操作的请求携带的数据进行写入之后,接收到所述执行提交操作的请求的块数据服务器向客户端反馈基于执行提交操作的结果的提交信息;
所述提交信息接收单元,用于所述客户端接收各个块数据服务器基于执行提交操作的结果反馈的提交信息;
所述复制单元,用于若所述提交信息为失败,则向主服务器发送复制对应的块数据服务器到其他块数据服务器的请求。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括非暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
2、本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请虽然以较佳实施例公开如上,但其并不是用来限定本申请,任何本领域技术人员在不脱离本申请的精神和范围内,都可以做出可能的变动和修改,因此本申请的保护范围应当以本申请权利要求所界定的范围为准。
Claims (33)
1.一种客户端的数据写入方法,其特征在于,包括:
向存储对应文件的块数据服务器发送执行追加写操作的请求后,即返回追加写操作成功的响应;所述请求携带需要追加写入文件的数据;所述块数据服务器是指从主服务器中获取的多个储存了对应文件的块数据服务器中的一个;
在满足需求后,向存储对应文件的所有块数据服务器并行发送执行提交操作的请求,所述满足需求是指向多个存储对应文件的块数据服务器中的一个发送执行追加写操作的请求后,即返回追加写操作成功的状态。
2.根据权利要求1所述的客户端的数据写入方法,其特征在于,在所述向存储对应文件的块数据服务器发送执行追加写操作的请求的步骤之前,还包括:
向主服务器发送需要写入数据的文件的名称;
接收所述主服务器发送的存储对应文件的所有块数据服务器的位置信息。
3.根据权利要求2所述的客户端的数据写入方法,其特征在于,在所述接收所述主服务器发送的存储对应文件的所有块数据服务器的位置信息的步骤之后,包括:
在本地缓存中存储接收的所述主服务器发送的存储对应文件的所有块数据服务器的位置信息。
4.根据权利要求2所述的客户端的数据写入方法,其特征在于,在所述向存储对应文件的块数据服务器发送执行追加写操作的请求的步骤之前,包括:
根据网络拓扑结构计算存储对应文件的所有块数据服务器的追加写入顺序。
5.根据权利要求4所述的客户端的数据写入方法,其特征在于,在所述向存储对应文件的块数据服务器发送执行追加写操作的请求时,还包括:
向所述块数据服务器发送存储对应文件的所有块数据服务器的追加写入顺序。
6.根据权利要求1所述的客户端的数据写入方法,其特征在于,在所述向存储对应文件的块数据服务器发送执行追加写操作的请求的步骤之后,包括:
接收块数据服务器基于所述数据的状态向所述客户端反馈所述数据的状态信息;所述数据的状态信息是指未收到数据的状态;
向对应的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
7.根据权利要求1所述的客户端的数据写入方法,其特征在于,在所述向存储对应文件的所有块数据服务器并行发送执行提交操作的请求的步骤之后,包括:
接收各个块数据服务器基于执行提交操作的结果反馈的提交信息;
若所述提交信息为失败,则向主服务器发送复制对应的块数据服务器到其他块数据服务器的请求。
8.一种客户端的数据写入装置,其特征在于,包括:
追加写请求单元,用于向存储对应文件的块数据服务器发送执行追加写操作的请求后,即返回追加写操作成功的响应;所述请求携带需要追加写入文件的数据;所述块数据服务器是指从主服务器中获取的多个储存了对应文件的块数据服务器中的一个;
提交单元,用于在满足需求后,向存储对应文件的所有块数据服务器并行发送执行提交操作的请求,所述满足需求是指向多个存储对应文件的块数据服务器中的一个发送执行追加写操作的请求后,即返回追加写操作成功的状态。
9.根据权利要求8所述的客户端的数据写入装置,其特征在于,还包括:
名称发送单元,用于在所述向存储对应文件的块数据服务器发送执行追加写操作的请求之前,向主服务器发送需要写入数据的文件的名称;
位置信息接收单元,用于接收所述主服务器发送的存储对应文件的所有块数据服务器的位置信息。
10.根据权利要求9所述的客户端的数据写入装置,其特征在于,还包括:
位置信息存储单元,用于在所述接收所述主服务器发送的存储对应文件的所有块数据服务器的位置信息之前,在本地缓存中存储接收的所述主服务器发送的存储对应文件的所有块数据服务器的位置信息。
11.根据权利要求9所述的客户端的数据写入装置,其特征在于,还包括:
顺序计算单元,用于在所述向存储对应文件的块数据服务器发送执行追加写操作的请求之前,根据网络拓扑结构计算存储对应文件的所有块数据服务器的追加写入顺序。
12.根据权利要求11所述的客户端的数据写入装置,其特征在于,所述追加写请求单元,还包括:
顺序发送子单元,用于向存储对应文件的块数据服务器发送执行追加写操作的请求时,向所述块数据服务器发送存储对应文件的所有块数据服务器的追加写入顺序。
13.根据权利要求8所述的客户端的数据写入装置,其特征在于,还包括:
状态信息接收单元,用于向存储对应文件的块数据服务器发送执行追加写操作的请求之后,接收块数据服务器基于所述数据的状态向所述客户端反馈所述数据的状态信息;所述数据的状态信息是指未收到数据的状态;
请求重发单元,用于向对应的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
14.根据权利要求8所述的客户端的数据写入装置,其特征在于,还包括:
提交信息接收单元,用于向存储对应文件的所有块数据服务器并行发送执行提交操作的请求之后,接收各个块数据服务器基于执行提交操作的结果反馈的提交信息;
块数据复制单元,用于若所述提交信息为失败,则向主服务器发送复制对应的块数据服务器到其他块数据服务器的请求。
15.一种电子设备,其特征在于,所述电子设备包括:
显示器;
处理器;
存储器,用于存储数据写入程序,所述程序在被所述处理器读取执行时,执行如下操作:向存储对应文件的块数据服务器发送执行追加写操作的请求后,即返回追加写操作成功的响应;所述请求携带需要追加写入文件的数据;在满足需求后,向存储对应文件的所有块数据服务器并行发送执行提交操作的请求,所述满足需求是指向多个存储对应文件的块数据服务器中的一个发送执行追加写操作的请求后,即返回追加写操作成功的状态;所述块数据服务器是指从主服务器中获取的多个储存了对应文件的块数据服务器中的一个。
16.一种块数据服务器的数据处理方法,其特征在于,包括:在客户端发送执行追加写操作的请求后,即接收客户端或者块数据服务器发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据;
接收客户端向存储对应文件的所有块数据服务器并行发送的执行提交操作的请求;
将所述数据进行写入。
17.根据权利要求16所述的块数据服务器的数据处理方法,其特征在于,在所述接收客户端或者块数据服务器发送的执行追加写操作的请求时,还包括:
接收所述客户端或者块数据服务器发送的存储对应文件的所有块数据服务器的追加写入顺序。
18.根据权利要求17所述的块数据服务器的数据处理方法,其特征在于,在所述接收客户端或者块数据服务器发送的执行追加写操作的请求的步骤之后,包括:
在存储对应文件的所有块数据服务器的追加写入顺序中获取位于当前块数据服务器之后的块数据服务器的位置,向该块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
19.根据权利要求16所述的块数据服务器的数据处理方法,其特征在于,在所述接收客户端或者块数据服务器发送的执行追加写操作的请求的步骤之后,包括:
判断执行追加写操作的请求中的数据的状态;
若所述数据的状态为未收到数据,则基于所述数据的状态向所述客户端反馈所述数据的状态信息;
接收所述客户端基于所述数据的状态信息发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
20.根据权利要求16所述的块数据服务器的数据处理方法,其特征在于,在所述将所述数据进行写入的步骤之后,包括:
向客户端反馈基于执行提交操作的结果的提交信息。
21.一种块数据服务器的数据处理装置,其特征在于,包括:
追加写请求接收单元,用于在客户端发送执行追加写操作的请求后,即接收客户端或者块数据服务器发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据;提交请求接收单元,用于接收客户端向存储对应文件的所有块数据服务器并行发送的执行提交操作的请求;
写入单元,用于将所述数据进行写入。
22.根据权利要求21所述的块数据服务器的数据处理装置,其特征在于,还包括:
顺序接收单元,用于在所述接收客户端或者块数据服务器发送的执行追加写操作的请求时,接收所述客户端或者块数据服务器发送的存储对应文件的所有块数据服务器的追加写入顺序。
23.根据权利要求22所述的块数据服务器的数据处理装置,其特征在于,还包括:
追加写请求发送单元,用于在所述接收客户端或者块数据服务器发送的执行追加写操作的请求之后,在存储对应文件的所有块数据服务器的追加写入顺序中获取位于当前块数据服务器之后的块数据服务器的位置,向该块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
24.根据权利要求21所述的块数据服务器的数据处理装置,其特征在于,还包括:
数据状态判断单元,用于在所述接收客户端或者块数据服务器发送的执行追加写操作的请求之后,判断执行追加写操作的请求中的数据的状态;
状态信息反馈单元,用于接收所述数据状态判断单元的判断结果,若所述数据的状态为未收到数据,则基于所述数据的状态向所述客户端反馈所述数据的状态信息;
追加写请求重新接收单元,用于接收所述客户端基于所述数据的状态信息发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
25.根据权利要求21所述的块数据服务器的数据处理装置,其特征在于,还包括:
提交信息反馈单元,用于在所述将所述数据进行写入之后,向客户端反馈基于执行提交操作的结果的提交信息。
26.一种电子设备,其特征在于,所述电子设备包括:
显示器;
处理器;
存储器,用于存储数据处理程序,所述程序在被所述处理器读取执行时,执行如下操作:在客户端发送执行追加写操作的请求后,即接收客户端或者块数据服务器发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据;接收客户端向存储对应文件的所有块数据服务器并行发送的执行提交操作的请求;将所述数据进行写入。
27.一种分布式文件系统,其特征在于,包括:
根据上述权利要求8至14中任一项所述的客户端的数据写入装置;以及
根据权利要求21至26中任一项所述的块数据服务器的数据处理装置。
28.一种基于分布式文件系统的数据写入方法,其特征在于,包括:
客户端向存储对应文件的块数据服务器发送执行追加写操作的请求后,即返回追加写操作成功的响应;所述请求携带需要追加写入文件的数据;所述块数据服务器是指从主服务器中获取的多个储存了对应文件的块数据服务器中的一个;
所述块数据服务器接收客户端或者块数据服务器发送的执行追加写操作的请求;
在满足需求后,所述客户端向存储对应文件的所有块数据服务器并行发送执行提交操作的请求,所述满足需求是指向多个存储对应文件的块数据服务器中的一个发送执行追加写操作的请求后,即返回追加写操作成功的状态;
存储对应文件的各个块数据服务器接收客户端发送的执行提交操作的请求;
接收到所述执行提交操作的请求的块数据服务器将所述执行追加写操作的请求携带的数据进行写入。
29.根据权利要求28所述的基于分布式文件系统的数据写入方法,其特征在于,在所述块数据服务器接收客户端或者块数据服务器发送的执行追加写操作的请求的步骤之后,包括:
当前块数据服务器判断执行追加写操作的请求中的数据的状态;
若所述数据的状态为未收到数据,则基于所述数据的状态向所述客户端反馈所述数据的状态信息;
所述客户端接收块数据服务器基于所述数据的状态反馈的所述数据的状态信息;
向对应的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据;
块数据服务器接收所述客户端基于所述数据的状态信息发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
30.根据权利要求28所述的基于分布式文件系统的数据写入方法,其特征在于,在所述接收到所述执行提交操作的请求的块数据服务器将所述执行追加写操作的请求携带的数据进行写入的步骤之后,包括:
接收到所述执行提交操作的请求的块数据服务器向客户端反馈基于执行提交操作的结果的提交信息;
所述客户端接收各个块数据服务器基于执行提交操作的结果反馈的提交信息;
若所述提交信息为失败,则向主服务器发送复制对应的块数据服务器到其他块数据服务器的请求。
31.一种基于分布式文件系统的数据写入装置,其特征在于,包括:
追加写请求发送单元,用于客户端向存储对应文件的块数据服务器发送执行追加写操作的请求后,即返回追加写操作成功的响应;所述请求携带需要追加写入文件的数据;所述块数据服务器是指从主服务器中获取的多个储存了对应文件的块数据服务器中的一个;
追加写请求接收单元,用于所述块数据服务器接收客户端或者块数据服务器发送的执行追加写操作的请求;
提交请求发送单元,用于在满足需求后,所述客户端向存储对应文件的所有块数据服务器并行发送执行提交操作的请求,所述满足需求是指向多个存储对应文件的块数据服务器中的一个发送执行追加写操作的请求后,即返回追加写操作成功的状态;
提交请求接收单元,用于存储对应文件的各个块数据服务器接收客户端发送的执行提交操作的请求;
数据写入单元,用于接收到所述执行提交操作的请求的块数据服务器将所述执行追加写操作的请求携带的数据进行写入。
32.根据权利要求31所述的基于分布式文件系统的数据写入装置,其特征在于,包括:
数据状态判断单元,用于在所述块数据服务器接收客户端或者块数据服务器发送的执行追加写操作的请求之前,当前块数据服务器判断执行追加写操作的请求中的数据的状态;
状态反馈单元,用于若所述数据的状态为未收到数据,则基于所述数据的状态向所述客户端反馈所述数据的状态信息;
状态接收单元,用于所述客户端接收块数据服务器基于所述数据的状态反馈的所述数据的状态信息;
请求重发单元,用于向对应的块数据服务器发送执行追加写操作的请求;所述请求携带需要追加写入文件的数据;
重新接收单元,用于块数据服务器接收所述客户端基于所述数据的状态信息发送的执行追加写操作的请求;所述请求携带需要追加写入文件的数据。
33.根据权利要求31所述的基于分布式文件系统的数据写入装置,其特征在于,包括:
提交信息反馈单元,用于在所述接收到所述执行提交操作的请求的块数据服务器将所述执行追加写操作的请求携带的数据进行写入之后,接收到所述执行提交操作的请求的块数据服务器向客户端反馈基于执行提交操作的结果的提交信息;
提交信息接收单元,用于所述客户端接收各个块数据服务器基于执行提交操作的结果反馈的提交信息;
复制单元,用于若所述提交信息为失败,则向主服务器发送复制对应的块数据服务器到其他块数据服务器的请求。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610192497.0A CN107295030B (zh) | 2016-03-30 | 2016-03-30 | 一种数据写入方法、装置、数据处理方法、装置及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610192497.0A CN107295030B (zh) | 2016-03-30 | 2016-03-30 | 一种数据写入方法、装置、数据处理方法、装置及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN107295030A CN107295030A (zh) | 2017-10-24 |
CN107295030B true CN107295030B (zh) | 2021-03-16 |
Family
ID=60086551
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201610192497.0A Active CN107295030B (zh) | 2016-03-30 | 2016-03-30 | 一种数据写入方法、装置、数据处理方法、装置及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN107295030B (zh) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110968557B (zh) * | 2018-09-30 | 2023-05-05 | 阿里巴巴集团控股有限公司 | 分布式文件系统中的数据处理方法、装置及电子设备 |
CN110505314B (zh) * | 2019-09-26 | 2022-11-25 | 浪潮电子信息产业股份有限公司 | 一种并发追加上传请求的处理方法 |
CN111274201B (zh) * | 2019-10-29 | 2023-04-18 | 上海彬黎科技有限公司 | 一种文件系统 |
CN111209263A (zh) * | 2020-01-14 | 2020-05-29 | 中国建设银行股份有限公司 | 数据存储方法、装置、设备及存储介质 |
CN114297172B (zh) * | 2022-01-04 | 2022-07-12 | 北京乐讯科技有限公司 | 一种基于云原生的分布式文件系统 |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102081665A (zh) * | 2008-12-10 | 2011-06-01 | 阿里巴巴集团控股有限公司 | 一种数据同步方法及装置 |
CN101976175B (zh) * | 2010-08-19 | 2011-12-14 | 北京同有飞骥科技股份有限公司 | 一种水平型分组并行集中校验的磁盘阵列的构建方法 |
US20120130950A1 (en) * | 2010-11-23 | 2012-05-24 | Canon Kabushiki Kaisha | Data replication to multiple data nodes |
CN102136003A (zh) * | 2011-03-25 | 2011-07-27 | 上海交通大学 | 大规模分布式存储系统 |
CN103207867B (zh) * | 2012-01-16 | 2019-04-26 | 联想(北京)有限公司 | 处理数据块的方法、发起恢复操作的方法和节点 |
CN103379156B (zh) * | 2012-04-24 | 2016-03-09 | 深圳市腾讯计算机系统有限公司 | 实现存储空间动态均衡的方法、系统和装置 |
CN102902716A (zh) * | 2012-08-27 | 2013-01-30 | 苏州两江科技有限公司 | 基于Hadoop分布式计算平台的存储系统 |
CN102932424B (zh) * | 2012-09-29 | 2015-04-08 | 浪潮(北京)电子信息产业有限公司 | 一种分布式并行文件系统缓存数据同步的方法及系统 |
CN103207894A (zh) * | 2013-03-14 | 2013-07-17 | 深圳市知正科技有限公司 | 一种多路实时视频数据存储系统及其进行缓存控制的方法 |
CN103530387A (zh) * | 2013-10-22 | 2014-01-22 | 浪潮电子信息产业股份有限公司 | 一种hdfs针对小文件的改进方法 |
CN103595805A (zh) * | 2013-11-22 | 2014-02-19 | 浪潮电子信息产业股份有限公司 | 一种基于分布式集群的数据放置方法 |
CN103685544A (zh) * | 2013-12-24 | 2014-03-26 | 华中科技大学 | 一种基于性能预估的客户端缓存分配方法和系统 |
CN104156381A (zh) * | 2014-03-27 | 2014-11-19 | 深圳信息职业技术学院 | Hadoop分布式文件系统的副本存取方法、装置和Hadoop分布式文件系统 |
-
2016
- 2016-03-30 CN CN201610192497.0A patent/CN107295030B/zh active Active
Non-Patent Citations (2)
Title |
---|
"GOOGLE文件系统翻译学习";hackervirus;《博客园》;20130609;全文 * |
"论文学习笔记:GFS";依然;《CSDN博客》;20131022;全文 * |
Also Published As
Publication number | Publication date |
---|---|
CN107295030A (zh) | 2017-10-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN107295030B (zh) | 一种数据写入方法、装置、数据处理方法、装置及系统 | |
US9934242B2 (en) | Replication of data between mirrored data sites | |
US9906598B1 (en) | Distributed data storage controller | |
EP3223165B1 (en) | File processing method, system and server-clustered system for cloud storage | |
US8918392B1 (en) | Data storage mapping and management | |
JP6044539B2 (ja) | 分散ストレージシステムおよび方法 | |
US11321291B2 (en) | Persistent version control for data transfer between heterogeneous data stores | |
US10831741B2 (en) | Log-shipping data replication with early log record fetching | |
JP4461147B2 (ja) | リモートデータミラーリングを用いたクラスタデータベース | |
US8930364B1 (en) | Intelligent data integration | |
US20190370365A1 (en) | Distributed transactions in cloud storage with hierarchical namespace | |
CN111182067B (zh) | 一种基于星际文件系统ipfs的数据写入方法及设备 | |
JP5548829B2 (ja) | 計算機システム、データ管理方法及びデータ管理プログラム | |
EP4213038A1 (en) | Data processing method and apparatus based on distributed storage, device, and medium | |
US11409711B2 (en) | Barriers for dependent operations among sharded data stores | |
JP5292351B2 (ja) | メッセージキュー管理システム及びロックサーバ及びメッセージキュー管理方法及びメッセージキュー管理プログラム | |
CN113377868A (zh) | 一种基于分布式kv数据库的离线存储系统 | |
US11514000B2 (en) | Data mesh parallel file system replication | |
JP4208506B2 (ja) | 高性能記憶装置アクセス環境 | |
CN111225003B (zh) | 一种nfs节点配置方法和装置 | |
US10545667B1 (en) | Dynamic data partitioning for stateless request routing | |
JP2012008934A (ja) | 分散ファイルシステム及び分散ファイルシステムにおける冗長化方法 | |
JP4512386B2 (ja) | バックアップシステムおよび方法 | |
CN103108045A (zh) | 基于云架构的Web地图服务实现方法 | |
JP4997784B2 (ja) | データ記憶システム、データ記憶方法、データ記憶プログラム |
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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant |