CN102202094A

CN102202094A - 一种基于http的业务请求处理方法及装置

Info

Publication number: CN102202094A
Application number: CN2011101236499A
Authority: CN
Inventors: 孙轶超; 卢勤元; 沈蓓洁
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2011-05-13
Filing date: 2011-05-13
Publication date: 2011-09-28
Also published as: WO2012155440A1

Abstract

本发明公开了一种基于HTTP的业务请求处理方法及装置，该方法中，当接收到业务请求后，确定对该业务请求进行了处理时，将构建的套接字在其建立时加入到可读或可写触发事件集合中，根据当前的链路状态选择性的可读或可写触发，对可读或可写触发事件集合中的套接字做对应的处理。由于在本发明实施例中，根据业务请求是否进行了处理，将套接字加入到对应的可读或可写触发事件集合中，只对可读或可写触发事件集合中的套接字进行处理，不需要反复清空套接字集合，统计套接字，轮询套接字以查找链路，因此避免了每次网络输入输出中对可读或可写套接字轮询所消耗的时间，提高了业务请求处理的效率，适用于维护大量链路，节省了系统的资源。

Description

一种基于HTTP的业务请求处理方法及装置

技术领域

本发明涉及互联网技术领域，尤其涉及一种基于超文本传输协议(Hyper Text Transfer Protocol，HTTP)业务请求处理方法及装置。

背景技术

随着移动互联网技术的飞速发展，短信业务、彩信业务以及交互式网络电视(IPTV)业务导致用户数量急剧增加，从而也促使大数据量的媒体业务在移动互联网中普及。因此几百甚至上千兆的文件可能会在链路中传输，从而占用该链路较长时间，造成服务提供商(SP)因为访问量太大，而产生响应延迟，进而增加了每个业务的生命周期。

在现有技术中对业务请求进行处理的通信模块一般采用select/poll模式。在链路较少的情况下，其通讯的效率较高，但是当单线程链路数量增加一定程度时，该select/poll模式会占用大量的CPU资源，导致数据发送和接收延迟。并且当链路数量达到阈值时导致消息队列大量积累，CPU和内存耗尽无法工作。

现有技术中存在上述问题的原因主要是因为：

select/poll模式需要进行套接字的收集(FD_SET)，在链路中存在大量可写可读的套接字，采用select/poll模式需要遍历线程内所有的链路，收集所有的套接字；

select/poll模式需要进行套接字的清理(FD_ZERO)，即在每次进行套接字收集之前需要将上一时刻收集的套接字清零；

select/poll模式需要进行判断(FD_ISSET)，即轮询所有链路，判断每条链路的套接字是否在套接字集中。

由于上述现有的对业务处理的过程中，采用select/poll模式，而select/poll模式由于其需要反复轮询套接字集，而其中可能大部分套接字的状态都没有发生变化，从而造成了系统资源的浪费。而通过增加线程的方式可以从一定程度上可以节省开销，但是无法从根本上解决问题，当业务量增加时，上述问题尤其严重。

发明内容

有鉴于此，本发明提供一种基于HTTP的业务请求处理方法及装置，用以解决现有技术中维护大量链路时对业务请求进行处理的过程中，采用select/poll模式造成的系统资源浪费的问题。

本发明实施例提供了一种基于超文本传输协议HTTP的业务请求处理方法，该方法包括如下步骤：

根据接收的业务请求，判断是否对该业务请求进行了处理；

当确定对该业务请求进行了处理时，将构建的该业务请求对应的套接字加入到可读或可写触发事件集合中；

根据可读或可写触发事件集合中包含的套接字进行相应的操作。

本发明实施例提供了一种基于超文本传输协议HTTP的业务请求处理的装置，所述装置包括：

判断模块，用于根据接收的业务请求，判断是否对该业务请求进行了处理；

添加模块，用于当确定对该业务请求进行了处理时，将构建的套接字加入到可读或可写触发事件集合中；

处理模块，用于根据可读或可写触发事件集合中包含的套接字进行相应的操作。

本发明实施例提供了一种基于HTTP的业务请求处理方法及装置，该方法中，当接收到业务请求后，确定对该业务请求进行了处理时，将构建的套接字加入触发事件集合中，根据当前的链路状态选择性的加入到可读或可写触发事件集合中，每次触发这些事件后，根据当前的链路状态选择性的可读或可写触发，对可读或可写触发事件集合中的套接字做对应的处理。由于在本发明实施例中，根据业务请求是否进行了处理，将套接字加入到对应的可读或可写触发事件集合中，只对可读或可写触发事件集合中的套接字根据不同的链路状态做处理，不需要反复清空套接字集合，统计套接字，轮询套接字以查找链路，因此避免了每次对可读或可写套接字轮询所消耗的时间，提高了业务请求处理的效率，可维护大量链路，节省了系统的资源。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本发明的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1为本发明实施例提供的一种基于HTTP的业务请求处理过程；

