文章目录
一、 NIO 原生 API 弊端
二、 Netty 简介
三、 Netty 架构
四、 Netty 版本
五、 Netty 线程模型
六、 阻塞 IO 线程模型
七、 反应器 ( Reactor ) 模式引入
一、 NIO 原生 API 弊端
NIO 原生 API 的弊端 :
① NIO 组件复杂 : 使用原生 NIO 开发服务器端与客户端 , 需要涉及到 服务器套接字通道 ( ServerSocketChannel ) , 套接字通道 ( SocketChannel ) , 选择器 ( Selector ) , 缓冲区 ( ByteBuffer ) 等组件 , 这些组件的原理 , API 都要熟悉 , 才能进行 NIO 的开发与调试 , 之后还需要针对应用进行调试 , 优化 ;
② NIO 开发基础 : NIO 门槛略高 , 需要开发者掌握 多线程 , 网络编程 , 才能开发并且优化 NIO 网络通信的应用程序 ;
③ 原生 API 开发网络通信模块的基本的传输处理 : 网络传输不光是实现服务器端和客户端的数据传输功能 , 还要处理各种异常情况 , 如 连接断开重连机制 , 网络堵塞处理 , 异常处理 , 沾包处理 , 半包拼接处理 , 缓存机制 等方面的问题 , 这是所有成熟的网络应用程序都要具有的功能 , 否则只能说是入门级的 Demo ;
④ NIO BUG : NIO 本身存在一些 BUG , 如 Epoll , 导致 选择器 ( Selector ) 空轮询 , 在 JDK 1.7 中还没有解决 ;
Netty 在 NIO 的基础上 , 封装了 Java 原生的 NIO API , 解决了上述问题 ;
二、 Netty 简介
Netty 简介 : Netty 是一个网络应用框架 ;
① Netty 特点 :
异步 : 可以开发 阻塞 / 非阻塞 网络通信功能 ;
基于事件驱动 : 底层封装了可扩展的事件模型 ;
② Netty 使用场景 : 快速开发 高性能 的服务器端与客户端应用程序 ;
③ Netty 原理 : Netty 框架 对 Java 的原生 NIO API 进行了二次封装 , 适用于各种类型的 IO 通信 ( 阻塞 / 非阻塞 ) , 兼容各种协议 ( TCP / UDP / HTTP ) ;
④ Netty 安全性 : Netty 支持 SSL / TSL / StartTSL 等安全协议 ;
⑤ Netty 社区 : Netty 社区很活跃 , 截止到当前 , Netty 一直在持续维护 , 半个月前刚发布了新的版本 ;
2 . Netty 相关网站 :
① Netty 官网 : https://netty.io/
② Netty 下载页面 : https://netty.io/downloads.html
三、 Netty 架构
Netty 架构 :
① 底层核心 : 零拷贝字节缓冲区 , 通用的交互通信 API , 扩展的事件模型 ;
② Netty 支持的协议和功能 : HTTP 协议 , WebSocket 协议 ( 开发浏览器长连接程序 ) , zlib / gzip 数据压缩功能 , SSL 安全连接功能开发 , StartTLS 协议 , Google Protobuf 编码解码 , 大文件传输 , RTSP 协议 ;
③ 支持的传输服务 : TCP / UDP 协议传输 , HTTP 隧道传输 ;
四、 Netty 版本
Netty 版本 :
① Netty 3.x : 版本太老 , 不推荐使用 ;
② Netty 4.x : 目前正在使用的版本 ( 必须使用这个版本 ) , 目前最新的是 netty-4.1.50 版本 ( 2020-05-13 ) ;
③ Netty 5.x : 由于出现重大 BUG , 已经废弃 , 不能使用 ;
五、 Netty 线程模型
1 . 现有的线程模型 : 主要分为 阻塞 IO 模型 , 反应器模式 , 两个大的类型 ;
① 阻塞 IO 模型 : 传统的 BIO 模型 , 即阻塞 IO 模型 ;
② 反应器 ( Reactor ) 模式 : 反应器 ( Reactor ) 模式根据 反应器 和 处理线程 数量进行分类 , 又可以分为以下三类 :
单 反应器 ( Reactor ) 单线程 模式
单 反应器 ( Reactor ) 多线程 模式
主从 反应器 ( Reactor ) 多线程 模式
上述 反相器 ( Reactor ) 模型分类都有相应的模型支撑 ;
2 . Netty 线程模型 : Netty 的线程模型是在上面的 反应器 ( Reactor ) 模式分类下的 主从反应器 ( Reactor ) 多线程模型 的基础上 , 进行改进而来的 ;
Reactor 对应的中文翻译 : 反应器 / 分发者 / 通知者 ;
六、 阻塞 IO 线程模型
1 . 阻塞 IO 线程模型 :
① 场景说明 : 这里以服务器端为例 , 前提是连接已经建立 , 当前处于数据传输阶段 ;
② 主要用途 : 使用阻塞 IO 模型 , 获取客户端输入数据 ;
③ 阻塞获取数据 : 服务器端开始处于阻塞状态 , 接收到客户端数据后 , 解除阻塞 , 处理客户端上传的数据 ;
④ 线程模型 : 基于阻塞获取数据 , 如果没有数据到来 , 则需要一直处于阻塞状态 , 因此 每个连接都需要一个独立的线程处理对应客户端连接的数据交互 ;
2 . 阻塞 IO 模型弊端 :
① 客户端 连接 线程 对应关系 : 该模式下 , 每个客户端都要维持一个连接 , 每个连接都需要占用一个线程资源处理数据交互 ;
② 资源消耗 : 如果客户端数量非常大 , 如十万百万级别 , 服务器大并发处理压力非常大 , 创建很多线程 , 消耗的系统资源巨大 ;
③ 资源浪费 : 如果服务器端与客户端没有数据交互 , 那么服务器端会阻塞的 read() 方法上 , 此时线程处于阻塞状态 , 但还占用着系统的资源 , 造成了资源的浪费 ;
阻塞 IO 模型 , 资源消耗大 , 浪费也大 ;
下图是 BIO 模型的示意图 , 在该模型中每个客户端都要占用服务器端的一个线程 ;
七、 反应器 ( Reactor ) 模式引入
1 . 针对 BIO 模型的 资源浪费 的解决方案 : 线程 IO 复用模型 ;
① BIO 模型中的资源浪费 : 服务器端的线程 大部分时间都处于阻塞状态 , 没有数据交互时 , 还占用着线程资源 ;
② 单个线程为多个连接服务 : 多个连接共用一个线程 , 在这个线程中监听多个连接是否有数据写入 , 不用每个连接都各自占用一个线程阻塞监听 ;
③ 线程解除阻塞机制 : 多个连接中如果有某个连接收到数据 , 该线程就会 解除监听阻塞 , 开始为有数据写入的连接服务 ;
该模型中 , 一个线程为多个连接服务 , 类似于 NIO 模型的机制 , 该机制就是之前讲过的 在单个线程中使用 单个选择器 ( Selector ) 阻塞监听多个客户端对应的多个套接字通道 ( SocketChannel ) ;
( 该 反应器模式 与 NIO 模型类似 , 但不是 NIO 模型 )
2 . 针对 BIO 模型的 资源消耗 的解决方案 : 使用线程池机制 , 实现对线程资源的复用 ;
① BIO 模型中的资源消耗 : 每个客户端都要建立一个对应的连接 , 每个连接都要占用一个线程 , 这样需要创建很多线程 ;
② 线程池机制复用线程 : 每个连接不再分配单独的线程进行处理 , 使用线程池机制分配线程资源 ;
③ 业务与线程的对应关系 : 每个业务逻辑都可能分配给多个线程中的一个 ( 不能同时分配多个 ) , 每个线程可以承担多个连接的业务 ( 不能同时承担多个 ) , 其对应关系是多对多的 ;
( 同一时刻 , 一个线程只能对应一个连接的业务 , 一个连接的业务逻辑也只能交给一个线程处理 )
