Apache RocketMQ 5.0 メッセージの進歩: 複雑なビジネスメッセージシナリオをサポートするには?

著者: ロンジー

一貫性

まず、RocketMQ の最初の機能であるトランザクションメッセージを見てみましょう。トランザクションメッセージは、RocketMQ の整合性関連の機能であり、RocketMQ と他のメッセージキューの最も特徴的な機能です。

大規模な電子商取引システムを例に挙げると、支払いが成功すると、トランザクションシステムの注文データベースは注文ステータスを支払い済みに更新します。次に、取引システムは RocketMQ にメッセージを送信し、RocketMQ はその後のパフォーマンスを保証するために注文が支払われたことをすべての下流アプリケーションに通知します。

ただし、上記のプロセスには問題があります。取引システムはデータベースの書き込みとメッセージの送信を別々に行います。これはトランザクションではないため、データベースの書き込みは成功したがメッセージの送信に失敗するなど、多くの異常な状況が発生します。ダウンストリームアプリケーションは、この注文のステータスを受信できません。電子メールの場合、販売業者の場合、多数のユーザーが支払いを行う可能性がありますが、販売者が商品を配達しない場合、およびメッセージが最初に正常に送信され、データベースへの書き込みに失敗すると、下流アプリケーションは注文が支払われたと判断し、販売者に商品の発送を促すことになりますが、実際のユーザーは正常に支払っていません。これらの異常は、電子商取引ビジネスに大量のダーティデータを引き起こし、ビジネスに壊滅的な影響をもたらします。

RocketMQ のトランザクションメッセージ機能は、プロデューサーのローカルトランザクション (データベースへの書き込みなど) とメッセージ送信トランザクションの一貫性を保証できます。最後に、少なくとも 1 回のブローカーの消費セマンティクスを通じて、コンシューマーのローカルトランザクションも正常に実行できるようにします。著者と消費者は、同じビジネスの取引状況について最終合意に達します。

一貫性: トランザクションメッセージ - 原則

以下の図に示すように、トランザクションメッセージは主に 2 段階の送信 + トランザクション補償メカニズムの組み合わせによって実装されます。

まず、プロデューサーは準備メッセージである半分のメッセージを送信し、ブローカーは半分をキューに保存します。次に、プロデューサはローカルトランザクションを実行し、通常はデータベースに書き込みます。ローカルトランザクションが完了すると、コミット操作が RocketMQ に送信されます。RocketMQ はコミット操作を OP キューに書き込み、圧縮を実行し、送信されたメッセージを書き込みますコンシューマの ConsumeQueue に送信されます。一方、ロールバック操作の場合、対応するハーフメッセージはスキップされます。

コミットまたはロールバックを送信する前にプロデューサーがダウンするなどの異常な状況に直面した場合、RocketMQ ブローカーには、プロデューサーのトランザクションステータスを定期的にチェックしてトランザクションを続行する補償チェックメカニズムも備えています。

準備メッセージ、コミット/ロールバックメッセージ、またはコンパクトリンクのいずれであっても、ストレージレベルでは、RocketMQ のシーケンシャル読み取りおよび書き込みの設計哲学に従って、最適なスループットを実現します。

一貫性: トランザクションメッセージのデモ

次に、トランザクションメッセージの簡単な例を見てみましょう。トランザクションメッセージを使用するには、トランザクションステータスのクエリを実装する必要があります。これが通常のメッセージとの最大の違いです。取引システムの場合、このトランザクションレビューアの実装は、注文 ID に基づいてデータベースにクエリを実行し、注文のステータス (正常に作成された、支払われた、返金されたなど) が送信されたかどうかを判断することになる場合があります。本体のメッセージ生成プロセスも大きく異なり、分散トランザクションを有効にし、準備されたメッセージを送信し、次にローカルトランザクションを実行する 2 段階の送信を行う必要があります。ここでのローカルトランザクションは通常、データベース操作を実行することです。その後、ローカルトランザクションが正常に実行された場合は、全体としてコミットし、事前に準備したメッセージを送信します。このようにして、消費者はこのメッセージを利用できます。ローカルトランザクションで例外が発生した場合、トランザクション全体がロールバックされ、前の準備メッセージもキャンセルされ、プロセス全体がロールバックされます。トランザクションメッセージの使用方法の変更は主にプロデューサーコードに反映されますが、コンシューマーの使用方法は通常のメッセージと同じですが、デモでは示されていません。

