Netty is a high-performance, asynchronous event-driven NIO framework, which provides support for TCP, UDP and file transfer. As an asynchronous NIO framework, all Netty IO operations are asynchronous and non-blocking. Through the Future-Listener mechanism, Users can easily obtain IO operation results actively or through a notification mechanism.
As the most popular NIO framework at present, Netty has been widely used in the Internet field, big data distributed computing field, game industry, communication industry, etc. Some well-known open source components in the industry are also built based on Netty's NIO framework
Traditional communication uses synchronous blocking IO. When the concurrent pressure of the client or the network delay increases, synchronous blocking IO will cause the IO thread to be blocked frequently due to frequent waits. Because the thread cannot work efficiently, the IO processing capacity will naturally decline.
Let's look at the disadvantages of BIO communication through the BIO communication model diagram
The server using the BIO communication model usually has an independent Acceptor thread responsible for monitoring the client's connection. After receiving the client connection, a new thread is created for the client connection to process the request message. After the processing is completed, the response message is returned to the client. , the thread is destroyed, which is a typical request-response model .
The biggest problem of this architecture is that it does not have the ability to elastically scale. When the number of concurrent accesses increases, the number of threads on the server side is linearly proportional to the number of concurrent accesses. Since threads are very valuable system resources of the JAVA virtual machine, when the number of threads expands, The performance of the system drops sharply, and as the amount of concurrency continues to increase, problems such as handle overflow and thread stack overflow may occur, and eventually the server goes down.
Based on NIO, Netty implements the encapsulation and optimization of NIO, so Netty's communication mode is asynchronous non-blocking communication
In the IO programming process, when multiple client access requests need to be processed at the same time, multi-threading or IO multiplexing technology can be used for processing. The IO multiplexing technology multiplexes the blocking of multiple IOs to the blocking of the same select, so that the system can process multiple client requests at the same time in the case of a single thread. Compared with the traditional multi-thread/multi-process model, the biggest advantage of I/O multiplexing is that the system overhead is small, the system does not need to create new additional processes or threads, nor does it need to maintain the operation of these processes and threads, reducing the System maintenance workload, saving system resources.
JDK1.4 provides support for non-blocking IO (NIO). JDK1.6 uses epoll instead of traditional select/poll, which greatly improves the performance of NIO communication.
The Netty architecture is designed and implemented according to the Reactor mode , and its server-side communication sequence diagram is as follows
Netty's IO thread NioEventLoop aggregates the multiplexer Selector, which can concurrently process hundreds or thousands of client Channels. Since read and write operations are non-blocking, this can fully improve the efficiency of the IO thread and avoid due to Thread suspension caused by frequent IO blocking. In addition, because Netty adopts the asynchronous communication mode, one IO thread can process N client connections and read and write operations concurrently, which fundamentally solves the traditional synchronous blocking IO-connection-thread model, and the performance, elastic scaling ability and Reliability has been greatly improved.
What is the Reactor threading model ?
The Reactor mode is event-driven , with one or more concurrent input sources, a Service Handler, and multiple Request Handlers; this Service Handler will synchronously multiplex the incoming request (Event) and distribute it to the corresponding Request Handler
Structurally, this is somewhat similar to the producer-consumer pattern, that is, one or more producers put events into a Queue, and one or more consumers actively process Poll events from the Queue; while the Reactor pattern There is no Queue for buffering. Whenever an Event is input to the Service Handler, the Service Handler will immediately distribute it to the corresponding Request Handler for processing according to different Event types .
There are many advantages to doing this. First, we can implement a separate thread for the Request handler that handles events, namely
In this way, the Service Handler and the request Handler are asynchronous, which speeds up the processing of the event by the service Handler. Then each request can also process its own event in the form of multiple threads, that is, Thread1 is extended to Thread pool 1,
Netty's Reactor thread model 1 Reactor single-threaded model The Reactor mechanism ensures that each read and write can be non-blocking read and write
One thread (single thread) to handle CONNECT event (Acceptor), one thread pool (multi-thread) to handle read, and one thread pool (multi-thread) to handle write, then from Reactor Thread to handler are asynchronous, so IO operation Also multithreaded.
Compared with BIO, the performance has been greatly improved, but it can continue to improve. Since the Reactor Thread is still single-threaded, there are still limitations in terms of performance.
2 Reactor multi-threading model
In this way, the ability to distribute events is improved through Reactor Thread Pool
3 Reactor master-slave model
Netty's efficient concurrent programming is mainly reflected in the following points:
1) Massive and correct use of volatile;
2) Widespread use of CAS and atomic classes;
3) The use of thread-safe containers;
4) Improve concurrency performance through read-write locks.
In addition to using reactor to improve performance, Netty also has
1、零拷贝，IO性能优化
2、通信上的粘包拆包
2、同步的设计