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

Question

メッセージ キューをいつ使用するか、また実際にどのような問題に対処する必要があるかについて、経験則を教えてもらえますか?

ありがとう

Answer 1

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

他にも利点があります。多くの場合、メッセージングは​​ (場合によっては意図しない) 調整メカニズムを提供します。これにより、多数の要求がすべて同時に受信された場合に、受信システムが過負荷になるのを防ぐことができます。

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

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

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

Answer 2

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

Answer 3

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

メッセージ キューは、メッセージの損失がビジネスに悪影響を及ぼしたり、システムが不安定になったりする状況で使用する必要があります。これらを使用するとオーバーヘッドが発生するため、ビジネス要件で必要な場合にのみ実装する必要があります。

それらが実装されている状況では、凍結されたメッセージ (サービスがダウンしている、メッセージの形式が正しくないなどの理由で処理できないメッセージ) をチェックして処理する、何らかの監視プロセスを導入する必要があります。適切に。