ドメインモデル
このセクションでは、Apache RocketMQ のドメインモデルについて説明します。
Apache RocketMQ は、非同期通信モデルとパブリッシュ/サブスクライブ メッセージ伝送モデルを採用する、分散ミドルウェア サービスです。
通信モデルと伝送モデルの詳細については、「通信モデル」と「メッセージの伝送モデル」を参照してください。
Apache RocketMQ の非同期通信モデルは、シンプルなシステムトポロジと弱いアップストリーム-ダウンストリーム結合を特徴としています。Apache RocketMQ は、非同期的デカップリングとロードシフティングのシナリオで使用されます。
Apache RocketMQ のドメイン モデル
前の図のように、Apache RocketMQ メッセージのライフサイクルは、生成、保存、消費の 3 つのステージで構成されています。
プロデューサーはメッセージを生成し、Apache RocketMQ ブローカーに送信します。メッセージは、ブローカーのトピックに保存されます。コンシューマはトピックをサブスクライブしてメッセージを消費します。
メッセージの生成
Apache RocketMQ でメッセージの生成に使用される実行エンティティ。プロデューサーはビジネス コール リンクのアップストリーム部分です。プロデューサーは軽量、匿名で、ID を持ちません。
メッセージの保存
トピック：
Apache RocketMQ でメッセージの伝送と保存に使用されるグループ化コンテナ。トピックは複数のメッセージキューで構成され、それらはメッセージの保存とトピックのスケールアウトに使用されます。
Apache RocketMQ でメッセージの伝送と保存に使用されるユニットコンテナ。メッセージキューは Kafka のパーティションに似ています。Apache RocketMQ は無限キュー構造に基づいてストリーミング方式でメッセージを保存します。メッセージはキュー内に順序どおりに保存されます。
Apache RocketMQ での最小のデータ伝送単位。メッセージは初期化されて保存されると不変になります。
メッセージの消費
Apache RocketMQ のパブリッシュ/サブスクライブ モデルで定義された、独立したコンシューマ ID グループ。コンシューマ グループにより、下層で実行されるコンシューマが集中管理されます。同じグループ内のコンシューマは、互いに同じ消費ロジックと構成を維持し、グループによってサブスクライブされたメッセージを一緒に消費して、グループの消費容量をスケールアウトする必要があります。
Apache RocketMQ でメッセージを消費するために使用される実行エンティティ。コンシューマは、ビジネス呼び出しリンクの下流部です。コンシューマは、特定のコンシューマ グループに属する必要があります。
Apache RocketMQ のパブリッシュ/サブスクライブ モデルの構成のコレクション。構成には、メッセージ フィルタリング、リトライ、およびコンシューマの進行状況が含まれます。サブスクリプションはコンシューマ グループ レベルで管理されます。コンシューマ グループを使用してサブスクリプションを指定し、グループ内のコンシューマがメッセージをフィルタリングし、消費をリトライし、コンシューマ オフセットを復元する方法を管理します。
Apache RocketMQ サブスクリプションの構成は、フィルタ式を除いて永続的です。ブローカーが再起動したり接続が閉じたりしても、サブスクリプションは変更されません。
通信モデル
分散システム アーキテクチャの概念によると、マイクロサービス モジュールなどの複数の独立したモジュールに複雑なシステムを分割できます。モジュール間のリモート通信はシステムで確保する必要があります。この目的には、2 つの一般的な通信モデルがあります。RPC ベースの同期通信モデルと、ミドルウェアベースの非同期通信モデルです。
RPC ベースの同期モデル
このモデルでは、リモート システムは直接相互に通信します。各リクエストは、発信者から受信者へ直接送信され、受信者はコールの結果をすぐに発信者に返します。お気づきの点 「同期」という単語は、プログラミング インターフェイスのモードを表すものではありません。RPC は、非同期の非ブロック呼び出しのプログラミング モードもサポートします。この場合でも、発信者は指定された期間内に受信者から直接応答を期待します。
非同期通信モデル
このモデルでは、サブシステムは強く結合された方法では接続されていません。発信者は、リクエストを非同期イベントまたはメッセージに変換し、それをエージェントに送信する必要があります。メッセージが送信されると、その呼び出しは完了したものと見なされます。エージェントは、メッセージを呼び出されたダウンストリーム サブシステムに送信し、タスクが完了するよう確保します。エージェントの役割は通常、メッセージ ミドルウェアによって担われます。
非同期通信には次のような利点があります
- シンプルなシステム トポロジー。発信者と受信者の両方がエージェントのみと通信するため、システムは星型構造で、メンテナンスと管理が容易です。
- 弱いアップストリームとダウンストリームの結合。結合が弱いと、システム構造をより柔軟にすることができます。エージェントは、バッファリングと非同期回復を実行します。アップストリームとダウンストリームに配置されたシステムは、互いに影響を与えることなく、それぞれ独立してアップグレードおよび変更できます。
- 負荷のシフト。メッセージ指向のエージェントは通常、大規模なトラフィック バッファおよび強力なトラフィック シェーピング機能を提供します。これにより、トラフィックのピークがダウンストリーム システムをダウンさせることが防止されます。
メッセージ送信モデル
メッセージ ミドルウェア サービスには、ポイントツーポイント モデルとパブリッシュ/サブスクライブ モデルという 2 つの一般的な送信モデルがあります。
ポイントツーポイント モデル
ポイントツーポイント モデルは、キュー モデルとも呼ばれ、次の特徴があります
コンシューマの匿名性: キューは、アップストリームからダウンストリームへの通信中に使用される唯一の ID です。ダウンストリームのコンシューマは、キューからメッセージを取得したときに ID を宣言できません。
1 対 1 のコミュニケーション: コンシューマには ID がありません。コンシューマグループ内のすべてのコンシューマは、サブスクライブされたメッセージをまとめて消費します。各メッセージは、特定のコンシューマによってのみ消費されます。そのため、このモデルは 1 対 1 のコミュニケーションのみをサポートします。
パブリッシュ/サブスクライブモデル 
このモデルには次の特性があります
独立した消費: このモデルでは、コンシューマはコンシューマグループの ID かサブスクリプションを使用してメッセージを受け取って消費します。コンシューマグループは互いに独立しています。
1 対多数のコミュニケーション: 独立した ID のデザインに基づいて、このモデルでは複数のコンシューマグループがトピックをサブスクライブできます。各グループはすべてのメッセージに完全にアクセスできます。そのため、パブリッシュ/サブスクライブモデルは 1 対多数のコミュニケーションをサポートします。
伝送モデルの比較
ポイントツーポイントモデルは構造が単純ですが、パブリッシュ/サブスクライブモデルの方がスケーラビリティに優れています。Apache RocketMQ もパブリッシュ/サブスクライブモデルを使用しており、同様に高いスケーラビリティを備えています。