6

約10の異なるメッセージをエンキューしてから、デキュー/処理する必要があるシナリオがあります。1人のサブスクライバーは10個のメッセージすべてを必要としますが、別のサブスクライバーは10個のメッセージのうち8個だけを必要とします。このタイプのアーキテクチャをセットアップするための最良の方法を理解しようとしています。メッセージタイプごとにキューを作成して、サブスクライバーが関連するキューをサブスクライブできるようにしますか、それともすべてを同じキューにダンプして、そのサブスクライバーに関連しないメッセージを無視しますか？ソリューションが柔軟でスケーラブルであることなどを確認したい。

プロセス：

  1. 10個の異なるxmlメッセージがIBMWebSphereMQサーバーにエンキューされます。
  2. .Netを使用します（WebSphere MQ 7.1がWCFサポートに追加されたため、おそらくWCFです）
  3. メッセージをデキューし、別のバックエンドDB（ほとんどの場合SQL Server）にロードします。
  4. 非常に多くのメッセージを処理するため、ソリューションを適切に拡張する必要があり、これは増大する可能性があります（おそらく40〜50,000 /時間）。少なくとも私たちにとっては多額です。

いつものように情報を大いに感謝します。

--S

4

2 に答える 2

2

キューの作成は、リソースの観点からは比較的「安価」です。さらに、特定の目的ごとにキューを使用することをお勧めします。したがって、この場合、可能であれば、ターゲットクライアントごとにキューを分離することをお勧めします。キューを使用して、いくつかの基準（相関IDまたはその他のもの）に基づいてメッセージを選択的にプルすることは、通常、悪い考えです。メッセージングで最もパフォーマンスの高いシナリオは、最も単純なシナリオです。メッセージを選択的にピークして受信するのではなく、メッセージが到着したときにキューからメッセージをプルするだけです。

スケーリングに関しては、Websphere MQやその他のIBM製品について話すことはできませんが、Windows Server上のMSMQが1時間あたり40〜50Kのメッセージを処理するのはそれほど難しいことではないので、IBMもそれを実行できると思います。通常、ボトルネックはキューイングプラットフォーム自体ではなく、個々のメッセージのキューイングを解除して処理するプロセスです。

于 2011-10-30T18:55:07.533 に答える
1

OK、コメントに基づいて、これは拡張可能で、アプリに大きな変更を必要としない提案です。

プロデューサー側では、メッセージ選択基準をメッセージプロパティにコピーしてから、メッセージをトピックに公開します。ここでアプリに必要な唯一の変更は、メッセージプロパティです。何らかの理由でネイティブ機能を使用して公開したくない場合は、トピックのエイリアスを定義できます。アプリはメッセージを送信していると見なしますが、実際には出版物です。

消費者側では、いくつかの選択肢があります。1つは、アプリごとに管理サブスクリプションを作成し、サブスクリプションでセレクターを使用することです。次に、メッセージは、選択基準に基づいて、コンシューマーごとに専用のキューに送られます。アプリは、単にメッセージを消費していると考えています。

または、アプリでトピックをサブスクライブすることもできます。これにより、アプリが切断されたときにメッセージを受信しない動的サブスクリプション（実際に必要な場合）または管理サブスクリプションと機能的に同等の永続サブスクリプションのオプションが提供されます。

このソリューションは、引用したボリュームに簡単に拡張できます。もう1つのオプションは、プロデューサーがプロパティを使用しないことです。ここで、コンシューマーアプリケーションはすべてのメッセージを消費し、それぞれのメッセージペイロードを中断して開き、メッセージを処理するか無視するかを決定します。このソリューションでは、プロデューサーはまだトピックに公開しています。ストレートキューイングを含むソリューションでは、プロデューサーはすべての宛先を知る必要があります。別のコンシューマーを追加し、プロデューサーを変更します。また、宛先ごとにPUTがあります。

最悪のケースは、プロデューサーが複数のメッセージを配置し、コンシューマーがそれぞれを読んで無視されるかどうかを判断する必要があることです。このオプションでは、選択基準フィールドがペイロードの深さによっては、スケーリングに問題が生じる可能性があります。非常に長いXPath式=パフォーマンスが低下し、WMQを調整してそれを補う方法がありません。これは、その時点でレイテンシーがすべてアプリケーションにあるためです。

最良の場合、プロデューサーはメッセージプロパティを設定して公開します。消費者はサブスクリプションでプロパティを選択するか、管理サブスクリプションがこれを行います。このソリューションがアプリケーションサブスクリプションを使用するか管理サブスクリプションを使用するかは、スケーラビリティに関する限り、何の違いもありません。

于 2011-10-30T19:30:07.283 に答える