具体实施方式
在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施,本领域技术人员可以在不违背本申请内涵的情况下做类似推广,因此本申请不受下面公开的具体实施的限制。
本申请第一实施例提供了一种任务逻辑的处理方法。以下结合图1和图2进行详细说明。
如图1所示,在步骤S101中,确定任务包含的任务逻辑。
所述任务包括的任务逻辑,包括:事件处理;协议栈收发包。
事件处理:RPC层封装处理后,处理RPC request与response需要对应到网络连接上收发数据,为了实现网络性能的高性能与大规模,收发数据需要实现事件驱动来异步化,事件处理主要处理各种网络事件,如套接字建立事件、套接字断开事件、套接字可读事件、套接字可写事件等。
RPC层实现业务的各种网络请求处理,业务的网络请求有method、request、response、result四个要素,发送前需要将描述的业务场景封装为request消息对象(主要是google protobuf对象),发送时,将这个对象序列化为内存,通过TCP/IP发送到remote(远端);remtote收到后经过TCP/IP获得的只是祼的数据,反序列化为request对象后,才方便处理业务逻辑,并封装response发给请求方。
简言之,RPC可以让不同的业务根据自己的需求,定义不同类型的method/request/response,RPC层封装主要指request/response的序列化和反序列化,如IO业务、数据处理业务、proxy业务等。
其中,事件处理,包括:
连接事件处理;RPC通信处理;IO业务处理等。
其中,连接事件处理中的连接事件为利用协议栈对网络数据包解析后触发的事件,所述连接事件包括如下事件:套接字可读事件、套接字可写事件、套接字建立事件、套接字断开事件等。
IO业务处理包括:server端(服务器端)提交IO请求到底层存储、client端(客户端)通知上层业务IO请求处理的结果等。具体的,IO业务处理包括以下操作:磁盘打开、关闭,IO请求解析,IO流控,条带处理,crc(Cyclic Redundancy Check,循环冗余校验),性能监控等。
RPC(Remote Procedure Call,远程过程调用)通信处理:IO业务处理完成后,基于开源google protobuf封装为RPC请求,RPC通信将业务请求封装不同的service(服务)与method(方法),例如,磁盘打开、关闭为一类service;IO请求为一类service;IO请求分为读写等不同的method,IO请求封装为RPC request(RPC请求)与response(应答)。
其中,协议栈收发包,包括:经DPDK从网卡接收网络数据包;利用协议栈对所述网络数据包进行解析及处理;利用协议栈进行定时任务处理;利用协议栈对封装后的网络数据包进行发包处理;经DPDK将所述封装后的网络数据包发送到网卡等。
经DPDK从网卡接收网络数据包:经DPDK从网卡接收网络数据包,且每次尝试尽量从网卡收一批(多个)网络数据包;
利用协议栈对所述网络数据包进行解析及处理:对收到的网络数据包依次解析链路层、IP层、TCP/UDP层的header;处理连接的建立、销毁等生命周期;记录套接字连接上的payload数据(原始数据)、处理ack(确认字符)、快速重传等;处理完后生成对应的连接事件,如套接字可读事件、套接字可写事件、套接字建立事件、套接字断开事件等。
利用线程定时器处理协议栈的定时任务:超时重传、连接timewait等。由于TCP协议栈要保证数据的可靠传输,因此对丢包、乱序这些场景需要定时重试;TCP连接具有状态,状态异常时需要定时清理,如timewait。
利用协议栈进行发包处理:处理socket调用事件,例如套接字建立事件、套接字断开事件、写数据事件等;封装为网络数据包,依次封装TCP/UDP层、IP层、链路层的header。
经DPDK将封装后的网络数据包发送到网卡:经DPDK将封装后的网络数据包发送到网卡,且每次尝试尽量向网卡发一批网络数据包。
如图1所示,在步骤S102中,在一个线程内运行任务包含的任务逻辑。
在一个线程内运行任务包含的任务逻辑,减少了来回多次线程通知、CPU上下文切换,并且减少CPU cache miss(缓存未命中),更充分发挥CPU cache的作用,提高CPU指令的执行效率;并且进一步减少协议栈收发包逻辑里的内存拷贝,减少CPU的运算任务,降低CPU负载线程之间的切换开销,降低了处理时延。
所述在一个线程内运行任务包含的任务逻辑,包括:在一个线程内运行事件处理和协议栈收发包。
优选的,为了实现在一个线程内运行任务包含的任务逻辑,并保证任务包含的任务逻辑不发生阻塞,一个线程内运行任务包含的所有任务逻辑(如业务处理、RPC通信、协议栈收发包等)以事件形式来处理。
所述在一个线程内运行任务包含的任务逻辑,包括在一个线程内执行如下至少一个任务包含的任务逻辑:
客户端发任务;服务端收任务;服务端发任务;客户端收任务。
所述客户端发任务,可以包括如下步骤:
将请求上下文封装为RPC消息对象;
对所述RPC消息对象进行RPC通信处理,将所述RPC消息对象序列化为内存数据;
通过套接字可写事件将所述内存数据写到TCP/IP套接字接口;
利用协议栈从TCP/IP套接字接口将所述内存数据取出,并封装为网络数据包;
经DPDK将网络数据包提交至网卡,发送到服务端。
所述服务端收任务,可以包括如下步骤:
经DPDK从网卡接收网络数据包;
利用协议栈对所述网络数据包进行解析及处理,得到payload数据并产生套接字可读事件;
通过所述套接字可读事件读出payload数据;
将读出的payload数据解码获得对应的RPC消息对象;
从所述RPC消息对象中获得请求上下文;
所述服务端发任务,可以包括如下步骤:
获得请求结果后进行业务逻辑处理,将所述请求结果封装为第二RPC消息对象;
对所述RPC消息对象进行RPC通信处理,将所述RPC消息对象序列化为内存数据;
通过套接字可写事件将所述内存数据写到TCP/IP套接字接口;
利用协议栈从TCP/IP套接字接口将所述内存数据取出,并封装为网络数据包;
经DPDK将所述网络数据包提交至网卡,发送到客户端。
所述客户端收任务,可以包括如下步骤:
经DPDK从网卡接收网络数据包;
利用协议栈对所述网络数据包进行解析及处理,产生套接字可读事件;
通过所述套接字可读事件读出payload数据;
将读出的payload数据解码获得对应的RPC消息对象;
从所述RPC消息对象中获得请求结果。
下面以以VM存储IO业务为例介绍客户端发任务;服务端收任务;服务端发任务;客户端收任务。请参照图2,客户端发任务的流程为以下顺序:首先处理虚线表示的流程:事件处理开始、IO业务处理、RPC通信处理、连接事件处理、事件处理结束;事件处理结束后轮询开始,协议栈发包处理、经DPDK向网卡发包、轮询结束。服务端发任务的流程与客户端发任务的流程类似;服务端收任务的流程与客户端发任务的流程相反,具体详见下面介绍。
1、客户端发任务(客户端提交I/O请求)
1)、IO业务处理:客户端从请求队列获得请求到达的事件后,取出请求上下文(如VM存储IO业务的七个基本属性),再将请求上下文封装为RPC消息对象,如VMIO_RPC_Request;其中,七个基本属性包括:
cluster_id;/*来自哪个集群*/
device_id;/*来自哪块磁盘*/
request_id;/*这块磁盘的每个请求给一个id标识*/
type;/*读、写、sync、trim等类型*/
data;/*数据地址*/
length;/*io请求的长度*/
offset;/*io请求的开始位置*/
除了上述七个属性,还有其它属性,比如性能trace、数据正确性相关的属性,这里不再详细列举;以上七个是VM存储IO业务的基本属性。
2)RPC通信处理:通过SubmitVMIO这个method,将RPC消息对象附加上rpc header(里面有service和method);并将RPC消息对象序列化为内存数据(将RPC消息对象编码到一段内存buffer);
3)连接事件处理:通过套接字可写事件取出buffer中的数据,并将数据写到TCP/IP套接字接口;
4)协议栈发包处理:TCP/IP协议栈将buffer的数据按照需要切分为网络MTU大小的数据,附上TCP/IP/ETHER的包头;
5)经DPDK向网卡发包:将带有TCP/IP/ETHER包头的buffer,通过DPDK提交给网卡,发送到服务端。
上述所有步骤在一个线程里运行。
2、服务端收任务
请参照图2,其流程为以下顺序:
1)服务端经DPDK从网卡接收网络数据包;
2)利用协议栈对所述网络数据包进行解析(解析TCP/IP/ETHER的包头)及处理,得到payload数据并产生套接字可读事件;
需要的话,处理协议栈定时任务处理,如TCP超时重传、连接timewait等(TCP协议栈要保证数据的可靠传输,丢包、乱序这些场景要定时重试,TCP连接有状态,状态异常时需要定时清理,如timewait);
3)通过所述套接字可读事件读出payload数据;
4)将读出的payload数据解码获得对应的RPC消息对象,如VMIO_RPC_Request;
5)从VMIO_RPC_Request消息对象中得到获得VM存储IO业务的上述七个基本属性;将IO请求提交到后面对应的分布式文件。
3、服务端发任务:
1)对应的分布式文件返回结果后,将结果封装为RPC消息对象,如VMIO_RPC_Response;
2)RPC通信将RPC消息对象附加上rpc header;并将RPC消息对象序列化为内存数据(将RPC消息对象编码到一段内存buffer)
3)通过套接字可写事件取出buffer中的数据,并将数据写到TCP/IP套接字接口;
4)TCP/IP协议栈将buffer的数据按照需要切分为网络MTU大小的数据,附上TCP/IP/ETHER的包头;
5)将带有TCP/IP/ETHER包头的buffer,通过DPDK提交给网卡,发送到客户端。
4、客户端收任务:
1)客户端经DPDK从网卡接收网络数据包;
2)利用协议栈对所述网络数据包进行解析(解析TCP/IP/ETHER的包头)及处理,得到payload数据并产生套接字可读事件;
需要的话,处理协议栈定时任务处理,如TCP超时重传、连接timewait等(TCP协议栈要保证数据的可靠传输,丢包、乱序这些场景要定时重试,TCP连接有状态,状态异常时需要定时清理,如timewait);
3)通过所述套接字可读事件读出payload数据;
4)将读出的payload数据解码获得对应的RPC消息对象,如VMIO_RPC_Response;
5)从VMIO_RPC_Request消息对象中得到得到VM存储IO请求的结果,例如,根据errorcode可以确定IO请求是成功还是失败,从trace等数据得到表示性能相关的数据等。
需要说明的是,在一个线程里,每个大流程(例如,客户端接收IO处理结果、客户端提交IO请求等)的基本流程处理是相同的,而根据业务的需要会有不同的业务逻辑处理子流程。
一个线程可以同时运行client和server,client和server的RPC通信处理流程不同,但不同的业务可以使用同一套client RPC处理流程和同一套serverRPC处理流程。
由于本申请第一实施例实现了一个线程处理IO生命周期的所有逻辑,会导致这个线程所在CPU核心执行更多的指令,加重CPU的负载,而一个CPU核心的处理能力是有上限的,如果负载过高导致轮询不够及时,可能会造成高压力场景网络重传增多,性能恶化。因此,为了解决上述问题,本申请第一实施例在协议栈收包处理与协议栈发包处理过程中各减少一次内存拷贝:
实现发送队列send_queue,发送队列维护send_head,记录当前发送的位置(Tcp发数据时会分配sequence,当前发送的位置指的是发送的sequence),在写事件处理里,直接根据用户IO的数据size、MTU、发送窗口等因素创建DPDK buffer加入到发送队列,并将数据拷贝到DPDKbuffer中。
实现接收队列recv_queue,接收队列中维护乱序接收所形成的数据段fragment,每个fragment内维护sequence连续的若干个DPDKbuffer;读事件处理里,将数据直接从recv_queue拷贝到用户的IO中。
由于TCP/IP网络数据收发时都是处理大量小段数据并附上包头header,send_queue和recv_queue管理这些数据段,因此减少数据拷贝,优化了性能。
与上述提供的一种任务逻辑的处理方法相对应的,本申请第二实施例还提供了一种任务逻辑的处理装置。
如图3所示,任务逻辑的处理装置,包括:任务逻辑确定单元301、任务逻辑运行单元302。
任务逻辑确定单元301,用于确定任务包含的任务逻辑;
任务逻辑运行单元302,用于在一个线程内运行所述任务包含的任务逻辑。
可选的,还包括:所述任务包含的所有任务逻辑以事件形式处理。
可选的,所述任务包括如下至少一种任务逻辑:
事件处理;
协议栈收发包;
所述在一个线程内运行所述任务包含的任务逻辑,包括:在一个线程内运行事件处理和协议栈收发包。
可选的,所述协议栈收发包,包括:
经DPDK从网卡接收网络数据包;
利用协议栈对所述网络数据包进行解析及处理;
利用线程定时器处理协议栈的定时任务;
利用协议栈进行发包处理;
经DPDK将封装后的网络数据包发送到所述网卡。
可选的,所述事件处理,包括:
连接事件处理;所述连接事件为利用协议栈对网络数据包解析后触发的事件;
RPC通信处理;
业务处理。
可选的,所述连接事件包括如下至少一种事件:
套接字可读事件、套接字可写事件、套接字建立事件、套接字断开事件。
可选的,所述任务逻辑运行单元,具体用于:
在一个线程内执行如下至少一个任务包含的任务逻辑::
客户端发任务;服务端收任务;服务端发任务;客户端收任务。
可选的,所述客户端发任务,包括如下步骤:
将请求上下文封装为RPC消息对象;
对所述RPC消息对象进行RPC通信处理,将所述RPC消息对象序列化为内存数据;
通过套接字可写事件将所述内存数据写到TCP/IP套接字接口;
利用协议栈从TCP/IP套接字接口将所述内存数据取出,并封装为网络数据包;
经DPDK将网络数据包提交至网卡,发送到服务端。
可选的,所述服务端收任务,包括如下步骤:
经DPDK从网卡接收网络数据包;
利用协议栈对所述网络数据包进行解析及处理,得到payload数据并产生套接字可读事件;
通过所述套接字可读事件读出payload数据;
将读出的payload数据解码获得对应的RPC消息对象;
从所述RPC消息对象中获得请求上下文;
可选的,所述服务端发任务,包括如下步骤:
获得请求结果后进行业务逻辑处理,将所述请求结果封装为RPC消息对象;
对所述RPC消息对象进行RPC通信处理,将所述RPC消息对象序列化为内存数据;
通过套接字可写事件将所述内存数据写到TCP/IP套接字接口;
利用协议栈从TCP/IP套接字接口将所述内存数据取出,并封装为网络数据包;
经DPDK将所述网络数据包提交至网卡,发送到客户端。
可选的,所述客户端收任务,包括如下步骤:
经DPDK从网卡接收网络数据包;
利用协议栈对所述网络数据包进行解析及处理,产生套接字可读事件;
通过所述套接字可读事件读出payload数据;
将读出的payload数据解码获得对应的RPC消息对象;
从所述RPC消息对象中获得请求结果。
需要说明的是,对于本申请第二实施例提供的任务逻辑的处理装置的详细描述可以参考对本申请第一实施例的相关描述,这里不再赘述。
与上述提供的一种任务逻辑的处理方法相对应的,本申请第三实施例还提供了一种电子设备。
如图4所示,电子设备包括:
处理器401;以及
存储器402,用于任务逻辑的处理方法的程序,该设备通电并通过所述处理器运行该任务逻辑的处理方法的程序后,执行下述步骤:
确定任务包含的任务逻辑;
在一个线程内运行所述任务包含的任务逻辑。
可选的,还包括:所述任务包含的所有任务逻辑以事件形式处理。
可选的,所述任务包括如下至少一种任务逻辑:
事件处理;
协议栈收发包;
所述在一个线程内运行所述任务包含的任务逻辑,包括:在一个线程内运行事件处理和协议栈收发包。
可选的,所述协议栈收发包,包括:
经DPDK从网卡接收网络数据包;
利用协议栈对所述网络数据包进行解析及处理;
利用线程定时器处理协议栈的定时任务;
利用协议栈进行发包处理;
经DPDK将封装后的网络数据包发送到所述网卡。
可选的,所述事件处理,包括:
连接事件处理;所述连接事件为利用协议栈对网络数据包解析后触发的事件;
RPC通信处理;
业务处理。
可选的,所述连接事件包括如下至少一种事件:
套接字可读事件、套接字可写事件、套接字建立事件、套接字断开事件。
可选的,所述在一个线程内运行所述任务包含的任务逻辑,包括:在一个线程内执行如下至少一个任务包含的任务逻辑:
客户端发任务;服务端收任务;服务端发任务;客户端收任务。
可选的,所述客户端发任务,包括如下步骤:
将请求上下文封装为RPC消息对象;
对所述RPC消息对象进行RPC通信处理,将所述RPC消息对象序列化为内存数据;
通过套接字可写事件将所述内存数据写到TCP/IP套接字接口;
利用协议栈从TCP/IP套接字接口将所述内存数据取出,并封装为网络数据包;
经DPDK将网络数据包提交至网卡,发送到服务端。
可选的,所述服务端收任务,包括如下步骤:
经DPDK从网卡接收网络数据包;
利用协议栈对所述网络数据包进行解析及处理,得到payload数据并产生套接字可读事件;
通过所述套接字可读事件读出payload数据;
将读出的payload数据解码获得对应的RPC消息对象;
从所述RPC消息对象中获得请求上下文;
可选的,所述服务端发任务,包括如下步骤:
获得请求结果后进行业务逻辑处理,将所述请求结果封装为RPC消息对象;
对所述RPC消息对象进行RPC通信处理,将所述RPC消息对象序列化为内存数据;
通过套接字可写事件将所述内存数据写到TCP/IP套接字接口;
利用协议栈从TCP/IP套接字接口将所述内存数据取出,并封装为网络数据包;
经DPDK将所述网络数据包提交至网卡,发送到客户端。
可选的,所述客户端收任务,包括如下步骤:
经DPDK从网卡接收网络数据包;
利用协议栈对所述网络数据包进行解析及处理,产生套接字可读事件;
通过所述套接字可读事件读出payload数据;
将读出的payload数据解码获得对应的RPC消息对象;
从所述RPC消息对象中获得请求结果。
需要说明的是,对于本申请第三实施例提供的电子设备的详细描述可以参考对本申请第一实施例的相关描述,这里不再赘述。
与上述提供的一种任务逻辑的处理方法相对应的,本申请第四实施例还提供了一种存储设备,存储有任务逻辑的处理方法的程序,该程序被处理器运行,执行下述步骤:
确定任务包含的任务逻辑;
在一个线程内运行所述任务包含的任务逻辑。
需要说明的是,对于本申请第四实施例提供的存储设备的详细描述可以参考对本申请第一实施例的相关描述,这里不再赘述。
本申请虽然以较佳实施例公开如上,但其并不是用来限定本申请,任何本领域技术人员在不脱离本申请的精神和范围内,都可以做出可能的变动和修改,因此本申请的保护范围应当以本申请权利要求所界定的范围为准。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括非暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。