一般的なメッセージミドルウェアの比較

1. Kafka、RabbitMQおよびRedisメッセージミドルウェアの比較

分散システムでは、システム間のデータ交換にメッセージミドルウェアがよく利用され
、実際の業務需要シナリオや運用・保守コストに応じて、お客様に合った製品をお選びいただけます。

2.関連概念の紹介

• Kafka
  1.メッセージの消費を処理するプルモードに基づく
  2.高スループットを追求する
  3.最初の目的はログの収集と送信を目的とする
  4.0.8バージョンはレプリケーションをサポートし始めた、トランザクションをサポートしない、メッセージの重複、損失、エラーは厳密ではない大量のデータを生成するインターネットサービスを必要とし、それに適したデータ収集ビジネス。

• RabbitMQ
  RabbitMQは、Erlang言語を使用して開発され、AMQPプロトコルに基づいて実装されたオープンソースのメッセージキューイングシステムです。AMQP1.
  の主な機能は
  、メッセージ指向、キューイング、ルーティング（ピアツーピアおよびパブリッシュ/サブスクライブを含む）、信頼性、およびセキュリティです。
  2. AMQPプロトコルはエンタープライズシステムでより多く使用されており、高いデータの一貫性、安定性、および信頼性を必要とするシナリオ、およびパフォーマンスとスループットの要件が2番目です。
  主に使用されます：ダボフレームワーク（zookeeperは登録センターに使用されます）、春の雲など。

• Redis
  Redisは、キーと値のペアに基づくNoSQLデータベースであり、開発とメンテナンスに非常に積極的です。
  キーと値のデータベースストレージシステムですが、それ自体がMQ関数をサポートしているため、軽量キューサービスとして使用できます。

3.機能比較

1.アプリケーションシナリオの観点から、
RabbitMQはAMQPプロトコルに準拠し、内部同時実行性が高いアーラン言語によって開発され、高い信頼性要件を備えたリアルタイムメッセージングに使用されます。

Kafkaは2010年12月のLinkedinのオープンソースメッセージサブスクリプションシステムです。主に、ライブストリーミングデータと大量のデータを処理するために使用されます。

2.アーキテクチャモデルでは、
RabbitMQはAMQPプロトコルに従います。RabbitMQのブローカーはExchange、Binding、およびキューで構成され、交換とバインディングがメッセージのルーティングキーを形成します。クライアントプロデューサーはチャネルとサーバーを接続して通信し、コンシューマーはキューからメッセージを取得します。消費（長い接続、キューメッセージはコンシューマ側にプッシュされます。コンシューマは入力ストリームからループでデータを読み取ります）。rabbitMQはブローカーを中心にしており、メッセージ確認メカニズムがあります。

Kafkaは一般的なMQ構造、プロデューサー、ブローカー、コンシューマー、コンシューマーを中心として準拠しています。メッセージコンシューマー情報のコンシューマー情報が保存され、コンシューマーは消費ポイントに従ってブローカーからバルクデータをプルします。メッセージ確認メカニズムはありません。

3.
スループットに関して、Kafkaは高スループット、メッセージの内部バッチ処理、ゼロコピーメカニズム、データの保存と取得はローカルディスクの順次バッチ操作であり、O（1）複雑さ、メッセージ処理の効率とても高い。
RabbitMQは、スループットの点でkafkaよりもわずかに劣っています。開始点は異なります。rabbitMQは、メッセージの信頼できる配信をサポートし、トランザクションをサポートし、バッチ操作をサポートしていません。ストレージ要件の信頼性に基づいて、ストレージはメモリまたはハードディスクを使用できます。

4.可用性の観点から、
RabbitMQはミラーのキューをサポートし、メインキューは無効で、ミラーキューは
kafkaのブローカーを引き継ぎ、アクティブモードとスタンバイモードをサポートします。

5.クラスターの負荷分散に関して、
kafkaはzookeeperを使用してクラスター内のブローカーとコンシューマーを管理し、トピックをzookeeperに登録できます。zookeeperの調整メカニズムにより、プロデューサーは対応するトピックのブローカー情報を保存します。ブローカー情報はランダムに、またはポーリングしてブローカーに送信できます。 ;そして、プロデューサーはセマンティクスに基づいてシャードを指定でき、メッセージはブローカーのシャードに送信されます。
RabbitMQのロードバランシングでは、それをサポートするために別のロードバランサーが必要です。

4、アプリケーションシナリオ

Rabbitmqはkafkaよりも信頼性が高く、
Kafkaは高IOスループット処理に適しています。たとえば、ELKログコレクションKafkaとRabbitMqは、汎用メッセージブローカーです。これらはすべて分散展開用です。しかし、メッセージセマンティックモデルの定義に関する彼らの仮定は非常に異なります。

• 次のシナリオでは、Kafkaを使用する方が適しています。多数のイベント（1秒あたり100,000を超える）があり、オンラインでの消費とパッケージ化された消費を混在させるコンシューマーへの配信を少なくとも1回、連続して分割する必要があり、メッセージを再読み込みできるようにしたい。ノードレベルは高可用性であるか、フォーラムやIRCツールを介してまだ幼児向けのソフトウェアからサポートを受けてもかまいません。

• 次のシナリオでは、RabbitMQを使用する方が適しています。イベント数が少なく（20,000 /秒を超え）、複雑なルーティングロジックを通じてコン​​シューマーを見つける必要があり、メッセージ配信の信頼性を確保する必要がある、メッセージ配信の順序を気にしない、クラスターノードをサポートする必要がある高レベルの可用性、または7 * 24時間の有償サポートが必要（もちろん、フォーラム/ IRCツールを使用することもできます）

• Redisメッセージプッシュ（分散パブ/サブに基づく）は、主にリアルタイムメッセージプッシュに使用され、信頼性は保証されません

Redisメッセージプッシュ（分散pub / subに基づく）は主にリアルタイムメッセージプッシュに使用され、信頼性は保証されません。他のmqとkafkaは信頼できることが保証されていますが、多少の遅延があります（非リアルタイムシステムは遅延を保証しません）。Redis-pub / subは電源がオフになると空になり、メッセージプッシュとしてのredis-listの使用は持続しますが、完全に信頼できるわけではなく、失われることはありません。

• Redisはインメモリデータベースです！Redisの父親がDisqueを実行しました。それを試しますか？mqは、通常、サブスクリプションパブリッシュモデルを使用します。パフォーマンスを考慮する場合、主な焦点は、消費モデルがプルかプッシュかです。最も影響力のあるのはストレージ構造です。Kafkaのパフォーマンスは、トピックの数が64未満の場合にのみ効果的です。パーティションによって決定されます。極端なケースでのメッセージの損失（例：マスターがメッセージを書き込んだ後、ホストマシンがダウンし、ハードディスクが破損している）