WO2012155440A1 - 一种基于超文本传输协议的业务请求处理方法及装置 - Google Patents
一种基于超文本传输协议的业务请求处理方法及装置 Download PDFInfo
- Publication number
- WO2012155440A1 WO2012155440A1 PCT/CN2011/080604 CN2011080604W WO2012155440A1 WO 2012155440 A1 WO2012155440 A1 WO 2012155440A1 CN 2011080604 W CN2011080604 W CN 2011080604W WO 2012155440 A1 WO2012155440 A1 WO 2012155440A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- service request
- readable
- writable
- socket
- processed
- Prior art date
Links
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/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
Definitions
- the present invention relates to the field of Internet technologies, and in particular, to a hypertext transfer protocol.
- the communication module that processes the service request in the prior art generally adopts the select/poll mode. In the case of fewer links, the communication efficiency is higher, but when the number of single-threaded links increases to a certain extent, the select/poll mode consumes a large amount of CPU resources, resulting in data transmission and reception delay. And when the number of links reaches the threshold, the message queue is accumulated in a large amount, and the CPU and memory exhaustion cannot work.
- the select/poll mode requires socket collection (FD_SET). There are a large number of writable sockets in the link. In the select/poll mode, all links in the thread need to be traversed, and all sockets are collected. ;
- the select/poll mode requires socket cleaning (FD_ZER0), which means that the sockets collected at the previous time need to be cleared before each socket collection;
- the select/poll mode needs to be judged (FD_ISSET), that is, polling all links to determine whether the socket of each link is in the socket set. Since the above existing processing of the service uses the select/poll mode, the select/poll mode does not change the state of most of the sockets because it needs to repeatedly poll the socket set. This has caused a waste of system resources. By adding threads, you can save money to a certain extent, but you can't solve the problem fundamentally. When the business volume increases, the above problems are especially serious. Summary of the invention
- the present invention provides an HTTP-based service request processing method and apparatus, which are used to solve the problem of system resource waste caused by using the select/poll mode in the process of processing a service request when maintaining a large number of links in the prior art.
- the problem is not limited to HTTP-based service request processing method and apparatus, which are used to solve the problem of system resource waste caused by using the select/poll mode in the process of processing a service request when maintaining a large number of links in the prior art.
- the embodiment of the invention provides a method for processing a service request based on HTTP, and the method comprises the following steps:
- the service request is a service request for establishing a link, and when it is determined that the service request has been processed, the socket corresponding to the service request to be built is added to a set of readable or writable trigger events. For:
- the socket corresponding to the business request is added to the readable trigger event set.
- the service request is a listener service request, and when it is determined that the service request has been processed, the socket corresponding to the service request that is to be built is added to the readable or writable trigger event set:
- the socket corresponding to the service request is added to the readable trigger event set.
- the service request is a data transmission service request, and when it is determined that the service request has been processed, the socket corresponding to the service request is added to the readable or writable trigger event set.
- the socket corresponding to the service request is added to the set of writable trigger events.
- the method further includes: receiving a service request, and processing the service request.
- the receiving industry request, processing the service request includes:
- the master thread receives the service request, and distributes the received service request to the message queue of each worker thread;
- the worker thread gets each business request from the message queue and processes the obtained business request.
- the processing of the obtained service request includes:
- the obtained service request is processed.
- An embodiment of the present invention provides an apparatus for processing a service request based on an HTTP, where the apparatus includes:
- a determining module configured to determine, according to the received service request, whether the service request has been processed
- An adding module configured to add a socket corresponding to the constructed service request to a set of readable or writable trigger events when it is determined that the service request has been processed;
- a processing module configured to perform corresponding operations according to a socket included in a readable or writable trigger event set.
- the adding module is specifically configured to: when the service request is a service request for establishing a link, and determine that the operation of establishing a link is completed, adding the socket corresponding to the service request to the readable trigger event set. .
- the adding module is specifically configured to: when the service request is a listening service request, and determine to start listening, add the socket corresponding to the service request to the readable trigger event set.
- the adding module is specifically configured to: when the service request is a data sending service request, and determine that there is data to be sent, add the socket corresponding to the service request to the writable trigger event set.
- the device also includes:
- the receiving module is configured to receive a service request, and process the service request.
- the receiving module is specifically configured to receive a service request by using a master thread, and distribute the received service request to a message queue of each worker thread; the worker thread obtains each service request from the message queue, and acquires the service request.
- Business requests are processed.
- the receiving module is specifically configured to determine whether the number of the obtained service requests reaches a set threshold, or whether there is no service request to be obtained in the message queue; when the number of the obtained service requests reaches a set threshold, Or, when there is no service request to be obtained in the message queue, the obtained service request is processed.
- An embodiment of the present invention provides a method and an apparatus for processing a service request based on an HTTP.
- the method after receiving a service request, determining to process the service request, adding the constructed socket to the trigger event set.
- the socket is added to the corresponding readable or writable trigger event set, only in the readable or writable trigger event set.
- the sockets are processed according to different link states, and there is no need to repeatedly clear the socket set, the statistics socket, and the polling socket to find the link, thus avoiding the readable or writable socket each time.
- the time consumed by word polling improves the efficiency of business request processing, maintains a large number of links, and saves system resources.
- FIG. 1 is a schematic flowchart of a method for processing a service request based on HTTP according to an embodiment of the present invention
- FIG. 2 is a schematic diagram of a detailed process of a method for processing a service request based on HTTP according to an embodiment of the present invention
- FIG. 3 is a schematic diagram of a process of an HTTP-based service request processing method when the service request is a service request for establishing a link according to an embodiment of the present invention
- FIG. 4 is a schematic structural diagram of an HTTP-based service request processing apparatus according to an embodiment of the present invention. detailed description
- the embodiment of the present invention provides a service request processing method and device for maintaining a large number of links based on HTTP, and the method is processed according to whether the service request is processed.
- the join is added to the corresponding set of readable or writable trigger events, and only the sockets in the readable or writable trigger event collection are processed, thus avoiding polling for readable or writable sockets each time. The time consumed increases the efficiency of business request processing and saves system resources.
- FIG. 1 shows a process of an HTTP-based service request processing method according to an embodiment of the present invention, the process comprising the following steps:
- S101 Determine, according to the received service request, whether the service request is processed.
- the method before determining whether the service request is processed, the method further includes:
- the service request includes: establishing a linked service request, a listening service request, and a data sending service request.
- S103 Perform corresponding operations according to the socket included in the readable or writable trigger event collection.
- the socket is added to the corresponding readable or writable trigger event set, and only the socket in the readable or writable trigger event set is processed. , you don't need to empty the socket set, count the socket, poll the socket to find the link, thus avoiding the time spent readable or writable socket polling in each network input and output.
- Improve the efficiency of business request processing and is suitable for maintaining a large number of links, saving system resources.
- the epoll mode is used for communication to implement processing of the service request, and the epoll mode does not need to collect a large number of sockets, as long as the link and the link are established after the link is established, monitored, or established.
- the related socket is written into a piece of memory, and then the socket collection is no longer needed. It is only necessary to change the trigger mode of the socket through the interface.
- the system returns the link index and obtains the link information, thereby avoiding the select/poll mode. In order to obtain the link information, each time the polling thread needs to be all Link, whether the sockets in the socket set are consistent with the link socket, so as to find the corresponding link information.
- all the links are divided into multiple threads for maintenance, thereby improving service request reception. And the efficiency of sending, and because each thread fixedly processes a certain number of service requests, so that the queuing or delay of the message queue is not caused by frequent read and write operations, the efficiency of reading and writing can be effectively improved.
- each service request in order to further improve the efficiency of reading and writing, when each thread processes a service request, each service request can be uniformly received, and each service request is processed, and then unified.
- Asynchronous read and write operations such as processing a service request to establish a link, listening for a service request, or adding data to be sent to a message queue, and then performing asynchronous operations uniformly, thereby further avoiding queuing of message queues due to frequent read and write operations. Delay, further improve the efficiency of reading and writing.
- the receiving the service request, the processing the service request includes: the main control thread receiving the service request, and distributing the received service request to the message queue of each worker thread;
- the worker thread gets each business request from the message queue and processes the obtained business request.
- the specific processing of the obtained service request includes:
- the obtained service request is processed.
- FIG. 2 is a detailed process of a method for processing a service request based on HTTP according to an embodiment of the present invention, where the process includes the following steps:
- S201 The master thread receives the service request, and distributes the received service request to the message queue of each worker thread.
- S202 The worker thread obtains each service request from the message queue, determines whether the quantity of the obtained service request reaches a set threshold, or whether there is no service request to be obtained in the message queue, and when at least one of the determination results is yes Go to step S203, otherwise, go to step S202.
- step S204 It is judged whether the service request is processed. When the determination result is YES, step S205 is performed; otherwise, step S204 is performed.
- step S206 Perform corresponding operations according to the sockets included in the readable or writable trigger event collection.
- the main control thread is responsible for distributing the received service request to each worker thread, wherein in the foregoing process, step S201 is a distribution action process of the main control thread, and steps S202 to S206 are working threads. Processing.
- the service request when receiving the service request, includes a request to establish a link, a service request for listening to a port, or a service request for sending data on a link.
- the master thread After receiving the service request, the master thread sends the service request to each worker thread. Specifically, the master thread sends each service request received to the message queue of each worker thread.
- each service request is obtained from the message queue.
- the asynchronous read/write operation is not directly performed, but the asynchronous operation is performed when a certain condition is met. operating.
- the condition is that the service request to be obtained does not exist in the message queue, or the number of service requests obtained by the worker thread reaches a set threshold, and the set threshold may be determined according to the processing capability of the worker thread, for example, It is 200.
- the worker thread After the worker thread obtains each service request, it processes the obtained service request, and after processing a certain service request, adds the constructed socket corresponding to the service request to the readable or writable trigger event. In the collection. When the socket corresponding to each business request is built After the readable or writable trigger event collection, the worker thread does not perform asynchronous read and write operations, but only after the above conditions are met, the asynchronous read and write operations are unified.
- the service request may be a link service request, a monitoring service request, and a data sending service request.
- the socket is added to the set of readable trigger events.
- the socket is added to the readable trigger event set.
- the socket is added to the writable trigger event set.
- FIG. 3 is a flowchart of a method for processing a service request based on an HTTP when the service request is a service request for establishing a link according to an embodiment of the present invention, where the process includes the following steps:
- S301 The terminal (CP) sends a service request for establishing a link, and the service request processing device receives the service request for establishing the link.
- the service request processing device After receiving the service request for establishing the link, the service request processing device establishes a socket (Socket), binds the local IP, sets a non-blocking mode (ioctl), and initiates a connection to the service provider (SP) (connect ).
- Socket Socket
- binds the local IP sets a non-blocking mode (ioctl)
- SP service provider
- the service request processing device After determining that the establishing link operation is completed, the service request processing device adds the socket corresponding to the service request for establishing the link to the readable trigger event set, and when the operation of establishing the link is asynchronous completion, the next epoll
- the socket returned after _waiting (epoll_wait) is in the set of writable trigger events, and the socket is added to the set of readable trigger events.
- S304 Perform corresponding operations according to the sockets included in the readable trigger event collection.
- the service request processing device receives the service request as the monitoring service request
- the socket is established for the service request, the local IP address and the port are bound, and the non-blocking mode is set. Listening, and adding the corresponding socket of the business request to the readable trigger event collection.
- a service request to establish a link is heard at a certain moment, the socket is received, and the socket is distributed to a thread to listen for its readable trigger.
- the socket corresponding to the service request is added to the writable trigger event set according to the link that sends the service request, after epoll_wait, when When the link is writable, the data is sent directly. Only when the data is sent, the corresponding socket of the service request is added to the readable trigger, so that a large number of readable events are returned after each epolLwait, so the service request is Processing methods improve the efficiency of reading and writing.
- the link establishes the link, the corresponding socket of the service request is added to the readable trigger event set. If there is data to be read, epoll_wait will trigger a readable event, and then receive (recv) the data.
- FIG. 4 is a schematic structural diagram of an apparatus for processing a service request based on a hypertext transfer protocol HTTP according to an embodiment of the present disclosure, where the apparatus includes:
- the determining module 41 is configured to determine, according to the received service request, whether the service request is processed;
- An adding module 42 is configured to add the constructed socket to a set of readable or writable trigger events when it is determined that the service request is processed;
- the processing module 43 is configured to perform corresponding operations according to the sockets included in the readable or writable trigger event set.
- the adding module 42 is specifically configured to: when the service request is a service request for establishing a link, when it is determined that the operation of establishing a link is completed, the socket is added to the readable trigger event set.
- the adding module 42 is specifically configured to: when the service request is a listening service request, add a socket to the readable trigger event set when it is determined to start listening.
- the adding module 42 is specifically configured to: when the service request is a data sending service request, when it is determined that there is data to be sent, add the socket to the writable trigger event set.
- the device also includes:
- the receiving module 44 is configured to receive the service request, and process the service request.
- the receiving module 44 is specifically configured to receive a service request by using a master thread, and distribute the received service request to a message queue of each worker thread; the worker thread obtains each service request from the message queue, and obtains the obtained service. Request for processing.
- the receiving module 44 is specifically configured to determine whether the number of the obtained service requests has reached a set threshold, or whether there is no service request to be obtained in the message queue; when the number of the obtained service requests reaches a set threshold If the service request to be obtained does not exist in the message queue, the obtained service request is processed.
- An embodiment of the present invention provides a method and an apparatus for processing a service request based on an HTTP.
- the constructed socket is added to the readable file.
- a set of writable trigger events selectively added to a set of readable or writable trigger events according to the current link state, each time the events are triggered, selectively readable or writable according to the current link state Trigger, which handles the corresponding sockets in the set of readable or writable trigger events.
- the socket is added to the corresponding readable or writable trigger event set, and only the socket in the readable or writable trigger event set is based on Different link states are processed, eliminating the need to repeatedly clear the socket set, the statistics socket, and the polling socket to find the link, thus avoiding the consumption of readable or writable socket polling each time. Time, improve the efficiency of business request processing, maintain a large number of links, and save system resources.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
Description
一种基于超文本传输协议的业务请求处理方法及装置 技术领域
本发明涉及互联网技术领域， 尤其涉及一种基于超文本传输协议
( Hyper Text Transfer Protocol , HTTP ) 的业务请求处理方法及装置。 背景技术
随着移动互联网技术的飞速发展， 短信业务、 彩信业务以及交互式网 络电视（IPTV )业务导致用户数量急剧增加， 从而也促使大数据量的媒体 业务在移动互联网中普及。 因此几百甚至上千兆的文件可能会在链路中传 输， 从而占用该链路较长时间， 造成服务提供商 （SP ) 因为访问量太大， 而产生响应延迟， 进而增加了每个业务的生命周期。
在现有技术中对业务请求进行处理的通信模块一般采用 select/poll模 式。 在链路较少的情况下， 其通讯的效率较高， 但是当单线程链路数量增 加一定程度时， 该 select/poll模式会占用大量的 CPU资源， 导致数据发送 和接收延迟。 并且当链路数量达到阈值时导致消息队列大量积累， CPU和 内存耗尽无法工作。
现有技术中存在上述问题的原因主要是：
select/poll模式需要进行套接字的收集（ FD_SET ), 在链路中存在大量 可写可读的套接字， 采用 select/poll模式需要遍历线程内所有的链路， 收集 所有的套接字；
select/poll模式需要进行套接字的清理（FD_ZER0 ), 即在每次进行套 接字收集之前需要将上一时刻收集的套接字清零；
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_等待（epoll_wait )之后则返回的该套接 字位于可写触发事件集合中， 将该套接字加入到可读触发事件集合中。
S304: 根据可读触发事件集合中包含的套接字进行相应的操作。
当业务请求处理装置接收到的业务请求为监听业务请求时， 当业务请 求处理装置接收到该监听业务请求后， 针对该业务请求建立套接字， 绑定 本地 IP和端口， 设置非阻塞模式并监听， 并将该业务请求对应的套接字加 入到可读触发事件集合中。 当某一时刻监听到建立链接的业务请求时， 则 接收该套接字， 并将该套接字分发到某一线程， 侦听其可读触发。
当业务请求处理装置接收到的业务请求为数据发送业务请求时， 则根 据发送该业务请求的链路， 将该业务请求对应的套接字加入到可写触发事 件集合中， epoll_wait之后， 当该链路可写时， 直接发送该数据， 只有在数 据发送时， 才将该业务请求对应的套接字加入到可读触发， 避免每次 epolLwait之后返回大量的可读事件， 因此该业务请求的处理方式提高了读 写的效率。 当链路建立链接之后该业务请求对应的套接字加入到可读触发 事件集合中， 如果存在待读取的数据， 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所述的装置， 其中， 所述接收模块， 设置为通过主 控线程接收业务请求， 将接收到的业务请求分发给每个工作线程的消息队 歹 |J ; 工作线程从消息队列获取每个业务请求， 并对获取到的业务请求进行 处理。
14、 如权利要求 13所述的装置， 其中， 所述接收模块， 设置为判断获 取到的业务请求的数量是否达到设定阈值， 或是否消息队列中不存在待获 取的业务请求； 当获取到的业务请求的数量达到设定阈值， 或消息队列中 不存在待获取的业务请求时， 对获取到的业务请求进行处理。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2011101236499A CN102202094A (zh) | 2011-05-13 | 2011-05-13 | 一种基于http的业务请求处理方法及装置 |
| CN201110123649.9 | 2011-05-13 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2012155440A1 true WO2012155440A1 (zh) | 2012-11-22 |
Family
ID=44662484
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2011/080604 WO2012155440A1 (zh) | 2011-05-13 | 2011-10-10 | 一种基于超文本传输协议的业务请求处理方法及装置 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN102202094A (zh) |
| WO (1) | WO2012155440A1 (zh) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20230350739A1 (en) * | 2022-05-02 | 2023-11-02 | Sap Se | Resilient asynchronous request-reply solution for message-driven architectures |
| US12001897B2 (en) * | 2022-05-02 | 2024-06-04 | Sap Se | Resilient asynchronous request-reply solution for message-driven architectures |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102202094A (zh) * | 2011-05-13 | 2011-09-28 | 中兴通讯股份有限公司 | 一种基于http的业务请求处理方法及装置 |
| CN102938783A (zh) * | 2012-10-30 | 2013-02-20 | 中兴通讯股份有限公司 | 一种Socket处理方法、装置和Web服务器 |
| CN103905484B (zh) * | 2012-12-26 | 2017-08-01 | 北京新媒传信科技有限公司 | 处理超文本传输协议请求的方法及装置 |
| CN103605568B (zh) * | 2013-10-29 | 2017-10-31 | 北京奇虎科技有限公司 | 一种多线程管理方法及装置 |
| CN106302554A (zh) * | 2016-11-08 | 2017-01-04 | 郑州云海信息技术有限公司 | 一种socket通信方法、装置和存储设备 |
| CN107454167A (zh) * | 2017-08-04 | 2017-12-08 | 深圳市元征科技股份有限公司 | 请求处理方法及服务器 |
| CN108509259A (zh) * | 2018-01-29 | 2018-09-07 | 深圳壹账通智能科技有限公司 | 获取多方数据源的方法以及风控系统 |
| CN108563493A (zh) * | 2018-04-12 | 2018-09-21 | 郑州云海信息技术有限公司 | 一种事件驱动方法、装置、设备及可读存储介质 |
| CN111698275B (zh) | 2019-03-15 | 2021-12-14 | 华为技术有限公司 | 数据处理方法、装置及设备 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101124801A (zh) * | 2004-12-21 | 2008-02-13 | 高通股份有限公司 | 客户机协助的防火墙配置 |
| CN101772981A (zh) * | 2007-08-23 | 2010-07-07 | 艾利森电话股份有限公司 | 网络接入选择信息的简单检索的方法 |
| CN102202094A (zh) * | 2011-05-13 | 2011-09-28 | 中兴通讯股份有限公司 | 一种基于http的业务请求处理方法及装置 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101141474B (zh) * | 2007-09-27 | 2010-06-16 | 中兴通讯股份有限公司 | 一种基于超文本传输协议的通讯系统及方法 |
| CN101621532B (zh) * | 2008-06-30 | 2012-09-05 | 中兴通讯股份有限公司 | 一种使用线程池实现超文本传输协议应用的方法 |
| CN101448006B (zh) * | 2008-12-25 | 2012-01-11 | 中兴通讯股份有限公司 | 一种实现流媒体服务器大量终端接入的方法及系统 |
| CN102055718B (zh) * | 2009-11-09 | 2014-12-31 | 华为技术有限公司 | 一种在http streaming系统中实现分层请求内容的方法,装置和系统 |
| CN102055774B (zh) * | 2009-11-10 | 2015-09-16 | 腾讯科技（深圳）有限公司 | 基于包处理的http服务器及其数据处理方法 |
-
2011
- 2011-05-13 CN CN2011101236499A patent/CN102202094A/zh active Pending
- 2011-10-10 WO PCT/CN2011/080604 patent/WO2012155440A1/zh active Application Filing
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101124801A (zh) * | 2004-12-21 | 2008-02-13 | 高通股份有限公司 | 客户机协助的防火墙配置 |
| CN101772981A (zh) * | 2007-08-23 | 2010-07-07 | 艾利森电话股份有限公司 | 网络接入选择信息的简单检索的方法 |
| CN102202094A (zh) * | 2011-05-13 | 2011-09-28 | 中兴通讯股份有限公司 | 一种基于http的业务请求处理方法及装置 |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20230350739A1 (en) * | 2022-05-02 | 2023-11-02 | Sap Se | Resilient asynchronous request-reply solution for message-driven architectures |
| US12001897B2 (en) * | 2022-05-02 | 2024-06-04 | Sap Se | Resilient asynchronous request-reply solution for message-driven architectures |
Also Published As
| Publication number | Publication date |
|---|---|
| CN102202094A (zh) | 2011-09-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2012155440A1 (zh) | 一种基于超文本传输协议的业务请求处理方法及装置 | |
| US9634915B2 (en) | Methods and computer program products for generating a model of network application health | |
| US9374425B2 (en) | Behavior based client selection for disparate treatment | |
| US11080090B2 (en) | Method and system for scalable job processing | |
| US8001176B2 (en) | Web service with multiple listening endpoints | |
| WO2021258753A1 (zh) | 一种业务处理方法、装置及电子设备和存储介质 | |
| CN105338061A (zh) | 一种轻量级消息中间件的实现方法与系统 | |
| CN105007337A (zh) | 集群系统负载均衡的方法和系统 | |
| WO2010072081A1 (zh) | 一种实现流媒体服务器大量终端接入的方法及系统 | |
| CN103036926A (zh) | 业务推送系统及方法 | |
| WO2023103419A1 (zh) | 基于消息队列的5g消息批量发送方法、装置及电子设备 | |
| US20140059152A1 (en) | Support server for redirecting task results to a wake-up server | |
| CN108228625B (zh) | 一种推送消息处理方法及装置 | |
| CN105681426A (zh) | 异构系统 | |
| CN111131499A (zh) | 并发和异步任务处理方法及其设备 | |
| JP2011203810A (ja) | サーバ、計算機システム及び仮想計算機管理方法 | |
| CN114064309A (zh) | 一种基于处理优先级的电缆业务数据处理方法及装置 | |
| CN113259408A (zh) | 数据传输方法和系统 | |
| CN111796935B (zh) | 调用日志信息的消费实例分配方法及系统 | |
| WO2013189421A2 (zh) | 分布式的话单统计方法、装置以及系统 | |
| WO2017165999A1 (zh) | 网络服务实现方法、服务控制器及通信系统 | |
| CN115883639A (zh) | 一种web实时消息推送方法及装置、设备、存储介质 | |
| CN111641698B (zh) | 一种数据统计方法、系统、设备及存储介质 | |
| CN115665042B (zh) | 数据处理方法、装置、用户平面功能实体及存储介质 | |
| JP2016076184A (ja) | ファイルシステム、管理装置の制御プログラム、および、ファイルシステムの制御方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 11865816 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 11865816 Country of ref document: EP Kind code of ref document: A1 |