問題タブ [backpressure]

単純なコンフレート コンボ (以下) は、staartup でデバッグ メッセージを出力し、需要がないためにメッセージをドロップしていることを示すことがあります。私は合成段階が無限の需要を提供することを期待するので、上記は決して当てはまらない. 私は何が欠けていますか？

私のソケット リアクティブ ライブラリの作業プロセスの問題については、少し長い背景話があります。

Monixソケット ライブラリは、主に(ReactiveX に類似した)という名前のリアクティブ ライブラリに基づいています。Monix にはAck、現在のメッセージが処理されたときに次のメッセージを発行する (Future を拡張する) 型によってバックプレッシャーを処理するベスト プラクティスがあります。これは、大量のメッセージが殺到した場合にシステムを保護するための優れたメカニズムです。

現在の設計では、すべてのソケット接続は Observable (または Stream) であり、Observable は TCP/IP ネットワーク バイト ストリームが解析されるときにプロトコル メッセージを作成し、プロトコル メッセージをサブスクライバーにプッシュします。

問題は、Monix ライブラリだけがすべての Observable に対してバックプレッシャーを実行できることです。何千ものクライアントが接続されていると考えると、クラウドが非常に多くのオブザーバブルになり、バックプレッシャーは無意味になります。

では、単一の Observable 以外のグローバル システムに関して、そのようなリアクティブ システムの背圧メカニズムを設計するにはどうすればよいでしょうか。

ありがとう