图2为本发明实施例提供的一种基于HTTP的业务请求处理的详细过程；

图3为本发明实施例提供的当该业务请求为建立链接的业务请求时，基于HTTP的业务请求处理过程；

图4为本发明实施例提供的一种基于超文本传输协议HTTP的业务请求处理的装置的结构示意图。

具体实施方式

为了使本发明所要解决的技术问题、技术方案及有益效果更加清楚、明白，以下结合附图和实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明实施例为了有效的提高业务请求的处理效率，节省系统的资源，提供了一种基于HTTP维护大量链路时的业务请求处理方法及装置，该方法根据业务请求是否进行了处理，将套接字加入到对应的可读或可写触发事件集合中，只对可读或可写触发事件集合中的套接字进行处理，因此避免了每次对可读或可写套接字轮询所消耗的时间，提高了业务请求处理的效率，节省了系统的资源。

下面结合说明书附图，对本发明实施例进行详细说明。

图1为本发明实施例提供的一种基于HTTP的业务请求处理过程，该过程包括以下步骤：

S101：根据接收的业务请求，判断是否对该业务请求进行了处理。

其中，在本发明实施例中在判断是否对该业务请求进行了处理之前，该方法还包括：

接收该业务请求，并对该业务请求进行处理。

S102：当确定对该业务请求进行了处理时，将构建的套接字加入到可读或可写触发事件集合中。

具体的在本发明实施例中该业务请求包括：建立链接的业务请求、监听业务请求和数据发送业务请求。

S103：根据可读或可写触发事件集合中包含的套接字进行相应的操作。

由于本发明实施例中，根据业务请求是否进行了处理，将套接字加入到对应的可读或可写触发事件集合中，只对可读或可写触发事件集合中的套接字进行处理，不需要反复清空套接字集合，统计套接字，轮询套接字以查找链路，因此避免了每次网络输入输出中对可读或可写套接字轮询所消耗的时间，提高了业务请求处理的效率，适用于维护大量链路，节省了系统的资源。

具体的在本发明实施例中采用epoll模式进行通信，实现对业务请求的处理，epoll模式无需进行大量套接字的收集，只要在建立链接、监听或者建立后，一次性的将和链路相关的套接字写入到一段内存中，之后就不再需要进行套接字的收集了，只需要通过接口改变套接字的触发方式即可。在对相应触发方式的套接字进行处理时，系统会返回链路索引而获取到链路信息，从而规避了select/poll模式下，为了获知链路信息，每次都需要轮询线程下所有链路，是否套接字集中各个套接字与本链路套接字一致，以便于查找对应的链路信息。

在多数链路活跃的情况下，为了提高读写的效率，减小业务请求处理的时延，在本发明实施例中将所有链路均分到多线程中进行维护，从而可以提高业务请求接收和发送的效率，并且由于每个线程固定处理一定数量的业务请求，从而不会因为频繁的读写操作造成消息队列的排队或时延，可以有效的提高读写的效率。

另外，在本发明实施例中为了进一步提高读写的效率，在每个线程对业务请求进行处理时，可以统一的接收每个业务请求，并对每个业务请求进行处理，之后在进行统一的异步读写操作，例如处理完建立链接的业务请求、监听业务请求或将要发送的数据的加入消息队列后，再统一的进行异步操作，这样可以进一步避免因为频繁的读写操作造成消息队列的排队或时延，进一步提高读写的效率。

在本发明实施例中所述接收业务请求，对该业务请求进行处理包括：

主控线程接收业务请求，将接收到的业务请求分发给每个工作线程的消息队列；

工作线程从消息队列获取每个业务请求，并对获取到的业务请求进行处理。

具体的所述对获取到的业务请求进行处理，包括：

判断获取到的业务请求的数量是否达到了设定阈值，或是否消息队列中不存在待获取的业务请求；

当获取到的业务请求的数量达到了设定阈值，或消息队列中不存在待获取的业务请求时，对获取到的业务请求进行处理。

图2为本发明实施例提供的一种基于HTTP的业务请求处理的详细过程，该过程包括以下步骤：

S201：主控线程接收业务请求，将接收到的业务请求分发给每个工作线程的消息队列。

S202：工作线程从消息队列获取每个业务请求，判断获取到的业务请求的数量是否达到了设定阈值，或是否消息队列中不存在待获取的业务请求，当其中至少一个判断结果为是时，进行步骤S203，否则，进行步骤S202。

