Java メッセージ キューの概要 (ActiveMQ、RabbitMQ、ZeroMQ、Kafka)

[[266704]]

1. メッセージキューの概要

メッセージ キュー ミドルウェアは、分散システムの重要なコンポーネントです。主にアプリケーションの分離、非同期メッセージング、トラフィックのクリッピングなどの問題を解決し、高性能、高可用性、スケーラブル、最終的に一貫性のあるアーキテクチャを実装します。現在、最も一般的に使用されているメッセージ キューは、ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ です。

2. メッセージキューのアプリケーションシナリオ

以下では、実際のアプリケーションにおけるメッセージ キューの一般的な使用シナリオを紹介します。シナリオは、非同期処理、アプリケーションの分離、トラフィックのクリッピング、メッセージ通信の 4 つです。

2.1 非同期処理

シナリオの説明: ユーザーが登録した後、登録メールと SMS メッセージを送信する必要があります。従来の方法は 2 つあります: 1. シリアル方式。 2. 並列方式

a.シリアル方式: 登録情報がデータベースに正常に書き込まれると、登録メールが送信され、その後に登録 SMS が送信されます。上記の 3 つのタスクがすべて完了すると、クライアントに返されます。

b.並列方式: 登録情報がデータベースに正常に書き込まれると、登録メールと登録 SMS が同時に送信されます。上記3つの作業が完了したら、クライアントに返されます。シリアルとの違いは、並列処理では処理時間を改善できることです。

3 つのサービス ノードがそれぞれ 50 ミリ秒を使用し、ネットワークなどの他のオーバーヘッドを無視すると、シリアル時間は 150 ミリ秒、並列時間は 100 ミリ秒になる可能性があります。

単位時間あたりに CPU が処理できるリクエスト数は固定されているため、CPU スループットは 1 秒あたり 100 回であると仮定します。シリアルモードでは、CPU が 1 秒間に処理できるリクエストの数は 7 (1000/150) です。並行して処理されるリクエストの数は10倍（1000/100）

要約: 上記のケースで説明したように、従来のシステムのパフォーマンス (同時実行性、スループット、応答時間) にはボトルネックがあります。この問題を解決するにはどうすればいいでしょうか?

メッセージ キューの導入により、不要なビジネス ロジックを非同期で処理できるようになります。変換されたアーキテクチャは次のとおりです。

上記の合意によれば、ユーザーの応答時間は、登録情報をデータベースに書き込むのにかかる時間、つまり 50 ミリ秒に相当します。メールを登録し、テキストメッセージを送信すると、メッセージキューに書き込まれ、直接返されます。したがって、メッセージ キューへの書き込み速度は非常に速く、基本的に無視できます。したがって、ユーザーの応答時間は 50 ミリ秒になる可能性があります。したがって、アーキテクチャの変更後、システム スループットは 20 QPS に増加しました。シリアルより 3 倍、パラレルより 2 倍高速です。

2.2 アプリケーションの分離

シナリオの説明: ユーザーが注文を行った後、注文システムは在庫システムに通知する必要があります。従来のアプローチでは、注文システムが在庫システムのインターフェースを呼び出します。以下のように表示されます。

従来のモデルの欠点: 在庫システムにアクセスできない場合、在庫不足の注文は失敗し、注文は失敗します。注文システムは在庫システムと連動しています。

上記の問題をどのように解決すればよいでしょうか?アプリケーション メッセージ キューを導入した後のソリューションは次のとおりです。

注文システム: ユーザーが注文をすると、注文システムは永続処理を完了し、メッセージをメッセージキューに書き込み、ユーザーに注文成功を返します。

在庫システム: 注文メッセージを購読し、プル/プッシュ方式を使用して注文情報を取得し、在庫システムは注文情報に基づいて在庫操作を実行します。

注文時に在庫システムが正常に動作しない場合はどうなりますか。また、注文が行われると、注文システムはそれをメッセージ キューに書き込み、それ以降の操作は考慮しなくなるため、通常の注文にも影響しません。発注システムと在庫システムの分離

2.3 トラフィックピークシェービング

