Shulou(Shulou.com)06/01 Report--

This article mainly introduces "what is the use of netty". In the daily operation, I believe that many people have doubts about the use of netty. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "what is the use of netty?" Next, please follow the editor to study!

One: Netty simple Cognition

Netty is an asynchronous, event-driven network programming framework provided by JBOSS. Netty can help you develop a web application quickly and easily, which is equivalent to streamlining and simplifying the development process of NIO. Netty is used inside the well-known Elasticsearch and Dubbo frameworks.

1 Why use netty

Shortcomings of NIO

The class library and API of NIO are complicated and troublesome to use. You need to be proficient in Selector, ServerSocketChannel, SocketChannel, ByteBuffer, etc.

The reliability is not strong, and the development workload and difficulty are very large.

Bug for NIO. "for example, Epoll Bug, which causes Selector empty polling, resulting in CPU 100%."

Advantages of Netty

Provide a unified API for various transport protocols

Highly customizable threading model-single thread, one or more thread pools

Better throughput, lower wait latency

Less resource consumption

Minimize unnecessary memory copies

2 Reactor threading model

The Reactor pattern is based on event-driven development, and the core components include Reactor and thread pool, where Reactor is responsible for listening and assigning events, and thread pool is responsible for handling events. The Netty threading model is an implementation of the Reactor pattern.

No matter the network framework written by C++ or Java, most of them are designed and developed based on Reactor pattern. Reactor mode is based on event-driven, which is especially suitable for dealing with massive Icano events.

According to the number of Reactor and thread pool, Reactor is divided into three models:

Single thread model (single Reactor single thread)

Multithreading model (single Reactor multithreading)

Master-slave multithreading model (multi-Reactor multithreading).

2.1 Reactor single thread model

Reactor single-threaded model means that all IO operations (receiving requests, business logic processing) are done on the same NIO thread.

The characteristics of NIO threads are as follows:

As a NIO server, receive the TCP connection of the client

As a NIO client, initiate a TCP connection to the server

Read the request or reply message from the other end of the communication

Send a request message or reply message to the other end of the communication

Reactor monitors connection events through selector, and distributes them through dispatch after receiving them. If it is an event established by a connection, it is handled by Acceptor. Acceptor accepts the connection through accept, and creates a Handler to handle the subsequent events of the connection. If it is a read-write event, directly call the business Handler corresponding to the connection to handle it.

Applicable scenarios:

For some small-capacity application scenarios, the single-threaded model can be used.

However, it is not suitable for high load and high concurrency application scenarios. A NIO thread processes hundreds of links at the same time, which cannot be supported in performance. Even if the CPU load of the NIO thread reaches 100%, it cannot satisfy the encoding, decoding, reading and sending of massive messages.

2.2 Reactor multithreading model

In the Reactor multithreading model, there is still only one Nio thread listening for connection requests; business logic processing is handled by a thread pool.

In the main thread, the Reactor object monitors the connection event through selector and distributes the event through dispatch. If it is a connection establishment event, it is handled by Acceptor. Acceptor receives the connection through accept and creates a Handler to handle subsequent events. Handler is only responsible for responding to events and does not perform business operations, that is, only read reads data and write writes data, and business processing is handed over to a thread pool for processing.

The thread pool allocates a thread to complete the real business processing, and then sends the response result to the Handler of the main process, and the Handler sends the result to the client

Applicable scenarios:

In most scenarios, the Reactor multithreading model can meet the performance requirements.

However, in very few special scenarios, there may be performance problems when a NIO thread is responsible for listening and processing all client connections. For example, millions of concurrent client connections, or the server needs to secure authentication of the client handshake, but the authentication itself is very costly performance. In such scenarios, a single thread may have an underperformance problem.

2.3 Master-slave multithreading model (commonly used)

Compared with the multithreading model, the server used to receive client connections is no longer a single NIO thread, but a separate NIO thread pool. The Acceptor thread pool is only used for client login, handshake and security authentication. Once the link is successfully established, the link is registered to the IO thread of the back-end subReactor thread pool, and the IO thread is responsible for the subsequent IO operations.

There are multiple Reactor, and each Reactor has its own selector selector, thread and dispatch

The mainReactor in the main thread monitors the connection establishment event through its own selector, receives the event through Accpetor, and assigns the new connection to a child thread.

The subReactor in the child thread adds the connection assigned by mainReactor to the connection queue to listen through its own selector and creates a Handler to handle subsequent events

Handler completes the complete business process of read- > Business processing-> send

3 the relationship between Netty threading model and Reactor 3.1 single threading model

In the single-threaded model, only one thread is specified to perform client connection and read and write operations, that is, it is done in a Reactor. The corresponding implementation in Netty is to set the number of NioEventLoopGroup threads to 1. The core code is:

