KafkaではなくRabbitMQを使用する理由はありますか？

KafkaではなくRabbitMQを評価するように依頼されましたが、Kafkaよりも優れている理由を見つけるのが難しいと感じました。スループット、耐久性、レイテンシ、使いやすさが本当に優れているかどうか誰かが知っていますか？

RabbitMQは、AMQP、MQTT、STOMPなどのいくつかのプロトコルをサポートする堅牢な汎用メッセージブローカーです。高スループットを処理できます。RabbitMQの一般的な使用例は、バックグラウンドジョブや、ファイルスキャン、画像スケーリング、PDF変換などの長時間実行タスクを処理することです。RabbitMQはマイクロサービス間でも使用され、アプリケーション間の通信手段として機能し、メッセージを渡すボトルネックを回避します。

Kafkaは、高入力データストリームと再生用に最適化されたメッセージバスです。大量のデータを移動したり、リアルタイムでデータを処理したり、一定期間のデータを分析したりする必要がある場合は、Kafkaを使用してください。つまり、データを収集、保存、処理する必要がある場所です。たとえば、Webショップでのユーザーアクティビティを追跡し、購入するための推奨アイテムを生成する場合です。別の例は、追跡、取り込み、ロギング、またはセキュリティのためのデータ分析です。

Kafkaは、アプリケーションがディスク上のストリーミングデータを処理および再処理できる耐久性のあるメッセージブローカーと見なすことができます。Kafkaには、非常に単純なルーティングアプローチがあります。複雑な方法でメッセージをコンシューマーにルーティングする必要がある場合、RabbitMQにはより優れたオプションがあります。オフラインになる可能性のあるバッチコンシューマーや、低遅延でメッセージを必要とするコンシューマーをサポートする必要がある場合は、Kafkaを使用します。 

カフカからデータを読み取る方法を理解するには、まずその消費者と消費者グループを理解する必要があります。パーティションを使用すると、データを複数のノードに分割することにより、トピックを並列化できます。パーティション内の各レコードは、一意のオフセットによって割り当てられ、識別されます。このオフセットは、パーティション内のレコードを指します。Kafkaの最新バージョンでは、Kafkaはパーティション内の各レコードの数値オフセットを維持します。Kafkaのコンシューマは、定期的にオフセットを自動的にコミットするか、このコミットされた位置を手動で制御することを選択できます。RabbitMQは、消費/確認済み/未確認のメッセージに関するすべての状態を保持します。Kafkaは、RabbitMQの場合よりも理解するのがより複雑であることがわかります。

RabbitMQのキューは空のときに最も高速ですが、Kafkaは非常に少ないオーバーヘッドで大量のデータを保持します-Kafkaは大量のメッセージを保持および配信するように設計されています。（RabbitMQで非常に長いキューを計画している場合は、遅延キューを確認することができます。）

Kafkaは水平スケーリング（マシンの追加によるスケーリング）を念頭に置いてゼロから構築されていますが、RabbitMQは主に垂直スケーリング（電力の追加によるスケーリング）向けに設計されています。

RabbitMQには、WebブラウザーからRabbitMQサーバーを監視および処理できる組み込みのユーザーフレンドリーなインターフェースがあります。とりわけ、キュー、接続、チャネル、エクスチェンジ、ユーザー、ユーザー権限を処理することができます-作成、削除、ブラウザでの一覧表示、およびメッセージレートの監視とメッセージの送受信を手動で行うことができます。Kafkaには多数のオープンソースツールがあり、一部には商用のツールもあり、管理機能と監視機能を提供しています。RabbitMQをよく理解する方が簡単/速くなると思います。

詳細といくつかの比較データは、https：//www.cloudamqp.com/blog/2019-12-12-when-to-use-rabbitmq-or-apache-kafka.htmlにあります。

業界紙も推奨：「KafkaとRabbitMQの比較：2つの業界参照のパブリッシュ/サブスクライブ実装の比較研究」：http : //dl.acm.org/citation.cfm?id=3093908

