メッセージング/メッセージキューに関する経験則

Question

メッセージキューを使用するタイミングと実際に現実の問題に対処するためのルールについて教えてください。

ありがとうございます。

Answer 1

非同期メッセージングは​​、システムが切断された方法で通信できるようにします。両方のシステムが同時に作業を完了できる必要はありません。

他にも利点があります。多くの場合、メッセージングは​​（時には意図しない）スロットルメカニズムを提供します。これにより、多くのリクエストがすべて同時に受信されると、受信システムが圧倒されることがなくなります。

メッセージングシステムの多くは、メッセージングプラットフォームまたは受信システムがクラッシュした場合でも、メッセージが最終的に配信されることを保証する、永続性と信頼性の機能を提供します。

メッセージキューも間接的なレイヤーを提供します。キューにメッセージを配置するシステムでは、誰がメッセージを受信して​​いるかを必ずしも知る必要はありません。受信者は、送信者にまったく影響を与えることなく、微妙にまたは劇的に変化する可能性があります。このような疎結合は通常望ましい。

多くのメッセージングソリューションもトランザクションに参加できます。これにより、システムはメッセージを受信し、応答してデータベースを更新することができ、両方が成功したか、どちらも成功しなかったことを知ることができます。必要に応じて、メッセージの受信を「ロールバック」して、問題が発生した場合は再試行することができます。

Answer 2

メッセージキューは信頼性の高いメッセージングを提供します。メッセージが完全に失われないようにします。それでも依然として遅延メッセージキューなどに送られることはありますが、システムから完全に消えることはありません。明示的に削除されない限り、元のクライアントにスタックされていてもどこかにコピーが常に存在します。

メッセージキューは、メッセージの損失がビジネスに害を及ぼし、システムが不安定になるような状況で使用する必要があります。それらの使用にはオーバーヘッドがあるため、ビジネス要件に応じて実装する必要があります。

実装されている状況では、凍結されたメッセージ（サービスが停止しているために処理できないメッセージ、メッセージが間違ってフォーマットされているなど）を確認するモニタリングプロセスを導入する必要があります。 ）適切に扱います。

Answer 3

ステートレスなサービス指向のリクエストを、階層化された環境で処理する非同期で保証された方法が必要な場合。

Answer 4

メッセージキューは、ロードバランシングを実装するのに便利です。たとえば、サーバーは「ジョブ」メッセージ（注文、ステータスメッセージなど）を受信し、すべてのリスニングクライアントに配布します。

メッセージキューは、メッセージが1つのクライアントに確実に配信されることを保証します。

クライアントが異なるコンピュータ上で実行されている場合、負荷が分散され、必要に応じて別のクライアントをメッセージのロードにスローするのは簡単です。クライアントはキューに接続するだけで、メッセージ。

編集：

また、システム間で（非同期に）オブジェクトを移動するのに適しています。それらがプラットフォームに依存しないフォーマット（JSON、XML）でシリアル化されている場合、異なるプログラミング言語間でオブジェクトを交換することもできます。