1

デフォルトのプリフェッチで複数のサブスクライブ クライアントが実行されているトピックがあります。クライアントの 1 つが遅いと、サブスクライブしている他のクライアントの速度が低下します。遅いコンシューマーのプリフェッチ制限を動的に下げたいのですが、クライアントがランダムに遅くなるため、動的に行う必要があります。

次のソリューションのプロトタイプを作成したいと思います: サブスクライバごとにキューを作成します。スレッドのプールは、トピックからイベントを削除し、イベントをキューにコピーします。サブスクライバーごとにキューがあるため、各クライアントは互いに独立しています。各キューにプリフェッチ制限を設定します。その制限に達したら、イベントを削除します。欠点: 現在、キューごとにメモリが必要です。

上記の解決策または私の場合に適していると思われる他の解決策について、いくつかの見解をお願いします。

ユースケースの詳細を以下に追加しました:
リスナー 1 の処理速度: 142 rps - リスナー 2 の処理速度: 10 rps

イベント生成速度 - 100 rps

デフォルトのプリフェッチ制限: 32000

ケース 1: プリフェッチ制限が両方のリスナーで等しい場合。~ 761 秒以内 - トピックがイベントのドロップを開始する前にいっぱいになります。

ケース 2: 低速コンシューマーのプリフェッチ制限が高速コンシューマー リスナーのプリフェッチ制限よりも小さい場合 2 プリフェッチ制限: 64K 上記のソリューションはうまく機能します

リスナー 2 の処理速度が向上し、リスナー 1 の処理速度が低下することはありません (処理速度が正確に逆になるわけではありませんが、極端な値を使用していることに注意してください)。また、case2 が機能しない場合もあります。リスナー 1: 10 rps リスナー 2: 142 rps イベントのドロップを開始する前に、トピックがいっぱいになるまでに 1523 秒かかります。イベントのドロップが開始されると、リスナー 1 もリスナー 2 と同じ速度で処理を開始します。

各リスナーを独立して実行し、他のリスナーをブロックしないようにするための提案を探していますか?

4

1 に答える 1

1

遅い消費者を扱うための ActiveMQ ページのドキュメントを見ましたか。基本的には、保留中のメッセージ制限戦略を使用して、動きが遅くバックアップの原因となっているコンシューマーに対してブローカが古いメッセージを破棄し始めるようにするという戦略です。コンシューマーが遅いと Broker でメッセージがビルドされるため、configure の制限に達し始め、Broker が Producer を遅くします。保留中のメッセージの制限を制定することで、物事を遅くする蓄積を防ぎます。

プロデューサのフロー制御をオフにして、プロデューサが通常の速度で処理を継続できるようにし、ディスクが限界に達するまでメッセージをディスクにスプールさせることもできます。これについては、ドキュメントでも説明されています。

于 2013-03-16T16:28:39.993 に答える