私はサービスとしてApache KafkaとRabbitMQの両方を提供する会社で働いています。

私は毎週この質問を聞いています... RabbitMQ（IBM MQやJMSなどの一般的なメッセージングソリューションなど）は従来のメッセージングに使用されていますが、Apache Kafkaはストリーミングプラットフォーム（メッセージング+分散ストレージ+データの処理）として使用されています。どちらも異なるユースケース用に構築されています。

「従来のメッセージング」にはKafkaを使用できますが、Kafka固有のシナリオにはMQを使用できません。

記事「Apache KafkaとEnterprise Service Bus（ESB）の比較-友達、敵、またはフレネミー？（https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends-enemies-or-frenemies/）」は、カフカが競争力がないが統合およびメッセージングソリューションを補完する理由を説明しています（RabbitMQを含む）および両方を統合する方法。

5 KafkaとRabbitMQの主な違い：それらを使用しているお客様：

どのメッセージングシステムを選択するか、または既存のメッセージングシステムを変更する必要がありますか？

上記の質問に対する答えはありません。あなたがメッセージングシステムまたは既存のシステムを変更する必要があるかを決定する必要がある場合審査に1つの可能なアプローチは、「することですスコープとコストを評価します」

皆さんが忘れていた1つの重要な違いは、RabbitMQがプッシュベースのメッセージングシステムであるのに対し、Kafkaはプルベースのメッセージングシステムです。これは、メッセージングシステムが異なる処理機能を持つさまざまなタイプのコンシューマを満足させる必要があるシナリオで重要です。プルベースのシステムでは、コンシューマーは、プッシュシステムがコンシューマーの状態に関係なくメッセージをプッシュする機能に基づいて消費できるため、コンシューマーを高いリスクにさらします。

RabbitMQは、従来の汎用メッセージブローカーです。これにより、Webサーバーは要求にすばやく応答し、複数のサービスにメッセージを配信できます。パブリッシャーはメッセージをパブリッシュしてキューで使用できるようにすることで、コンシューマーがメッセージを取得できるようにします。通信は非同期または同期のいずれかです。

一方、Apache Kafkaは単なるメッセージブローカーではありません。メッセージキューとして機能するために、LinkedInによって最初に設計および実装されました。2011年以来、Kafkaはオープンソースであり、リアルタイムデータパイプラインとストリーミングアプリケーションの実装に使用される分散ストリーミングプラットフォームに急速に進化しています。

水平方向にスケーラブルで、フォールトトレラントで、高速で、数千の企業で運用されています。

現代の組織には、システムまたはサービス間の通信を容易にするさまざまなデータパイプラインがあります。適切な数のサービスがリアルタイムで相互に通信する必要がある場合、状況は少し複雑になります。

これらのサービスの相互通信を可能にするためにさまざまな統合が必要となるため、アーキテクチャは複雑になります。より正確には、m個のソースサービスとn個のターゲットサービスを含むアーキテクチャの場合、nxm個の異なる統合を作成する必要があります。また、すべての統合には異なる仕様が付属しているため、異なるプロトコル（HTTP、TCP、JDBCなど）または異なるデータ表現（バイナリ、Apache Avro、JSONなど）が必要になる可能性があり、事態はさらに困難になります。 。さらに、ソースサービスは、潜在的にレイテンシに影響を与える可能性がある接続からの増加した負荷に対処する場合があります。

Apache Kafkaは、データパイプラインを分離することで、よりシンプルで管理しやすいアーキテクチャを実現します。Kafkaは、ソースサービスがデータのストリームをプッシュする高スループットの分散システムとして機能し、ターゲットサービスがそれらをリアルタイムでプルできるようにします。

また、Kafkaクラスターを管理するための多くのオープンソースおよびエンタープライズレベルのユーザーインターフェイスが現在利用可能です。詳細については、私の記事を参照してください。ApacheKafkaクラスターのUI監視ツールの概要と「Apache Kafkaを選ぶ理由。

