【netty】reactor模式的演变

详细介绍：

https://segmentfault.com/a/1190000019469833

个人理解

传统基于socket编程的服务端开发模式：（BIO）

1. 服务端启动，建立serverSocket，调用accept()等待连接建立。
2. 握手成功，这时服务端会新建一个socket，等待客户端输入数据。
3. 客户端数据传输完毕，服务端调用read()读取数据，读取完进行数据的处理。
4. 处理完调用write(),将数据返回给客户端，等待客户端接收。
5. 回到步骤3（等待客户端输入）。

而整个服务端进程在运行时，同一时间肯定不仅只有一个客户端，该进程必须为同时为多个客户端服务。现代操作系统都支持线程，线程才是CPU调度的基本单位，于是乎，只要每个流程都用一个线程跑，客户有多少个，就创建多少个线程。有一点要注意，在一般的服务进程中，一般只会监听一个端口，所有也只会存在一个serverSocket。多个线程是不能同时调用accept()，会抢占资源，同一时间只有一个线程能调用accept()。所以只有当三次握手成功后，新建完socket，后面的流程才能交给新的线程处理，线程间彼此不会受影响。

上面流程就是用多线程优化过的BIO下的处理模式，但性能还满足不了高并发场景。因为线程资源是宝贵的，一个請求对应一个线程还是有点奢侈。

想要优化，就要了解这个模型的缺点。这个模型有三个涉及到系统调用的地方是阻塞的，accept(),read(),write()。而read()和write()又在每个处理客户端请求的线程中，说明在read()和write()这段时间中，线程是处于等待状态的，并没有干活。想要提高线程的效率，那需要减少线程的等待时间，可当前线程对应的客户端的确没有产生什么输入，那只能线程去抢别人的活做，那当然，其他线程就会“失业”。线程要去抢别人的活，那read()和write()就不能是阻塞的了，就必须是非阻塞的 ，马上能得到结果。

操作系统提供了一套机制，支持这种模型，叫IO多路复用。

IO多路复用是指内核一旦发现进程指定的一个或者多个IO条件准备读取，它就通知该进程。
IO多路复用适用如下场合：
　　1）当客户处理多个描述符时（一般是交互式输入和网络套接口），必须使用I/O复用。
　　2）当一个客户同时处理多个套接口时，这种情况是可能的，但很少出现。
　　3）如果一个TCP服务器既要处理监听套接口，又要处理已连接套接口，一般也要用到I/O复用。
　　4）如果一个服务器即要处理TCP，又要处理UDP，一般要使用I/O复用。
　　5）如果一个服务器要处理多个服务或多个协议，一般要使用I/O复用。

基于IO多路复用机制，一个进程（线程）可以注册多个感兴趣的事件（主要有三个，accept，read和write事件）到不同的socket上，当有感兴趣的事件发生，通过遍历fdset找到触发的事件和socket。

这里引入reactor模式，先了解下什么是reactor模式？

Reactor模式首先是事件驱动的，有一个或多个并发输入源，有一个Service Handler，有多个Request Handlers；这个Service Handler会同步的将输入的请求（Event）多路复用的分发给相应的Request Handler。

下列就是reactor的三种模式的演进：

生活类比

生活场景：饭店规模变化

• 一个人招揽所有：迎宾，点菜，做饭，上菜，送客 （Reactor单线程模型）
• 多招几个伙计：大家一起做上面的事情 （Reactor多线程模型）
• 进一步分工：搞一个或多个专门做迎宾，其他人负责点菜，做饭，上菜，送客（主从Reactor多线程模式）