トラフィックのカットもメッセージ キューで一般的なシナリオであり、フラッシュ セールやグループ グラビング アクティビティでよく使用されます。

アプリケーション シナリオ: フラッシュ セールは通常、トラフィックの急増を引き起こし、過剰なトラフィックによりアプリケーションがクラッシュします。この問題を解決するには、通常、アプリケーションのフロントエンドにメッセージ キューを追加する必要があります。

a.アクティビティに参加する人数を制御できる

b.短期間でアプリケーションを圧倒する大量のトラフィックを軽減できます

サーバーがユーザーのリクエストを受信すると、まずそのリクエストがメッセージ キューに書き込まれます。メッセージ キューの長さが最大数を超えると、ユーザー要求は直接破棄されるか、エラー ページにジャンプします。

フラッシュセール事業者は、メッセージキュー内のリクエスト情報に基づいて後続の処理を実行します。

2.4 ログ処理

ログ処理とは、Kafka の適用など、ログ処理においてメッセージ キューを使用し、大規模なログ転送の問題を解決することを指します。アーキテクチャは次のように簡略化されます。

ログ収集クライアントは、ログ データを収集し、定期的に Kafka キューに書き込む役割を担います。

ログ データの受信、保存、転送を担当する Kafka メッセージ キュー。

ログ処理アプリケーション: Kafka キュー内のログ データをサブスクライブして消費します。

2.5 メッセージ通信

メッセージ通信とは、メッセージ キューには通常、効率的な通信メカニズムが組み込まれているため、純粋なメッセージ通信にも使用できることを意味します。たとえば、ポイントツーポイントのメッセージ キューやチャット ルームを実装します。

ポイントツーポイント通信:

クライアント A とクライアント B は、メッセージ通信に同じキューを使用します。

チャットルーム通信:

クライアント A、クライアント B、クライアント N は同じトピックをサブスクライブして、メッセージを公開および受信します。チャットルームのような効果を実現します。

上記は、実際にはメッセージ キューの 2 つのメッセージ モード、ポイントツーポイント モードまたはパブリッシュ サブスクライブ モードです。モデルは参考用の概略図です。

3. メッセージミドルウェアの例

3.1 電子商取引システム

メッセージ キューは、可用性が高く永続的なメッセージ ミドルウェアを使用します。たとえば、Active MQ、Rabbit MQ、Rocket Mq などです。

アプリケーションはメインロジック処理を完了すると、それをメッセージ キューに書き込みます。メッセージが正常に送信されたかどうかによって、メッセージ確認モードを有効にすることができます。 (メッセージキューが正常に受信したメッセージを返した後、アプリケーションが戻り、メッセージの整合性が確保されます)

キュー メッセージをサブスクライブするためのプロセス (SMS の送信、配信処理) を拡張します。メッセージを取得して処理するには、プッシュ メソッドまたはプル メソッドを使用します。

メッセージはアプリケーションを分離しますが、データの一貫性の問題も引き起こします。これは、結果整合性を使用して解決できます。例えば、メインデータはデータベースに書き込まれ、拡張アプリケーションはメッセージキューに基づいており、メッセージキューに基づく後続の処理はデータベース方式と組み合わせて実装されます。

3.2 ログ収集システム

これは、Zookeeper 登録センター、ログ収集クライアント、Kafka クラスター、Storm クラスター (OtherApp) の 4 つの部分で構成されています。

飼育係登録センター、負荷分散、アドレス照会

アプリケーション システム ログを収集し、データを Kafka キューにプッシュするために使用されるログ収集クライアント

Kafka クラスター: 受信、ルーティング、保存、転送、その他のメッセージ処理

ストームクラスタ: OtherAppと同じレベルで、キュー内のデータをプル方式で消費します。

MQ選択比較ドキュメント

RabbitMqの包括的な選択

Kafka は LinkedIn のオープンソース MQ システムです。主な特徴は、プルモデルに基づいてメッセージの消費を処理し、高いスループットを追求することです。本来の目的は、ログの収集と送信に使用することでした。 0.8 以降レプリケーションはサポートされていますが、トランザクションはサポートされていません。大量のデータを生成するインターネットサービスのデータ収集業務に適しています。

