Kafka、RocketMQ、Pulsar の包括的な比較!

[[419149]]

画像はBaotu.comより

ビッグデータ時代の到来により、Apache の Kafka はメッセージ キューの代名詞になりました。メッセージ キューについて言及するとき、人々は自然に Kafka を思い浮かべます。

ただし、メッセージ キュー自体は、エンジニアリング分野における問題に対する一般的な解決策です。その背後には、メッセージ キューの本質と魂である、いくつかの共通の設計アイデアと古典的なモデルがあります。

これらは、メッセージ キューの特定の実装 (Kafka など) とは独立していますが、これらの設計思想は、各メッセージ キューの実装のあらゆる場所に反映されています (Kafka に加えて、RocketMQ、Pulsar などがあります)。

この記事では、主に、メッセージ キューなどのコンポーネントを理解できるように、抽象的なレベルからメッセージ キューの背後にある設計上のアイデアについて説明します。

主に3つの問題を解決します:

• メッセージ キューはどのようなシナリオに適していますか?
• 主流のメッセージ キュー製品と、それぞれの長所と短所は何ですか?
• メッセージ キューの背後にある設計アイデア (全体的なコア モデル、データ ストレージの考慮事項、データ取得ソリューションの比較、消費者の消費モデル)

メッセージ キューはどのようなシナリオに適していますか?

メッセージ キュー: 主に、プロデューサーによって生成されたメッセージを他のコンシューマーが後で消費するために一時的に保存するために使用されます。

主な機能は 2 つあります。

• 一時保管
• キュー（順序：先入れ先出し）

他のほとんどのシナリオでは、データ消費に順次的な要件はなく、主に一時的なストレージ機能が使用されます。

現在のインターネット アプリケーションでメッセージ キューを使用するシナリオは、主に次の 3 つです。

• 非同期でデータを処理する
• システムアプリケーションの分離
• 交通ピークの削減

以下に、上記の各シナリオの簡単な説明を示します。

①非同期データ処理

最初の例では、現実世界の速達配達の例えを使用します。この例では、速達小包を一時的に保管する速達キャビネットと、データを一時的に保管するメッセージ キューを比較します。

現実の生活を見てみましょう。エクスプレスロッカーがない場合は、宅配業者が荷物を目的地に配達した後、通常は受取人に連絡して荷物の受け取りに署名してもらう必要があります。この時点で荷受人が空いていれば、すべてスムーズに進みます。ただし、荷受人がこの時点で都合がつかない場合（会議中、昼食中、出張中など）は、

これは配達員にとって非常に恥ずかしいことで、待機（会議や昼食のため）したり、荷物を持ち帰ったり（出張中）する必要があり、結果として無駄な移動となってしまいます。これは宅配業者にとって本当に不親切です。

このことから、宅配業者が商品を配達する際、それは同期状態にあることがわかります。つまり、次の注文を配達する前に、受取人が署名するのを待つ必要があり、宅配業者にとっては非常に非効率的です。上記の例は少し無理が​​あるかもしれませんが、大体の意味が理解できれば大丈夫です。

次に、宅配キャビネットがある場合の状況を見てみましょう。宅配業者は、荷物を配達する必要があるたびに、荷物を宅配キャビネットに投げ込み、テキストメッセージまたは電話で受取人に具体的な配達情報を通知するだけで済みます。

その後、次の注文の配達に進むことができます。受取人にとっては、特定の都合の良い時間に商品を受け取ることもできます。このように、2 つは完全に非同期であり、お互いを待つ必要はありません。

この例では、宅配業者を生産者に、荷受人を消費者に例えると、エクスプレス ロッカーはメッセージ キューに似ています。メッセージキューを使用することで非同期データ処理を実装できます。

② システムアプリケーションの分離

ケース 2 では、最も主流の推奨システムにおけるコンテンツの流れを例に挙げます。推奨システムでは、クリエイターがコンテンツを公開すると、そのコンテンツはまずセキュリティ部門による適切な審査を受けます。レビューに合格した後、通常はコンテンツをデータベースに保存し、機能の計算と生成のためにモデルに送信する必要があります。

