RocketMQ（3）技術アーキテクチャ

1技術アーキテクチャ

RocketMQアーキテクチャは、上の図に示すように、主に4つの部分に分かれています。

• プロデューサー：分散クラスター展開をサポートするメッセージ発行の役割。プロデューサーは、MQのロードバランシングモジュールを介したメッセージ配信に対応するブローカークラスターキューを選択します。配信プロセスは、高速障害と低遅延をサポートします。
• コンシューマー：分散クラスター展開をサポートするメッセージ消費の役割。メッセージを消費するためのプッシュとプルの2つのモードをサポートします。同時に、クラスターモードとブロードキャストモードの消費もサポートし、ほとんどのユーザーのニーズを満たすリアルタイムのメッセージサブスクリプションメカニズムを提供します。
• NameServer：NameServerは、非常にシンプルなトピックルーティング登録センターです。その役割はDubboのzookeeperに似ており、動的な登録とBrokerの検出をサポートします。主に2つの機能が含まれています。ブローカー管理、NameServerはブローカークラスターの登録情報を受け入れ、ルーティング情報の基本データとして保存します。次に、ハートビート検出メカニズムを提供して、ブローカーがまだ生きているかどうかを確認します。ルーティング情報の管理では、各NameServerは、ブローカークラスターに関するルーティング情報全体とクライアントクエリのキュー情報を保存します。次に、プロデューサーとコナムサーは、メッセージを配信および消費するために、NameServerを介してブローカークラスター全体のルーティング情報を知ることができます。NameServerは通常クラスターにデプロイされ、インスタンスは相互に通信しません。ブローカーは独自のルーティング情報を各NameServerに登録するため、各NameServerインスタンスは完全なルーティング情報を保存します。NameServerが何らかの理由でオフラインになった場合でも、Brokerはそのルーティング情報を他のNameServerと同期でき、プロデューサーとコンシューマーは引き続きBrokerのルーティング情報を動的に認識できます。
• BrokerServer：Brokerは主に、メッセージの保存、配信、クエリ、およびサービスの高可用性の保証を担当します。これらの機能を実現するために、Brokerには次の重要なサブモジュールが含まれています。

1. リモーティングモジュール：ブローカー全体のエンティティであり、クライアントからの要求の処理を担当します。
2. クライアントマネージャー：クライアント（プロデューサー/コンシューマー）を管理し、コンシューマーのトピックサブスクリプション情報を維持する責任があります
3. ストアサービス：物理ハードディスクへのメッセージストレージとクエリ機能を処理するための便利でシンプルなAPIインターフェイスを提供します。
4. HAサービス：マスターブローカーとスレーブブローカー間のデータ同期機能を提供する、可用性の高いサービス。
5. インデックスサービス：特定のメッセージキーに従ってブローカーに配信されるメッセージのインデックスサービスで、メッセージのクイッククエリを提供します。

2デプロイメントアーキテクチャ

[外部リンクの画像転送に失敗しました。元のサイトにホットリンク防止メカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします（img-6MCviSPf-1606900409585）（https://github.com/apache/rocketmq/raw/master/docs/cn /image/rocketmq_architecture_3.png）]

RocketMQネットワーク展開の特性

• NameServerはほとんどステートレスなノードであり、ノード間の情報同期なしでクラスターにデプロイできます。
• ブローカーの展開は比較的複雑です。ブローカーはマスターとスレーブに分割されます。1つのマスターは複数のスレーブに対応できますが、1つのスレーブは1つのマスターにしか対応できません。マスターとスレーブ間の対応関係は、同じBrokerNameと異なるBrokerIdを指定することによって定義されます。BrokerIdは0です。マスターを表し、ゼロ以外はスレーブを表します。マスターは複数を展開することもできます。各ブローカーは、NameServerクラスター内のすべてのノードとの長い接続を確立し、トピック情報をすべてのNameServerに定期的に登録します。注：現在のRocketMQバージョンは、デプロイメントアーキテクチャで1つのマスターと複数のスレーブをサポートしますが、メッセージ読み取りのロードに参加するのはBrokerId = 1のスレーブサーバーのみです。
• プロデューサーは、NameServerクラスター内のノードの1つ（ランダムに選択）との長い接続を確立し、NameServerからトピックルーティング情報を定期的に取得し、トピックサービスを提供するマスターとの長い接続を確立し、ハートビートをマスターに定期的に送信します。プロデューサーは完全にステートレスであり、クラスターにデプロイできます。
• コンシューマーは、NameServerクラスター内のノード（ランダムに選択）の1つとの長い接続を確立し、NameServerからトピックルーティング情報を定期的に取得し、トピックサービスを提供するマスターとスレーブへの長い接続を確立し、マスターとスレーブに定期的にハートビートを送信します。消費者はマスターまたはスレーブからのメッセージをサブスクライブできます。消費者がマスターからメッセージをプルすると、マスターサーバーはプルオフセットと最大オフセットの間の距離に応じて古いメッセージを読み取るかどうかを決定します。 I / O）、およびスレーブサーバーが読み取り可能かどうかに関係なく、次回はマスターまたはスレーブからプルすることをお勧めします。

デプロイメントアーキテクチャ図と組み合わせて、クラスタワークフローを説明します。

• NameServerを起動し、NameServerが起動した後にポートをリッスンし、ブローカー、プロデューサー、およびコンシューマーが接続するのを待ちます。これは、ルーティングコントロールセンターに相当します。
• ブローカーが起動し、すべてのNameServerとの長い接続を維持し、ハートビートパケットを定期的に送信します。ハートビートパケットには、現在のブローカー情報（IP +ポートなど）が含まれ、すべてのトピック情報が格納されます。登録が成功すると、NameServerクラスター内のトピックとブローカーの間にマッピング関係があります。
• メッセージを送受信する前に、まずトピックを作成します。トピックを作成するときは、トピックを保存するブローカーを指定する必要があります。そうしないと、メッセージの送信時にトピックを自動的に作成できます。
• プロデューサーはメッセージを送信し、開始時にNameServerクラスターの1つとの長い接続を確立し、現在送信されているトピックが存在するブローカーをNameServerから取得し、キューリストからキューをポーリングして選択し、キューが配置されているブローカーと確立します。長い接続はブローカーにメッセージを送信します。
• コンシューマーはプロデューサーに似ています。NameServerの1つとの長い接続を確立し、現在サブスクライブしているブローカーを取得してから、ブローカーとの接続チャネルを直接確立してメッセージの消費を開始します。

3元のリンク

注释：来源于GitHub
https://github.com/apache/rocketmq/blob/master/docs/cn/README.md