0

私はここ数日、Netty を調査してきました。これは、多くのリクエストを受信する必要がある迅速でタイトな HTTP サーバーを作成しているためです。Netty の HTTP サーバーの実装は非常にシンプルで、その役割を果たします。

次のステップは、リクエスト処理の一環として、外部 Web サーバーへの HTTP リクエストを起動する必要があります。私の直感は、同時に多くのリクエストを送信できる非同期クライアントを実装することですが、正しいアプローチとは何かについて少し混乱しています。私の理解では、Netty サーバーは着信メッセージごとにワーカー スレッドを使用するため、そのワーカー スレッドは、ハンドラーの作業が完了するまで解放されず、新しいメッセージを受け入れることができません。ここにパンチがあります: 非同期 HTTP クライアントが手元にある場合でも、各応答を待ってサーバー ハンドラーで処理する必要があるかどうかは問題ではありません。同じワーカー スレッドがずっとブロックされたままになります。別の方法は、クライアントの非同期の性質を使用することです。

これは理にかなっていますか？私は私の仮定から離れていますか？そのような種類の Netty アクセプター サーバー + 外部クライアントを高い並行性で実装するための良い方法は何ですか?

ありがとう、

4

1 に答える 1

2

Netty 4について質問していると仮定します。

ServerBootstrap で構成された Netty には、次のように、リクエストを受け入れてチャネルを実行するために使用する固定数のワーカー スレッドがあります。

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 メッセージをデコードしたりするのをブロックしたくないのは正しいことです。それを軽減するためにできることが 2 つあります。

まず、Async netty クライアントを使用して発信リクエストを作成し、発信リクエストが返されたときにリスナーが元のリクエスト チャネルにレスポンスを書き込むようにします。これは、ブロックして待機しないことを意味します。つまり、それらの要求を処理するために使用できるスレッドの数よりも多くの同時発信要求を処理できます。

次に、独自の EventExecutorGroup でカスタム ハンドラーを実行することができます。これは、次のように、アクセプター/http コーデック チャネル ハンドラーとは別のスレッドプールで実行されることを意味します。

// 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);
    }
};

つまり、送信リクエストは、受信リクエストの受け入れ/処理に使用されるスレッドを占有しません。

于 2013-05-25T08:31:42.313 に答える