後で推奨効果を向上させたい場合は、別途コールド スタート推奨プールを構築する必要があり、この部分のコンテンツも使用する必要があります。すると問題が起こります。メッセージキューを使用しない場合、上流サービスでは、新しいロジックを拡張してこの機能を実装する必要があります。

同時に、このシナリオでは、3 つのダウンストリーム サービスに依存します。ダウンストリーム サービスの 1 つが失敗した場合、それをどのように処理するか、再試行するか、失敗を返すか、およびその他の詳細を処理する必要があります。

後でこのデータを他のチャネルを通じて配布したい場合、どのように接続すればよいでしょうか?明らかに、このシナリオはシステムの密接な結合の問題に直面しています。

最初にメッセージ キューを導入した場合にどのような問題が発生するかを見てみましょう。

コンテンツがレビューされ承認されると、データが直接生成されてメッセージ キューに投入され、その後、複数の下流サービスがメッセージ キューからデータを消費します。

将来、このデータを他のシステムで使用するために拡張する必要がある場合は、新しいコンシューマーを介してメッセージ キューに接続してデータを消費できます。

アップストリーム メッセージ生成モジュールには変更を加えないでください。このようにして、メッセージ キューを通じてシステム アプリケーションを分離します。これはメッセージ キューの 2 回目の使用です。

③ ビジネストラフィックのピークカット

メッセージに対応する 3 番目の使用シナリオは、ピークシェービングです。今日のインターネットの世界では、電子商取引のシナリオにおける毎年恒例の 618 フラッシュ セールやダブル 11 の買い物ラッシュが最も典型的なケースです。

このシナリオでは、システムのピークトラフィックが短期間に集中することが多く、通常のトラフィックは比較的制御可能です。そのため、システムが短期間でピークトラフィックに圧倒されるのを防ぐために、ピークトラフィックを弱めるためにメッセージキューがよく使用されます。

ピーク時に生成された注文メッセージやその他のデータは、まずメッセージ キューに送信され、一時的に保存され、その後、下流のシステムによってその消費能力に応じて徐々に処理されます。

同時に、このタイプのメッセージは、レイテンシの要件がそれほど高くないことが多く、メッセージ キューでの一時的な保存に適しています。

このセクションの内容を簡単に要約します。メッセージ キューの 3 つの一般的な使用シナリオを、非同期、分離、ピーク シェービングという 3 つの簡単な例を通して紹介します。

別の観点から理解すると、メッセージ キューは、メッセージの要件がそれほどリアルタイムではなく、データが複数の場所で使用される可能性があり、ユーザーによって処理速度が異なる処理シナリオに主に適していることがわかります。読者は、メッセージ キューの使用シナリオに関する詳細情報と概要を独自に見つけることができます。

メッセージキュー「ファミリー」のメンバーは何ですか

① 主流のメッセージキュー製品

上の図は、タイムラインに従ってさまざまな時点で生成されたメッセージ キュー製品を示しています。主な製品は次のとおりです。

• アクティブMQ (2003)
• ラビットMQ (2006)
• カフカ（2010）
• ロケットMQ (2011)
• パルサー（2012）

私たちは皆、これらのメッセージ キューについてある程度聞いたことがあり、実際にプロジェクトで使用されているものもあります。以下に、上記のメッセージ キューの簡単な紹介を示します。

ActiveMQ: ActiveMQ は、Java 言語に基づいて Apache Software Foundation によって開発されたオープン ソース メッセージ ブローカーです。

複数のクライアントまたはサーバーをサポートできます。コンピュータ クラスターなどの属性は、通信システムを管理するために ActiveMQ をサポートします。

RabbitMQ: RabbitMQ は、Advanced Message Queuing Protocol (AMQP) を実装するオープン ソースのメッセージ ブローカー ソフトウェア (メッセージ指向ミドルウェアとも呼ばれます) です。

RabbitMQ サーバーは Erlang で記述されており、クラスタリングとフェイルオーバーは Open Telecom Platform フレームワーク上に構築されています。

