Netty principle

Netty principle

Netty What is it? Netty is a highly efficient development framework JBoss Java NIO produced.

Reactor mode

Netty use the Reactor pattern, including three modes:

1. Reactor single-threaded model
2. Reactor multi-threaded model
3. Master-slave multi-threaded model

In fact the Reactor model is based on Java NIO in his basis, abstracted two components --Reactor and Handler of two components:

1. Reactor: IO responsible for responding to events, when it detects a new event, send it to the appropriate Handler to deal with; new events include connection setup ready, ready for reading, writing, etc. ready.
2. Handler: itself (handler) and the event binding, is responsible for handling the event, completing the read channel, post-processing business logic to complete, will be responsible for the results of write channel.
3. Acceptor: accept the client's request, it can also be seen as a Handler.

Reactor single-threaded model

Only one thread to complete everything, including the TCP connection request receiving client, listen for events, read and write socket data.

For some small-capacity scenarios, you can use single-threaded model. But for high-load, large concurrent application was inappropriate, mainly due to the following:

1. Performance limit, can not deal with hundreds of events, even if the CPU load NIO thread 100%, can not meet the massive message encoding, decoding, reading and transmission;
2. When the NIO thread overloaded, performance will decline, which will lead to a large number of client connection timeout, timeout after tend to be retransmitted, which is even more heavy load NIO thread will eventually lead to a large number of messages backlog and handle timeouts, NIO thread will become a performance bottleneck system;
3. Reliability issues: NIO thread once one event handler (handle) the failure to send or obstruction, will handle all of the other can not be, and will be blocked acceptor live, that is to say, the whole system communication module is not available , can not receive and process external message, causing node failure.

To address these issues, the evolution of the Reactor multi-threading model.

Reactor multi-threading model:

Rector's largest multi-threaded and single-threaded model model difference is: there is a real thread pool IO operations, that is to say, will handle a lot of IO operation carried into the thread pool, and acceptor, reactor or single-threaded to accept a client TCP connection requests.

Reactor multi-threading model features:

1. NIO thread has a dedicated thread for listening TCP -Acceptor server, the client receives a connection request;
2. Network IO operations - read (Handler), and writing a responsible NIO thread pool comprising N and a task queue of available threads, these threads are responsible NIO message reading, decoding, encoding and transmitting;
3. One thread can be processed simultaneously NIO N links, but only a link corresponding to a NIO thread from concurrent problems.

In most scenarios, Reactor multi-threading models to meet the performance requirements; however, in a very special scenario, a NIO thread is responsible for monitoring and handling all client connections may exist performance problems.

Eg millions of concurrent client connections, or the server requires a handshake message client security authentication, certification itself is very loss performance. In such scenarios, a single thread Acceptor there may be insufficient performance issues in order to solve performance problems, resulting in a third Reactor threading model - multi-threaded master model from Reactor.

Reactor master-slave multi-threaded model

The biggest difference from the main thread Reactor and Reactor model multi-threading model is: there is a main reactor listen for connections, multiple listeners to read and write events from the reactor. In other words, a Reactor main points from two types of connection are responsible for monitoring events and write events.

Here MainReactor only one, but subReactor can have more.

MainReactor monitors Acceptor thread pool, and subReactor monitors Handler thread pool.

Acceptor thread pool is only used for client login, handshakes and safety certification, once the link is established, it will link-to-back registration subReactor thread pool of the I / O thread, there are I / O thread is responsible for subsequent I / O operating.

I.e., from the multi-threaded model by a thread to listen for connection events and event data read , is split into a thread connection event listener, a plurality of threads listener thread pool data read and write socket events connection has been established , and additionally multi-threading model as a dedicated thread pool real IO operations.

Netty mode

Having three forms Reacotr model, then Netty what it is?

In fact, there is a Reactor model variant, it is the third form of the variant to remove the thread pool, which is the default mode Netty NIO.
In the realization, Netty class acts as the Boss mainReactor, NioWorker class acts subReactor (default number is NioWorker Runtime.getRuntime (). AvailableProcessors ()) . When processing new requests, NioWorker to read data is received ChannelBuffer, after which the trigger ChannelHandler ChannelPipeline stream.

1. EventLoopGroup is equivalent Reactor, bossGroup corresponding primary Reactor, workerGroup corresponding to the Reactor
2. TimeServerHandler is Handler
3. The method begins with the child configuration is a client channel, the method of non-child is the beginning of the configuration of the server channel

NioEventLoop is Netty's Reactor thread, it duties Netty Reactor threading model is as follows:

1. As a server Acceptor thread responsible for handling requests access to client
2. As a client Connecor thread is responsible for registering listen for connections operating position for judging the results of an asynchronous connection
3. As the IO thread, listening to the network read bit, responsible for reading from SocketChannel its message
4. As the IO thread is responsible to SocketChannel written message sent to the other party, if there was a write half a pack, it will automatically register event listeners to write, continue to send half a pack for subsequent data until all the data transmission is complete
   as shown below, it is a process of NioEventLoop chain:

note:

• Handler processing method in the processing chain is a serialization of execution

• A client connects only to register on a NioEventLoop, avoiding multiple IO threads concurrent operations

• Netty specific in what mode

Original link: https: //blog.csdn.net/qq_18603599/article/details/80768390