一貫性: 連続メッセージのシナリオ + 原則

RocketMQ の 2 番目の高度な機能はシーケンシャルメッセージングであり、これも注目の機能の 1 つです。これにより、シーケンスの一貫性の問題が解決され、同じビジネスのメッセージの生成と消費の順序が一貫したままであることが保証されます。

アリババにはかつて、買い手と売り手のデータベースが複製されるシナリオがありましたが、アリババの注文データベースはサブデータベースとサブテーブル技術を使用しているため、買い手と売り手のさまざまなビジネスシナリオに合わせて、買い手の主キーと売り手の主キー。2 つのデータベースの同期には、Binlog シーケンシャル分散メカニズムが採用されており、シーケンシャルメッセージを使用することで、購入者のデータベースの Binlog の変更が販売者のデータベースで厳密な順序で再生され、注文データベースの一貫性が実現されます。順序の保証がない場合、データベースレベルでダーティデータが表示され、重大なビジネスエラーが発生する可能性があります。

シーケンシャルメッセージの実装原理を次の図に示します。これは、Log の自然なシーケンシャル読み取りおよび書き込み特性を最大限に活用して、効率的な実装を実現します。

ブローカーストレージモデルでは、各トピックには固定の ConsumeQueue があり、これはトピックのパーティションとして理解できます。プロデューサは、送信されるメッセージにビジネスキーを追加します。この場合、注文 ID を使用できます。同じ注文 ID を持つメッセージは、同じトピックパーティションに順番に送信されます。各パーティションは、特定の時点で 1 つのコンシューマによってのみロックされます。コンシューマは、同じパーティションからメッセージを順番に読み取り、それらを順番に消費して、逐次的な一貫性を実現します。

一貫性: 連続メッセージのデモ

次に、連続メッセージの簡単なデモを見てみましょう。連続メッセージの場合、プロデューサーとコンシューマーの両方が注意を払う必要があります。

実稼働フェーズでは、最初にメッセージグループを定義する必要があります。各メッセージはメッセージグループとしてビジネス ID を選択できますが、ビジネス ID はできる限り個別でランダムである必要があります。同じビジネス ID が同じデータストレージシャードに割り当てられるため、生産と消費はこのデータシャードでシリアル化されます。ビジネス ID にホットスポットがある場合、深刻なデータスキューとローカルメッセージの蓄積が発生します。

たとえば、電子商取引のシナリオでは、より離散的な注文 ID と購入者 ID を選択する方がよいでしょう。販売者 ID を選択すると、ホットスポットが表示される場合があり、ホットスポット販売者のトラフィックは通常の販売者のトラフィックよりもはるかに多くなります。

消費フェーズも従来のメッセージ送受信とは異なり、フルマネージドのプッシュコンシューマモードとアクティブにメッセージを取得するセミマネージドのシンプルコンシューマモードの大きく2つのモードがあります。RocketMQ SDK は、同じグループのメッセージがビジネス消費ロジックに連続的に入力されることを保証します。独自のビジネス消費コードもシリアルに実行する必要があり、その後、消費が成功したことの確認が同期的に返される必要があることに注意してください。同じグループ内のメッセージを別のスレッドプールに入れて同時処理を行わないでください。これにより、シーケンシャルセマンティクスが破壊されます。

複雑なビジネス

複雑なビジネス: SQL フィルタリングシナリオ

RocketMQ の 3 番目の高度な機能は SQL 消費モードです。これも複雑なビジネスシナリオには必要です。

上に示したように、Ali の e コマースビジネスはトランザクションを中心に展開しており、数百もの異なる企業がトランザクションメッセージを購読しています。ビジネスは基本的に特定の細分化された分野を指向しており、そのトピックに属するニュースの一部のみを取引する必要があります。従来のモデルによると、通常、トランザクショントピックを完全にサブスクライブし、ローカルでフィルタリングする必要があります。ただし、これには大量のコンピューティングリソースとネットワークリソースが消費されます。特にダブルイレブンの期間中は、このソリューションのコストは許容範囲外です。

複雑なビジネス: SQL フィルタリングの原則

