RabbitMQの基本理論
RabbitMQ は、キューイングおよびメッセージ パッシング技術に基づくメッセージ ミドルウェアに属し、ネットワーク環境のアプリケーション システムに同期または非同期の信頼性の高いメッセージ伝送サポート ソフトウェア システムを提供します。
1. 同期通信と非同期通信
マイクロサービス間の通信には、同期と非同期の 2 つの方法があります。
同期コミュニケーション:妹やイケメンに電話するのと同じように、リアルタイムで応答する必要があり、通話が終わってから別の人に電話をかけることができます。
非同期コミュニケーション:WeChatのチャットと同じように、すぐに返信する必要はなく、同時に複数の妹やハンサムな男性とチャットできます.
どちらの方法にも一長一短があり、電話をかけるとすぐに応答が得られますが、同時に複数の人と話すことはできません。メッセージの送信は、同時に複数の人とメッセージを送受信できますが、応答に遅延が生じることがよくあります。
1. 同期通信
偽のリモート呼び出しは同期メソッドであり、リアルタイムで結果を取得できますが、次のような問題があります。
要約:
同期呼び出しの利点:
- 時間に敏感で、すぐに結果を得ることができます
同期呼び出しの問題:
- 高結合
- パフォーマンスとスループットの低下
- 追加のリソース消費があります
- カスケード障害の問題があります
2.非同期通信
非同期呼び出しにより、上記の問題を回避できます。
商品の購入を例にとると、ユーザーは支払いを済ませた後、注文サービスを呼び出して注文ステータスの変更を完了し、物流サービスを呼び出し、倉庫から対応する在庫を割り当て、配送の準備をする必要があります。
イベント モードでは、支払いサービスはイベント パブリッシャー (publisher) であり、支払いが完了した後、成功した支払いイベント (イベント) をイベント内の注文 ID と共に公開するだけで済みます。
注文サービスと物流サービスは、支払いが成功したイベントにサブスクライブし、イベントを聞いた後に自分のビジネスを完了するイベント サブスクライバー (コンシューマー) です。
イベントのパブリッシャーとサブスクライバーの間の結合を取り除くために、両者は直接通信するのではなく、仲介者 (ブローカー) を持っています。パブリッシャーは、誰がイベントをサブスクライブするかに関係なく、イベントを Broker にパブリッシュします。サブスクライバーは Broker からのイベントにサブスクライブし、メッセージの送信者は気にしません。
ブローカーはデータ バスのようなものです. データを受信し、データを送信する必要があるすべてのサービスは、このバスに送信されます. このバスは、サービス間の通信を標準化および制御可能にするプロトコルのようなものです.
利点:
-
スループットの向上: サブスクライバーが処理を完了するのを待つ必要がなく、応答が速くなります
-
障害分離: サービスは直接呼び出されず、カスケード障害の問題はありません
-
呼び出し間にブロッキングがないため、無効なリソース占有が発生しません
-
結合度が極めて低く、各サービスを柔軟に差し替え可能
-
トラフィック ピーク クリッピング: 発行されたイベントのトラフィックがどれだけ変動しても、ブローカーによって受信され、サブスクライバーは自分の速度でイベントを処理できます。
欠点:
- 構造が複雑で、ビジネスに明確なプロセスラインがなく、管理が難しい
- ブローカーの信頼性、セキュリティ、およびパフォーマンスに依存する必要がある
2. 技術比較
MQ、中国語はメッセージ キュー (MessageQueue)、文字通りメッセージを格納するためのキューです。つまり、イベント駆動型アーキテクチャのブローカーです。
より一般的な MQ の実装:
- アクティブMQ
- RabbitMQ
- ロケットMQ
- カフカ
いくつかの一般的な MQ の比較:
可用性の追求: Kafka、RocketMQ、RabbitMQ
信頼性の追求:RabbitMQ、RocketMQ
スループットの追求:RocketMQ、Kafka
低メッセージ遅延の追求: RabbitMQ、Kafka