RabbitMQとKafkaのどちらを採用するかは、プロジェクトの要件によって決まります。一般に、シンプルで伝統的なpub-subメッセージブローカーが必要な場合は、RabbitMQを使用してください。イベント駆動型のアーキテクチャーを構築し、その上で組織がリアルタイムでイベントを処理する場合は、Apache Kafkaを使用してください。これにより、このアーキテクチャータイプ（Kafka StreamsやksqlDBなど）の機能が増えます。

私はそれが少し遅れていることを知っています、そしておそらくあなたはすでに間接的に言ったでしょう、しかし再び、カフカはまったくキューではなく、それはログです（誰かが上で述べたように、投票に基づいています）。

簡単にするために、RabbitMQ（または任意のキューテクノ）をKafkaよりも優先する必要がある最も明白な使用例は次のとおりです。

キューから消費する複数のコンシューマーがあり、キューに新しいメッセージがあり、使用可能なコンシューマーがある場合は常に、このメッセージを処理する必要があります。Kafkaがどのように機能するかをよく見ると、その方法が分からないことに気づくでしょう。パーティションのスケーリングのため、パーティション専用のコンシューマーが存在し、飢餓の問題が発生します。単純なキューテクノを使用することで簡単に回避できる問題。同じパーティションから異なるメッセージをディスパッチするスレッドを使用することを考えることができますが、Kafkaには選択的な確認応答メカニズムがありません。

あなたができることのほとんどは、それらの人としてやって、カフカをキューとして変換しようとすることです： https //github.com/softwaremill/kmq

ヤニック

次の場合にRabbitMQを使用します。

• Bigdataで処理する必要はなく、モニタリングには便利な組み込みのUIを好みます
• 自動的に複製可能なキューは不要
• メッセージのマルチサブスクライバーはありません-ログであるKafkaとは異なり、RabbitMQはキューであり、メッセージが消費され、確認が到着すると削除されます
• メッセージにワイルドカードと正規表現を使用する必要がある場合
• メッセージの優先度を定義することが重要な場合

簡単に言うと、RabbitMQは、データのトラフィックが少なく、優先キューと柔軟なルーティングオプションの利点がある単純なユースケースに適しています。大量のデータと高スループットには、Kafkaを使用します。

私は両方の経験に基づいて客観的な回答を提供します。すでに知っているか、他の回答で十分に提供されている場合は、それらの背後にある理論もスキップします。

RabbitMQ：私の要件が、チャネル/キューを介したシステム通信を処理するのに十分単純で、保持とストリーミングが要件でない場合は、これを選択します。たとえば、製造システムが資産を構築したとき、契約を構成するように同意システムに通知します。

Kafka：主にイベントソーシング要件。ストリーム（場合によっては無限）を処理する必要がある場合、大量のデータを一度に適切にバランスさせ、特定の状態を保証するためにオフセットを再生するなど。このアーキテクチャには、トピック、パーティション、ブローカー、墓石メッセージなどの概念がファーストクラスの重要性として含まれているため、より複雑になることにも注意してください。

私が考えることができる唯一の利点はトランザクション機能であり、残りはすべてカフカを使用して行うことができます

分散フォールトトレラントな方法で両方をスケーリングすることは困難ですが、RabbitMQを使用すると、大規模なスケールでははるかに困難になると私は主張します。Shovel、Federation、Mirrored Msg Queues、ACK、Memの問題、フォールトトレランスなどを理解するのは簡単なことではありません。KafkaのZookeeperなどで特定の問題も発生しないことは言うまでもありませんが、管理する可動部分が少なくなります。そうは言っても、RMQとのポリグロット交換は、カフカとは異なります。ストリーミングが必要な場合は、Kafkaを使用してください。シンプルなIoTまたは同様の大量のパケット配信が必要な場合は、Kafkaを使用してください。それはスマートな消費者についてです。より高いコストと、場合によってはある程度の複雑さで、メッセージの柔軟性と信頼性を高めたい場合は、RMQを使用してください。

