私は Tokio TCP バックエンド アプリケーションを持っています。簡単に言うと、リクエストを受け取った後、Redis から何かを読み取り、PostgreSQL に何かを書き込み、HTTP 経由で何かをアップロードし、RabbitMQ に何かを送信します。各リクエストの処理には多くの時間がかかるため、リクエストごとに個別のタスクが作成されます。非同期モデルでは接続を共有できないため、いくつかの接続プーリングが必要です。今のところ、リクエストごとに新しい接続が確立されており、非常に過剰です。
Rust で非同期接続プールの実装を探していましたが、最新のものは見つかりませんでした。
自分で実装する方法についてアドバイスを聞きたいです。
私が思いついた唯一のアイデアは次のとおりです。
Stream/Sink接続の内部コレクションを持つオブジェクトを実装します。接続は同じなので、LIFO か FIFO かは関係ありません。アプリケーションの起動時に、N 個の接続が割り当てられます。- このようなプールをタスク間で共有できるかどうかはわかりませんが、可能であれば、タスクは (独自のプールを確立するのではなく) 接続インスタンスのストリームをポーリングし、それを使用してから戻します。
- 利用可能な接続がなかった場合、ストリームはそれらをさらに確立するか、タスクにハングアップするように要求する可能性があります (構成によって異なります)。
- 接続が失敗した場合、その接続はドロップされ、プールには現在 N-1 個の接続が含まれているため、次の要求で新しい接続を割り当てることが決定される場合があります。
したがって、適切な答えがどこにも見つからない2つの問題があります。
何らかの方法でストリーム/シンクプールをタスク間で共有する必要がありますか/できますか? とにかく、箱
Sharedの中にいくつかの先物が見えます。futurestokio/futures チュートリアルにはいくつかの暗い点があります。たとえば、最上位のタスクに通知する方法、つまり、それ自体は何もプールしないが、上位の先物に通知する必要がある、神話上の最も内側の未来をどのように実装するかについては説明していません。
それとも私のアプローチは完全に間違っていますか？私は自分でそれを試してみることができましたが、ワンクリック ソリューションなど、何かを見逃しているのではないかと強く疑っています。