1 Netty简介
入门知识:
Netty是⼀个⾼性能的、异步的、基于事件驱动的⽹络应⽤框架。官⽹：https://netty.io/
官⽅对它有这样的描述：
1.1 异步、事件驱动
同步、异步是相对的，在请求或执⾏过程中，如果会阻塞等待，就是同步操作，反之就是异步操作。
1.2 核心架构
Netty是一种NIO客户端服务器框架，它支持网络应用程序(如协议服务器和客户端)的快速和轻松开发。它大大简化和简化了网络编程，如TCP和UDP套接字服务器。“快速和简单”并不意味着最终的应用程序会受到可维护性或性能问题的影响。Netty是根据许多协议(如FTP、SMTP、HTTP以及各种二进制和基于文本的遗留协议)的实现所获得的经验精心设计的。因此，Netty成功地找到了一种在不妥协的情况下实现轻松开发、性能、稳定和灵活性的方法。
核心:
1.可扩展的事件模型
2.统⼀的通信api,⽆论是http还是socket都使⽤统⼀的api，简化了操作
传输服务
⽀持socket以及datagram（数据报）
⽀持http协议
In-VM Pipe （管道协议）
协议⽀持
http 以及 websocket
SSL 安全套接字协议⽀持
Google Protobuf （序列化框架）
⽀持zlib、gzip压缩
⽀持⼤⽂件的传输 RTSP（实时流传输协议，是TCP/IP协议体系中的⼀个应⽤层协议）
⽀持⼆进制协议并且提供了完整的单元测试
1.3 Netty优势
Netty是基于Java的NIO实现的，Netty将各种传输类型、协议的实现API进⾏了统⼀封装，实现了阻塞和⾮阻塞Socket。
基于事件模型实现，可以清晰的分离关注点，让开发者可以聚焦业务，提升开发效率。
⾼度可定制的线程模型-单线程、⼀个或多个线程池，如SEDA（Staged Event-Driven
Architecture）
SEDA：把⼀个请求处理过程分成⼏个Stage，不同资源消耗的Stage使⽤不同数量的线程来处理，Stage间使⽤事件驱动的异步通信模式。Netty只依赖了JDK底层api，没有其他的依赖，如：Netty 3.X依赖JDK5以上，Netty4.x依赖JDK6以上。
Netty在⽹络通信⽅⾯更加的⾼性能、低延迟，尽可能的减少不必要的内存拷⻉，提⾼性能。在安全⽅⾯，完整的SSL/TLS和StartTLS⽀持。
社区⽐较活跃，版本迭代周期短，发现bug可以快速修复，新版本也会不断的加⼊。
1.4 版本说明
Netty的版本分为，3.x、4.x和5.x，其中5.x版本已经被官⽅废弃，详情查看github的issue：https://github.com/netty/netty/issues/4466
废弃5.x的主要原因是，使⽤ForkJoinPool后复杂度提升了，但是性能⽅⾯并没有明显的优势，反⽽给项⽬的维护带来了很⼤的⼯作量，因此还有到发布新版本的时机，所以将5.x废弃。
Netty的下载：
2、为什么选择Netty，而不选择原生的NIO？
在网络编程⽅⾯，⼀般都不会选择原⽣的NIO，⽽是会选择Netty、Mina等封装后的框架，主要原因是：
NIO的类库和API繁杂，使⽤麻烦，需要熟练掌握Selector、ServerSocketChannel、 SocketChannel、ByteBuffer等。需要具备其他的额外技能做铺垫，例如熟悉Java多线程编程。这是因为NIO编程涉及到Reactor模式，你必须对多线程和⽹路编程⾮常熟悉，才能编写出⾼质量的NIO程序。可靠性能⼒补⻬，⼯作量和难度都⾮常⼤。例如客户端⾯临断连重连、⽹络闪断、半包读写、失败缓存、⽹络拥塞和异常码流的处理等问题，NIO编程的特点是功能开发相对容易，但是可靠性能⼒补⻬的⼯作量和难度都⾮常⼤。
JDK NIO的BUG，例如臭名昭著的epoll bug，它会导致Selector空轮询，最终导致CPU 100%。官⽅声称在JDK 1.6版本的update18修复了该问题，但是直到JDK 1.7版本该问题仍旧存在，只不过该BUG发⽣概率降低了⼀些⽽已，它并没有得到根本性解决。
具体问题查看：https://www.jianshu.com/p/3ec120ca46b2
3 Netty应用场景
Netty的应⽤场景是⾮常⼴泛的，⽐如：互联⽹⾏业的、游戏⾏业、⼤数据⾏业、医疗⾏业、⾦融等⾏业。互联⽹⾏业
在互联⽹⾏业项⽬中，最具代表性的就是分布式系统架构的远程服务调⽤，通过RPC的⽅式
进⾏⾼性能的服务调⽤，⽬前主流的RPC框架底层均采⽤了Netty作为⽹络通信组件。
⽐如：阿⾥巴巴的分布式服务治理框架Dubbo，底层就是使⽤Netty作为通信组件。
gRPC，是Google提供的⾼性能RPC框架，底层也使⽤了Netty。
⼤数据⾏业⼤数据⾏业中的许多技术也采⽤了Netty作为通信组件，如：Flink、Spark、Elasticsearch等。官⽅列出了使⽤Netty的⼀些项⽬：https://netty.io/wiki/related-projects.html
4 Reactor线程模型
Reactor线程模型不是Java专属，也不是Netty专属，它其实是⼀种并发编程模型，是⼀种思想，具有指导意义。⽐如，Netty就是结合了NIO的特点，应⽤了Reactor线程模型所实现的。
Reactor模型中定义的三种⻆⾊：
Reactor：负责监听和分配事件，将I/O事件分派给对应的Handler。新的事件包含连接建⽴就绪、读就绪、写就绪等。
Acceptor：处理客户端新连接，并分派请求到处理器链中。
Handler：将⾃身与事件绑定，执⾏⾮阻塞读/写任务，完成channel的读⼊，完成处理业务逻辑后，负责将结果写出channel。
常⻅的Reactor线程模型有三种，如下：
Reactor单线程模型
Reactor多线程模型
主从Reactor多线程模型
4.1 单Reactor单线程模型
说明：
Reactor充当多路复⽤器⻆⾊，监听多路连接的请求，由单线程完成Reactor收到客户端发来的请求时，如果是新建连接通过Acceptor完成，其他的请求由Handler完成。
Handler完成业务逻辑的处理，基本的流程是：Read --> 业务处理 --> Send 。
这种模型的优缺点：
优点
结构简单，由单线程完成，没有多线程、进程通信等问题。
适合⽤在⼀些业务逻辑⽐较简单、对于性能要求不⾼的应⽤场景。
缺点
由于是单线程操作，不能充分发挥多核CPU的性能。
当Reactor线程负载过重之后，处理速度将变慢，这会导致⼤量客户端连接超时，超时之后往往会进⾏重发，这更加重Reactor线程的负载，最终会导致⼤量消息积压和处理超时，成为系统的性能瓶颈。
可靠性差，如果该线程进⼊死循环或意外终⽌，就会导致整个通信系统不可⽤，容易造成单
点故障。
4.2 单Reactor多线程模型
说明：
在Reactor多线程模型相⽐较单线程模型⽽⾔，不同点在于，Handler不会处理业务逻辑，只是负责响应⽤户请求，真正的业务逻辑，在另外的线程中完成。
这样可以降低Reactor的性能开销，充分利⽤CPU资源，从⽽更专注的做事件分发⼯作了，提升整个应⽤的吞吐。
但是这个模型存在的问题：
多线程数据共享和访问⽐较复杂。如果⼦线程完成业务处理后，把结果传递给主线程Reactor进⾏发送，就会涉及共享数据的互斥和保护机制。
Reactor承担所有事件的监听和响应，只在主线程中运⾏，可能会存在性能问题。例如并发百万客户端连接，或者服务端需要对客户端握⼿进⾏安全认证，但是认证本身⾮常损耗性能。
为了解决性能问题，产⽣了第三种主从Reactor多线程模型。
4.3 主从Reactor多线程模型
在主从模型中，将Reactor分成2部分：
MainReactor负责监听server socket，⽤来处理⽹络IO连接建⽴操作，将建⽴的socketChannel指定注册给SubReactor。
SubReactor主要完成和建⽴起来的socket的数据交互和事件业务处理操作。
该模型的优点：
响应快，不必为单个同步事件所阻塞，虽然Reactor本身依然是同步的。
可扩展性强，可以⽅便地通过增加SubReactor实例个数来充分利⽤CPU资源。
可复⽤性⾼，Reactor模型本身与具体事件处理逻辑⽆关，具有很⾼的复⽤性。
5 Netty模型
Netty模型是基于Reactor模型实现的，对于以上三种模型都有⾮常好的⽀持，也⾮常的灵活，⼀般情况，在服务端会采⽤主从架构模型，基本示意图如下：
说明：
在Netty模型中，负责处理新连接事件的是BossGroup，负责处理其他事件的是WorkGroup。Group就是线程池的概念。NioEventLoop表示⼀个不断循环的执⾏处理任务的线程，⽤于监听绑定在其上的读/写事件。通过Pipeline（管道）执⾏业务逻辑的处理，Pipeline中会有多个ChannelHandler，真正的业务逻辑是在ChannelHandler中完成的。
