问题描述
在过去的几天里，我一直在探索Netty，因为我正在编写一个快速且紧凑的HTTP服务器，该服务器应该接收大量请求，并且Netty的HTTP服务器实现非常简单并且可以完成工作.
I have been exploring Netty for the past days, as I am writing a quick and tight HTTP server that should receive lots of requests, and Netty's HTTP server implementation is quite simple and does the job.
下一步是请求处理的一部分，我需要向外部Web服务器启动HTTP请求.我的直觉是实现一个可以同时发送许多请求的异步客户端，但是对于正确的方法，我有些困惑.我的理解是Netty服务器为每个传入消息使用一个工作线程，因此，直到我的处理程序完成工作之前，该工作线程不会被释放以接受新消息.这很重要:即使我手头有一个异步HTTP客户端，也不需要等待每个响应并用我的服务器处理程序将其处理回去-相同的工作线程将一直保持阻塞状态.替代方法是使用客户端的异步特性，快速返回将来的对象以释放线程并放置侦听器(这意味着我必须向客户端返回200或202状态)，并检查我的将来的对象以指示响应时间已收到，我可以将其推送给客户端.
My next step is as part of the request handling, I need to launch an HTTP request to an external web server. My intuition is to implement an asynchronous client that can send a lot of requests simultaneously, but I am a little confused as what is the right approach. My understanding is that Netty server uses a worker thread for each incoming message, therefore that worker thread would not be freed to accept new messages until my handler finishes its work. Here is the punch: even if I have an asynchronous HTTP client in hand, it won't matter if I need to wait for each response and process it back with my server handler - the same worker thread would remain blocking all this time. The alternative is to use the async nature of the client, returning a future object quickly to release the thread and place a listener (meaning I have to return 200 or 202 status to the client), and check my future object to indicate when the response is received and I can push it to the client.
这有意义吗?我的假设会偏离目标吗?实现此类高并发Netty接受器服务器+外部客户端的良好实践是什么?
Does this make sense? Am I way off with my assumptions? What is a good practice to implement such kind of Netty acceptor server + external client with high concurrency?
谢谢
推荐答案
假设您要询问Netty 4.
Assuming you're asking about Netty 4.
配置有ServerBootstrap的Netty将具有固定数量的工作线程，用于接受请求和执行通道，如下所示:
Netty configured with a ServerBootstrap will have a fixed number of worker threads that it uses to accept requests and execute the channel, like so:
Two threads accepting / processing requests
bootstrap.group(NioEventLoopGroup(2))
One thread accepting requests, two threads processing.
bootstrap.group(NioEventLoopGroup(1), NioEventLoopGroup(1))
在您的情况下，您有一个包含一堆Http Codec解码/编码内容的通道以及您自己的处理程序，该处理程序本身会发出传出的Http请求.没错，您不想阻止服务器接受传入的请求或对传入的Http消息进行解码，并且可以采取两种措施来减轻这种情况，您已经对第一种感到震惊了.
In your case, you have a channel includes a bunch of Http Codec decoding/encoding stuff and your own handler which itself makes an outgoing Http request. You're right that you don't want to block the server from accepting incoming requests, or decoding the incoming Http message, and there are two things you can do to mitigate that, you've struck on the first already.
首先，您要使用异步Netty客户端发出外发请求，让侦听器在外发请求返回时将响应写入原始请求通道.这意味着您无需阻塞并等待，这意味着您可以处理的并发传出请求比可用于处理这些请求的线程数还要多.
Firstly, you want to use an Async netty client to make the outgoing requests, have a listener write the response to the original requests channel when the outgoing request returns. This means you don't block and wait, meaning you can handle many more concurrent outgoing requests than the number of threads available to process those requests.
第二，您可以将自定义处理程序运行在其自己的EventExecutorGroup中，这意味着它在与acceptor/http编解码器通道处理程序不同的线程池中运行，如下所示:
Secondly, you can have your custom handler run in its own EventExecutorGroup, which means it runs in a separate threadpool from the acceptor / http codec channel handlers, like so:
// Two separate threads to execute your outgoing requests..
EventExecutorGroup separateExecutorGroup new DefaultEventExecutorGroup(2);
bootstrap.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
public void initChannel(SocketChannel ch) {
ChannelPipeline pipeline = ch.pipeline();
.... http codec stuff ....
pipeline.addLast(separateExecutorGroup, customHandler);
}
};
意味着您的传出请求不会占用将用于接受/处理传入请求的线程.
Meaning your outgoing requests don't hog the threads that would be used for accepting / processing incoming ones.
这篇关于异步Netty HttpServer和HttpClient的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！