Nettyを使用するUDPロードバランサ

Question

Nettyを使用してUDPロードバランサを作成しています。

ロードバランサは、ローカルトランスポートアドレスをリッスンします。 Nettyに関しては、このアドレスでリッスンするために1つだけChannelが作成されます。次に、着信UDPパケットは、単一スレッドのイベントループグループの単一スレッドによって、処理のためにワーカースレッドのプールにディスパッチされます（ここでは、処理はロードバランシングを実行することを意味します）。

アウトバウンド側では、複数のサーバーを利用できます。受信したすべてのUDPパケットについて、関連するワーカースレッドはサーバーを選択し、このサーバーにUDPパケットを転送します。 UDPパケットを転送するには、Channelが必要です。サーバーへのすべてのパケットを転送するために使用される単一のアウトバウンドChannelを使用して

1. ：

   私は4つのアプローチを見ることができます。この方法を使用すると、パケットは常に同じ転送アドレスから送信されます。

2. 利用可能なサーバーごとに1つのアウトバウンドChannelを使用します。サーバーに転送されたすべてのパケットは、そのサーバーに関連付けられたChannelを使用して転送されます。
3. NアウトバウンドChannel利用可能なサーバーごとに。サーバーに転送されたすべてのパケットは、そのサーバーに関連付けられたChannelsのグループのChannelを使用して転送されます。
4. 転送するパケットごとに新しいChannelを使用する。

私はアプローチ4を試みましたが、それは悪い性能をもたらすことがわかります。特に、大きすぎるソケットが作成されたため、オープンされているファイルの制限を超えてしまったという問題がありました。

Channelsは複数のパケットで共有されるため、1,2,3のアプローチではUDPパケット内にリクエストの送信者アドレスを追加する必要がありますが、実際にパケットを処理するサーバーにはこの情報が必要です。

1,2,3の推奨アプローチは何ですか？宛先サーバーごとに1つ以上のChannelを使用することをお勧めしますか？

---

EDIT：私の心に来る

別のアプローチは、Channelsの共有プールを使用することです。 UDPパケットが受信されると、利用可能なサーバが選択され、プールからChannelが選択され（例えばラウンドロビン選択アルゴリズムを使用して）、Channelを使用してパケットが転送される。

Answer 1

私はあなたと同様の問題があり、私はAnother approachを使用します。しかし、バランサの性能問題についてはAnother approachを選択しませんでしたが、使用可能なサーバのパフォーマンス問題については私は選択しませんでした。

バランサーのパフォーマンスについては、私のパフォーマンステストでは、アプローチ1とAnother approachの間に大きな違いはありません。 Nettyには1つのリスンチャンネルの上限レートがあるので、複数のリスンチャンネルを作成するにはEpollChannelOption.SO_REUSEPORTを使用する方がよいでしょう。