そして、何かありますか？私にとって、MBはサブスクライバーとパブリッシャーの両方を知っており、メディエーターとして機能し、サブスクライバーに新しいメッセージを通知します（事実上「プッシュ」モデル）。一方、MQは、より「プル」モデルであり、コンシューマーはメッセージをキューからプルします。

私はここで完全に軌道から外れていますか？

概して、ベンダーソフトウェア製品に関しては、それらは交換可能に使用され、あなたが説明するように、プッシュまたはプルに関して強い区別はありません。

BUS対QUEUEは、最近IBM MQやTibco Rendezvousのようなシステムに起因する、確かに多少のレガシー概念です。MQはもともと1対1のシステムで、実際にはさまざまなシステムを分離するためのキューでした。

対照的に、Tibcoは（として販売された）メッセージングバックボーンであり、同じトピックについて複数のパブリッシャーとサブスクライバーが存在する可能性があります。

ただし、両方（および新しい競合製品）は、最近、互いのスペースで遊ぶことができます。どちらも、割り込みだけでなく、新しいメッセージのポーリングも設定できます。どちらもさまざまなシステム間の相互作用を仲介します。

ただし、message-queueというフレーズは、内部スレッド内メッセージポンプなどにも使用されます。この文脈では、実際の使用法は異なります。従来のWindowsメッセージポンプについて考えると、これは確かにプルモデルと言えますが、実際にはアプリ間やボックス間よりもアプリ内です。

メッセージバス

A メッセージバスは、異なるシステムを介して通信することを可能にするメッセージングインフラストラクチャであるインターフェイスの共有セット（メッセージ・バス）。

出典：EIP

メッセージキュー

メッセージキューの基本的な考え方は単純です。

• 2つ（またはそれ以上）のプロセスが、共通のシステムメッセージキューへのアクセスを介して情報を交換できます。

• 送信プロセスは、いくつかの（OS）メッセージ受け渡しモジュールを介して、別のプロセスが読み取ることができるキューにメッセージを置きます。

出典：Dave Marshall

画像ソース

差

メッセージキューは含まFIFO（先入れ先出しにおける一方ルール）メッセージバスはありません。

結論

どちらもLOOKは同じ種類の作業を行うようです。2つのアプリケーション 、 モジュール 、 インターフェイス 、 システム、 または プロセス間でメッセージを渡しますが、FIFOのわずかな違いは除きます。

一部の製品は以前はどちらか一方のカテゴリにのみ属していた機能をサポートするようになりました（たとえば、Azure Service Busは両方のアプローチをサポートします）。

キュー

メッセージキューは、アプリケーションからメッセージを受信し、先入れ先出し（FIFO）方式で1つ以上の他のアプリケーションがそれらを利用できるようにします。多くのアーキテクチャシナリオでは、アプリケーションAが更新またはコマンドをアプリケーションBおよびCに送信する必要がある場合、BおよびCに個別のメッセージキューを設定できます。Aは各キューに個別のメッセージを書き込み、各依存アプリケーションはそのキューから読み取ります。独自のキュー（デキュー時に削除されるメッセージ）。Aが更新を送信するために、BもCも使用可能である必要はありません。各メッセージキューは永続的であるため、アプリケーションが再起動すると、オンラインに戻ると、キューからのプルが開始されます。これにより、依存システム間の依存関係が解消され、アプリケーションのスケーラビリティとフォールトトレランスが向上します。

バス

メッセージバスまたはサービスバスは、1つ（または複数）のアプリケーションが1つまたは複数の他のアプリケーションにメッセージを通信する方法を提供します。先入れ先出しの順序は保証されない場合があり、バスの加入者はメッセージの送信者の知識がなくても行き来できます。したがって、アプリケーションAは、メッセージバスを介してステータス更新をアプリケーションBに通信するように記述できます。その後、これらの更新の恩恵を受けることができるアプリケーションCが作成されます。アプリケーションCは、メッセージバスをリッスンし、これらの更新に基づいてアクションを実行するように構成できます。アプリケーションAを更新する必要はありません。送信アプリケーションがすべてのキューにメッセージを明示的に追加するキューとは異なり、メッセージバスはpublish /を使用します。サブスクライブモデル。メッセージはバスに発行され、その種類のメッセージをサブスクライブしたアプリケーションはそれを受信します。

ソース

他の回答で明確に言及されていない主な違いは、メッセージバスは複数のサブスクライバーを許可するのに対し、キューはキューをリッスンしているものに1つずつアイテムをデキューするということです。複数のリスナーがキューから出てくる同じアイテムを自分で処理する必要があることを確認したい場合は、サービスバスがすぐにこれを実行します。

私が見るところ、メッセージキューはメッセージバスを作成します。クライアント（ノード）はメッセージバスをリッスンできます。これは、UDPを介してMQブロードキャストメッセージを送信する場合に特に当てはまります。つまり、メッセージをブロードキャストまたはマルチキャストアドレスに送信し、だれがメッセージを受信するかを知らないか、気にしません。このシナリオの詳細については、この記事を確認してください。

Service Busは、メッセージキューよりも一般的な用語です。

MQは単純なFIFOですが、サービスバス、つまりメッセージを操作するための巨大な「中心」であるイベントハブを実装するためのより洗練された方法があります。MQが提供する機能に加えて、メッセージの保存（したがって複数のサブスクライバーの使用）などが可能です。

メッセージバスは、1対多の配布モデルです。このモデルの宛先は通常、トピックまたはサブジェクトと呼ばれます。同じ発行済みメッセージが、すべての消費サブスクライバーによって受信されます。これを「ブロードキャスト」モデルと呼ぶこともできます。トピックは、分散コンピューティングのObserver設計パターンのサブジェクトに相当すると考えることができます。一部のメッセージバスプロバイダーは、これをTCPではなくUDPとして実装することを効率的に選択します。トピックの場合、メッセージ配信は「ファイアアンドフォーゲット」です。誰も聞いていない場合、メッセージは表示されなくなります。それが望ましくない場合は、「永続サブスクリプション」を使用できます。

メッセージキューは、メッセージの1対1の宛先です。メッセージは、消費しているレシーバーの1つだけが受信します（注意：「トピッククライアント」のサブスクライバーとキュークライアントのレシーバーを常に使用することで、混乱を避けることができます）。キューに送信されたメッセージは、誰かがピックアップするか期限が切れるまで、ディスクまたはメモリに保存されます。したがって、キュー（および永続サブスクリプション）にはアクティブなストレージ管理が必要です。遅いコンシューマーについて考える必要があります。

ほとんどの環境では、アーキテクチャを変更せずにコンポーネントをいつでも追加できるため、トピックの方が適しています。追加されたコンポーネントは、監視、ロギング、分析などです。プロジェクトの最初は、要件が1年、5年、10年でどのようになるかはわかりません。変化は避けられません、それを受け入れてください:-)