すべての主要なプログラミング言語には、ブローカー インターフェイスと通信するためのクライアント ライブラリがあります。 RabbitMQ は、複数のメッセージング プロトコル、配信確認、その他の機能をサポートしています。

Kafka: Apache Kafka は、Apache Software Foundation によって開発され、Scala で記述されたオープンソースのメッセージング システム プロジェクトです。

Kafka はもともと LinkedIn によって開発され、2011 年初頭にオープンソース化されました。2012 年 10 月に Apache Incubator を卒業しました。

このプロジェクトの目標は、リアルタイム データを処理するための、統合された高スループット、低レイテンシのプラットフォームを提供することです。 Kafka は、分散型、パーティション化型、マルチレプリカのログ配信サービスです。独自の設計によりメッセージング システムの機能を提供します。

RocketMQ: Apache RocketMQ は、低レイテンシ、強力な一貫性、高いパフォーマンスと信頼性、兆レベルの容量、柔軟なスケーラビリティを備えた分散メッセージングおよびストリーミング プラットフォームです。これは Kafka の設計アイデアに基づいていますが、Kafka のコピーではありません。

Pulsar: Apache Pulsar は、Apache Software Foundation のトップレベル プロジェクトであり、メッセージング、ストレージ、軽量機能コンピューティングを統合し、コンピューティングとストレージを分離するアーキテクチャ設計を採用した次世代のクラウドネイティブ分散メッセージ ストリーミング プラットフォームです。

複数のコンピュータ ルームでのマルチテナント、永続ストレージ、および地域間のデータ レプリケーションをサポートします。強力な一貫性、高スループット、低レイテンシ、高スケーラビリティなどのストリーミング データ ストレージ特性を備えています。クラウドネイティブ時代のリアルタイム メッセージ ストリーム伝送、ストレージ、コンピューティングに最適なソリューションと見なされています。

② 異なるメッセージキューの比較

上の図は、いくつかのメッセージ キューの機能、利点、および欠点を詳細に示しています。まず、ActiveMQ と RabbitMQ は同じレベルですが、スループットは後者の 3 つよりも 1 桁低くなります。

第二に、RocketMQ と Pulsar は強力な一貫性をサポートします。これらの製品は、メッセージの一貫性に対する高い要件が求められるシナリオで使用できます。

Kafka にはデータ損失のリスクがありますが、スループットは比較的高く、コミュニティも非常に活発です。 Kafka はほとんどのビッグデータ シナリオで使用できます。

最後に、Kafka、RocketMQ、Pulsar は、ディスクベースのデータ ストレージとメモリ高速アクセスに基づいています。

ActiveMQ と RabbitMQ はメモリを使用してデータを保存し、ディスクへのデータの永続性もサポートします。

メッセージキューの設計思想

最初のセクションでは、主にメッセージ キューを使用する理由と、メッセージ キューが解決するのに適している問題を紹介しました。

2 番目のセクションでは、利用可能なメッセージ キューと、それぞれの利点と欠点を紹介します。

このセクションは最も重要な内容であり、主に上記のメッセージ キューの背後にあるいくつかの一般的な設計アイデアを紹介します。

いくつかのアイデアは他のビジネスモデルや分野に拡張できます。該当内容については後ほど記載します。

①メッセージキューコアモデル

上の図は、ほぼすべてのメッセージ キュー設計のコア モデルです。メッセージ キューは、データ フローの観点から、プロデューサー、メッセージ キュー クラスター、コンシューマーの 3 つの部分に分けることができます。

データはプロデューサーからメッセージ キュー クラスターに流れ、最終的にメッセージ キュー クラスターからコンシューマーに流れます。これらの概念は以下で一つずつ説明されます。

プロデューサー: データを生成するサービス。一般的にはデータ入力プロバイダーとも呼ばれます。ここでのデータは通常、推奨シナリオにおけるコンテンツ上のユーザークリックデータ、コンテンツ露出データ、eコマースにおける注文データなどのビジネスデータを指します。

プロデューサーは通常クライアントとして存在しますが、トランザクション メッセージをサポートするメッセージ キューでは、プロデューサーはトランザクション メッセージ機能を実装するサーバーとしても設計されています。

