CN112765119A - Hdfs api的调用方法、装置、设备及存储介质 - Google Patents
Hdfs api的调用方法、装置、设备及存储介质 Download PDFInfo
- Publication number
- CN112765119A CN112765119A CN201911001130.6A CN201911001130A CN112765119A CN 112765119 A CN112765119 A CN 112765119A CN 201911001130 A CN201911001130 A CN 201911001130A CN 112765119 A CN112765119 A CN 112765119A
- Authority
- CN
- China
- Prior art keywords
- client
- target file
- data
- file
- hdfs
- 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
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/182—Distributed file systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/13—File access structures, e.g. distributed indices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/172—Caching, prefetching or hoarding of files
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
-
- 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]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
- H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- Signal Processing (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Health & Medical Sciences (AREA)
- Cardiology (AREA)
- General Health & Medical Sciences (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明的HDFS API的调用方法、装置、设备及存储介质,服务端采用多线程接收客户端发送的文件读取请求,利用接口对接模块对接HDFS API以获取目标文件标识发送至客户端,为分布式及高并发场景提供支持,以在高并发环境下对HDFS API实现高效调用;接收客户端发送的携带预设偏移值、预设数据块大小与目标文件标识的数据读取请求,据此获取目标文件的部分数据,并分配对应的内存共享缓冲区进行存储,按照排队后的顺序将存储的部分数据发送至客户端,并重新接收客户端发送的数据读取请求,直至接收到客户端发送的文件读取完毕指示,从而在HDFS API高效调用的基础上,对大文件的异步传输进行优化,提升了数据传输效率。
Description
技术领域
本发明涉及数据通信技术领域,更具体的说,涉及HDFS API的调用方法、装置、设备及存储介质。
背景技术
Hadoop分布式文件系统(HDFS,Hadoop Distributed File System),是Hadoop抽象文件系统的一种实现。Hadoop抽象文件系统可以与本地系统、Amazon S3等集成,甚至可以通过Web协议(webhsfs)来操作。HDFS的文件分布在集群机器上,同时提供副本进行容错及可靠性保证。
目前,HDFS提供的Java/C API都是一个返回句柄Handle接口,即一个阻塞式的接口,比如需要读取10M的数据,必须等所有数据全部读取完成才会返回,可是如此就会导致调用线程堵住,而nginx是一个进程内只有一个单线程的工作模型,无法完成高并发的调用。目前有解决方案是使用Node.js和WebHDFS REST API来访问Hadoop HDFS数据,其目标是让身处HDFS集群之外的应用程序,不但不用安装Hadoop和Java库,并且可以通过流行的REST风格的接口去访问HDFS集群。但是,WebHDFS提供的接口非常有限,需要使用HTTP GET/PUT进行上传和下载,而且WebHDFS对HDFS文件的读写,会被重定向到文件所在的DataNode,并且会完全占用HDFS的带宽,可见通过WebHDFS进行中转,会严重限制HDFS带宽的使用,使并发请求的处理性能及处理效率差,况且由于HDFS采用集群部署方案,所以带宽、DISK IO也会成为瓶颈,使定制化开发难度大。
因此,目前迫切需要一种高效的HDFS API的调用方案,以实现在高并发环境下高效调用HDFS API,提升数据传输效率。
发明内容
有鉴于此,本发明提供了一种HDFS API的调用方法、装置、设备及存储介质,以解决目前HDFS API无法在高并发环境下被高效调用的技术问题。
为实现上述目的,本发明提供如下技术方案:
一种HDFS API的调用方法,应用于服务端,所述调用方法包括:
采用多线程接收客户端发送的文件读取请求,所述文件读取请求中携带有目标文件路径;
根据所述目标文件路径,利用接口对接模块从HDFS中获取目标文件信息;所述接口对接模块用于与HDFS API对接;
将所述目标文件信息发送至所述客户端,所述目标文件信息中包括目标文件标识与目标文件大小;
采用多线程接收所述客户端发送的数据读取请求,所述数据读取请求中携带有预设偏移值、预设数据块大小与所述目标文件标识;所述数据读取请求是所述客户端在接收到所述目标文件信息后,根据所述目标文件信息发出的;
根据所述预设偏移值、预设数据块大小与所述目标文件标识,获取目标文件的部分数据,并分配对应的内存共享缓冲区;
将所述目标文件的部分数据写入到所述内存共享缓冲区中进行排队;
按照排队后的顺序,将所述目标文件的部分数据发送至所述客户端,并重新执行所述接收所述客户端发送的数据读取请求的步骤,直至接收到所述客户端发送的文件读取完毕指示。
优选的,所述采用多线程接收客户端发送的文件读取请求包括:
当监听到有客户端发送请求时,通过操作系统进行多线程调度,分配相应的处理线程来接收并处理客户端发送的文件读取请求。
优选的,所述采用多线程接收客户端发送的文件读取请求包括:
当服务端与客户端之间存在空闲的TCP长连接时,基于所述空闲的TCP长连接,采用多线程接收客户端发送的文件读取请求。
优选的,所述服务端与客户端之间基于套接字来进行数据传输;所述调用方法还包括:
监听客户端基于所述套接字发送的心跳报文;
当在预设时间段内未监听到所述心跳报文时,关闭所述套接字。
优选的,所述调用方法还包括:
将处理线程的请求处理速度与HDFS文件读写接口的数据读写速度之间的比值配置为1:8。
优选的,所述根据所述目标文件路径,利用接口对接模块从HDFS中获取目标文件信息包括:
获取预设的文件路径与文件标识之间映射关系;
根据所述目标文件路径与所述映射关系,利用接口对接模块从HDFS中获取目标文件标识;
根据所述目标文件标识,获取目标文件大小。
优选的,所述客户端是基于OpenResty构建的;
所述服务端是采用C程序构建的;
所述接口对接模块是基于SDK API构建的。
一种HDFS API的调用装置,应用于服务端,所述调用装置包括:
客户请求接收单元,用于采用多线程接收客户端发送的文件读取请求,所述文件读取请求中携带有目标文件路径;
文件信息获取单元,用于根据所述目标文件路径,利用接口对接模块从HDFS中获取目标文件信息;所述接口对接模块用于与HDFS API对接;
文件信息发送单元,用于将所述目标文件信息发送至所述客户端,所述目标文件信息中包括目标文件标识与目标文件大小;
所述客户请求接收单元,还用于采用多线程接收所述客户端发送的数据读取请求,所述数据读取请求中携带有预设偏移值、预设数据块大小与所述目标文件标识;所述数据读取请求是所述客户端在接收到所述目标文件信息后,根据所述目标文件信息发出的;
文件数据处理单元,用于根据所述预设偏移值、预设数据块大小与所述目标文件标识,获取目标文件的部分数据,并分配对应的内存共享缓冲区;
文件数据缓冲单元,用于将所述目标文件的部分数据写入到所述内存共享缓冲区中进行排队;
文件数据发送单元,用于按照排队后的顺序,将所述目标文件的部分数据发送至所述客户端,并触发所述客户请求接收单元重新执行所述接收所述客户端发送的数据读取请求的步骤,直至接收到所述客户端发送的文件读取完毕指示。
一种HDFS API的调用设备,包括处理器与存储器;
其中,所述存储器用于存储有接口调用程序;
所述处理器用于调用所述存储器中存储的所述接口调用程序,以执行前述所述的HDFS API的调用方法。
一种计算机可读存储介质,所述计算机可读存储介质中存储有接口调用程序,所述接口调用程序在被计算机设备调用时实现前述所述的HDFS API的调用方法。
从上述的技术方案可以看出,本发明提供的HDFS API的调用方法、装置、设备及存储介质,服务端采用多线程接收客户端发送的文件读取请求,利用接口对接模块与HDFSAPI对接以获取目标文件标识并发送至客户端,为分布式及高并发场景提供充分支持,能够在高并发环境下对HDFS API实现高效调用;然后接收客户端发送的携带预设偏移值、预设数据块大小与目标文件标识的数据读取请求,据此获取目标文件的部分数据,并分配对应的内存共享缓冲区进行存储,按照排队后的顺序将存储的部分数据发送至客户端,并重新接收客户端发送的数据读取请求,直至接收到客户端发送的文件读取完毕指示,从而在HDFS API高效调用的基础上,对大文件的异步传输进行优化,提升了数据传输效率。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据提供的附图获得其他的附图。
图1为本发明实施例提供的HDFS API的调用方案的架构示意图;
图2为本发明实施例提供的HDFS API的调用方法的流程图;
图3为本发明实施例提供的线程分配方式的示意图;
图4为本发明实施例提供的HDFS API的调用方法的信息交互流程图;
图5为本发明实施例提供的HDFS API的调用装置的结构示意图;
图6为本发明实施例提供的HDFS API的调用设备的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
OpenResty是一个基于Nginx与Lua的高性能Web平台,其内部集成了大量精良的Lua库、第三方模块以及大多数的依赖项,可用于方便地搭建能够处理超高并发、扩展性极高的动态Web应用、Web服务和动态网关。
OpenResty充分利用了Nginx的非阻塞I/O模型,而Nginx采用的是master-worker模型,一个master进程管理多个worker进程,基本的事件处理都是放在woker中,master负责一些全局初始化,以及对worker的管理。在OpenResty中,每个worker使用一个LuaVM,当请求被分配到worker时,将在这个LuaVM里创建一个coroutine(协程)。协程之间数据隔离,每个协程具有独立的全局变量_G。因此借助于Nginx的事件驱动模型和非阻塞I/O,可以实现高性能的Web应用程序。
对于异步非阻塞来说,就是当一个线程调用出现等待的I/O之类的情况时,先去处理别的任务,而不是阻塞在这里,等I/O准备好了,然后再去执行当前任务。
epoll是Linux内核为处理大批量文件描述符而作了改进的poll,是Linux下多路复用IO接口select/poll的增强版本,它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率。另一点原因就是获取事件的时候,它无须遍历整个被侦听的描述符集,只要遍历那些被内核IO事件异步唤醒而加入Ready队列的描述符集合就行了。
C10K问题是指,在很多服务器初始状态下,无法服务1w左右的并发连接。这与每次服务的资源消耗、服务器的硬件配置固然有关,但很多时候是被linux的默认配置以及软件stack选型所限制。如果硬件配置没有问题,性能较高的服务器上,产生c10k问题,很多情况下与配置和软件栈相关,例如最大文件打开数、socket端口数、IO基础栈等。
现有的Hadoop文件系统(HDFS)面向用户的接口是阻塞式接口,比如读取1024个字节就必须等待全部字节完成时才能返回,如此会导致调用线程堵住,而nginx是一个进程内只有一个单线程的工作模型、从而无法完成高并发的调用。
本发明所提供的HDFS API的调用方法,实际上也是一种在OpenResty的高并发环境下调用HDFS API接口来实现文件操作的方法。通过本发明提供的HDFS代理接口协议服务器(也即协议服务端),用于接收高并发请求、而内部采用多线程接收请求和epoll多路复用I/O开发模型,对于不同的文件操作接口提供了统一化的流程处理逻辑,而且与HDFS API接口使用解藕的模块化开发。
本发明的技术实现,主要可包括三个部分,如协议客户端(简称“客户端”)、协议服务端(简称“服务端”)与SDK接口对接模块(简称“接口对接模块”)。而且,如图1所示,所述客户端是基于OpenResty构建的;所述服务端是采用C程序构建的;所述接口对接模块是基于SDK API构建的,主要负责与HDFS API与File API对接。
为了提高通讯的安全和效率性,满足需要自主定义字段的需求,客户端与服务端之间的通讯协议可采用具有“私有的数据头+数据体”的TCP协议,因为TCP是流式协议且有重传机制,可以实现数据通信的高可用性。其中,通信双方是客户端与服务端,属于典型的C/S架构模型。由于TCP协议是一个流式协议,即以字节流的形式传递给接收者的,没有固有的“报文”或“报文边界”的概念,所以在接收到数据时,先读取固定数据头,取出其数据体的长度,再读取数据体长度的数据即可,分两次进行读取数据。
请参阅图2,图2为本发明实施例提供的HDFS API的调用方法的一种流程图。
本实施例提供的HDFS API的调用方法,应用于服务端,即站在服务端的角度来执行的HDFS API的调用方法。
如图2所示,所述调用方法包括:
S101:采用多线程接收客户端发送的文件读取请求。
所述文件读取请求中携带有目标文件路径。
客户端在向服务端发送文件读取请求之前,还需要先发起数据连接建立请求,并在客户端与服务端之间建立好数据连接请求后,再发起文件读取请求。
当监听到有客户端发送请求时,可通过操作系统进行多线程调度,分配相应的处理线程来接收并处理客户端发送的文件读取请求。
由于并发请求的连接数目较多,而每个线程处理的等待队列有限,若一个连接请求等待被处理的时间太长则会发生超时,所以在客户端发起连接请求后,服务端接收连接请求及处理请求的时间不能太长,一般超过2~3s左右则判定的超时,所以为了匹配HDFS接口请求处理速度与网络I/O速度,需要在服务端开启开启多线程来进行请求的接收与处理,以减小请求高并发时的等待时间。
服务端在程序启动时先在主线程中进行监听,然后在开启新程序的同时将相应的文件句柄fd(file description)传递到所有的子线程当中,当有客户端发起请求时再由操作系统进行多线程调度(如图3所示),而上层应用程序不参与。其中,采用操作系统进行多线程调度的主要原因是每个链接处理的时间、数据带宽与负载链接数都不一样,而很难负载均衡地分配处理线程。
连接线程CID(connect id,连接标识)是全局的唯一的ID值,用于标识会话值。客户端在发送请求之前需要先与服务器进行TCP三次握手,建立TCP连接。一般情况下每次都需要进行三次握手发送与接收十几个TCP包才建立好连接,这对于成千上万的连接请求来说是个不小的资源消耗。因此,本发明还采用了TCP复用技术,当客户端请求连接时,首先检测客户端与服务端之间是否存在着空闲的长连接,如果不存在则建立一个新连接,如果存在则直接复用此长连接,由此可以避免了新建TCP连接所造成的延迟和服务器资源的消耗。
也就是说,当服务端与客户端之间存在空闲的TCP长连接时,基于所述空闲的TCP长连接,采用多线程接收客户端发送的文件读取请求;当服务端与客户端之间不存在空闲的TCP长连接时,建立新的TCP连接,并基于所述新的TCP连接,采用多线程接收客户端发送的文件读取请求。
在使用过程中,套接字fd可能会相同,但CID值不会变化且表示唯一的连接标识。套接字本身就是一个整型值,一般来说一个系统进程只能分配的套接字是有限的,但达到最大值数又会从最小值且并未被使用值循环分配。CID值是一个标识会话的值,也是一个全局的递增值,64位的整型范围,每次创建新链接时自加1,通常情况下是无法使用完的。
S102:根据所述目标文件路径,利用接口对接模块从HDFS中获取目标文件信息。
所述接口对接模块用于与HDFS API对接。
所述目标文件信息中包括目标文件标识与目标文件大小,步骤S102可具体包括:
A1、获取预设的文件路径与文件标识之间映射关系;
A2、根据所述目标文件路径与所述映射关系,利用接口对接模块从HDFS中获取目标文件标识;
A3、根据所述目标文件标识,获取目标文件大小。
其中,目标文件标识可以是虚拟文件标识VFID(Virtual File Identify)。预先建立文件路径与VFID之间的映射关系,文件路径是一个最长1024个字节的字符串长度,每次需要信息交互时都需要传递头信息用于标识唯一的链接,那次每次都传输这个很长的字符串将会浪费很大的带宽,此处带宽相对于文件需要传输的总的带宽数占比数越小越好,所以需要尽量将必要的传输信息内容缩少。因此在本发明中针对文件路径与VFID建立了映射关系,VFID为64bit位整型值,为了查找效率本发明采用HASH算法,并以VFID作为其中的Hash_Key值。
VFID由<机器序列号+进程PID+当前时间+全部累加值>构造而成,是一个全局唯一的值,每次打开一个文件路径时就会产生一个新的VFID,文件关闭时则删除,目的就是为了保证在文件传输过程中只需要传输VFID值而不用重复传输文件路径。
S103:将所述目标文件信息发送至所述客户端,所述目标文件信息中包括目标文件标识与目标文件大小。
S104:采用多线程接收所述客户端发送的数据读取请求,所述数据读取请求中携带有预设偏移值、预设数据块大小与所述目标文件标识。
所述数据读取请求是所述客户端在接收到所述目标文件信息后,根据所述目标文件信息发出的。
S105:根据所述预设偏移值、预设数据块大小与所述目标文件标识,获取目标文件的部分数据,并分配对应的内存共享缓冲区。
S106:将所述目标文件的部分数据写入到所述内存共享缓冲区中进行排队。
处理请求的异步非阻塞式模型是一种被动的的通知模型、将相应的fd加入到epoll队列中,通过集中的函数触发机制唤醒fd的状态,比如读写,异常等状况。一般的少量数据请求与回应比较简单,但对于大数据量的读写需要一种特殊的机制。
首先由于内存资源的限制,不可能将一个几G大小的文件全部读取到内存然后再慢慢发送,即使内存够的话也是按需读取数据块到内存再发送,发送完成后再请求新数据块。
在视频播放场景下,由于读取的文件基本上都是用于视频播放的大文件用于视频播放,用户随时可能快进或拖动进度条,所以以分块方式读取是比较合适的,例如,预设数据块大小是4M,那么就以最大4M大小的数据块进行数据传输,客户端以VFID、预设偏移值及预设数据块大小请求块,服务端收到数据读取请求后,将相应数据块读到内存共享缓冲区,以供客户端读取读取。客户端可以在下次重新发送新的数据读取请求,一直到读完所有数据块为止。这样一方面可以实现块内存被重复使用,减少内存的碎片及多次分配释放带来的效率损失,另一方面采用分而冶之的方法,对大文件分片处理,能够提高数据传输效率及数据传输的灵活性。
下面介绍一下服务端的数据读取与数据写入的流程:
I、数据读取的流程:
①以最小块4M分配一个共享缓冲区,缓冲区内部是一个双链表结构。
②根据双链表分配的缓冲区大小,从后端文件系统中读取数据填满循环链表的所有块,并将文件数据填充满。
③更新文件的偏移地址与读取的数据长度回复给客户端。
④将数据挂载在此连接套接字的epoll发送队列中,发送完成后释放共享缓冲区的资源。
II、数据写入的流程:
①以最小块4M分配一个共享缓冲区,缓冲区内部是一个双链表结构。
②将该套接字挂载到epoll接收队列中,按照协议头的体长度接收完成通知WR(write-read)线程
③循环链表的所有块,并将文件写入到对应的文件系统中。
④更新已接收到的文件当前偏移地址及已接收到的数据长度,并回复给客户端。
⑤回收共享缓冲区的资源。
S107:按照排队后的顺序,将所述目标文件的部分数据发送至所述客户端。
S108:判断是否接收到客户端发送的文件读取完毕指示,若否,则继续执行步骤S104;若是,则执行步骤S109。
S109:关闭文件数据传输。
按照排队后的顺序,将所述目标文件的部分数据发送至所述客户端,并重新执行所述接收所述客户端发送的数据读取请求的步骤,直至接收到所述客户端发送的文件读取完毕指示。
本实施例提供的HDFS API的调用方法,服务端采用多线程接收客户端发送的文件读取请求,利用接口对接模块与HDFS API对接以获取目标文件标识并发送至客户端,为分布式及高并发场景提供充分支持,能够在高并发环境下对HDFS API实现高效调用;然后接收客户端发送的携带预设偏移值、预设数据块大小与目标文件标识的数据读取请求,据此获取目标文件的部分数据,并分配对应的内存共享缓冲区进行存储,按照排队后的顺序将存储的部分数据发送至客户端,并重新接收客户端发送的数据读取请求,直至接收到客户端发送的文件读取完毕指示,从而在HDFS API高效调用的基础上,对大文件的异步传输进行优化,提升了数据传输效率,尤其是提高了对于大的媒体文件的传输效率及媒体播放的质量。
并且,通过接口的协议化,不仅可以与HDFS API对接,还可以与磁盘文件操作API对接,使本发明的技术方案可以适配并运行在不同的平台上,为分布式及高并发场景提供支持,适用于各种需要解决C10K问题的应用场景。
请参阅图4,图4为本发明实施例提供的HDFS API的调用方法的信息交互流程图。
本实施例提供的HDFS API的调用方法,是站在整个交互系统的层面来描述客户端、服务端与HDFS系统之间的信息交互过程。
如图4所示,所述调用方法包括:
S201:打开文件,传入目标文件路径。
客户端将需要读取的目标文件路径先发送给客户端协议接口,待封装完后返回需要发送的数据及长度。客户端将封装好的数据(即文件读取请求)发送给服务端。
S202:在HDFS中查询目标文件信息。
由服务端通过接口对接模块与HDFS API对接,在HDFS中查询目标文件信息。
S203:回复查询结果。
HDFS系统向服务器返回查询结果。
S204:根据不同查询结果确定不同反馈信息。
服务端根据不同查询结果确定不同反馈信息。查询结果包括查询到与未查询到。
服务端收到请求并建立连接,分析请求的数据头确认需要读取的目标文件,确认目标文件的状态及属性信息,如果目标文件不存在则返回目标文件未存在的反馈信息;如果目标文件存在则返回目标文件的VFID及文件大小等信息(即目标文件信息)。
S205:发送反馈信息。
服务端向客户端发送反馈信息,在找到目标文件的情况下,服务端向客户端发送的反馈信息,即为目标文件信息,可包括VFID及文件大小。
S206:确定目标文件存在则继续,否则直接关闭链接。
S207:请求读取数据VFID、偏移值及数据块大小。
客户端收到服务端的回应头信息,解析得到文件的VFID值及总长度。客户端根据预设偏移值加预设数据块大小进行封装再次发送数据读取请求,此数据块大小一般为4M,即将目标文件分隔成4M一个块(即目标文件的部分数据),只有最后一块可能以不足完整块的长度进行传输。
S208:填充共享缓冲区。
服务端为请求的数据块分配共享缓冲区。
S209:根据偏移值读取数据。
服务端根据偏移值从HDFS系统读取请求的数据块。
S210:回复符合预设数据块大小的数据。
服务端收到数据读取请求,根据预设数据块大小及偏移值从文件服务源端读取数据到内部的共享缓冲区,最后并将数据挂到epoll等待传输队列中,当数据可发送时将其发送给客户端中。
客户端等待数据的接收,并将接收到的数据读取出来发送给需要的后端,比如播放器。
S211:重复执行步骤S207~S210。
S212:发送文件读取完毕或达到需求量大小的指示。
客户端在获取到目标文件的完整数据后,会向服务端发送文件读取完毕指示,或达到需求量大小的指示。
S213:关闭文件。
服务端在接收到客户端发送的文件读取完毕指示,或达到需求量大小的指示后,表示目标文件的数据均已传输完,最后将数据连接与目标文件关闭,结束流程。
在一示例中,所述服务端与客户端之间可基于套接字来进行数据传输。相应的,本发明还可以监听客户端基于所述套接字发送的心跳报文,当在预设时间段内未监听到所述心跳报文时,关闭所述套接字。
该示例可解决套接字的异常关闭问题,在任何网络通信过程中,对端的套接字关闭没有任何可监听的机制,所以只能通过主动的心跳机制,不停地发送自已的心跳数据信息,告诉对方还活着,如果一段时间内没有监听到心跳报文则认为对端已关闭。这样,一方面可以减小需要维护的活动队列,另一方面可以关闭不用或无效的链接数目,从而提高程序的处理效率,而且有利于程序出现问题时的查询。
每个传输通道都有自已的超时时间,只要在这些通道上发生通讯,比如读或写数据时则更新其心跳时间,并以此心跳时间作为开始时间,如果一段时间后都未收到对方的任何心跳数据信息则对此通道进行处理,比如关闭此链接并关闭此链接上的所有资源。
另一示例中,所述调用方法还可包括:将处理线程的请求处理速度与HDFS文件读写接口的数据读写速度之间的比值配置为1:8。
该示例主要面对HDFS文件读写接口的I/O速度与处理线程的请求处理速度之间的匹配问题,按照一台HDFS服务器最大输出带宽4000MB-5000MB的能力,那么一个处理线程与数据的WR线程的比较通过测试,以1:8比例配置性能较优,即吐吞量、CPU、内存及带宽输出的效果最佳,可保证已有资源的充分利用。
本发明中协议头及协议体结构可如下所示:
表1协议头
协议体是变长长度,以pack_length标识,其长度最大是4MB字节。
本实施例提供的HDFS API的调用方法,从服务端、客户端与HDFS系统的角度描述了三端之间的信息交互过程,服务端采用多线程接收客户端发送的文件读取请求,利用接口对接模块与HDFS API对接以获取目标文件标识并发送至客户端,为分布式及高并发场景提供充分支持,能够在高并发环境下对HDFS API实现高效调用;并在HDFS API高效调用的基础上,对大文件的异步传输进行优化,提升了数据传输效率;而且,还对套接字的异常关闭建离了一套完整的心跳机制,通过心跳机制来决定哪些链接套接字需要关闭、消除无效的套接字的影响。
本发明实施例还提供了HDFS API的调用装置,所述HDFS API的调用装置用于实施本发明实施例提供的HDFS API的调用方法,下文描述的HDFS API的调用装置的技术内容,可与上文描述的HDFS API的调用方法的技术内容与相互对应参照。
请参阅图5,图5为本发明实施例提供的HDFS API的调用装置的结构示意图。
本实施例提供的HDFS API的调用装置,应用于服务端。
如图5所示,所述调用装置包括:客户请求接收单元10、文件信息获取单元20、文件信息发送单元30、文件数据处理单元40、文件数据缓冲单元50、文件数据发送单元60。
客户请求接收单元10,用于采用多线程接收客户端发送的文件读取请求,所述文件读取请求中携带有目标文件路径;
文件信息获取单元20,用于根据所述目标文件路径,利用接口对接模块从HDFS中获取目标文件信息;所述接口对接模块用于与HDFS API对接;
文件信息发送单元30,用于将所述目标文件信息发送至所述客户端,所述目标文件信息中包括目标文件标识与目标文件大小;
所述客户请求接收单元10,还用于采用多线程接收所述客户端发送的数据读取请求,所述数据读取请求中携带有预设偏移值、预设数据块大小与所述目标文件标识;所述数据读取请求是所述客户端在接收到所述目标文件信息后,根据所述目标文件信息发出的;
文件数据处理单元40,用于根据所述预设偏移值、预设数据块大小与所述目标文件标识,获取目标文件的部分数据,并分配对应的内存共享缓冲区;
文件数据缓冲单元50,用于将所述目标文件的部分数据写入到所述内存共享缓冲区中进行排队;
文件数据发送单元60,用于按照排队后的顺序,将所述目标文件的部分数据发送至所述客户端,并触发所述客户请求接收单元重新执行所述接收所述客户端发送的数据读取请求的步骤,直至接收到所述客户端发送的文件读取完毕指示。
本实施例提供的HDFS API的调用装置,服务端采用多线程接收客户端发送的文件读取请求,利用接口对接模块与HDFS API对接以获取目标文件标识并发送至客户端,为分布式及高并发场景提供充分支持,能够在高并发环境下对HDFS API实现高效调用;然后接收客户端发送的携带预设偏移值、预设数据块大小与目标文件标识的数据读取请求,据此获取目标文件的部分数据,并分配对应的内存共享缓冲区进行存储,按照排队后的顺序将存储的部分数据发送至客户端,并重新接收客户端发送的数据读取请求,直至接收到客户端发送的文件读取完毕指示,从而在HDFS API高效调用的基础上,对大文件的异步传输进行优化,提升了数据传输效率,尤其是提高了对于大的媒体文件的传输效率及媒体播放的质量。
请参阅图6,图6为本发明实施例提供的HDFS API的调用设备的结构示意图。
如图6所示,本发明实施例还提供了HDFS API的调用设备,该调用设备可以包括:处理器1,通信接口2,存储器3,通信总线4;其中,处理器1、通信接口2与存储器3通过通信总线4完成相互间的通信。
通信接口2可以为通信模块的接口,如GSM模块的接口;
存储器3,用于存储有接口调用程序;
处理器1,用于调用所述存储器3中存储的所述接口调用程序,以执行前述的HDFSAPI的调用方法;
程序可以包括程序代码,所述程序代码包括处理器的操作指令。
处理器可能是一个中央处理器CPU,或者是特定集成电路ASIC,或者是被配置成实施本申请实施例的一个或多个集成电路。
存储器可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM),存储器包括至少一个存储芯片。
本发明实施例提供了一种计算机可读存储介质,所述计算机可读存储介质中存储有接口调用程序,所述接口调用程序在被计算机设备调用时实现前述的HDFS API的调用方法。
本文中的HDFS API的调用设备可以是服务器、PC等。
本申请还提供了一种计算机程序产品,当在计算机设备上执行时,适于执行初始化有前述的HDFS API的调用方法的步骤的程序。
最后,还需要说明的是,在本文中,诸如第一和第一等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式来实现。基于这样的理解,本申请的技术方案对背景技术做出贡献的全部或者部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间可以相互组合使用,各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言,由于其与实施例公开的方法相对应,所以描述的比较简单,相关之处参见方法部分说明即可。
本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处。综上所述,本说明书内容不应理解为对本申请的限制。
Claims (10)
1.一种HDFS API的调用方法,其特征在于,应用于服务端,所述调用方法包括:
采用多线程接收客户端发送的文件读取请求,所述文件读取请求中携带有目标文件路径;
根据所述目标文件路径,利用接口对接模块从HDFS中获取目标文件信息;所述接口对接模块用于与HDFS API对接;
将所述目标文件信息发送至所述客户端,所述目标文件信息中包括目标文件标识与目标文件大小;
采用多线程接收所述客户端发送的数据读取请求,所述数据读取请求中携带有预设偏移值、预设数据块大小与所述目标文件标识;所述数据读取请求是所述客户端在接收到所述目标文件信息后,根据所述目标文件信息发出的;
根据所述预设偏移值、预设数据块大小与所述目标文件标识,获取目标文件的部分数据,并分配对应的内存共享缓冲区;
将所述目标文件的部分数据写入到所述内存共享缓冲区中进行排队;
按照排队后的顺序,将所述目标文件的部分数据发送至所述客户端,并重新执行所述接收所述客户端发送的数据读取请求的步骤,直至接收到所述客户端发送的文件读取完毕指示。
2.如权利要求1所述的调用方法,其特征在于,所述采用多线程接收客户端发送的文件读取请求包括:
当监听到有客户端发送请求时,通过操作系统进行多线程调度,分配相应的处理线程来接收并处理客户端发送的文件读取请求。
3.如权利要求1所述的调用方法,其特征在于,所述采用多线程接收客户端发送的文件读取请求包括:
当服务端与客户端之间存在空闲的TCP长连接时,基于所述空闲的TCP长连接,采用多线程接收客户端发送的文件读取请求。
4.如权利要求1所述的调用方法,其特征在于,所述服务端与客户端之间基于套接字来进行数据传输;所述调用方法还包括:
监听客户端基于所述套接字发送的心跳报文;
当在预设时间段内未监听到所述心跳报文时,关闭所述套接字。
5.如权利要求1所述的调用方法,其特征在于,所述调用方法还包括:
将处理线程的请求处理速度与HDFS文件读写接口的数据读写速度之间的比值配置为1:8。
6.如权利要求1所述的调用方法,其特征在于,所述根据所述目标文件路径,利用接口对接模块从HDFS中获取目标文件信息包括:
获取预设的文件路径与文件标识之间映射关系;
根据所述目标文件路径与所述映射关系,利用接口对接模块从HDFS中获取目标文件标识;
根据所述目标文件标识,获取目标文件大小。
7.如权利要求1所述的调用方法,其特征在于,
所述客户端是基于OpenResty构建的;
所述服务端是采用C程序构建的;
所述接口对接模块是基于SDK API构建的。
8.一种HDFS API的调用装置,其特征在于,应用于服务端,所述调用装置包括:
客户请求接收单元,用于采用多线程接收客户端发送的文件读取请求,所述文件读取请求中携带有目标文件路径;
文件信息获取单元,用于根据所述目标文件路径,利用接口对接模块从HDFS中获取目标文件信息;所述接口对接模块用于与HDFS API对接;
文件信息发送单元,用于将所述目标文件信息发送至所述客户端,所述目标文件信息中包括目标文件标识与目标文件大小;
所述客户请求接收单元,还用于采用多线程接收所述客户端发送的数据读取请求,所述数据读取请求中携带有预设偏移值、预设数据块大小与所述目标文件标识;所述数据读取请求是所述客户端在接收到所述目标文件信息后,根据所述目标文件信息发出的;
文件数据处理单元,用于根据所述预设偏移值、预设数据块大小与所述目标文件标识,获取目标文件的部分数据,并分配对应的内存共享缓冲区;
文件数据缓冲单元,用于将所述目标文件的部分数据写入到所述内存共享缓冲区中进行排队;
文件数据发送单元,用于按照排队后的顺序,将所述目标文件的部分数据发送至所述客户端,并触发所述客户请求接收单元重新执行所述接收所述客户端发送的数据读取请求的步骤,直至接收到所述客户端发送的文件读取完毕指示。
9.一种HDFS API的调用设备,其特征在于,包括处理器与存储器;
其中,所述存储器用于存储有接口调用程序;
所述处理器用于调用所述存储器中存储的所述接口调用程序,以执行如权利要求1~7任一项所述的HDFS API的调用方法。
10.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质中存储有接口调用程序,所述接口调用程序在被计算机设备调用时实现如权利要求1~7任一项所述的HDFSAPI的调用方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911001130.6A CN112765119A (zh) | 2019-10-21 | 2019-10-21 | Hdfs api的调用方法、装置、设备及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911001130.6A CN112765119A (zh) | 2019-10-21 | 2019-10-21 | Hdfs api的调用方法、装置、设备及存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN112765119A true CN112765119A (zh) | 2021-05-07 |
Family
ID=75691690
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201911001130.6A Pending CN112765119A (zh) | 2019-10-21 | 2019-10-21 | Hdfs api的调用方法、装置、设备及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112765119A (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113467996A (zh) * | 2021-07-08 | 2021-10-01 | 咪咕音乐有限公司 | 数据库备份方法、装置、计算机设备及存储介质 |
CN113505067A (zh) * | 2021-07-09 | 2021-10-15 | 浪潮云信息技术股份公司 | 基于openresty的分布式数据库tpc-c测试优化方法及系统 |
CN113596148A (zh) * | 2021-07-27 | 2021-11-02 | 上海商汤科技开发有限公司 | 一种数据传输方法、系统、装置、计算设备和存储介质 |
CN114331445A (zh) * | 2022-03-15 | 2022-04-12 | 上海金仕达软件科技有限公司 | 用于海量用户接入的api接口、方法、存储介质及电子设备 |
CN117376344A (zh) * | 2023-12-08 | 2024-01-09 | 荣耀终端有限公司 | 数据传输方法、电子设备和计算机可读存储介质 |
-
2019
- 2019-10-21 CN CN201911001130.6A patent/CN112765119A/zh active Pending
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113467996A (zh) * | 2021-07-08 | 2021-10-01 | 咪咕音乐有限公司 | 数据库备份方法、装置、计算机设备及存储介质 |
CN113467996B (zh) * | 2021-07-08 | 2024-04-19 | 咪咕音乐有限公司 | 数据库备份方法、装置、计算机设备及存储介质 |
CN113505067A (zh) * | 2021-07-09 | 2021-10-15 | 浪潮云信息技术股份公司 | 基于openresty的分布式数据库tpc-c测试优化方法及系统 |
CN113505067B (zh) * | 2021-07-09 | 2024-02-20 | 上海沄熹科技有限公司 | 基于openresty的分布式数据库tpc-c测试优化方法及系统 |
CN113596148A (zh) * | 2021-07-27 | 2021-11-02 | 上海商汤科技开发有限公司 | 一种数据传输方法、系统、装置、计算设备和存储介质 |
CN114331445A (zh) * | 2022-03-15 | 2022-04-12 | 上海金仕达软件科技有限公司 | 用于海量用户接入的api接口、方法、存储介质及电子设备 |
CN117376344A (zh) * | 2023-12-08 | 2024-01-09 | 荣耀终端有限公司 | 数据传输方法、电子设备和计算机可读存储介质 |
CN117376344B (zh) * | 2023-12-08 | 2024-05-10 | 荣耀终端有限公司 | 数据传输方法、电子设备和计算机可读存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN112765119A (zh) | Hdfs api的调用方法、装置、设备及存储介质 | |
CN106603598B (zh) | 处理业务请求的方法及装置 | |
US20210311781A1 (en) | Method and system for scalable job processing | |
US10341196B2 (en) | Reliably updating a messaging system | |
CA2629694C (en) | Centralized polling service | |
US10318550B2 (en) | Systems and methods for autonomous resource discovery, management, and stitching | |
US20140280398A1 (en) | Distributed database management | |
CN112631788B (zh) | 数据传输方法及数据传输服务器 | |
US10826977B2 (en) | System and method for supporting asynchronous request/response in a network environment | |
CN109802895B (zh) | 数据处理系统、方法及令牌管理方法 | |
CN113259415B (zh) | 一种网络报文处理方法、装置及网络服务器 | |
CN113326155A (zh) | 一种信息处理方法、装置、系统和存储介质 | |
WO2021051881A1 (zh) | Vpp 集群管理方法及装置、计算机设备及存储介质 | |
US20130054735A1 (en) | Wake-up server | |
CN112104679B (zh) | 处理超文本传输协议请求的方法、装置、设备和介质 | |
CN111522663B (zh) | 一种基于分布式存储系统的数据传输方法、装置和系统 | |
US10154116B1 (en) | Efficient synchronization of locally-available content | |
CN111835797A (zh) | 一种数据处理方法、装置及设备 | |
US10728291B1 (en) | Persistent duplex connections and communication protocol for content distribution | |
CN111245794B (zh) | 数据传输方法和装置 | |
CN113886082A (zh) | 请求处理方法、装置、计算设备及介质 | |
Byun et al. | DynaGrid: A dynamic service deployment and resource migration framework for WSRF-compliant applications | |
CN111901689A (zh) | 流媒体数据的传输方法、装置、终端设备和存储介质 | |
CN108055305B (zh) | 一种存储扩展方法及存储扩展装置 | |
CN113726723B (zh) | 基于udp的数据传输方法、装置及设备 |
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 |