このトピックでは、ApsaraMQ for RocketMQ のメッセージキューについて説明します。定義、モデル関係、内部プロパティ、バージョンの互換性、および使用に関する推奨事項について説明します。
定義
ApsaraMQ for RocketMQ において、キューはメッセージを格納および送信するコンテナーです。キューは、ApsaraMQ for RocketMQ メッセージの最小ストレージユニットでもあります。
ApsaraMQ for RocketMQ のすべての Topic と軽量 Topic は、1 つ以上のキューで構成されます。このアーキテクチャは、キューの水平分割と各キュー内のストリームベースのストレージをサポートします。
キューには、主に次の目的があります:
順序付きストレージ
キューは本質的に順序付けられています。メッセージはキューに入った順にストレージに書き込まれ、同じキュー内のメッセージに自然な順序が作成されます。最も古いメッセージはキューの先頭にあり、最新のメッセージは末尾にあります。オフセットは、キュー内の各メッセージの位置と順序をマークするために使用されます。
ストリーミング操作セティクス
ApsaraMQ for RocketMQ のキューベースのストレージモデルを使用すると、任意のオフセットから任意の数のメッセージを読み取ることができます。これにより、集計読み取りやバックトラック読み取りなどの機能が可能になります。RabbitMQ や ActiveMQ など、キューベースのストレージモデルを使用しない他のメッセージングシステムでは、これらの機能は提供されません。
モデル関係
次の図は、ApsaraMQ for RocketMQ のドメインモデル内でのキューの位置とフローを示しています:
デフォルトでは、ApsaraMQ for RocketMQ は信頼性の高いメッセージストレージメカニズムを提供します。正常に送信されたすべてのメッセージは、キューに永続的に保存されます。このメカニズムは、プロデューサーおよびコンシューマークライアントからの呼び出しと組み合わされて、at-least-once (少なくとも 1 回) の配信セマンティクスを実現します。
ApsaraMQ for RocketMQ のキューモデルは、Kafka のパーティションモデルに似ています。ApsaraMQ for RocketMQ のメッセージングモデルでは、キューは Topic のコンポーネントです。すべてのメッセージリソースは Topic と軽量 Topic の粒度で管理されますが、実際の操作はキューで実行されます。たとえば、プロデューサーは特定の Topic にメッセージを送信しますが、メッセージはその Topic 内のキューに配信されます。
ApsaraMQ for RocketMQ は、キューの数を変更することで、スケールアウトとスケールインの両方の水平スケーリングを実装します。
内部プロパティ
動作上の制約
各 Topic と軽量 Topic は、1 つ以上のキューを使用してメッセージを格納します。各 Topic または軽量 Topic のキューの数は、メッセージタイプとインスタンスが存在するリージョンによって異なります。キューの数は変更できません。
バージョンの互換性
ApsaraMQ for RocketMQ サービスのバージョンによってキュー名プロパティが異なります:
サービスバージョン 3.x および 4.x: キュー名は {Topic Name}+{Broker ID}+{Queue ID} のトライアド (3つ組) であり、物理ノードにバインドされます。
サービスバージョン 5.x: キュー名はクラスターによって割り当てられたグローバルに一意の文字列であり、物理ノードから分離されています。
したがって、開発中は、キュー名について想定したり、他の操作にバインドしたりしないでください。コードでキュー名を手動で作成し、他の操作にバインドすると、サービスのスペックアップ後にキュー名を解析できない互換性の問題が発生する可能性があります。
使用に関する推奨事項
ビジネス消費に基づいてキューの数を設定する
ApsaraMQ for RocketMQ キューについては、必要最小限の数を使用するという原則に従ってください。キューの数を任意に増やさないでください。
Topic 内のキューの数が多すぎると、次の問題が発生する可能性があります:
クラスターメタデータの肥大化
ApsaraMQ for RocketMQ は、キューの粒度でメトリックとモニタリングデータを収集します。キューの数が多すぎると、コントロールプレーンのメタデータが肥大化する可能性があります。
過剰なクライアント負荷
ApsaraMQ for RocketMQ では、メッセージの読み取りと書き込みはキューで実行されます。キューの数が多すぎると、空のポーリングリクエストが生成され、システム負荷が増加する可能性があります。
キューを増やす一般的なシナリオ
物理ノードの負荷分散のためにキューを増やす
ApsaraMQ for RocketMQ では、Topic のキューを異なるサービスノードに分散できます。ノードを追加してクラスターを水平スケーリングした後、新しいサービスノードに新しいキューを追加したり、古いキューを移行したりできます。これにより、クラスターのトラフィックの負荷分散が保証されます。
順序指定メッセージのパフォーマンスをスケーリングするためにキューを増やす
ApsaraMQ for RocketMQ サービスバージョン 4.x では、メッセージの順序は単一のキュー内でのみ保証されます。したがって、キューの数は順序指定メッセージの同時実行性に影響します。システムのパフォーマンスボトルネックが発生した場合にのみ、キューの数を増やしてください。
順序指定なしメッセージ消費の負荷分散はキューの数に依存しない
ApsaraMQ for RocketMQ サービス 5.x シリーズのインスタンスでは、コンシューマーの負荷分散はメッセージレベルの粒度にスペックアップされます。同じキュー内のメッセージは、すべてのコンシューマーによって均等に消費できます。したがって、キューの数が消費の同時実行性に影響することを心配する必要はありません。負荷分散の詳細については、「コンシューマーの負荷分散」をご参照ください。