S203：对获取到的每个业务请求进行处理。

S204：判断是否对该业务请求进行了处理，当判断结果为是时，进行步骤S205，否则，进行步骤S204。

S205：将构建的套接字加入到可读或可写触发事件集合中。

S206：根据可读或可写触发事件集合中包含的套接字进行相应的操作。

具体的在本发明实施例中主孔线程负责将接收到的业务请求分发给各个工作线程，其中在该上述过程中步骤S201为主控线程的分发动作过程，步骤S202～S206为工作线程的处理过程。

当主控线程进行业务请求的发送时，当且接收到业务请求时，该业务请求包括向外建立链接的请求，监听某一端口的业务请求或在某一链路上发送数据的业务请求，当主控线程接收到该每个业务请求后，将业务请求均发到各个工作线程中去。具体的主控线程将接收到的每个业务请求均发到每个工作线程的消息队列中。

而工作线程在初始化完成后，从消息队列中获取每个业务请求，工作线程从消息队列获取到业务请求后，并不直接进行异步读写操作，而是当满足一定的条件时，才进行异步操作。该满足的条件是，消息队列中不存在待获取的业务请求，或者工作线程获取到的业务请求的数量达到了设定的阈值，该设定的阈值可以根据工作线程的处理能力确定，例如可以为200个。

当工作线程获取到每个业务请求后，对获取到的业务请求进行处理，当对某一业务请求进行处理后，将构建的该业务请求对应的套接字加入到可读或可写触发事件集合中。当将构建的每个业务请求对应的套接字加入到可读或可写触发事件集合中后，该工作线程也并不进行异步读写操作，而是在满足了上述条件后，才统一进行异步读写操作。

当工作线程进行了异步读写操作后，将业务请求的数量清零，以便循环进行下一次业务请求处理的过程。

具体的在本发明实施例中该业务请求可以为建立链接的业务请求、监听业务请求和数据发送业务请求。

当所述业务请求为建立链接的业务请求，当确定完成了建立链接的操作时，将套接字加入到可读触发事件集合中。

当所述业务请求为监听业务请求，当确定开始进行监听时，将套接字加入到可读触发事件集合中。

当所述业务请求为数据发送业务请求，当确定存在待发送数据时，将套接字加入到可写触发事件集合中。

下面通过具体的实施例进行说明。

图3为本发明实施例提供的当该业务请求为建立链接的业务请求时，基于HTTP的业务请求处理过程，该过程包括以下步骤：

S301：终端(CP)发送建立链接的业务请求，该业务请求处理装置接收该建立链接的业务请求。

S302：业务请求处理装置接收到该建立链接的业务请求后，建立套接字(socket))，绑定本地IP，设置非阻塞模式(ioctl)，并向服务提供商(SP)发起连接(connect)。

S303：业务请求处理装置当确定完成建立链接操作后，将该建立链接的业务请求对应的套接字加入到可读触发事件集合中，当该建立链接的操作为异步完成时，则在下次epoll_wait之后则返回的该套接字触发可写事件后，将该套接字加入到可读触发事件集合中。

S304：根据可读触发事件集合中包含的套接字进行相应的操作。

当业务请求处理装置接收到的业务请求为监听业务请求时，当业务请求处理装置接收到该监听业务请求后，针对该业务请求建立套接字，绑定本地IP和端口，设置非阻塞模式并监听，并将该业务请求对应的套接字加入到可读触发事件集合中。当某一时刻监听到建立链接的业务请求时，则接收该套接字，并将该套接字分发到某一线程，侦听其可读触发。

当业务请求处理装置接收到的业务请求为数据发送业务请求时，则根据发送该业务请求的链路，将该业务请求对应的套接字加入到可写触发事件集合中，epoll_wait之后，当该链路可写时，直接发送该数据，只有在数据发送时，才将该业务请求对应的套接字加入到可读触发，避免每次epoll_wait之后返回大量的可读事件，因此该业务请求的处理方式提高了读写的效率。当链路建立链接之后该业务请求对应的套接字加入到可读触发事件集合中，如果存在待读取的数据，epoll_wait将触发可读事件，进而接收(recv)该数据。

图4为本发明实施例提供的一种基于超文本传输协议HTTP的业务请求处理的装置的结构示意图，所述装置包括：

判断模块41，用于根据接收的业务请求，判断是否对该业务请求进行了处理；

添加模块42，用于当确定对该业务请求进行了处理时，将构建的套接字加入到可读或可写触发事件集合中；

处理模块43，用于根据可读或可写触发事件集合中包含的套接字进行相应的操作。

