このトピックでは、RocketMQ が使用される一般的なシナリオについて説明し、ビジネスで RocketMQ を使用する方法をより深く理解できるようにします。
たとえば、インターネット e コマース企業のビジネスは、登録、注文、在庫、物流など、さまざまな側面を網羅しています。企業は、フラッシュセール、記念日のお祝い、定期的な特別オファーなどのプロモーション活動中のビジネストラフィックのピークに対応する必要があります。これらの活動は、分散システムにおけるマイクロサービス アプリケーションの処理能力に大きな課題をもたらします。
分散システムのコアコンポーネントとして、RocketMQ は前述の課題を克服するのに役立ちます。たとえば、RocketMQ を使用して、非同期デカップリングの問題を解決できます。
このトピックでは、ユーザー登録シナリオで RocketMQ を使用して次の機能を実装する方法について説明します。
非同期デカップリング
分散トランザクションのデータ整合性
順序付けられたメッセージの公開とサブスクライブ
このトピックでは、e コマース企業のフラッシュセールにおけるピーク負荷のシフトと大規模サーバーのキャッシュ同期、および価格同期シナリオで RocketMQ を使用して実装する方法についても説明します。
非同期デカップリング
従来の実装モード
一般的なユーザー登録シナリオでは、ユーザーが登録した後、システムはメールと SMS 通知を送信して、登録が成功したことをユーザーに通知する必要があります。この要件の従来の実装では、次のモードが使用されます。
シリアルモード
次の図は、シリアルモードでの登録プロセスを示しています。
上記の登録プロセスは、次の手順で構成されます。
ユーザーはアカウントとパスワードを入力し、登録ページで登録情報を送信します。登録情報は登録システムに書き込まれます。
登録システムは、メール通知システムにリクエストを送信します。メール通知システムがリクエストを受信すると、メール通知システムはユーザーにメール通知を送信します。
メール通知システムは、SMS 通知システムにリクエストを送信します。 SMS 通知システムがリクエストを受信すると、SMS 通知システムはユーザーに SMS 通知を送信します。
上記の手順がすべて完了すると、登録結果がクライアントに送信され、ユーザーは登録済みアカウントでログインできます。
各手順の完了に 50 ミリ秒かかるとすると、ユーザーは登録ページで 150 ミリ秒待機してからログインする必要があります。
パラレルモード
次の図は、パラレルモードでの登録プロセスを示しています。
上記の登録プロセスは、次の手順で構成されます。
ユーザーはアカウントとパスワードを入力し、登録ページで登録情報を送信します。登録情報は登録システムに書き込まれます。
登録システムは、メール通知システムと SMS 通知システムに同時にリクエストを送信します。 2 つの通知システムがリクエストを受信すると、メール通知システムはユーザーにメール通知を送信し、SMS 通知システムはユーザーに SMS 通知を送信します。
上記の手順がすべて完了すると、登録結果がクライアントに送信され、ユーザーは登録済みアカウントでログインできます。
各手順の完了に 50 ミリ秒かかるとすると、ユーザーは登録ページで 100 ミリ秒待機してからログインする必要があります。これは、メール通知と SMS 通知が同時にユーザーに送信されるためです。
次のセクションでは、ユーザー登録シナリオにおける RocketMQ の実装について説明します。
非同期デカップリング
登録システムがユーザーのアカウント情報を保存した直後にユーザーがログインすると、ユーザーエクスペリエンスが向上します。ユーザーは SMS とメールの通知を確認する必要はありません。
登録システムは、登録が成功したときに SMS およびメール通知システムが通知を送信するのを待つ必要はありません。データが登録システムに書き込まれた後、登録システムは必要な操作を RocketMQ に配置し、すぐに登録結果をユーザーに返すことができます。必要な操作は、RocketMQ で非同期的に完了します。
上記の登録プロセスは、次の手順で構成されます。
ユーザーはアカウントとパスワードを入力し、登録ページで登録情報を送信します。登録情報は登録システムに書き込まれます。
登録システムは RocketMQ にメッセージを送信します。 RocketMQ はすぐに登録システムに応答を送信します。登録は完了し、ユーザーはログインできます。
メールおよび SMS 通知システムは、RocketMQ からの登録メッセージをサブスクライブし、ユーザーにメールおよび SMS 通知を送信します。登録プロセスは完了です。
この場合、ユーザーは登録データが登録システムと RocketMQ に書き込まれるまで待つ必要があり、これは 55 ミリ秒しかかかりません。
非同期デカップリングは、RocketMQ の重要な機能です。この機能は、応答時間を短縮し、デカップリングを実装するために設計されています。この機能は、時間がかかり、すぐに応答する必要のない操作に適用できます。操作はメッセージとしてメッセージキューに配置できます。メッセージの送信者と受信者は、RocketMQ によってデカップリングされます。メッセージ形式が変更されない限り、メッセージの送信者と受信者は互いに通信したり影響を与えたりしません。
分散トランザクションのデータ整合性
登録プロセスでは、ユーザーは登録システムの Web ページに登録情報を入力し、通知はメール通知システムによって送信されます。 2 つのシステムのデータは一致している必要があります。
通常のメッセージの処理
前のセクションで説明したように、登録システムとメール通知システムは、メッセージキューを使用して非同期処理を実装します。登録情報が登録システムに書き込まれた後、登録システムは登録の成功を示すメッセージを RocketMQ に送信します。メール通知システムは、RocketMQ からの登録メッセージをサブスクライブし、メールを送信して登録の成功をユーザーに通知します。
上記の登録プロセスは、次の手順で構成されます。
登録システムが登録を開始します。
登録システムは、登録の成功または失敗を示すメッセージを RocketMQ に送信します。
メッセージが RocketMQ に送信されると、プロセスは手順 3 に進みます。
メッセージの送信に失敗した場合、メール通知システムは RocketMQ から登録の成功または失敗を示すメッセージを受信できず、メール通知システムはユーザーにメール通知を送信できません。この場合、メール通知システムのステータスデータは登録システムのステータスデータと一致しません。
メール通知システムは、RocketMQ から登録の成功を示すメッセージを受信します。
メール通知システムは、登録の成功を示すメール通知をユーザーに送信します。
このプロセスでは、システムはデカップリングされており、アップストリームシステムはダウンストリームシステムの処理結果を気にしません。ただし、メール通知システムのステータスデータと登録システムのステータスデータ間の一貫性は保証されません。
トランザクションメッセージの処理
異なるシステム間のステータスデータの一貫性を確保するために、RocketMQ が提供するトランザクションメッセージを使用できます。
上記の登録プロセスは、次の手順で構成されます。
登録システムはハーフメッセージを RocketMQ に送信します。
ハーフメッセージが RocketMQ に送信されると、プロセスは手順 2 に進みます。
ハーフメッセージの送信に失敗した場合、登録システムはユーザーを登録せずにプロセスを終了します。
説明プロセスが終了した後、登録システムのデータはメール通知システムのデータと一致します。
登録システムはユーザーの登録を開始します。
登録が成功すると、プロセスは手順 3.1 に進みます。
登録が失敗すると、プロセスは手順 3.2 に進みます。
登録システムは、ハーフメッセージのステータスを RocketMQ に送信します。
ハーフメッセージが送信されると、登録の成功を示すメッセージが生成され、プロセスは手順 4 に進みます。
ハーフトランザクションメッセージがロールバックされると、登録の成功を示すメッセージは生成されず、プロセスは終了します。
説明プロセスが終了した後、登録システムのデータはメール通知システムのデータと一致します。
メール通知システムは、RocketMQ から登録の成功を示すメッセージを受信します。
メール通知システムは、登録の成功を示すメール通知をユーザーに送信します。
説明この手順の後、登録システムのデータはメール通知システムのデータと一致します。
分散トランザクションメッセージの詳細については、「トランザクションメッセージ」をご参照ください。
順序付けられたメッセージの公開とサブスクライブ
RocketMQ インスタンスの特定のトピックにあるパーティション順序付けメッセージは、シャーディングキーによってパーティション分割されます。同じパーティション内のメッセージは、厳密な先入れ先出し (FIFO) 順序で公開および消費されます。これにより、1 つのメッセージが 1 つのプロセスによって消費されることが保証されます。
ユーザー登録シナリオでは、パーティション分割のシャーディングキーとしてユーザー ID を指定できます。同じパーティションで作成、更新、または削除された登録メッセージは、FIFO 順序で公開および消費される必要があります。
順序付けられたメッセージの詳細については、「順序付けられたメッセージ」をご参照ください。
ピーク負荷のシフト
ピーク負荷のシフトは、RocketMQ のもう 1 つの頻繁に使用される機能です。たとえば、フラッシュセールや共同購入アクティビティでこの機能を使用できます。
フラッシュセールや共同購入アクティビティでは、大量のユーザーリクエストによりトラフィックが急激に増加します。フラッシュセール アプリケーションが膨大なアクセストラフィックを処理した後、通知システムは大量の呼び出しを処理できません。この場合、システムの停止などの問題により、一部の通知が失われる可能性があります。これらの問題を解決するには、アプリケーションと通知システムの間に RocketMQ を追加します。
上記のフラッシュセールプロセスは、次の手順で構成されます。
ユーザーはフラッシュセール処理システムに大量のリクエストを送信します。
フラッシュセール処理ロジックに基づいて、フラッシュセール処理システムはフラッシュセール条件を満たすリクエストを RocketMQ に送信します。
通知システムは RocketMQ からフラッシュセールメッセージを消費し、購入の成功を示すメッセージをユーザーに送信します。
ユーザーは購入の成功に関する通知を受信します。
大規模サーバーのキャッシュ同期
ダブル 11 の期間中、各会場にはさまざまな商品があり、価格はリアルタイムで変動する可能性があります。この場合、キャッシュテクノロジーは製品価格へのアクセス要件を満たすことができず、キャッシュサーバーのネットワークインターフェースコントローラー (NIC) は完全にロードされます。製品価格の複数のクエリにより、会場の Web ページの表示が遅くなる可能性があります。
この場合、ブロードキャストメカニズムが必要です。もともと、1 つのメッセージはクラスター内の 1 つのサーバーのみによって消費されます。ただし、RocketMQ のブロードキャスト消費モードでは、メッセージはコンシューマークラスター内のすべてのコンシューマーによって消費されます。このようにして、価格情報はすべてのサーバーに同期されます。この場合、ブロードキャストメカニズムはキャッシュ機能と同様の方法で使用されます。
詳細については、「クラスタリング消費とブロードキャスト消費」をご参照ください。