BIO、NIO、AIO与Linnux下的IO模型 概览

Netty 基础概念

  Netty 是一个 异步、基于事件驱动 的网络应用框架，用作快速开发高性能、高可用性的网络 I/O 应用。它的出现，是为了解决源生 NIO 的问题，如：

1. NIO 使用麻烦：需要熟练掌握 Selector、ServerSocketChannel、SocketChannel、ByteBuffer等。
2. 需要熟悉 Java 多线程编程，因为 NIO 编程涉及到 Reactor 模式，必须对多线程和网络编程非常熟悉，才能编写出高质量的 NIO 程序。
3. Epoll Bug，它会导致 Selector 空轮询，最终导致 CPU 100%

Netty 对 JDK 自带的 NIO 的 API 进行了封装，解决了上述问题，方便了开发，且拥有活跃的社区更新等。

  Netty 的高性能等特点，使得它成为众多开源框架的底层通讯架构，如 ElasticSearch、Dubbo、Hadoop 中的多个组件。

netty GitHub
netty 笔记参考

线程模型的演变

BIO 服务模型

  一个客户端连接请求，使用服务器一个线程
带来的问题：

1. 当并发数很大，就会创建大量的线程，占用很大系统资源
2. 连接创建后，如果当前线程暂时没有数据可读，该线程会阻塞在 read 操作，造成线程资源浪费

NIO 服务模型

Reactor 模式中的两个核心成员：

1. Reactor：Reactor 在一个单独的线程中运行，负责监听、等待数据，然后将数据分发给其他线程来对 IO 事件做出反应。类似于公司的客服，收集用户提出的问题，并记录下来，然后给对应的人去处理。
2. Handlers：对得到的 IO 做实际的处理。类似客户问题的实际处理人。

Reactor模式分类

1. 单 Reactor 单线程

服务器端用一个线程，通过多路复用搞定所有的 IO 操作（包括连接，读、写等），编码简单、没有线程切换的性能消耗，但是如果客户端连接数量较多，或 Handler 执行耗时任务时，将出现卡顿情况。

  使用场景：客户端的数量有限，业务处理非常快速，比如 Redis 在业务处理的时间复杂度为 O(1) 的情况

2. 单 Reactor 多线程

优点：可以充分的利用多核 cpu 的处理能力

缺点：多线程数据共享和访问比较复杂， reactor 处理所有的事件的监听和响应，是单线程运行状态， 在高并发场景容易出现性能瓶颈。

3. Netty 改进后的主从 Reactor 多线程

图解：

1. Netty 抽象出两组线程池 BossGroup 专门负责接收客户端的连接， WorkerGroup 专门负责网络的读写 ，程序中的线程数默认为实际 cpu 核数 * 2，也可在初始化 NioEventLoopGroup 时传入指定的线程数

2. NioEventLoopGroup 组中含有多个 NioEventLoop 事件循环 ，执行如图所示的3步工作，默认轮询的方式去处理多个事件

3. 每个 NioEventLoop 包含有一个 Selector，一个 taskQueue ；每个 Selector 上可以注册监听多个 NioChannel

4. 在 WorkerGroup 的每个 NIOEventLoop 处理业务时，会使用 pipeline(管道)， pipeline 中包含了 channel（频道、通道） , 即通过 pipeline 可以获取到对应通道, 管道中维护了很多的 handler 处理器。