上記の問題を解決するために、RocketMQ は SQL 消費モードを提供します。トランザクションシナリオでは、各注文メッセージには、販売者 ID、購入者 ID、カテゴリ、州と市、価格、注文ステータス、その他の属性を含む、さまざまな次元のビジネス属性が含まれます。SQL フィルタリングにより、消費者は SQL ステートメントを介してフィルタリングできます。ターゲットメッセージの消費。たとえば、消費者が特定の価格範囲内の注文作成メッセージのみに注意を払いたい場合は、サブスクリプション関係 Topic=Trade SQL: status=ordercreate and (Price between 50 and 100) を作成すると、ブローカーは SQL 計算をサーバーに送信し、有効なデータのみを消費者に返します。

パフォーマンスを向上させるために、Broker にはブルームフィルターモジュールも導入されています。メッセージの書き込みおよび配信時に事前に結果を計算し、無効な IO を減らすためにビットマップフィルターを書き込みます。

一般的に言えば、その本質は、最適なパフォーマンスを達成するために、コンシューマ側のローカルフィルタリングからサーバー側の書き込み時フィルタリングまで、フィルタリングリンクを継続的に進化させることです。

複雑なビジネス: SQL フィルタリングのデモ

次に、SQL サブスクリプションの例を見てみましょう。現在、RocketMQ SQL フィルタリングは、属性の非空判定、属性のサイズ比較、属性間隔フィルタリング、セット判定、論理計算をサポートしており、ほとんどのフィルタリングニーズを満たすことができます。

メッセージの作成段階では、トピックとタグの設定に加えて、複数のカスタム属性を追加することもできます。たとえば、この場合は、メッセージが杭州地域から送信されたことを示す地域属性が設定されています。SQL フィルターのサブスクリプションは、使用時にカスタム属性に基づいて実行できます。最初のケースでは、フィルター式を使用して、region フィールドが空ではなく、消費前の杭州と等しいかどうかを判断します。2つ目はさらに条件を追加したもので、注文メッセージであれば地域条件や価格帯も同時に判断して消費するかどうかを決定することができます。3 番目のケースは完全受信モードです。式は直接 True です。このサブスクリプションメソッドは、フィルタリングなしで特定のトピックの下にあるすべてのメッセージを受信します。

複雑なビジネス: スケジュールされたメッセージのシナリオ + 原則

RocketMQ の 4 番目の高度な機能は、スケジュールされたメッセージです。

プロデューサは、メッセージが送信されてから一定の時間が経過するまで、メッセージがコンシューマに表示されないように指定できます。大規模なスケジュールされたイベントのトリガーを必要とするビジネスシナリオは数多くあります。たとえば、一般的な e コマースシナリオでは、基本的に、注文作成後 30 分間支払いが行われない場合に注文を自動的にクローズするロジックがあります。スケジュールされたメッセージは、ユーザーに大きな利便性をもたらします。上記のシナリオ。

RocketMQ のタイミングメッセージは、TimerWheel に基づいて実装されます。時刻をソートするという目的は、ダイヤルの回転をシミュレートすることによって達成されます。

TimerWheel の各グリッドは、Tick と呼ばれる最小の時間スケールを表します。RocketMQ では、各 Tick は 1 秒であり、同時にメッセージは同じグリッドに書き込まれます。複数のメッセージが各瞬間に同時にトリガーされる可能性があり、各メッセージの書き込み時間が異なるため、RocketMQ では、Timerlog データ構造も導入されています。Timerlog は、順次追加方式でデータを書き込み、各要素には、メッセージの物理インデックスが含まれます。このメッセージと、同じ瞬間を指す前のメッセージは、論理リンクリストを形成します。TimeWheel の各グリッドは、その時点のメッセージリストの先頭ポインタと末尾ポインタを維持します。

TimerWheel には現在の瞬間を表すポインタがあり、TimerWheel を中心に回転します。ポインタが指す点は Tick の有効期限を表します。すべてのコンテンツが一緒にポップアップ表示され、消費者に表示される ConsumeQueue に書き込まれます。

現在、RocketMQ のスケジュールされたメッセージのパフォーマンスは RabbitMQ や ActiveMQ をはるかに上回っています。

グローバルな高可用性

次に、RocketMQ のグローバルな高可用性テクノロジーソリューションについて話しましょう。RocketMQ の高可用性アーキテクチャは主に、RocketMQ クラスター内のデータの複数のコピーとサービスの高可用性を指します。この記事での高可用性はグローバルなものであり、業界では、同じ都市の災害復旧、2 か所の 3 つのセンター、異なる場所でのマルチアクティビティなどのアーキテクチャを指すことがよくあります。

