RabbitMQのような高度なメッセージキュープロトコルを使用する場合 [閉まっている]

たとえば、RabbitMQのようなAMQPの使用を検討すべきユースケースを誰かが説明できますか？長所と短所は何ですか？

design message-queue

— vbd
ソース

スタックオーバーフローに関する同様の質問に対するいくつかの良い回答があります。JMS/メッセージキューの実際の使用ですか？

— ガン

以下のリンクを表示できます。幅広い説明があります：stackoverflow.com/a/51377756/3073945

— Ms. Sajedul Karim

1秒間に多くのリクエストを受け付けることができるWebサービスがあるとします。また、多くのことを行う会計システムもあります。その1つは、Webサービスからの要求を処理することです。

Webサービスと会計システムの間にキューを置くと、次のことができるようになります。

2つのアプリケーション間のカップリングが少なくなります。これは、両方のアプリケーションがキュー管理システムの構成パラメーターとキューの名前を知る必要があるためです。ここでのキャッチは、通常、キュー管理システムを移動するよりも、アプリケーションを別のサーバーに移動する可能性が高いことです。
短時間で多くのリクエストが来た場合、アカウンティングシステムはそれらをすべて処理することができます
それらの数が本当に大きくなった場合、いくつかのリクエストを保持します

もちろん、アプリケーションの数が2つよりもはるかに多く、アプリケーション間の通信を管理する必要がある、より複雑な状況になる可能性があります。

— ВиталийОлегович
ソース

1）AがBに結合され、AがCに結合され、CがBに結合されるよりも優れている方法

— チャーリー

2）キューをアカウンティングシステムに入れないのはなぜですか？追加の構成が必要な新しい移動ブラックボックスパーツを導入する理由

— チャーリー

質問1についての@Charlie、答えを修正しました。質問2について、キューをアカウンティングシステムに入れるとはどういう意味ですか？キューデータ構造を使用しますか？その場合、それを保持するために記述するコードが増えます。データベーステーブルを使用してキューをシミュレートしますか？繰り返しますが、そのテーブルを管理するには、適切なコードを記述する必要があります。私が考えていなかった他の何か？

— ВиталийОлегович

キューをWebサービスに配置するか、キューをアプリケーションに配置すると、1つのカップリングが残ります。ただし、キューが両方の外部にある場合は、カップリングが2倍になり、障害/ポイントを管理するシステムが50％増えます。サードパーティのキューが選択されている場合、この新しいパッケージについて学習して設定することもでき、キューを汎用的に使用するために追加された機能を使用することに興味のない無数の機能が邪魔される可能性がありますあなた自身よりも多くの状況。

— チャーリー

@Charlie、おそらく単一のメッセージブローカーが複数のシステム間で使用されます。または、ブローカーに対して単一のプロキシがあります。（この例では、すべてのシステムで毎秒数百万のメッセージを処理できる単一のメッセージングアプライアンスを使用しています）。メッセージは1つのシステムによって生成され、関心のあるシステムはそのメッセージを受信して適切なロジックを実行できるため、実際にはより大きな分離が作成されます。唯一のカップリングは、キュー自体へのカップリングです。

— マイケルブラウン14

Webサービスと別のバックエンドサービスの間にバッファーを提供することに加えて、より高度なシナリオにメッセージキューを使用できます。Rabbit MQ（および他の成熟したMessage Queue製品（MOM-Message Oriented Middleware）とも呼ばれる）は、さまざまなルールに従ってメッセージをルーティングおよび配信するように構成できます。

たとえば、Pub-Subルーティング技術により、単一のソースがメッセージを送信し、多くのリスナーが受信できます。これは一般的に株式取引ソフトウェアで使用され、フロアのユーザーを最新の状態に保ちます。

また、ほとんどのMOMには複数の言語とプラットフォーム用のSDKがあるため、異なるプラットフォームで作成されたアプリケーションを統合するために使用できます。

これらは、MOMによって有効化されるシナリオのほんの一部です。

— マイケル・ブラウン
ソース