异步非阻塞开发模式的优越性

同步阻塞开发模式：

1. 服务端启动监听；

2. 接收到一个客户端连接时，申请一个线程处理（可以是线程池，也能是直接启动线程。）

3.然后是接收请求（接受请求时，线程阻塞在这里），处理请求，如果需要依赖其他模块时，需要发送消息给其他系统。

4. 接收其他系统的应答（发送请求和接收应答时会阻塞线程），然后处理应答，最后给客户端发送最后的应答（也会阻塞线程）

 

同步模式存在下面的问题：

1.一个连接的并发请求数非常有限，因为线程阻塞在那里，前一个请求需要等到应答后，才能发送下一个请求；

2.连接数非常有限，因为每一个连接需要占用一个线程，当需要几万、几十万、上百万的连接并存时，系统无法开启那么多线程；

3.系统的并发性能依赖于响应时间，如果第三方系统故障无响应时，就可能有大批的线程被阻塞在那里，知道超时后才能释放，从而导致整体性能急剧下降；

4.故障会扩散，局部故障会扩散到整体，如果系统1出现问题，访问它的线程都会被阻塞，当某个流程不依赖系统1，而是依赖系统2，但是由于线程都阻塞在系统1上，导致线程池线程用完，没有线程来处理本来能够正常处理的新请求。

 

异步非阻塞开发模式：

1.通信线程与处理线程分离，通信线程只负责客户端连接的建立，消息的接收发送，请求由处理线程处理；

2.通信线程监听客户端的连接，请求接收，然后将请求消息发送到处理线程的消息队列；通信使用SOCKET异步非阻塞模式，为了支持海量连接并发，linux下采用epoll模式，windows使用IOCP模式，网上有较多这方面的介绍，这里不展开说明。

3.通信线程同时从自己的消息队列中取消息，然后将消息发送到指定的客户端中。

4.处理线程从自己的消息队列中取出请求，建立会话，然后处理该请求，如果该流程依赖其他模块，可以将请求消息发送给其他系统（将消息放到通信线程的消息队列）；

5.挂起会话，让会话等待其他系统应答，但是线程不阻塞，继续从消息队列中取其他消息处理。

6.当其他系统的应答消息来了时，通信线程同样将其发送给处理线程的消息队列。

7.处理线程从消息队列取出应答，然后查找会话处理，最后将应答发送给客户端。

 

异步非阻塞模式解决了同步模式存在的问题：

1.单连接的并发数提升海量，测试证明，光通信部分，一个线程就可以处理几万、十几万的请求数。

2.连接数大量提升，使用epoll、IOCP后，连接数可以达到几十万，上百W的数量级。

3.系统的并发性能不依赖于响应时间，更不依赖其他模块的响应时间，对方响应慢，只会适当的使会话增多，内多多一些。

4.也不会因为别的某个模块故障，导致整体系统不可用。

 

同步模式虽然简单，初学者开发起来也基本能胜任，但是对于比较大的系统，并发要求比较高的系统，后续就经常会出现各种各样的性能、可靠性等问题。

异步模式虽然编程复杂一些，当效益很明显，如果将异步模式框架进行封装后，对开发业务来说也是比较简单的事情，关键还是要回前期的框架设计。