章节

1、Netty学习（一）：初识Netty
2、Netty学习（二）：Netty的核心组件
3、Netty学习（三）：Netty的流程分析（正在写）

一、概述

• 本质：Netty的本质是一个网络应用程序框架
• 实现：异步、事件驱动
• 特性：高性能、可维护、快速开发
• 用途：开发服务器和客户端

作为当前最流行的 NIO 框架，Netty 在互联网领域、大数据分布式计算领域、游戏行业、通信行业等获得了广泛的应用，知名的 Elasticsearch 、Dubbo 框架及SpringWebFlux框架内部都采用了 Netty。

二、为什么使用Netty

一.不选择JAVA原生NIO编程的原因

1. NIO的类库和API繁杂，使用麻烦，你需要熟练掌握Selector、ServerSocketChannel、SocketChannel、ByteBuffer等；
2. 需要具备其它的额外技能做铺垫，例如熟悉Java多线程编程，因为NIO编程涉及到Reactor模式，你必须对多线程和网路编程非常熟悉，才能编写出高质量的NIO程序；
3. 可靠性能力补齐，工作量和难度都非常大。例如客户端面临断连重连、网络闪断、半包读写、失败缓存、网络拥塞和异常码流的处理等等，NIO编程的特点是功能开发相对容易，但是可靠性能力补齐工作量和难度都非常大；
4. JDK NIO的BUG，例如臭名昭著的epoll bug，它会导致Selector空轮询，最终导致CPU100%。官方声称在JDK1.6版本的update18修复了该问题，但是直到JDK1.7版本该问题仍旧存在，只不过该bug发生概率降低了一些而已，它并没有被根本解决。

二.选择Netty的原因

Netty是业界最流行的NIO框架之一，它的健壮性、功能、性能、可定制性和可扩展性在同类框架中都是首屈一指的，它已经得到成百上千的商用项目验证，例如Hadoop的RPC框架avro使用Netty作为底层通信框架。很多其它业界主流的RPC框架，也使用Netty来构建高性能的异步通信能力。

1. API使用简单，开发门槛低；（这个简单是相对的，事实上Netty使用并不简单，有茫茫多的专业词语需要去理解）
2. 功能强大，预置了多种编解码功能，支持多种主流协议；
3. 定制能力强，可以通过ChannelHandler对通信框架进行灵活的扩展；
4. 性能高，通过与其它业界主流的NIO框架对比，Netty的综合性能最优；
5. 成熟、稳定，Netty修复了已经发现的所有JDK NIO BUG，业务开发人员不需要再为NIO的BUG而烦恼；
6. 社区活跃，版本迭代周期短，发现的BUG可以被及时修复，同时，更多的新功能会被加入；

正是因为这些优点，Netty逐渐成为Java NIO编程的首选框架。

三、Netty的I/O模式

一.经典的三种I/O模式

生活场景
当我们去饭店吃饭时：
? 食堂排队打饭模式：排队在窗口，打好才走；
? 点单、等待被叫模式：等待被叫，好了自己去端；
? 包厢模式：点单后菜直接被端上桌

1、阻塞与非阻塞

• 菜没好，要不要死等 -> 数据就绪前要不要等待？
• 阻塞：没有数据传过来时，读会阻塞直到有数据；缓冲区满时，写操作也会阻塞。 非阻塞遇到这些情况，都是直接返回。

2、同步与异步

• 菜好了，谁端 -> 数据就绪后，数据操作谁完成？
• 数据就绪后需要自己去读是同步，数据就绪直接读好再回调给程序是异步。

二.Netty对三种I/O模式的支持

Netty目前仅支持NIO模式，即同步非阻塞。

1、为什么不支持BIO（同步阻塞）

耗资源、效率低
阻塞意味着等待，等待就会一直占用该线程，当连接数高时，大多线程又在等待，就会耗尽系统的线程资源。

2、为什么不支持AIO(异步非阻塞)

Netty其实曾经是支持AIO的，但是因为AIO模式在WINDOWS环境下性能提高很明显，但是在Liunx环境下性能提升不明显，而WINDOWS很少作为服务器使用，netty 也是联系实际情况才有选择地支持高性能的 IO 模式。

四、Netty的开发模式

一.处理WEB请求的体系结构

在web服务中，处理web请求通常有两种体系结构，分别为：thread-based architecture（基于线程的架构）、event-driven architecture（事件驱动模型），

1、thread-based architecture（基于线程的架构）

通俗的说就是：多线程并发模式，一个连接一个线程，服务器每当收到客户端的一个请求， 便开启一个独立的线程来处理。
这种模式一定程度上极大地提高了服务器的吞吐量，由于在不同线程中，之前的请求在read阻塞以后，不会影响到后续的请求。但是，仅适用于于并发量不大的场景，因为：

• 线程需要占用一定的内存资源
• 创建和销毁线程也需一定的代价
• 操作系统在切换线程也需要一定的开销
• 线程处理I/O，在等待输入或输出的这段时间处于空闲的状态，同样也会造成cpu资源的浪费

2、event-driven architecture（事件驱动模型）

事件驱动模型非常常见，当事件被触发运行时，程序感知到不同的时间而产生的不同的动作，比如常见的WEB界面，在点击不同的按钮后会产生不同的效果，为了能够实现这一效果，就需要程序能够实时的感知所关心的事件和触发事件之后要完成的动作。
事件驱动模型有多种设计方式，这里主要介绍Netty的Reactor设计模式。

二.Netty的Reactor设计模式

1、Reactor设计模式的三种版本

生活场景：饭店规模变化
小饭馆： 一个人包揽所有：迎宾、点菜、做饭、上菜、送客等；
普通饭店： 多招几个伙计：大家一起做上面的事情；
海底捞： 进一步分工：搞一个或者多个人专门做迎宾，迎宾完之后有专门的服务员对应一定的桌台。
生活场景类比：
? 饭店伙计：线程
? 迎宾工作：接入连接
? 点菜：请求
? 做菜：业务处理
? 上菜：响应
? 送客：断连

1. 一个人包揽所有：迎宾、点菜、做饭、上菜、送客等 -> Reactor 单线程
2. 多招几个伙计：大家一起做上面的事情 -> Reactor 多线程模式
3. 进一步分工：搞一个或者多个人专门做迎宾 -> 主从 Reactor 多线程模式

2、Reactor 单线程

所有操作都在同一个NIO线程处理，在这个单线程中要负责接收请求，处理IO，编解码所有操作，相当于一个饭馆只有一个人，同时负责前台和后台服务，效率低。

EventLoopGroup eventGroup = new NioEventLoopGroup(1);
ServerBootstrap serverBootstrap = new ServerBootstrap();
serverBootstrap.group(eventGroup);

EventLoopGroup eventGroup = new NioEventLoopGroup();
ServerBootstrap serverBootstrap = new ServerBootstrap();
serverBootstrap.group(eventGroup);

EventLoopGroup bossGroup = new NioEventLoopGroup();
EventLoopGroup workerGroup = new NioEventLoopGroup(); 
ServerBootstrap serverBootstrap = new ServerBootstrap();
serverBootstrap.group(bossGroup, workerGroup);