非同期HTTP要求と新しいスレッドのHTTP要求の比較

Question

2つのマイクロサービス（AとB）があります。

Aには、POST要求を受け入れるエンドポイントがあります。ユーザーがPOSTリクエストを行うと、次のようになります。

1. サービスAはPOST要求本体からオブジェクトを取り出し、データベースに格納します。
2. サービスAは、オブジェクトを別のオブジェクトに変換します。新しいオブジェクトはJersey HTTPクライアント経由でサービスBに送信されます。

ステップ2は、作成したJavaスレッドプール（Executors.newCachedThreadPool）で実行されます。新しいスレッドでステップ2を実行することにより、サービスAのエンドポイントの応答時間には影響しません。

しかし、サービスBが応答するのに時間がかかる場合、サービスAは、多くのPOST要求を受信して​​いるときに、多すぎるスレッドを作成する可能性があります。これを解決するために、固定スレッドプール（Exectuors.newFixedThreadPool）を使用できます。

固定スレッドプールに加えて、非同期非ブロッキングHTTPクライアントも使用する必要がありますか？ここのような：https://hc.apache.org/httpcomponents-asyncclient-dev/。私が使用するJersey HTTPクライアントはブロックしています。

非同期HTTPクライアントを使用するのは正しいと思われます。 固定のスレッドプールに切り替えると、非同期HTTPクライアントは大きな利点をもたらさないと私は思っています。

Answer 1

あなたは固定スレッドプールを使用する場合でも、その中にすべてのあなたのスレッドは、彼らがどんな意味のある仕事しないだろうというステップ2の意味でブロックされます - ちょうど実用的ではありません応答を返すために、あなたのAPIを待ちます資源管理。この場合、新しい要求を処理するのではなく、スレッドプール内のスレッドが常にビジー状態になるため、限られた量の着信要求を処理できます。

非ブロッキングクライアントの場合、すべての要求/応答の送信と待機を担当する単一のスレッド（ディスパッチャスレッドと呼ぶ）をブロックしています。これは "whileループ"（イベントループと呼ぶことができます）で実行され、すべてのパッケージが応答として受け取られているかどうかを確認して、ワーカースレッドが取得できる状態になっているかどうかを確認します。

後者のシナリオでは、意味のあるジョブを実行する準備ができているスレッドが多くなり、スループットが向上します。

Answer 2

違いは、同期クライアントでは、スレッドがステップ2エンドポイントへの接続を行い、応答を待つことです。ステップ2を非同期的に実装すると、待ち時間の短縮に役立つ200（または何でも）が返されます。それでも接続を行い、応答を待っています。

代わりに、非ブロッキングクライアントでは、ステップAの呼び出し自体は別のスレッドによって行われます。だから、すべてがステップAのスレッドから解かれている。また、システムは、ステップBからの応答を得て作業を再開するまで、他のもののためにそのスレッドを利用することができます。

考え方は、元のスレッドが応答を待っている間にアイドル状態にならず、その間に他の作業を行うために再利用されることです。

Answer 3

非ブロッキングHTTPクライアントを使用する理由は、スレッド切り替え時にあまりにも多くのCPUを使用しないようにするためです。バックグラウンドスレッドの量を制限してすでにこの問題を解決している場合、ノンブロッキングIOは目立った利点を提供しません。

セットアップに別の問題があります。これは、DDOS攻撃（故意または偶発的な攻撃）に対して非常に脆弱です。誰かがあなたのサービスを非常に頻繁に呼び出すと、内部的に膨大な作業負荷が発生し、サービスが長時間ビジー状態に保たれます。保留中のタスクが多すぎる場合は、間違いなくバックグラウンドタスクキュー（Executorクラスのサポートされている機能）を制限し、503（または同等のもの）を返す必要があります。