そして、何かありますか？私にとって、MBはサブスクライバーとパブリッシャーの両方を知っており、メディエーターとして機能し、サブスクライバーに新しいメッセージを通知します（事実上「プッシュ」モデル）。一方、MQは、コンシューマーがメッセージをキューからプルする「プル」モデルに近いものです。
私はここで完全に軌道に乗っていないのですか？
84369 次
7 に答える
145
メッセージバス
メッセージバスは、さまざまなシステムが共有インターフェイスセット（メッセージバス）を介して通信できるようにするメッセージングインフラストラクチャです。
出典：EIP
メッセージキュー
メッセージキューの基本的な考え方は単純です。
2つ（またはそれ以上）のプロセスが、共通のシステムメッセージキューへのアクセスを介して情報を交換できます。
送信プロセスは、いくつかの（OS）メッセージパッシングモジュールを介して、別のプロセスが読み取ることができるキューにメッセージを配置します。
出典：デイブマーシャル
違い
メッセージキューにはFIFO（先入れ先出し）ルールが含まれていますが、メッセージバスには含まれていません。
結論
FIFOのわずかな違いを除いて、どちらも同じ種類の作業を行うように見えます-2つのアプリケーションまたは モジュール または インターフェイス または システム または プロセス 間でメッセージを渡します
于 2015-11-28T08:19:33.243 に答える
59
概して、ベンダーソフトウェア製品に関しては、それらは交換可能に使用され、あなたが説明するようにプッシュまたはプルの点で強い区別はありません。
BUS vs. QUEUEは確かにいくぶんレガシーな概念であり、最近ではIBMMQやTibcoRendezvousなどのシステムに由来しています。MQは元々1：1システムであり、実際、さまざまなシステムを分離するためのキューでした。
対照的に、Tibcoは（として販売された）メッセージングバックボーンであり、同じトピックについて複数のパブリッシャーとサブスクライバーを持つことができました。
ただし、最近では、両方（および新しい競合製品）がお互いのスペースでプレイできます。両方とも、新しいメッセージのポーリングだけでなく、割り込みを設定することもできます。どちらも、さまざまなシステム間の相互作用を仲介します。
ただし、メッセージキューというフレーズは、内部スレッド内メッセージポンプなどにも使用されます。このコンテキストでは、使用法は実際には異なります。従来のWindowsメッセージポンプについて考えると、これは確かにあなたが説明するプルモデルですが、実際にはアプリ間やボックス間よりもアプリ内です。
于 2011-10-20T13:24:38.567 に答える
38
一部の製品は、以前はいずれかのカテゴリにのみ属していた機能をサポートするようになったため、これら2つの概念の境界線があいまいになっています（たとえば、Azure Service Busは両方のアプローチをサポートしています）。
列
メッセージキューは、アプリケーションからメッセージを受信し、先入れ先出し（FIFO）方式で1つ以上の他のアプリケーションで利用できるようにします。多くのアーキテクチャシナリオでは、アプリケーションAがアプリケーションBとCに更新またはコマンドを送信する必要がある場合、BとCに別々のメッセージキューを設定できます。Aは各キューに別々のメッセージを書き込み、依存する各アプリケーションはそのキューから読み取ります。独自のキュー（キューから取り出されるとメッセージが削除されます）。Aが更新を送信するために、BもCも使用可能である必要はありません。各メッセージキューは永続的であるため、アプリケーションが再起動すると、オンラインに戻るとキューからのプルが開始されます。これにより、依存するシステム間の依存関係を解消し、アプリケーションのスケーラビリティとフォールトトレランスを向上させることができます。
バス
メッセージバスまたはサービスバスは、1つ（または複数）のアプリケーションが1つまたは複数の他のアプリケーションにメッセージを通信する方法を提供します。先入れ先出しの保証はない場合があり、バスの加入者はメッセージの送信者の知らないうちに出入りすることができます。したがって、アプリケーションAは、ステータスの更新をメッセージバスを介してアプリケーションBに通信するように作成できます。後で、これらの更新の恩恵を受けることができるアプリケーションCが作成されます。アプリケーションCは、メッセージバスをリッスンし、これらの更新に基づいてアクションを実行するように構成できます。アプリケーションAを更新する必要はありません。送信アプリケーションがすべてのキューにメッセージを明示的に追加するキューとは異なり、メッセージバスはpublish/を使用します。サブスクライブモデル。メッセージはバスに公開され、その種類のメッセージをサブスクライブしているすべてのアプリケーションがそれを受信します。
于 2017-10-23T12:19:34.887 に答える
21
他の回答で実際に明示的に言及されていない主な違いは、メッセージバスは複数のサブスクライバーを許可するのに対し、キューはキューをリッスンしているものにアイテムを1つずつデキューすることです。複数のリスナーに同じアイテムがキューから出てくるのを自分で処理する必要があることを確認したい場合は、サービスバスが箱から出してこれを実行します。
于 2016-01-11T13:59:32.920 に答える
4
私の見方では、メッセージキューがメッセージバスを作成します。クライアント（つまりノード）は、メッセージバスをリッスンできます。これは、UDPを介してメッセージをブロードキャストするMQがある場合、つまり、誰がメッセージを受信するかを知らない、または気にせずに、ブロードキャスト/マルチキャストアドレスにメッセージを送信している場合に特に当てはまります。このシナリオのより詳細な説明については、この記事を確認してください。
于 2015-04-16T20:19:03.647 に答える
2
メッセージバスは、1対多の配信モデルです。このモデルの宛先は通常、トピックまたはサブジェクトと呼ばれます。同じ公開メッセージが、すべての消費サブスクライバーによって受信されます。これを「ブロードキャスト」モデルと呼ぶこともできます。トピックは、分散コンピューティングのオブザーバーデザインパターンのサブジェクトに相当すると考えることができます。一部のメッセージバスプロバイダーは、これをTCPではなくUDPとして効率的に実装することを選択します。トピックの場合、メッセージ配信は「ファイアアンドフォーゲット」です。誰も聞いていない場合、メッセージは消えてしまいます。それが希望しない場合は、「耐久性のあるサブスクリプション」を使用できます。
メッセージキューは、メッセージの1対1の宛先です。メッセージは、消費している受信者の1つだけが受信します（注意：トピッククライアントのサブスクライバーとキュークライアントの受信者を一貫して使用すると、混乱を避けることができます）。キューに送信されたメッセージは、誰かがそれを拾うか、期限切れになるまで、ディスクまたはメモリに保存されます。したがって、キュー（および永続サブスクリプション）にはアクティブなストレージ管理が必要であり、低速のコンシューマーについて考える必要があります。
ほとんどの環境では、アーキテクチャを変更せずにいつでもコンポーネントを追加できるため、トピックがより適切な選択であると私は主張します。追加されたコンポーネントには、監視、ロギング、分析などがあります。プロジェクトの開始時に、1年、5年、10年で要件がどのようになるかはわかりません。変化は避けられない、それを受け入れる:-)
于 2020-07-02T09:39:03.793 に答える
0
サービスバスは、メッセージキューよりも一般的な用語です。
MQは単純なFIFOですが、サービスバスを実装するためのより洗練された方法があります。つまり、メッセージを操作するための巨大な「センター」であるイベントハブです。MQによって提供される機能に加えて、メッセージの保存（したがって、複数のサブスクライバーの使用）などが可能になります。
于 2018-12-05T13:48:51.980 に答える