現在、Ant Pay と Alibaba の取引はいずれも遠隔地マルチアクティブアーキテクチャを採用しており、遠隔地マルチアクティブは、コールドスタンバイ、同一都市災害復旧、2 か所の 3 センターモデルよりも多くの利点があります。、地震、停電などの都市レベルの災害にも対応できます。さらに、特定の基本的なシステム変更における新しいバグの導入など、人間の操作によって引き起こされるいくつかの問題に対しては、リモートマルチアクティブアーキテクチャにより、利用可能なコンピュータルームへのトラフィックを直接削減できます。事業継続性の確保を優先し、具体的な課題を特定します。

一方、遠隔地でのマルチアクティブは、コンピュータルームレベルでの拡張も実現できます。単一のコンピュータルームのコンピューティングリソースとストレージリソースは限られていますが、遠隔地でのマルチアクティブでは、コンピュータルーム内のビジネストラフィックを複数のコンピュータルームに分散できます。比例して国。同時に、マルチアクティブアーキテクチャにより、すべてのコンピュータ室がコールドスタンバイ状態ではなくビジネスサービスを提供できるようになり、リソース使用率が大幅に向上します。マルチアクティブ状態のおかげで、使いやすさがより保証され、極端なシーンのカットオフに直面した場合でも、より高い信頼性が得られます。

リモートマルチアクティブアーキテクチャでは、RocketMQ がインフラストラクチャのマルチアクティブ機能を引き受けます。Duohuo のアーキテクチャはいくつかのモジュールに分かれています。

アクセス層:統合アクセス層を通じて、ユーザー要求はサービス ID に従って複数のコンピューター室に分散され、サービス ID には通常ユーザー ID が採用されます。
アプリケーション層:アプリケーション層は一般にステートレスであり、リクエストが特定のコンピュータ室に入った場合、RPC、データベースアクセス、メッセージの読み書きを含むリクエストのリンク全体がユニット内で閉じられるようにする必要があります。アクセス遅延を軽減し、システムパフォーマンスを確保することができ、マルチアクティブアーキテクチャによりパフォーマンスが低下することはありません。
データ層:データベースやメッセージキューなどのステートフルシステムを含みます。RocketMQ は、コネクタコンポーネントを使用してトピックの粒度に従ってメッセージデータをリアルタイムで同期し、コンシューマとトピックの組み合わせの粒度に従って消費ステータスをリアルタイムで同期します。
グローバル管理および制御層:グローバルユニットルールを維持し、どのトラフィックがどのコンピュータルームに送信されるかを割り当てる必要があります。また、マルチアクティブなメタデータ構成、どのアプリケーションをマルチアクティブにする必要があるか、どのトピックをマルチアクティブにする必要があるかを管理する必要もあります。 -active; さらに、トラフィックカットの瞬間に調整が必要ですすべてのシステムのカットフロープロセス、制御カットフローシーケンス。

要約する

この記事では、RocketMQ の多くの高度な機能を紹介します。1 つはシーケンスの整合性と分散ビジネスの整合性を含む整合性機能で、RocketMQ には大規模で複雑なビジネスに対処するための 2 つの機能があります。1 つは SQL フィルターサブスクリプションであり、そのような単一の非常に大規模なビジネスに対処できます。多くの消費者がフィルタリングのニーズを持っており、もう 1 つはスケジュールされたメッセージであり、これも多くのインターネットトランザクションで一般的なシナリオです。最後に、RMQ の高レベルの災害復旧機能の構築を紹介し、マルチアクティブリモートソリューションを提供します。

【イベント】RocketMQをプレイして「RocketMQ最高評価責任者」を競い合おう

実際に使用している開発者から長期的なフィードバックや提案をよりよく得るために、Alibaba Cloud 開発者コミュニティと協力して「RocketMQ 最高評価責任者募集」活動を開始し、メッセージングの実践的な技術経験を持つ人材を探しています。製品を徹底的に評価し、価値のある提案をする意欲のある開発者。Apache RocketMQ および Alibaba Cloud メッセージング製品の競争力向上を支援するために、皆様のご参加をお待ちしております。
**イベント入口
**

今すぐ参加するにはここをクリックしてください:

https://developer.aliyun.com/topic/rocketmq?utm_content=g_1000377381&spm=1000.2115.3001.5954

製品評価を直接行うことができます。

https://developer.aliyun.com/mission/review/rocketmqtest?spm=a2c6h.28281744.J_2889796290.5.c66c5bacLDNt46