0

ゲーム プロジェクトの場合、通常の Web アプリケーションのスケーリングとは逆のように見える、スケーラビリティにいくつかの課題があるものを構築しています。つまり、リクエストを受信するWebサーバーがあり、アプリケーションサーバー(Jetty)のスレッドプールによって自然に並行して実行されます。ここまでは簡単な部分です。

要求ごとに、サーバーは多数 (たとえば 500 ~ 1000) の参加者 (独自の単純な Web アプリケーションを実行している) を同時に呼び出し、動きを収集し、それらを結果に結合して、最初の着信要求に応答する必要があります。参加者は、ゲームに参加している信頼できないプログラマーによって作成された単純な Web アプリケーションです。彼らは遅すぎるか、到達できないか、または反応が遅いことで物事を積極的に壊そうとする可能性があります。

アプリケーション サーバーは通常、ThreadPool を使用して着信要求をクリーンに処理するように設計されています。しかし、送信リクエストの部分についてはどうすればよいでしょうか? スレッドを起動して (または ThreadPool を使用して) 各参加者にコールアウトを行い、それらのスレッドで Apache httpcomponents の HttpClient を使用して厳密なタイムアウトを設定し (たとえば、「500 ミリ秒以内に応答する必要があります」)、メインの要求スレッドを待機させることを考えました。それらすべてが完了するように。おそらく ConnectionManager とキープアライブを使用して、スレッドができるだけ早く戻るようにします (参加者がストールしていない場合、おそらく実行されないでしょう)。

しかし、わずか 20 の同時受信要求と 500 の参加者が 10000 のスレッドを起動する (またはそれよりも小さい場合は ThreadPool でブロックする) 場合、これはお勧めできません。

私は一般的な解決策を見つけることができませんでした.私が見つけたほとんどのものはサーバー側のもののスケーリングについて書かれています.

それで、これに対する一般的なアプローチはありますか?たぶん、私が分析できるようなことをする(オープンソースの)プログラムですか?大量の送信リクエストを処理するために NIO を使用するライブラリ? または、これを中心に設計されたライブラリはありますか?

4

0 に答える 0