次に、通常は複数のプロデューサーが存在し、メッセージ キュー クラスター内にも複数のパーティション キューが存在するため、プロデューサーがデータを送信するときには通常、いくつかの負荷分散戦略が採用されます。最も一般的な方法は、キー ハッシュ、ポーリング、ランダムなどの方法です。

その本質はデータであり、メッセージ キューによってカプセル化された後はメッセージとも呼ばれます。このメッセージは、メッセージ キュー クラスター内のパーティション キューにのみ送信できます。したがって、特定の戦略に従って複数のキューの中から 1 つのキューを選択するだけで済みます。

メッセージ キュー クラスター: メッセージ キュー クラスターは、メッセージ キュー コンポーネントの実装における中核です。主な機能は、メッセージの保存、メッセージのフィルタリング、メッセージの配信です。

メッセージの保存は、主に、プロデューサーによって生成されたデータをメッセージ キュー内に保存する必要があることを指します。メッセージの保存はメッセージキューの中核であると言えます。メッセージ キューのスループットとパフォーマンスは、そのストレージ モデルと密接に関連しています。この内容については次のセクションで紹介します。

メッセージのフィルタリングは、メッセージ キューが特定のルールまたはポリシーに従ってメッセージをフィルタリングできることを意味します。この機能は一般にメッセージ ルーティングとも呼ばれます。

メッセージのフィルタリングは高レベルの機能です。 AMQP プロトコルでは、これらの機能が比較的完全に抽象化されています。一部のメッセージ キューでは、この機能を実現するためにプロトコルを選択的に実装できます。 AMQP プロトコルの内容に関する情報は、読者が独自に検索することができます。ここでは詳しく説明しません。

メッセージを配布するということは、通常、メッセージ キューが同じロジックを処理する複数のコンシューマー、または異なるロジックを処理する異なるコンシューマーにメッセージを配布する必要があることを意味します。

メッセージ配信は、さまざまなデータ取得方法とコンシューマーのメッセージ消費モデルを含むコンシューマー モデルにリンクされていると言えます。

さらに、ほとんどのメッセージ キューはメッセージ分類もサポートしています。分類ラベルはトピックと呼ばれ、トピックには同じカテゴリのメッセージが格納されます。

コンシューマー: 最終的には、メッセージ キューに保存されたメッセージはコンシューマーによって消費されます。コンシューマーは、メッセージ キュー内のデータの出力側と見なすこともできます。

通常、コンシューマーがメッセージ キューからデータを取得するには、プッシュ データとプル データの 2 つの方法があります。第二に、コンシューマーはメッセージ キューなどのコンポーネント内でクライアントとして現れることが多いです。

②メッセージキューデータ構成方法

このセクションでは、メッセージ キューにメッセージを保存する際のトレードオフのいくつかについて詳しく説明します。通常、データストレージには次の 2 種類があります。

• 1 つは、ディスクなどの不揮発性ストレージに保存することです。
• もう 1 つのオプションは、揮発性ストレージ (通常はメモリ) に保存することです。

両者の比較については、ここでは詳しく説明しませんので、以下の表を参照してください。

通常、ほとんどのコンポーネントを設計する場合、保存用に 1 つの主要な媒体が選択され、補助的な使用のために別の媒体が選択されます。

Redis を例に挙げると、Redis は主にメモリを使用してデータを保存し、ディスクは補助的な永続化に使用されます。 RabbitMQ を例に挙げてみましょう。また、主にメモリを使用してメッセージを保存しますが、ディスクへのメッセージの保存もサポートします。

RocketMQ、Kafka、Pulsar の場合、データは主にディスクに保存され、メモリはシステム パフォーマンスの向上に使用されます。

MySQL などのリレーショナル データベース コンポーネントも、主にディスクを使用してデータを整理し、メモリを合理的に使用してパフォーマンスを向上させます。

メモリを使用してデータを保存するソリューションの場合、アクセス効率を低下させることなく、限られたメモリ空間を最大限に活用してできるだけ多くのデータを保存することが困難です。このプロセスでは、データ構造の選択と最適化が必要です。