所述添加模块42，具体用于当所述业务请求为建立链接的业务请求，当确定完成了建立链接的操作时，将套接字加入到可读触发事件集合中。

所述添加模块42，具体用于当所述业务请求为监听业务请求，当确定开始进行监听时，将套接字加入到可读触发事件集合中。

所述添加模块42，具体用于当所述业务请求为数据发送业务请求，当确定存在待发送数据时，将套接字加入到可写触发事件集合中。

所述装置还包括：

接收模块44，用于接收该业务请求，并对该业务请求进行处理。

所述接收模块44，具体用于通过主控线程接收业务请求，将接收到的业务请求分发给每个工作线程的消息队列；工作线程从消息队列获取每个业务请求，并对获取到得业务请求进行处理。

所述接收模块44，具体用于判断获取到的业务请求的数量是否达到了设定阈值，或是否消息队列中不存在待获取的业务请求；当获取到的业务请求的数量达到了设定阈值，或消息队列中不存在待获取的业务请求时，对获取到的业务请求进行处理。

本发明实施例提供了一种基于HTTP的业务请求处理方法及装置，该方法中，当接收到业务请求后，当确定对该业务请求进行了处理时，将构建的套接字加入到可读或可写触发事件集合中，根据当前的链路状态选择性的加入到可读或可写触发事件集合中，每次触发这些事件后，根据当前的链路状态选择性的可读或可写触发，对可读或可写触发事件集合中的套接字做对应的处理。由于在本发明实施例中，根据业务请求是否进行了处理，将套接字加入到对应的可读或可写触发事件集合中，只对可读或可写触发事件集合中的套接字根据不同的链路状态做处理，不需要反复清空套接字集合，统计套接字，轮询套接字以查找链路，因此避免了每次对可读或可写套接字轮询所消耗的时间，提高了业务请求处理的效率，可维护大量链路，节省了系统的资源。

上述说明示出并描述了本发明的优选实施例，但如前所述，应当理解本发明并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文所述发明构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本发明的精神和范围，则都应在本发明所附权利要求的保护范围内。

Claims

1.一种基于超文本传输协议HTTP的业务请求处理方法，其特征在于，该方法包括如下步骤：

根据接收的业务请求，判断是否对该业务请求进行了处理；

2.如权利要求1所述的方法，其特征在于，当所述业务请求为建立链接的业务请求，当确定完成了建立链接的操作时，将套接字加入到可读触发事件集合中。

3.如权利要求1所述的方法，其特征在于，当所述业务请求为监听业务请求，当确定开始进行监听时，将该业务请求对应的套接字加入到可读触发事件集合中。

4.如权利要求1所述的方法，其特征在于，当所述业务请求为数据发送业务请求，当确定存在待发送数据时，将将该业务请求对应的套接字加入到可写触发事件集合中。

5.如权利要求1所述的方法，其特征在于，判断是否对该业务请求进行了处理之前，所述方法还包括：

接收该业务请求，并对该业务请求进行处理。

6.如权利要求5所述的方法，其特征在于，所述接收业请求，对该业务请求进行处理包括：

7.如权利要求6所述的方法，其特征在于，所述对获取到的业务请求进行处理，包括：

8.一种基于超文本传输协议HTTP的业务请求处理的装置，其特征在于，所述装置包括：

9.如权利要求8所述的装置，其特征在于，所述添加模块，具体用于当所述业务请求为建立链接的业务请求，当确定完成了建立链接的操作时，将套接字加入到可读触发事件集合中。

10.如权利要求8所述的装置，其特征在于，所述添加模块，具体用于当所述业务请求为监听业务请求，当确定开始进行监听时，将套接字加入到可读触发事件集合中。

11.如权利要求8所述的装置，其特征在于，所述添加模块，具体用于当所述业务请求为数据发送业务请求，当确定存在待发送数据时，将套接字加入到可写触发事件集合中。

12.如权利要求8所述的装置，其特征在于，所述装置还包括：

接收模块，用于接收该业务请求，并对该业务请求进行处理。

13.如权利要求12所述的装置，其特征在于，所述接收模块，具体用于通过主控线程接收业务请求，将接收到的业务请求分发给每个工作线程的消息队列；工作线程从消息队列获取每个业务请求，并对获取到的业务请求进行处理。

14.如权利要求13所述的装置，其特征在于，所述接收模块，具体用于判断获取到的业务请求的数量是否达到了设定阈值，或是否消息队列中不存在待获取的业务请求；当获取到的业务请求的数量达到了设定阈值，或消息队列中不存在待获取的业务请求时，对获取到的业务请求进行处理。