のRabbitMQ同期メッセージング長所と短所

Question

我々はすべてのRabbitMQのようなメッセージバスは主に非同期メッセージングのためのものです知っているように、標準approch、火災やバスに何かを公開し、公開メッセージまたはときを処理する人を心配していないように忘れています。しかし私は、メッセージの同期処理に関する開発チームの最新の話を考えています。ケースはサービスバスにメッセージを公開することです。パブリッシャーとしては、メッセージを処理して結果を返すためにすべてのサブスクライバを待っています。むしろ要求 - 応答モデルである。私は今、このモデルでパフォーマンスを低下させるようなものがあると考えています。あなたの考えは？いつ非同期と同期を使用するのですか？トレードオフは何ですか？

Answer 1

同期メッセージングが可能ですが、影響スケーラビリティ。サイト運営者が受信者の応答を待つ必要がある場合、サイト運営者はいつでも達成できる範囲で制限されます。

ただし、非同期メッセージングを使用して、リクエスト・レスポンスを実現することができます。 RabbitMQではRemote Procedure Call (RPC)のパターンでこれを行います。

単純に言えば、パブリッシャーはメッセージを公開しますが、は応答を待たずに応答を返します。;その間に他のものをやり続けることができます。パブリッシャーは、メッセージにCorrelationIdを入れてローカルに保管することで、それを追跡します。メッセージは最終的に消費者に届き、それを処理し、別のキューの公開者に返信します。応答には同じCorrelationIdがあります。パブリッシャが応答を受け取ると、（CorrelationIdを介して）処理された特定のコールにマークを付けることができます。

必要であれば、あなたはまた、タイムアウトなどCorrelatonIdと他のもの、私たちは、例えば後に返事を受け取っていないいるため、それらのメッセージを行うことができます30秒。