netty

Posted 2021-04-30 IT分享

一、简介：讲解java的IO演进历史

1、jdk1.4之前的时候，选用的是同步阻塞模型-BIO,没有什么异步IO，非阻塞的IO

比如：在以前开发腾讯qq的时候，那么高的并发量在0几年的时候，如果用java开发的话，不可能做到那么高的高并发的，所以就采用了c和c++开发。用c和c++可以直接操作系统提供的异步IO或者AIO。所以这就是一个很大的区别。

2、在jdk1.4版出来以后用NIO，支持了非阻塞的IO了。所以现在的阿里系都用了NIO开发。包括很多的产品，都用java开发了。

3、在jdk1.7的时候，升级了NIO2.0,提供了AIO的功能，支持了文件和网络套接字的异步IO。

很多的都是基于这个版本升级的。

二、简介讲解下reactor模式和Netty线程模型

设计模式-Reactor模式(反应器设计模式),是一种基于事件驱动的设计模式，在事件驱动的应用中，将一个或多个客户的服务请求分离(demultiplex)和调度(dispatch)给应用程序(比如一个  tcp连接进来，我这里做一个和业务进行分离，分发给后面的程序进行去处理）。在事件驱动的应用中，同步地，有序地处理同时接收多个服务请求，一般出现在高并发系统中，比如netty，redis，nginx等。

事件驱动：就是给一个事件，触发事件就发生一个信号，可以做对应的事情。

比如按钮点击，触发关闭按钮的时候，它就会触发一个关闭的事件，别人监听这个事件的时候就可以做出动作。

优点：

1）响应快，不会因为单个同步而阻塞，虽热Reactor本身依然是同步的；因为是基于事件驱动的，监听的模式。

2）编程相对简单，最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销。

3）可扩展性，可以方便的通过增加Reactor实例个数来充分利用CPU资源

缺点：

1）相比传统的简单模型(一个连接请求，一个线程处理)，Reactor增加了一定的复杂性，因而有一定的门槛，并且不易于调试。

2）Reactor模式需要系统底层的支持，比如java中 的Selector支持，操作系统的select系统调用支持。在jdk1.4之前是没有nio的，是不支持的。

通俗理解：KTV例子：前台接待，服务人员带领去开机器,通过这个例子理解netty中的线程模型。

Reactor模式是基于事件驱动，适合处理海量的I/O事件，属于同步非阻塞IO（NIO)

Reactor单线程模型(比较少用)

1):作为NIO服务端，接收客户端的TCP连接；作为NIO客户端，向服务按发起TCP连接

2):服务端读请求数据并响应；客户端写请求并读取响应

使用场景：

对应小业务则合适，编码简单，对于高负载，大并发的应用场景不合适，一个NIO线程处理太多请求。则负载过高，并且可能响应变慢，导致大量请求超时，而且万一线程挂了，则不可用了。

Reactor多线程模式

1）：一个Acceptor线程，一组NIO线程，一般是使用自带的线程池，包含一个任务队列和多个可用的线程。比如jdk中的ExectorService。

使用场景：可满足大多数场景，但是当Acceptor需要做负责操作的时候，比如认证等耗时操作，再高并发情况下则也会有性能问题。

Reactor主从线程模型

1）Acceptor不在是一个线程，而是一组NIO线程；IO线程 也是一组NIO线程，这样就是两个线程池去处理接入连接和处理IO，可以解决阻塞和耗时的问题。

使用场景：

满足目前大部分场景，也是Netty推荐使用的线程模型

如果还耗时的话，在fork出来一个子线程

BossGroup:线程组里的线程用来监听

WorkGroup：业务线程去处理。

三、为什么Netty使用NIO而不是AIO,是同步非阻塞还是异步非阻塞

答案：

在Linux系统上，AIO底层实现仍用EPOLL,与NIO相同，因此在性能上没有明显的优势

Netty整体架构是reactor模型，采用epoll机制，所以往深的说，还是IO多路复用模式，所以也可以说netty是同步非阻塞模型(看的层次不一样)

很多人说这是netty是基于Java NIO类库实现的异步通信框架

特点：异步非阻塞，基于事件驱动 ，性能高，高可靠性和高可定制性

参考资料：https://github.com/netty/netty/issues/2515