複雑なルーティングのニーズがあり、組み込みGUIでブローカーを監視したい場合は、RabbitMQがアプリケーションに最適です。それ以外の場合、高スループットを処理し、ストリーム履歴へのアクセスを提供するメッセージブローカーを探している場合は、Kafkaを選択することをお勧めします。

Apache Kafkaは、データパイプラインを強化するための一般的な選択肢です。Apache kafkaは、一般的なetlの使用例をサポートするためにkafkaストリームを追加しました。KSQLを使用すると、パイプライン内のデータの変換が簡単になり、メッセージを別のシステムにクリーンに配置できます。KSQLは、Apache KafkaのストリーミングSQLエンジンです。JavaやPythonなどのプログラミング言語でコードを記述する必要なしに、Kafkaでのストリーム処理のための使いやすく強力なインタラクティブSQLインターフェイスを提供します。KSQLはスケーラブルで、弾力性があり、フォールトトレラントで、リアルタイムです。データのフィルタリング、変換、集約、結合、ウィンドウ処理、セッション化など、幅広いストリーミング操作をサポートしています。

https://docs.confluent.io/current/ksql/docs/index.html

Rabbitmqは、ETLシステムでは一般的な選択肢ではなく、スループットの低いシンプルなメッセージングシステムを必要とするシステムでは選択されます。

これは古い質問だと思いますが、RabbitMQの方が適しているシナリオの1つは、データの編集を処理するときです。

RabbitMQでは、デフォルトでメッセージが消費されると削除されます。Kafkaでは、デフォルトで、メッセージは1週間保持されます。これをはるかに長い時間に設定するか、削除しないこともよくあります。

どちらの製品もメッセージを保持する（または保持しない）ように構成できますが、CCPAまたはGDPRへの準拠が懸念される場合は、RabbitMQを使用します。

Kafkaは、スループット、耐久性、遅延の点でRabbitMQよりも優れています。10k /秒未満のトランザクションが予想される場合は、RabbitMQを使用できますが、これも実装によって異なります。

70k /秒を超えるトランザクションを処理していた製品にKafkaを実装しました。レイテンシは平均15ミリ秒で、スパイクが40ミリ秒に達することはほとんどありませんでした。トピックのサイズは100kbでした。

KAFKAとRabbitMQに関するPFBのより多くのデータポイント：Apache Kafkaにはブローカー自体が含まれています。ブローカー自体は実際に最もよく知られており、最も人気のある部分であり、ストリーム処理シナリオ向けに設計され、目立つように販売されています。これに加えて、Apache Kafkaは最近、Apache Spark、Apache Flink、Apache Beam / Google Cloud Data Flow、Spring Cloud Data Flowなどのストリーミングプラットフォームの代替として位置付けられるKafka Streamsを追加しました。このドキュメントは、ウェブサイトアクティビティトラッキング、メトリック、ログ集計、ストリーム処理、イベントソーシング、コミットログなどの一般的な使用例について適切に説明しています。説明するユースケースの1つはメッセージングであり、これにより混乱が生じる可能性があります。それでは、少しアンパックして、次のようにKafkaにとってどのメッセージングシナリオが最適かを明確にしてみましょう。

