Netty学习01

“Netty是一个NIO C/S框架，能够快速、简单的开发协议服务器和客户端等网络应用。它能够很大程度上简单化、流水线化开发网络应用，例如TCP/UDP socket服务器。”

mina与netty都是Trustin Lee的作品，所以在很多方面都十分相似，他们线程模型也是基本一致，采用了Reactors in threads模型，即Main Reactor + Sub Reactors的模式。

由main reactor处理连接相关的任务：accept、connect等，当连接处理完毕并建立一个socket连接（称之为session）后，给每个session分配一个sub reactor，之后该session的所有IO、业务逻辑处理均交给了该sub reactor。每个reactor均是一个线程，sub reactor中只靠内核调度，没有任何通信且互不打扰。

 

Netty是一个主要用于编写高并发网络系统、网络应用和服务的Java库。Netty和 标准的Java APIs一个主要的差别在于它的异步API。这个名词对于不同的人来说意味着不同的东西，可能和非阻塞、事件驱动有相同的意义。先不管这些，如果你之前从未使用过异步API，习惯于编写顺序执行的程序，那么转换思路编写Netty程序有点麻烦。在这里简要的介绍我如何解决这个问题。

编写一个Netty示例并启动。和其他Java API一样，发起request很容易。在处理response需要转换思维，因为没有response。几乎每个方法调用都是异步的，这意味着没有返回值，而且调用常常是立刻返回的。结果（如果有的话）是 由 其他线程传回的。这是普通API和异步API的基本区别。假如一个客户端API提 供一个方法来从服务器获取widget的 数量。

 

public WidgetCountListener myListener = new WidgetCountListener() {
     public void onWidgetCount(int widgetCount) {
          ...... doyour thing with the widget count
     }
};
方法调用没有返回数据，而且即刻执行完毕。
然而，它接受了一个response处理器参数，当获取到widget数据会回调这个监听器，
然后监听器可以利用这个结果执行任意有用的操作。
这个复杂的附加层看起来是不必要的，但这却是利用Netty等API实现的高性能的应用、服务的一个关键特
征。客户端不需要为线程被阻塞在等待服务器响应而浪费资源。当数据可用时会通知他们。对于一个线程
发起一个调用的情况，这种方式可能有些过度设计，但是设想有上百个线程百万次的执行这个方法。而且，
NIO最重要的好处是Selectors能够用来将我们感兴趣的事件通知委托给底层的操作系统，甚至是硬件来
完成。当16bytes已经成功从网络写入到一个服务器或者14bytes经过网络从一个服务器读到本地等操作
会被回调通知，很明显是一个底层而且细节的实现方式。但是通过一系列的抽象，开发人员使用Java NIO
和Netty API能够从更宏观、抽象的级别上来处理这些问题。

Netty中数据如何被分发是由ChannelBuffer完成的。

如果你的程序只是处理byte数组和byte缓冲区，那么你会很幸运因为使用ChannelBuffer。

 然而，如果你需要处理更高级的数据，例如java对象，把这个数据发送到一个远程服务器，然后再接受另

外一个返回的对象，那么这些byte计划需要被转义。或者，如果你需要发起一个请求到一个HTTP服务器，

你的请求或许是从发起一个字符串类型URL来开始它的生命周期，但是它需要被包装成一个HTTP服务器能

够理解的request，然后分解为原始的byte，最后通过网络发送。HTTP服务器需要接收这些byte，并且把

它们解析一个符合格式的HTTP request。一旦请求成功，这个流程会被反过来执行：服务器的响应（或许

是一个JPEG图片或者JavaScript文件）必须被包装成一个HTTP response，转换为bytes，然后返回给发

起请求的客户端。

在Netty中，byte在网络流通的基本抽象是Channel。