事件机制
用一个线程把Accept，读写操作，请求处理的逻辑全干了。如果什么事都没得做，它也不会死循环，它会将线程休眠起来，直到下一个事件来了再继续干活，这样的一个线程称之为NIO线程
while true {
events = takeEvents(fds) // 获取事件，如果没有事件，线程就休眠
for event in events {
if event.isAcceptable {
doAccept() // 新链接来了
} elif event.isReadable {
request = doRead() // 读消息
if request.isComplete() {
doProcess()
}
} elif event.isWriteable {
doWrite() // 写消息
}
}
}
组件
Channel：Channel保存了socket连接的有关信息，以及ChannelPipeLine（串起ChannelHandlerContext）/Unsafe（实现底层传输）/EventLoop（对应一个IO线程）/SelectionKey（如果为NIO模式，标识该Channel此时的连接读写事件）等有效信息，NIO服务端负责响应连接的是NioServerSocketChannel，客户端为NioSocketChannel
Buffer：缓冲区，用于和NIO Channel交互，从Channel中读取数据到Buffer，从Buffer将数据写入到Channel
Selector：Selector是Java NIO提供的多路复用器，负责配合操作系统的select/epoll操作将就绪的IO事件分离出来，落地为SelectionKey，我们可以将SelectionKey看做Reactor模式中的资源
实现一个线程就能监听多个Channel（Channel需先register到Selector）的读写等状态，然后触发ChannelPipeLine的fireChannelRead操作（串行ChannelHandlerContext持有的ChannelHandler）/底层Channel的数据写入（数据来源于Buffer）
EventLoop/EventLoopGroup，EventLoopGroup其实就是一个EventLoop线程组，netty中通常有多个EventLoop同时工作，每个EventLoop维护着一个Selector实例（类似单线程Reactor工作）。如果没有显式指定，默认每个EvenLoopGroup中的线程数为可用的CPU内核数*2
通常每个netty服务端有两个EventLoopGroup：bossGroup和workerGroup
bossGroup用作Acceptor线程池，负责处理客户端的连接请求，通常一个服务端口对应一个EventLoop线程，根据实际需要配置线程组的线程数量。Acceptor线程通过不断轮询Selector上的Accept事件，将accept的SocketChannel交给另外一个EventLoop线程组。如果系统只有一个服务端端口需要监听，则建议 bossGroup 线程组线程数设置为 1
workerGroup会根据线程组的顺序next一个可用的EventLoop将这个SocketChannel注册到其维护的Selector上，并处理其后续的I/O的事件，是真正负责 I/O 读写操作的线程组，通过 ServerBootstrap 的 group 方法进行设置，用于后续的 Channel 绑定
ChannelPipleline，每个SocketChannel都有一个Pipleline实例，而每个Pipleline中维护了一个ChannelHandler链表队列。Pipleline和ChannelHandler的关系类似servlet和filter过滤器的作用。EventLoop从Selector中分离出就绪的channel以后，会将它传递的消息传输到Pipleline中，通过ChannelHandler处理链进行层层处理，用户可以在Handler中添加自己的业务逻辑。
ChannelPipleline中本身维护着两个不可见的HeadHandler和TailHandler，head靠近网络层，tail靠近用户。netty中有两类事件类型，inbound和outbound。inbound可以理解为从网络数据外部流向内部，如读取消息；outbound为网络数据从内部流向外部，如写消息。Pipleline会根据事件的类型， 自上而下或自下而上调用事件相关联的ChannelHandler对消息进行处理。如读取消息的时候会依次执行HeadHandler、ChannelHandler1...ChannelHandlerN、TailHandler