複雑なルーティングなしでAからBにストリーミングし、最大スループット（100k /秒+）で、少なくとも1回は分割された順序で配信されます。アプリケーションがストリーム履歴にアクセスする必要がある場合、パーティション化された順序で少なくとも1回配信されます。Kafkaは耐久性のあるメッセージストアであり、メッセージが配信されるとキューから削除される従来のメッセージブローカーとは異なり、クライアントはオンデマンドでイベントストリームの「リプレイ」を取得できます。ストリーム処理イベントソーシングRabbitMQは汎用のメッセージングソリューションであり、ユーザーが結果を待つ間、リソースを大量に消費する手順を強制的に実行するのではなく、Webサーバーが要求にすばやく応答できるようにするためによく使用されます。また、消費のために複数の受信者にメッセージを配信したり、高負荷（20k + /秒）の下でワーカー間で負荷を分散したりするのにも適しています。要件がスループットを超える場合、RabbitMQには、信頼性の高い配信、ルーティング、フェデレーション、HA、セキュリティ、管理ツール、その他の機能など、さまざまな機能があります。RabbitMQに最適なシナリオをいくつか見てみましょう。

アプリケーションは、AMQP 0-9-1、STOMP、MQTT、AMQP 1.0などの既存のプロトコルの任意の組み合わせで動作する必要があります。メッセージごとに細かい整合性制御/保証（デッドレターキューなど）が必要です。しかし、Kafkaは最近、トランザクションのサポートを改善しました。アプリケーションには、ポイントツーポイント、要求/応答、およびパブリッシュ/サブスクライブメッセージングの多様性が必要です。コンシューマーへの複雑なルーティング、複数のサービス/アプリを重要なルーティングロジックと統合する追加のソフトウェアのヘルプ。RabbitMQは、アプリケーションがストリーム履歴にアクセスする必要がある場合、または「無限」キューを必要とするアプリケーションのLevelDBプラグインとともにApache Cassandraでよく使用されますが、どちらの機能もRabbitMQ自体には付属していません。

短い答えは「メッセージの確認」です。RabbitMQは、メッセージの確認を要求するように構成できます。受信者が失敗した場合、メッセージはキューに戻り、別の受信者が再試行できます。これは独自のコードを使用してKafkaで実現できますが、RabbitMQでそのまま使用できます。

私の経験では、情報のストリームを照会する必要があるアプリケーションがある場合、KafkaとKSqlが最善の策です。キューシステムが必要な場合は、RabbitMQを使用することをお勧めします。

最も投票された回答はほとんどの部分をカバーしていますが、ユースケースの観点を強調しておきたいと思います。kafkaはrabbit mqでできることを実行できます。答えはyesですが、rabbit mqはkafkaが行うすべてのことを実行できます。それで、rabbit mqがkafkaを区別できないことは何ですか、それは分散メッセージ処理です。これで、最も投票された回答が読み返されます。詳細については、facebookの「いいね」など、超高スループットのメッセージングシステムを作成する必要があるユースケースを取り上げ、そのためにrabbit mqを選択したとします。エクスチェンジとキュー、およびすべてのパブリッシャー（この場合はFBユーザー）が「いいね」メッセージをパブリッシュできるコンシューマーを作成しました。スループットが高いので、コンシューマーで複数のスレッドを作成してメッセージを並行して処理しますが、コンシューマーが実行されているマシンのハードウェア容量によって制限されます。1つのコンシューマーがすべてのメッセージを処理するのに十分ではないと仮定すると、何をしますか？キューにもう1つのコンシューマーを追加できますか？それはできません。新しいキューを作成し、そのキューをバインドして「いいね」のメッセージを公開する交換を行うことはできますか。答えは、メッセージが2回処理される原因ではありません。それがカフカが解決する中心的な問題です。これにより、互いに対話する分散パーティション（rabbit mqのキュー）と分散コンシューマーを作成できます。これにより、トピック内のメッセージが、さまざまなノード（マシン）に分散されたコンシューマーによるプロセスを確実に取得します。Kafkaブローカーは、メッセージがそのトピックのすべてのパーティション間で負荷分散されるようにします。コンシューマーグループは、すべてのコンシューマーが互いに対話し、メッセージが2回処理されないことを確認します。しかし、実際には、スループットが非常に高くない限り、この問題に直面することはありません。なぜなら、rabbit mqは、1人の消費者でも非常に高速にデータを処理できるからです。