如果不了解netty的，可以百度下，netty社区现在也比较活跃。
现在所谓的大数据，flume，storm等底层都是netty。
netty的性能模型：
io模型---->异步非阻塞io
1：jdk1.4开始提供了非阻塞io，即nio
jdk1.5以后，epoll代替了poll，打破了selector上链路的限制。
2：零拷贝
directbuffer vs heapbytebuffer
netty不用任何配置，默认线程发送和接受使用的就是directbuffer。
如果使用堆内存，tcp读取一条消息码流，先从fd句柄里读到directbuffer，然后从directbuffer拷贝到heapBuffer。
使用directbuffer，少了一次内存拷贝。
组合的buffer
我们做rpc或者私有协议时候，通常的消息都是由head和body组成，每次发送消息时都会内存拷贝，把老的buffer拷贝到新的buffer，把老的释放掉，再更新最新的buffer。但是使用组合的buffer时，可以把多个buffer聚合成一个buffer操作。
文件传输transferTo
在很多操作系统时，它会做优化，会在文件缓冲区，直接写到channel，省去了堆的操作。
3：内存池
poolbytebufAllocator
数据协议---->可定制的编解码框架
可定制的序列化框架，netty不绑架任何序列化工具。java序列化效率比较低，有兴趣的朋友可以自己做个试验。
线程模型---->reactor线程模型
1.单线程模型：
2.多线程模型：
3.无锁化串行设计：
java1.5以后，引入了线程池的概念，动态扩展。
netty使用了串行设计，串行化过程中，不存在锁的概念，如果多个串行共同执行效果避免了多线程竞争导致性能下降。
netty的可靠性：
netty提供了读空闲、写空闲、读写空闲的检测。
通常节点内部通信都是长连接，长连接一般都会做心跳检测，为了防止误判，连续xx次后关闭重连等。
我所接触的游戏都是自己设计channelHandler，然而netty本身提供了这种检测机制。监听这个event事件就可以了。
reactor线程保护
某个消息的异常不应该导致整条链路不可用
某条链路不可用不应该导致其他链路不可用
这与分布式服务，就是服务节点了，后面一章分析netty源码时会详细的说下。
jdk epoll空轮训：
空轮训导致cpu100%的bug，这个bug到现在也没有修复，内部设计的复杂程度可以想象。
但是netty采用的是rebuild，就是检测到的时候，把之前selector关闭（之前的channel转移到新的selector上）。
安全性：
ssl单向认证
内存分配与流量整形