[发明专利]一种异步非阻塞响应式消息处理方法

说明书

本发明公开一种异步非阻塞响应式消息处理方法。所述方法包括：通信线程监听客户端的连接，并建立连接，接收客户端的请求消息，然后将请求消息发送到处理线程的第一消息队列；处理线程从第一消息队列中取出所述请求消息，如果不需要其他系统，建立会话，然后处理所述请求消息，将处理结果或处理失败原因通过通信线程发送给客户端；如果需要其他系统，处理线程挂起会话，等待其他系统应答的同时处理新的消息。本发明采用异步非阻塞响应方式处理消息，及时响应客户端请求，使日连接数量达到几十万甚至上百万，在等待其他系统的应答时，不阻塞线程，同时处理新的消息，使一个线程可以处理几万到十几万的请求数。

技术领域

本发明属于网络通信技术领域，具体涉及一种异步非阻塞响应式消息处理方法。

背景技术

支撑云平台长时间自主运行的是服务。服务与服务间的通信，可以维持两个不同平台之间的正常交互。而云平台间的数据传输依赖接口，接口间多数使用http通信协议进行数据传输。客户端为客户提供了本地服务，http客户端之间的接口开发需要一定的通讯规则。接口间的通信常用的规则和约定有通信方式、规则和约定、安全方式、交易模式等。目前的接口调用平台是基于springboot框架的，springboot框架的优点是前后端完全分离，只需要协商好接口就行，前端负责开发页面并调用后端接口展示数据。后端只负责提供rest接口。而目前主流的开发模式为同步阻塞模式，其工作流程为：服务端启动监听；接收到一个客户端连接时一个线程处理(可以是线程池，也能是直接启动线程)；接收请求(接受请求时，线程阻塞在这里)，处理请求，如果需要依赖其他模块时，需要发送消息给其他系统；接收其他系统的应答(发送请求和接收应答时会阻塞线程)，然后处理应答，最后给客户端发送最后的应答(也会阻塞线程)。

同步阻塞模式存在下面的问题：一个连接的并发请求数非常有限，因为线程阻塞在那里，前一个请求需要等到应答后，才能发送下一个请求；连接数非常有限，因为每一个连接需要占用一个线程，当需要几万、几十万、上百万的连接并存时，系统无法开启那么多线程；系统的并发性能依赖于响应时间，如果第三方系统故障无响应时，就可能有大批的线程被阻塞在那里，直到超时后才能释放，从而导致整体性能急剧下降；故障会扩散，局部故障会扩散到整体，如果系统1出现问题，访问它的线程都会被阻塞，当某个流程不依赖系统1，而是依赖系统2，但是由于线程都阻塞在系统1上，导致线程池线程用完，没有线程来处理本来能够正常处理的新请求。

发明内容

为了解决现有技术中存在的上述问题，本发明提出一种异步非阻塞响应式消息处理方法。

为实现上述目的，本发明采用如下技术方案：

一种异步非阻塞响应式消息处理方法，包括以下步骤：

步骤1，通信线程监听客户端的连接，并建立连接，接收客户端的请求消息，然后将请求消息发送到处理线程的第一消息队列；

步骤2，处理线程从第一消息队列中取出所述请求消息，如果不需要其他系统，则建立会话，然后处理所述请求消息，将处理结果或处理失败原因发送到通信线程的第二消息队列；通信线程从第二消息队列中取出所述处理结果或处理失败原因，并发送给客户端；如果需要其他系统，转步骤3；

步骤3，处理线程将向其他系统请求的消息发送到第二消息队列，通信线程从第二消息队列中取出所述消息，并发送给其他系统；

步骤4，处理线程挂起会话，等待其他系统应答的同时，从第一消息队列中取出新的消息，并进行处理。

进一步地，通信线程工作在SOCKET异步非阻塞模式，linux操作系统下采用epoll模式，windows操作系统下采用IOCP模式。

进一步地，所述方法还包括：如果待处理的消息数量超过最大允许数量，按照最大允许数量进行处理，超出最大允许数量的消息等待处理。

与现有技术相比，本发明具有以下有益效果：