私はシニアプログラマーではありませんが、しばらくの間アプリケーションを展開し、小さな完全なシステムを開発してきました。
RabbitMQなどのキューイングシステムについて聞き始めています。おそらく、キューイングシステムを使用する必要のあるシステムを開発したことはありません。でも、どうしたらいいのかわからないので、使わないのではないかと心配です。彼らのサイトでRabbitMQチュートリアルを読んだことがありますが、なぜこれを使用するのかわかりません。追加のコンポーネントや通常のデータベースなどを使用しない従来のプログラミングでは、これらのいずれかを実現できないかどうかはわかりません。
誰かが私がキューイングシステムを使用する理由を小さな例で説明できますか？私はHelloWorldの例ではなく、実際的なシナリオを意味します。
どうもありがとうございました
メッセージキューのようなミドルウェアの主な用途の1つは、同種でないシステム間でデータを送信できるようにすることです。メッセージ自体は多くのものになる可能性があります。文字列は、さまざまなシステムのさまざまな言語で理解するのが最も簡単ですが、より意味のあるデータを転送する場合はあまり役に立ちません。その結果、JSONとXMLがメッセージに非常に人気があります。これらは、コンシューマー側で選択した言語のオブジェクトに変換できる構造化された文字列です。
その他の便利な機能：
ここにいくつかのおそらく考案された例があります。ローカルシステム上のJavaプログラムは、インターネットを介して接続されているシステムにメッセージを送信しようとしています。ローカルシステムには、インターネットに接続されたサーバーがあります。MQへの接続を除いて、インターネットからの送信はすべてブロックされます。Javaプログラムは、インターネットにアクセスしなくても、メッセージをMQに公開できます。メッセージは、外部システムがメッセージを取得するまでキューに残ります。Javaプログラムはメッセージを公開します。たとえばXMLであり、コンシューマーはPerlプログラムである可能性があります。事前定義されたシリアル化と逆シリアル化の方法でXMLを理解する方法がある限り、問題はありません。
MQシステムは、「ファイアアンドフォーゲット」シナリオで最適に機能する傾向があります。イベントが発生し、他の人に通知する必要があるが、ソースシステムが他のシステムからのフィードバックを必要としない場合は、MQが適している可能性があります。
MQの長所と短所を理解していても、それが特定のシステムに適している理由がわからない場合は、おそらくそうではありません。MQが使用されているが不要なシステムを見たことがあり、結果はきれいではありませんでした。
私が見た中でうまくいったシナリオのほとんどは、無関係なシステム（通常はすぐに使えるタイプのシステム）間の統合です。注文を受け取る1つのシステムと、注文を処理して発送する別のシステムがあるとします。そのシナリオでは、注文システムはMQを使用してフルフィルメントシステムに注文を通知できますが、注文システムはフルフィルメントシステムが注文を受け取るまで待つことに関心がありません。したがって、メッセージをキューに入れて続行します。
これは非常に単純化された答えですが、一般的な考え方を示しています。
これを電話と電子メールの観点から考えてみましょう。電子メールが存在しないふりをします。仕事を終わらせるには、全員に電話をかける必要があります。あなたが電話で誰かと通信するとき、あなたは彼らに連絡するために彼らを彼らの机に置く必要があります（彼らが工場にいて彼らの携帯電話の呼び出し音が聞こえないと仮定します）:-)あなたが連絡したい人がいない場合デスクでは、彼らがあなたの電話を返すまであなたは立ち往生しています（またははるかに可能性が高いのは、後で彼らに電話をかけることです）。それはあなたと同じです-誰かがあなたを呼ぶまであなたは何もする必要がありません。一度に複数の人が電話をかけてきた場合、一度に1人しか対応できないため、わかりません。
ただし、電子メールがある場合は、他の誰かとリクエストを「キューに入れて」、都合の良いときに応答する（ただし、無視する可能性が高い）可能性があります。彼らがあなたの電子メールを無視する場合、あなたはいつでもそれを再送信することができます。あなたは彼らが机に着くのを待つ必要はありませんし、あなたが電話を切るまで彼らは待つ必要もありません。ワークロードが均等になり、処理がはるかにスムーズになります。追加のボーナスとして、あなたはあなたが扱いたくないメッセージをあなたのペオンに転送することができます。
システムエンジニアリングでは、「密接に結合された」という用語を使用して、上記の電話シナリオのように機能するプログラム（またはプログラムの一部）を定義します。それらは互いに非常に密接に依存しており、プログラムのさまざまな部分で実装を共有することがよくあります。これらのプログラムでは、データは一度に1つずつシリアル順に処理されます。これらのシステムは通常、簡単に構築できますが、考慮すべき重要な欠点がいくつかあります。（1）プログラムの一部を変更すると、コード全体にカスケード変更が発生する可能性があり、これによりバグが発生します。（2）システムはあまりスケーラブルではなく、通常、ニーズの拡大に応じて廃棄および再構築する必要があります。（3）システムのすべての部分が同時に機能している必要があります。そうでないと、システム全体が機能しません。
基本的に、密結合プログラムは、プログラムが非常に単純である場合、または密結合プログラムを使用する特別な理由がある場合に適しています。
現実の世界では、物事ははるかに複雑です。プログラムはそれほど単純なものにすることはできず、緊密に結合された方法でエンタープライズアプリケーションを開発することは悪夢になります。したがって、「緩く結合された」という用語を使用して、多数の小さな部分で構成される大きなシステムを定義します。ピースには非常に明確な境界と機能があるため、システムの変更をより簡単に行うことができます。それがオブジェクト指向デザインの本質です。メッセージキュー（RabbitMQなど）を使用すると、さまざまなプログラムやプログラムの一部の間で電子メールのような通信を行うことができるため、ワークフローが人とのようになります。容量を追加すると、必要な場所でコンピュータを起動して追加するだけで済みます。
明らかに、これは大幅な単純化ですが、一般的な考え方を伝えていると思います。メッセージキューを使用するアプリケーションを構築すると、クラウドサービスプロバイダーを活用して非常にスケーラブルなアプリケーションをデプロイできます。クラウドの設計について説明している記事は次のとおりです。http： //blogs.msdn.com/b/silverlining/archive/2011/08/23/designing-and-building-applications-for-the-cloud.aspx