netty 是什么? 这个问题其实百度上一搜一堆。 这是官方话的描述：netty 是一个基于nio的客户、服务器端编程框架，使用netty 可以确保你快速和简单的开发出一个网络应用，例如实现了某种协议的客户、服务端应用。netty相当于简化和流线化了网络应用的编程开发过程，例如：基于tcp和udp的socket服务开发。
其实没那么复杂，用通俗易懂的话来讲：
netty 是一个框架，
这个框架做了什么事情了，做了一件 rpc 底层通讯对接的事情，
rpc 底层通顺采用什么方式呢，就是采用基于socket 的tcp/udp （nio+reactor ) 长连接模式进行通讯（重点）
那么netty 框架在对接系统级别的通讯层之后 又以编程接口的模式提供给app层。
netty 是基于nio 的客户端，服务端编程框架。正式因为如此，使得netty 在处理高并发量的时候，有很大的线程优势。那么我们接下来要讲讲什么是nio 模型？
对应nio(non-blocking i/o) 模型的 对立模型就是bio（blocking i/o） 模型。除此之外还有一种aio 模型（不做讲解）。我们比较关心的bio 模型。
我们来看下下面这张图—bio：
从上面图中我们可以看出在bio 模型中，可以清楚的了解到 ：一个套接字需要使用一个线程处理，它的过程就是建立连接、读数据、写数据，然而在这些过程中都有可能会发生阻塞。这就是为什么我们首先会接触到这种方式的原因，因为它简单，一个线程只处理一个socket，但如果是server端，在并发连接时就需要更多的线程才能完成工作。我们熟悉的 .net framework web 应用的 寄宿主 iis 就使用此种模式。
最传统的一种io模型，即在读写数据过程中会发生阻塞现象。
当用户线程发出io请求之后，内核会去查看数据是否就绪，如果没有就绪就会等待数据就绪，而用户线程就会处于阻塞状态，用户线程交出cpu。当数据就绪之后，内核会将数据拷贝到用户线程，并返回结果给用户线程，用户线程才解除block状态。
典型的阻塞io模型的例子为：
data = socket.read();
如果数据没有就绪，就会一直阻塞在read方法。
下面这张图描述了bio 的场景图： 客人来了，就开一个服务员服务,只等到客人走了。 说明这个餐厅的服务质量很好，但是效率很低，服务员的利用率跟饱和度低，占用资源浪费，并且成本增加。
我们在来看一张图—nio+reactor：
在我们将nio+reactor 模式之前，我们先了解下 nio 模型：
当用户线程发起一个read操作后，并不需要等待，而是马上就得到了一个结果。如果结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read操 作。一旦内核中的数据准备好了，并且又再次收到了用户线程的请求，那么它马上就将数据拷贝到了用户线程，然后返回。所以事实上，在非阻塞io模型中，用户线程需要不断地询问内核数据是否就绪，也就说非阻塞io不会交出cpu，而会一直占用cpu。
典型的非阻塞io模型一般如下：
while(true){
data = socket.read();
if(data!= error){
处理数据
break;
}
}
但是对于非阻塞io（nio）就有一个非常严重的问题，在while循环中需要不断地去询问内核数据是否就绪，这样会导致cpu占用率非常高，因此一般情况下很少使用while循环这种方式来读取数据。
了解了 nio,那么我们讲讲 nio+reactor 模型 （多路复用io 模型） 是基于事件驱动的思想，采用了reactor模式，相对于bio，nio一个明显的优势就是不需要为每一个socket套接字分配一个线程，而是在一个线程中可以处理多个socket套接字相关的工作。感兴趣的可以去了解一下reactor模式，在这里给一个链接 ->
下面这张是对nio+reactor 的场景描述图： 多个客人来了，有一个服务员先来接待，并且同步复制所有的客人的信息给相关的处理部门，部门根据自己感兴趣的来处理的相对应的的消息。
可以看出：
多路复用io模式，通过一个线程就可以管理多个socket，只有当socket真正有读写事件发生才会占用资源来进行实际的读写操作。因此，多路复用io比较适合连接数比较多的情况。
在多路复用io模型中，会有一个线程不断去轮询多个socket的状态，只有当socket真正有读写事件时，才真正调用实际的io读写操作。因为在多路复用io模型中，只需要使用一个线程就可以管理多个socket，系统不需要建立新的进程或者线程，也不必维护这些线程和进程，并且只有在真正有socket读写事件进行时，才会使用io资源，所以它大大减少了资源占用
另外多路复用io为何比非阻塞io模型的效率高是因为在非阻塞io中，不断地询问socket状态时通过用户线程去进行的，而在多路复用io中，轮询每个socket状态是内核在进行的，这个效率要比用户线程要高的多。
不过要注意的是，多路复用io模型是通过轮询的方式来检测是否有事件到达，并且对到达的事件逐一进行响应。因此对于多路复用io模型来说，一旦事件响应体很大，那么就会导致后续的事件迟迟得不到处理，并且会影响新的事件轮询。
总结：从场景图中可以看出/或者从众看各个系列文章： nio的模型是基于 一个线程接待了多个客户端套接字的管理,那么反过来说，在这个线程中产生了一个管理者，那么这个管理者称之为 selector, 那么这个 (线程+selector ) 是属于netty 层呢还是属于系统级别层呢？ 我们以上所述的，都是属于系统本身级别，也就是说 (线程+selector ) 还是属于系统级别层的，那么netty 做了些什么呢？ netty 它是基于系统的nio 模型构建的，并且实现了 与操作系统给的nio 模型中的 selector 进行对接，它封装之后，提供了一个易于操作的使用模式和接口，用户使用起来更加方便便捷。
我们使用通用的应用程序或者类库来实现互相通讯，比如，我们经常使用一个 http 客户端库来从 web 服务器上获取信息，或者通过 web 服务来执行一个远程的调用。
然而，有时候一个通用的协议或他的实现并没有很好的满足需求。比如我们无法使用一个通用的 http 服务器来处理大文件、电子邮件以及近实时消息，比如金融信息和多人游戏数据。我们需要一个高度优化的协议来处理一些特殊的场景。例如你可能想实现一个优化了的 ajax 的聊天应用、媒体流传输或者是大文件传输器，你甚至可以自己设计和实现一个全新的协议来准确地实现你的需求。
另一个不可避免的情况是当你不得不处理遗留的专有协议来确保与旧系统的互操作性。在这种情况下，重要的是我们如何才能快速实现协议而不牺牲应用的稳定性和性能。
但是：netty 也有自己的缺点：
nio 的 reactor模式在io读写数据时还是在同一个线程中实现的，即使使用多个reactor机制的情况下，那些共享一个reactor的channel如果出现一个长时间的数据读写，会影响这个reactor中其他channel的相应时间，比如在大文件传输时，io操作就会影响其他client的相应时间，因而对这种操作，使用传统的thread-per-connection或许是一个更好的选择，或则此时使用proactor模式。
因此在开发技术选型的时候，不能盲目的选择，还是配合业务场景，根据实际情况来选择.
如对本文有疑问， 点击进行留言回复！！
我要评论
网友评论