もう 1 つの側面は、データの損失をできるだけ少なくする方法です。この問題の解決策は、通常、広い意味でのスナップショット + wal ファイルであることがわかります。このタイプの代表的なものは Redis です。

ディスクを使用してデータを保存するソリューションの場合、システムが解決する必要がある特性シナリオに応じてディスクを合理的に配置する方法に難しさがあります。

書き込みよりも読み取りが多い場合は、B+ ツリーを使用してデータを保存します。読み取りよりも書き込みが多い場合は、lsm ツリーやその他のソリューションが使用されます。

もう 1 つの側面は、ディスクへの頻繁なアクセスを可能な限り減らす方法です。いくつかのアプローチでは、読み取りパフォーマンスを向上させるためにメモリ マッピングに mmap を使用します。その他には、頻繁にアクセスされるデータをキャッシュするためにキャッシュ メカニズムを使用するものもあります。

他のシステムでは、巧妙なデータ構造レイアウトを使用して、ディスクの事前読み取り機能を最大限に活用し、システム パフォーマンスを確保します。

一般的に、ディスク書き込みの最適化では、順次書き込みを使用してパフォーマンスを向上させるか、非同期書き込みを使用してパフォーマンスを向上させます (データの永続性を確保するには、ディスクへの非同期書き込みを WAL と組み合わせる必要があります。実際、WAL も主に順次書き込みの特性を使用します)。

ディスク読み取りの最適化では、一方ではキャッシュを使用し、他方では mmap メモリ マッピングを使用して読み取りを高速化します。

ストレージ ソリューションにおける上記のトレードオフは、Kafka、RocketMQ、Pulsar で確認できます。

実際、メッセージ キューを除けば、リレーショナル データベースであろうと kv タイプのコンポーネントであろうと、これらのストレージ ソリューションの選択は普遍的です。

次の図は、参考としてディスク上のデータを整理するいくつかの方法を示しています。

③ データ取得におけるプッシュ方式とプル方式の比較

前述したように、コンシューマーがメッセージ キューからデータを取得するには、主に 2 つのオプションがあります。

• プッシュデータを待機中
• 積極的にデータを取得する

現在、メッセージ キューは、少なくとも 2 つのオプションのうち 1 つをサポートする方法で実装されています。 2 つのオプションの比較については、以下の表を参照してください。

ここでは、メッセージ キューについては触れずに、これら 2 つのソリューションについての私の理解についてお話ししたいと思います。実際、プッシュ/プル モデルは、メッセージ キューなどのコンポーネントでのみ使用されるわけではありません。より一般的な意味では、これは実際にデータ転送における双方の問題を解決します。

本質は、データが一方から他方へ流れる必要があるということです。この考え方に従うと、次の 3 つの例はすべてこの原則に従います。

ネットワークで送信されるデータ: IO 多重化では、epoll を例にとると、カーネルが監視対象の記述子にデータが到着したことを検出すると、epoll_wait() ブロックが戻り、上位レベルのユーザー モード プログラムはデータが準備できたことを認識し、read() システム コール関数を介してデータを読み取ることができます。

このプロセスは通知の準備ができており、プッシュに似ていますが、プッシュされるのはデータではなく、データが準備できたという信号です。具体的なデータ取得方法は、プルを通じて積極的に読み取る必要があります。

フィード ストリーム システム ユーザー タイムライン バックグラウンド実装ソリューション (読み取り拡散、書き込み拡散): 読み取り拡散と書き込み拡散がこのようなケースです。

読み取り拡散の場合、データは主にプルによって取得されます。書き込み拡散に関しては、典型的なデータプッシュ方式です。もちろん、システムの実装では、より複雑なシナリオでは読み取りと書き込みの組み合わせが必要になることがよくあります。

実際の生活でテイクアウトを注文する例: テイクアウトを注文する場合、通常はテイクアウトの配達と店頭受け取りの 2 つのオプションがあります。

