このトピックでは、ApsaraMQ for RocketMQ の Topic の定義、モデル関係、内部属性、動作の制約、バージョンの互換性、および使用上の注意について説明します。
定義
ApsaraMQ for RocketMQ では、Topic はメッセージを転送および保存するための最上位のコンテナーです。Topic は、同じビジネスロジックを共有するメッセージを識別します。
Topic には次の利点があります。
データの分類と隔離
ApsaraMQ for RocketMQ を使用するソリューションを設計する際に、さまざまなトピックを作成して、さまざまな業務タイプのメッセージを管理できます。この方法により、隔離されたストレージとサブスクリプションが保証されます。
ID と権限管理
ApsaraMQ for RocketMQ のメッセージは匿名です。Topic を使用して、特定のカテゴリのメッセージの ID と権限を管理できます。
モデル関係
次の図は、ApsaraMQ for RocketMQ のドメインモデルにおける Topic の位置を示しています。
ApsaraMQ for RocketMQ では、Topic はすべてのメッセージリソースの最上位のコンテナーです。ただし、Topic は論理的な概念であり、実際のメッセージコンテナーではありません。
Topic は、メッセージストレージと水平スケーリングを処理する 1 つ以上のキューで構成されます。Topic のすべての制約と属性設定は、キューレベルで実装されます。
Topic が Lite タイプの場合、その下に LiteTopic リソースを作成できます。デフォルトでは、各 LiteTopic は 1 つのキューで構成されます。
概念
Topic
ApsaraMQ for RocketMQ では、Topic はメッセージを転送および保存するための最上位のコンテナーです。同じビジネスロジックを共有するメッセージを識別し、その Topic 名によって一意に識別されます。
LiteTopic
Topic が Lite タイプの場合、その下に LiteTopic を作成できます。Topic と LiteTopic の組み合わせにより、メッセージストレージコンテナーが一意に識別されます。デフォルトでは、各ストレージコンテナーは 1 つのキューで構成されます。
内部属性
動作の制約
強制的なメッセージタイプの検証
ApsaraMQ for RocketMQ 5.x では、メッセージタイプは Topic 内で独立して管理および処理されます。システムは、送信されたメッセージのタイプを宛先 Topic に定義されているメッセージタイプと照合して検証します。検証に失敗した場合、送信リクエストは拒否され、システムはタイプ不一致の例外を返します。次の検証ルールが適用されます。
メッセージタイプの一貫性
送信されたメッセージのタイプは、宛先 Topic に定義されているメッセージタイプと一致する必要があります。
Topic ごとの単一メッセージタイプ
各 Topic は 1 つのメッセージタイプのみをサポートします。同じ Topic に異なるタイプのメッセージを送信することはできません。
一般的な誤った使用シナリオ
不一致のタイプのメッセージを送信する
たとえば、Topic を作成し、そのメッセージタイプを順序付きとして定義したが、この Topic にトランザクションメッセージを送信した場合、送信リクエストは拒否され、タイプ不一致の例外が返されます。
単一の Topic でメッセージタイプを混在させる
たとえば、Topic を作成し、そのメッセージタイプを通常として定義します。その後、この Topic に通常メッセージと順序メッセージの両方を送信すると、順序メッセージを送信するリクエストは拒否され、タイプ不一致の例外が返されます。
バージョンの互換性
強制的なメッセージタイプの検証は、ApsaraMQ for RocketMQ 5.x ブローカーにのみ適用されます。
ApsaraMQ for RocketMQ 4.x ブローカーは、メッセージタイプの検証を強制しません。ただし、これらのブローカーを使用する場合は、メッセージタイプの一貫性を維持することをお勧めします。
使用上の注意
業務カテゴリに基づいて Topic を計画する
ApsaraMQ for RocketMQ で Topic を設計する場合、主要な業務カテゴリ別にメッセージをグループ化することをお勧めします。同じビジネスドメイン内で同じ機能属性を持つメッセージを単一の Topic にグループ化します。Topic の粒度を決定する際には、次の要素を考慮してください。
メッセージタイプの一貫性: 順序メッセージや通常メッセージなど、メッセージタイプが異なると、異なる Topic が必要になります。
ビジネスの関連性: ビジネスが直接関連していない場合は、異なる Topic を使用してください。たとえば、Taobao のトランザクションメッセージと Freshippo の物流メッセージにはビジネスの重複がなく、異なる Topic が必要です。Taobao のトランザクションメッセージなど、同じビジネス内のメッセージについては、婦人服と紳士服の両方の注文に同じ Topic を使用できます。ただし、ビジネスボリュームが大きい場合や、サブモジュールで注文タイプをさらに分類する必要がある場合は、メッセージを紳士服と婦人服の注文用に 2 つの別々の Topic に分割することもできます。
メッセージ量: マグニチュードや適時性の要件が異なるビジネスメッセージには、異なる Topic を使用することをお勧めします。たとえば、一部のビジネスメッセージは量が非常に少ないですが、時間的制約が非常に厳しいです。これらのメッセージが大量のメッセージを生成するビジネスと Topic を共有すると、時間的制約の厳しいメッセージの待機時間が増加します。
正しい Topic 分割の例: オンラインショッピングのシナリオでは、注文の作成、支払い、キャンセルなどの注文トランザクションメッセージに 1 つの Topic を使用できます。物流関連のメッセージには別の Topic を使用し、ポイント管理メッセージにはさらに別の Topic を使用できます。
誤った Topic 分割の例:
粗すぎる粒度での分割: これにより、ビジネスの隔離が不十分になり、独立した O&M とエラー処理が複雑になります。例としては、すべてのトランザクションメッセージと物流メッセージに単一の Topic を使用することが挙げられます。
細かすぎる粒度での分割: これにより、過剰な Topic リソースが消費され、システムに過負荷がかかる可能性があります。例としては、ユーザー ID ごとに個別の Topic を作成することが挙げられます。
1 つのメッセージタイプに 1 つの Topic を使用し、タイプの混在を避ける
ApsaraMQ for RocketMQ の Topic は、ビジネスを隔離するように設計されています。ビジネスロジックが異なるメッセージには、異なる Topic を使用することをお勧めします。同じビジネスロジックを持つメッセージは、同じメッセージタイプを持ちます。したがって、単一の Topic は 1 種類のメッセージにのみ使用する必要があります。
Topic 管理に自動化されたメカニズムを使用しない
ApsaraMQ for RocketMQ アーキテクチャでは、Topic は最上位のリソースおよびコンテナーです。権限管理、可観測性メトリックの収集、およびモニタリングのための独立した機能を備えています。Topic の作成と管理はシステムリソースを消費します。したがって、本番環境では Topic リソースを厳密に管理する必要があります。Topic を任意に追加、削除、変更、またはクエリしないでください。