Rocketmq before when looking at the source code and found the bottom with the Netty, the way to learn a little, there are many online blog talking about the mistakes, and most of the same, most of them are estimated to copy someone else's. In order not to be misled, I specifically bought a "Netty Definitive Guide", read read it carefully, and ask the micro-channel Feng brother (Lilin Feng), then sort out this share.
I have been adhering to the principle: rather not write, write less, but also try not to wrong knowledge! So as not to harm the younger generation!
Want to reprint the students, marked the original link. Thank you! While very welcome that mistake, I promptly corrected!
Imprint
Netty3 (3.x) version is older version.
Netty4 (4.x) version is the current official recommendation, currently has been in maintenance. Changes compared with version 3.x is relatively large, especially the API.
Netty5 (5.x) is discarded version, the official is not recommended!
Netty5 abandon the official explanation:
1. netty5 ForkJoinPool are used, it increases the complexity of the code, but does not significantly improve the performance of
2. Multiple branch code synchronization heavy workload
3. The authors feel that the moment is not to release a new version of the time
4. Prior to the release version, there are more issues to look into, such as whether to discard exceptionCaught, whether exposed EventExecutorChooser and so on.
Reference: https://github.com/netty/netty/issues/4466
1. Basic concepts Netty
Netty is a high performance, asynchronous event-driven NIO framework that provides support for TCP, UDP and file transfer as an asynchronous NIO framework, Netty all IO operations are asynchronous non-blocking by Future-Listener mechanism, users can easily retrieve or get active IO operation results notification mechanism.
As the most popular NIO framework, Netty in the Internet field, big data distributed computing, game industry, communications industry, such as access to a wide range of applications, some of the industry's leading open-source components are also based NIO framework Netty building. Such as: Dubbo, RocketMQ, Hadoop the Avro, Spark like.
Netty content to learn: codec, how to stick package TCP / unpacking and Netty resolved, ByteBuf, Channel and Unsafe, ChannelPipeline and ChannelHandler, EventLoop and EventLoopGroup, Future and so on.
Codec:
Java serialization There are two main purposes:
- network transmission
- Object persistence
Java Java serialization only one codec technology, because of his shortcomings, derived from a variety codec technology and a frame.
Java serialization Cons:
- Unable to cross-language
- Stream too serialized
- Serialization performance is too low
Industry mainstream codec framework:
- Google Protobuf: support for Java, C ++, Python three languages, efficient coding performance, structured data storage format (XML, JSON, etc.)
- Facebook Thrift: for static data exchange, we need to determine a good its data structures. After structural changes need to be recompiled IDL file, which is the Thrift weaknesses.
- JBoss Marshalling: Serialization API is a Java object, fixes a lot of problems JDK comes with the sequence of packets, but remain compatible with java.io.Serializable interface.
- Hessian: a lightweight remoting onhttp tool, using a simple method provides RMI functionality, uses a binary RPC protocol.
TCP stick package / unpacking:
TCP is a "flow" agreement, the so-called flow, is no limit to the string of data. TCP does not know the specific meaning of the underlying upper layer service data, it will be divided according to the actual TCP packet buffer, so that a complete package on the service, may be split into a plurality of TCP packets transmitted, may the plurality of packets encapsulated into a large packet transmission, and this is the TCP packet unpacking sticky problems.
There are several situations:
normal situation
Stick package
And simultaneously stick package unpacking
2. Netty threading model
In the JAVA NIO Selector respect to the Reactor pattern provides a basis, Netty combination Selector and Reactor model design efficient threading model.
About Java NIO construction Reator mode, Doug Lea in "Scalable IO in Java" in a very good exposition, where the interception PPT to achieve Reator mode will be explained.
(1) Reactor single-threaded model
This is the simplest of Reactor single-threaded model, due to the Reactor pattern using asynchronous non-blocking IO, all IO operations will not be blocked, in theory, a thread can independently handle all IO operations. Then Reactor thread is a versatile, responsible for demultiplexing socket, Accept the new connection, and distribute requests to the processing chain.
For some small-capacity scenarios, you can use the single-threaded model. But for high-load, large concurrent application was inappropriate, mainly due to the following:
1. When a thread NIO not processed simultaneously supporting hundreds of links, performance, even if the CPU load NIO thread 100%, can not fully process the message.
2. When the NIO thread is overloaded, the processing speed will slow down, it will lead to a large number of client connection timeout, retransmission timeout after often, more heavy load NIO thread.
3. low reliability, unexpected death of a thread loop, will cause the entire communication system is not available.
To solve these problems, there has been Reactor multi-threading model.
(2) Reactor multi-threaded model
Compared on a model, the model employed in the process of multi-thread chain portion (thread pool).
In most scenarios, the model can meet the performance requirements. However, in some special scenarios, such as a handshake message server will authenticate the client's security. Under such scenario, a separate thread Acceptor there may be insufficient performance problems. To solve these problems, generate a third Reactor threading model.
(3) Reactor from the master model
该模型相比第二种模型，是将Reactor分成两部分，mainReactor负责监听server socket，accept新连接；并将建立的socket分派给subReactor。subReactor负责多路分离已连接的socket，读写网络数据，对业务处理功能，其扔给worker线程池完成。通常，subReactor个数上可与CPU个数等同。
利用主从NIO线程模型，可以解决一个服务端监听线程无法有效处理所有客户端连接的性能不足问题，因此，在Netty的官方Demo中，推荐使用该线程模型。
(4)Netty模型
Netty的线程模型并不是一成不变，它实际取决于用户的启动参数配置。通过设置不同的启动参数，Netty可以同时支持Reactor单线程模型、多线程模型和主从模型。
前面介绍完 Netty 相关一些理论，下面从功能特性、模块组件来介绍 Netty 的架构设计。
3. Netty功能特性
下图是Netty的功能特性：
4. Netty模块组件
Netty主要有下面一些组件：
- Selector
- NioEventLoop
- NioEventLoopGroup
- ChannelHandler
- ChannelHandlerContext
- ChannelPipeline
Selector
Netty 基于 Selector 对象实现 I/O 多路复用，通过 Selector 一个线程可以监听多个连接的 Channel 事件。
NioEventLoop
其中维护了一个线程和任务队列，支持异步提交执行任务，线程启动时会调用 NioEventLoop 的 run 方法，执行 I/O 任务和非 I/O 任务。
NioEventLoopGroup
主要管理 eventLoop 的生命周期，可以理解为一个线程池，内部维护了一组线程，每个线程(NioEventLoop)负责处理多个 Channel 上的事件，而一个 Channel 只对应于一个线程。
ChannelHandler
是一个接口，处理 I/O 事件或拦截 I/O 操作，并将其转发到其 ChannelPipeline(业务处理链)中的下一个处理程序。
ChannelHandlerContext
保存 Channel 相关的所有上下文信息，同时关联一个 ChannelHandler 对象。
ChannelPipeline 是保存 ChannelHandler 的 List，用于处理或拦截 Channel 的入站事件和出站操作。实现了一种高级形式的拦截过滤器模式，使用户可以完全控制事件的处理方式，以及 Channel 中各个的 ChannelHandler 如何相互交互。
ChannelPipeline对事件流的拦截和处理流程：
Netty中的事件分为Inbond事件和Outbound事件。
Inbound事件通常由I/O线程触发，如TCP链路建立事件、链路关闭事件、读事件、异常通知事件等。
Outbound事件通常是用户主动发起的网络I/O操作，如用户发起的连接操作、绑定操作、消息发送等。
在 Netty中，Channel 、ChannelHandler、ChannelHandlerContext、 ChannelPipeline的关系如下图：
一个 Channel 包含了一个 ChannelPipeline，而 ChannelPipeline 中又维护了一个由 ChannelHandlerContext 组成的双向链表，并且每个 ChannelHandlerContext 中又关联着一个 ChannelHandler。
入站事件和出站事件在一个双向链表中，入站事件会从链表 head 往后传递到最后一个入站的 handler，出站事件会从链表 tail 往前传递到最前一个出站的 handler，两种类型的 handler 互不干扰。
以上是Netty的主要原理介绍，Netty源码分析的话，后续有时间会继续分享出来。