ただし、テイクアウトの配達の方が通常はよりリアルタイムなので、通常はこの方法を選択します。フードデリバリーは実際にはプッシュ方式であり、店舗での受け取りはプル方式であることがわかります。

④メッセージキュー消費モデル

このセクションでは、最後の部分である、メッセージ キュー内のコンシューマーの消費モデルについて紹介します。下の図の上部は、最も単純な消費モデルを示しています。プロデューサー 1 人とコンシューマー 1 人。

しかし、多くの場合、私たちのデータはさまざまなシナリオで使用されます。このとき、まず各シナリオは全量のデータを使用する必要があり、異なるシナリオは互いに相関関係を持たず、独立しています。

理解を容易にするために、同じデータを使用する必要があるシナリオが N 個あり、各シナリオで全量のデータを消費する必要があるものと想定します。

N 個のシナリオのうちの 1 つでは、複数の消費者がこのデータの消費を共有します。シナリオには M 人の消費者がいると想定します。各シナリオには M 個のコンシューマーが含まれるため、コンシューマー グループを使用して説明します。

上記の紹介を通じて、メッセージ キューの消費モデルを次の文で要約できます。消費者消費者モデルは、実際には 1:N:M の関係です。 1 つのデータは N 個の消費者グループによって独立して使用され、各消費者グループには消費を共有する M 個の消費者がいます。

実際、このモデルはパブリッシュ/サブスクライブ モデルとも呼ばれます。メッセージはグループ間でブロードキャストされ、グループ内ではユニキャストされます。メッセージは、コンシューマー グループ内の 1 つのコンシューマーによってのみ消費されます。

コンシューマー グループ内にもいくつかの負荷分散戦略があります。一般的に使用されるスキームには、ポーリング、ランダム、ハッシュ、一貫性のあるハッシュなどがあります。

このセクションでは、メッセージ キューのコア モデル、データ ストレージ モデル、プッシュ スキームとプル スキームによるデータ取得の比較、コンシューマー消費モデルなど、メッセージ キューの背後にある設計上のアイデアに焦点を当てます。

データ ストレージ モデルは、メッセージ キューだけでなく、他のデータ ストレージ コンポーネントのソリューションの選択にも適用できます。

同様に、データ取得のためのプッシュおよびプル ソリューションは、メッセージ キューに限定されません。多くのビジネスシナリオで同様のアイデアの影を見ることができます。

要約する

これでこの記事は終わりです。この記事では、主にメッセージ キューに関するいくつかのアイデアと概念を理論的かつ抽象的なレベルから説明します。

主に、メッセージ キューの使用シナリオ、主流のメッセージ キュー オプション、およびそれらの長所と短所について紹介します。

最後に、メッセージ キューの背後にあるいくつかの設計概念を紹介します。この記事は単なる出発点に過ぎません。上記の内容が皆様のメッセージキューの再理解に役立つことを願っています。

今後は、上記のメッセージ キュー (Kafka、RocketMQ、Pulsar) を徐々に選択し、それらの内部実装メカニズムの分析に重点を置きます。乞うご期待。私の個人的レベルには限界があるため、誤解があればご批判やご訂正をいただければ幸いです。

参考文献:

• ActiveMQとRabbitMQの違い
• Kafka、ActiveMQ、RabbitMQ、RocketMQ と高可用性の原則の違い
• Kafka、RabbitMQ、RocketMQ などのメッセージ ミドルウェアの比較。
• Tencent の課金シナリオにおける Apache Pulsar の応用
• Kafka のプッシュとプル
• メッセージキュー - プッシュ/プルモードの学習と ActiveMQ および JMS の学習

著者: 温暁飛

簡単な自己紹介: Tencent Cloud9 プロジェクトチームのバックエンド開発エンジニア。バックエンド開発の経験が 2 年あり、レコメンデーション システムのバックエンド作業に精通している。ネットワーク、ストレージ、分散コンセンサスアルゴリズム (raft) などのテクノロジーに興味があります。

編集者：タオ・ジアロン

出典：公開アカウント「途中で自分のビジネスを変えた舞台裏の技術者」（ID：wenxiaofeiCode）より転載