私が使用SelectorしたシナリオIO multiplexingは次のとおりです。
1 つのプライマリ コンテンツ サーバーと 100 のセカンダリ コンテンツ サーバーがあります。セカンダリ サーバーは変更されたコンテンツ メタ情報を送信し、プライマリ サーバーのすべての最新コンテンツ情報が更新されるようにします。最初の設計では、2 次サーバーに 1 対 1 でマップされた 100 個の開いたソケットに対して 100 個のスレッドを使用していました。しかし、より多くのセカンダリ サーバーをサポートする必要がSelectorsあるため、1 つのスレッドが IO 多重化 ( ) を実行し、ワーカー threadPool (サイズ 50 の固定スレッド プールselector.select()) に送信するように設計を変更しました。SelectionKey最も幸せな部分は、デザインがうまくいったことです。
このいくつかの質問を実装した後、私の頭に浮かんだのは次のとおりです。
セカンダリ コンテンツ サーバーが 1 秒間に 100/1000 のリクエストを送信した場合、この設計はうまくいくでしょうか (現在、セカンダリ コンテンツ サーバーごとに 1 秒あたり 5 ～ 7 のリクエストを取得しています)。上記の設計は、問題をもう 1 層下に押し込むことに他ならないと感じているためですが、問題はまだ残っています。私は正しいですか？
上記の設計は、セカンダリ サーバーの数を 100 から 500 にスケーリングする問題を解決するだけですが、1 秒あたりのリクエストをスケーリングしたい場合、つまり 5req/sec から 1000 req/sec を想定する場合、問題は解決しません。