RabbitMQ は、Erlang 言語で開発され、AMQP プロトコルに基づいて実装されたオープン ソースのメッセージ キュー システムです。 AMQP の主な機能は、メッセージの方向、キュー、ルーティング (ポイントツーポイントおよびパブリッシュ/サブスクライブを含む)、信頼性、およびセキュリティです。 AMQP プロトコルは主に、データの一貫性、安定性、信頼性に高い要件が課され、パフォーマンスとスループットは二次的な要件であるエンタープライズ システムで使用されます。

RocketMQ は Alibaba のオープンソース メッセージング ミドルウェアです。 Pure Java で開発されており、高スループット、高可用性、大規模分散システム アプリケーションへの適合性を特徴としています。 RocketMQ のアイデアは Kafka から生まれましたが、Kafka のコピーではありません。メッセージの信頼性の高い送信とトランザクションを最適化します。現在、アリババグループでは、トランザクション、リチャージ、ストリーム コンピューティング、メッセージ プッシュ、ログ ストリーミング処理、binglog 配信などのシナリオで広く使用されています。

ZeroMQ は、一般的なネットワーク要求フォーム (グループ管理、リンク管理、パブリッシュとサブスクライブなど) をモデル化してコンポーネント化する、ネットワーク プログラミング用のパターン ライブラリです。つまり、ソケットの上にあり、MQ の下にあります。 MQ の場合、ネットワーク伝送はその一部にすぎません。対処する必要があるその他の事項としては、メッセージの保存、ルーティング、ブローカー サービスの検出と検索、トランザクション、消費パターン (ack、再送信など)、クラスター サービスなどがあります。

RabbitMQ/Kafka/ZeroMQ はすべてメッセージ キュー サービスを提供できますが、それぞれに大きな違いがあります。

サービス指向アーキテクチャでは、プロデューサー-コンシューマー モデルを使用して、メッセージ ブローカー (RabbitMQ / Kafka など) を介してサービス間の非同期通信を実行することをお勧めします。

サービス間の依存関係が強い結合から弱い結合に変わったためです。メッセージ ブローカーは、メッセージを保存し、コンシューマーの負荷が高い場合や接続が切断された場合にメッセージが失われないようにするための永続性メカニズムを提供します。つまり、プロデューサーとコンシューマーが同時にオンラインになる必要はありません。これは、従来のリクエスト/レスポンス モデルでは実現が難しく、これを具体的に行うミドルウェアが必要になります。第二に、メッセージ ブローカーはメッセージ自体に基づいて単純なルーティング戦略を作成でき、コンシューマーはこれを使用して負荷分散、ビジネス分離などを行うことができます。

追加のメッセージ ブローカー クラスターを構築する必要があるという欠点もあります (ただし、利点が欠点を上回ります)。

ZeroMQ は RabbitMQ/Kafka とは異なります。これは、ソケットに基づいてメッセージ ブローカーのようなメカニズムを提供する単なる非同期メッセージ ライブラリです。 ZeroMQ を使用する場合は、ビジネス コードを変更する必要があり、これはサービスの分離には役立ちません。

RabbitMQ は、AMQP (バイナリ)、STOMP (テキスト)、MQTT (バイナリ)、HTTP (内部に他のプロトコルをラップ) などのプロトコルをサポートしています。 Kafka は独自のプロトコルを使用します。

Kafka 独自のサービスとコンシューマーは Zookeeper に依存する必要があります。

大量のメッセージが蓄積されると RabbitMQ のパフォーマンスは低下しますが、Kafka では低下しません。結局のところ、AMQP はもともと大量のメッセージを保存するように設計されたものではなく、Kafka はもともと大量のログを処理するために使用されていました。

一般的に、RabbitMQ と Kafka はどちらも優れた分散メッセージ ブローカー サービスです。合理的に、変更を加えずに導入すれば、基本的には生産環境下でのあらゆる要件を満たすことができます。