NioEventLoopGroup group = new NioEventLoopGroup (1); ServerBootstrap bootstrap = new ServerBootstrap (); bootstrap.group (group) .channel (NioServerSocketChannel.class) .option (ChannelOption.TCP_NODELAY, true) .option (ChannelOption.SO_BACKLOG, 1024) .childHandler (new ServerHandlerInitializer ())

The workflow is as follows:

3.2 Multithreading model

In the multi-thread model, the client connection is processed in a single Reactor, and then the business processing is handed over to the thread pool. The core code is as follows:

NioEventLoopGroup eventGroup = new NioEventLoopGroup (); ServerBootstrap bootstrap = new ServerBootstrap (); bootstrap.group (eventGroup) .channel (NioServerSocketChannel.class) .option (ChannelOption.TCP_NODELAY, true) .option (ChannelOption.SO_BACKLOG, 1024). ChildHandler (new ServerHandlerInitializer ())

The workflow is as follows:

3.3 Master-slave multithreading model

In the master-slave multithreading model, there are multiple Reactor, that is, multiple selector, so we define a bossGroup and a workGroup. The core code is as follows:

NioEventLoopGroup bossGroup = new NioEventLoopGroup (); NioEventLoopGroup workerGroup = new NioEventLoopGroup (); ServerBootstrap bootstrap = new ServerBootstrap (); bootstrap.group (bossGroup,workerGroup) .channel (NioServerSocketChannel.class) .option (ChannelOption.TCP_NODELAY, true) .option (ChannelOption.SO_BACKLOG, 1024) .childHandler (new ServerHandlerInitializer ())

The workflow is as follows:

Note: in fact, in Netty, the bossGroup thread pool will eventually randomly select only one thread to handle client connections. At the same time, NioServerSocetChannel binds to bossGroup threads, and NioSocketChannel binds to workGroup threads.

4 Netty Core components 4.1 ChannelHandler and its implementation classes

The ChannelHandler interface defines a number of event handling methods that can be overridden to implement specific business logic. It is often necessary to customize a Handler class to inherit ChannelInboundHandlerAdapter, and then implement the business logic by rewriting the corresponding methods

Public void channelActive (ChannelHandlerContext ctx), channel ready event public void channelRead (ChannelHandlerContext ctx, Object msg), channel read data event public void channelReadComplete (ChannelHandlerContext ctx), data read completed event public void exceptionCaught (ChannelHandlerContext ctx, Throwable cause), channel exception event 4.2 ChannelPipeline

ChannelPipeline is a collection of Handler, which is responsible for handling and intercepting inbound or outbound things and operations, the equivalent of a chain through Netty.

ChannelPipeline addFirst (ChannelHandler... Handlers), adding a business processing class (handler) to the first location in the chain, ChannelPipeline addLast (ChannelHandler...) Handlers), adding a business processing class (handler) to the last location in the chain

4.3 ChannelHandlerContext

ChannelHandlerContext is the event handler context object, the actual processing node in the Pipeline chain. Each processing node ChannelHandlerContext contains a specific event handler ChannelHandler, and the corresponding pipeline and Channel information is also bound in the ChannelHandlerContext.

ChannelFuture close (), close channel ChannelOutboundInvoker flush (), refresh ChannelFuture writeAndFlush (Object msg), write data to ChannelPipeline, the next ChannelHandler of the current ChannelHandler starts processing (outbound) 4.4ChannelFuture

ChannelFuture is used to represent the result of asynchronous IWeiO operation in Channel. In Netty, all IUnip O operations are asynchronous, and the call to IUnip O will return directly. The caller can not get the result immediately, but you can obtain the processing status of IWeiO operation through ChannelFuture.

Channel channel (), which returns the channel ChannelFuture sync () where the IO operation is currently in progress, and waits for the asynchronous operation to complete 4.5 EventLoopGroup.

EventLoopGroup is an abstraction of a group of EventLoop. In order to make better use of multi-core CPU resources, Netty usually has multiple EventLoop working at the same time, and each EventLoop maintains a Selector instance.

EventLoopGroup provides next interface, and you can get one of the EventLoop from the group to process the task according to certain rules.

In Netty server-side programming, we generally need to provide two EventLoopGroup, such as BossEventLoopGroup and WorkerEventLoopGroup.

4.6 ServerBootstrap and Bootstrap

ServerBootstrap is the server-side startup assistant in Netty, through which you can complete various server-side configurations; Bootstrap is the client-side startup assistant in Netty, through which you can complete various client-side configurations.

ServerBootstrap:

Public ServerBootstrap group (EventLoopGroup parentGroup, EventLoopGroup childGroup), which is used on the server side to set up two EventLoop public B channel (Class)

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.