17 の側面、4 つの分散メッセージ キュー (Kafka、RabbitMQ、RocketMQ、ActiveMQ) の包括的な比較

• 1. データの文書化
• 2. 開発言語
• 3. サポートされているプロトコル
• 4. メッセージの保存
• 5. ニュース
• 6. 負荷分散
• 7. クラスターモード
• 8. 管理インターフェース
• IX.可用性
• 10. メッセージの重複
• 11. スループットTPS
• 12. 購読フォームとメッセージ配信
• 13. 連続メッセージ
• 14. メッセージの確認
• 15. メッセージのバックトラッキング
• 16. メッセージの再試行
• 17. 並行性

[[265873]]

この記事では、メッセージ キューとして使用される場合の Kafka、RabbitMQ、ZeroMQ、RocketMQ、ActiveMQ の違いを 17 の側面から比較します。

1. データの文書化

カフカ：中程度。カフカ本人が書いた本もありますし、インターネット上にも情報があります。 rabbitmq: 複数。良い本がいくつかあり、オンライン上に多くの情報があります。 zeromq: 少ないです。 zeromq について具体的に書かれた本はありません。インターネット上の情報のほとんどは、コードの実装と簡単な紹介です。 rocketmq: 少ないですね。 RocketMQ について具体的に書かれた本はありません。インターネット上の情報は質がさまざまです。公式ドキュメントは非常に簡潔ですが、技術的な詳細は詳しく説明されていません。 activemq: 複数。 ActiveMQ について具体的に書かれた本はありませんが、インターネット上には多くの情報があります。

2. 開発言語

Kafka: Scala rabbitmq: Erlang zeromq: c rocketmq: java activemq: java

3. サポートされているプロトコル

Kafka: 自己定義セット... (TCP ベース) rabbitmq: AMQP zeromq: TCP、UDP rocketmq: 自己定義セット... activemq: OpenWire、STOMP、REST、XMPP、AMQP

4. メッセージの保存

Kafka: メモリ、ディスク、データベース。大量積み重ねにも対応します。

Kafka の最小のストレージ単位はパーティションです。トピックには複数のパーティションが含まれます。 Kafka がトピックを作成すると、これらのパーティションは複数のサーバーに割り当てられます (通常はサーバーごとに 1 つのブローカー)。パーティション リーダーは異なるサーバーに均等に分散され、パーティション レプリカも異なるサーバーに均等に分散されるため、負荷分散と高可用性が確保されます。新しいブローカーがクラスターに参加すると、一部のレプリカが新しいブローカーに移動されます。設定ファイル内のディレクトリ リストに基づいて、Kafka はディレクトリ リスト内のパーティション数が最も少ないディレクトリに新しいパーティションを割り当てます。デフォルトでは、パーティショナーはラウンドロビン アルゴリズムを使用して、同じトピックの異なるパーティション間でメッセージを均等に分散します。送信時にキーが指定されると、キーのハッシュコードを法とする値が対応するパーティションに保存されます。

rabbitmq: メモリ、ディスク。少量の積み重ねをサポートします。

RabbitMQ メッセージは、永続メッセージと非永続メッセージに分けられます。永続メッセージと非永続メッセージの両方をディスクに書き込むことができます。永続メッセージはキューに到着するとディスクに書き込まれ、可能であれば永続メッセージのコピーもメモリに保存されます。これにより、パフォーマンスがある程度向上し、メモリが不足するとメモリからクリアされます。非永続メッセージは通常、メモリ内にのみ存在し、メモリが不足している場合はメモリを節約するためにディスクにスワップされます。

ミラー キュー メカニズムを導入すると、重要なキューをクラスター内の他のブローカーに「コピー」して、これらのキュー内のメッセージが失われないようにすることができます。ミラーリングが構成されたキューには、マスター ノードと複数のスレーブ ノードが含まれます。マスターに障害が発生した場合、最も長い時間参加していたスレーブが新しい​​マスターに昇格されます。メッセージの送信を除くすべてのアクションはマスターに送信され、その後、マスターはコマンドの実行結果を各スレーブにブロードキャストします。 RabbitMQ はマスターを異なるサーバーに均等に分散し、同じキューのスレーブも異なるサーバーに均等に分散して、負荷分散と高可用性を確保します。

zeromq: メッセージは送信者のメモリまたはディスクに保存されます。永続性はサポートされていません。

rocketmq:ディスク。大量積み重ねにも対応します。

commitLog ファイルには実際のメッセージ データが保存されます。各 commitLog の上限は 1G です。いっぱいになると、データを保存するために新しい commitLog ファイルが自動的に作成されます。 ConsumeQueue キューには、オフセット、サイズ、タグコードのみが格納されます。これらは非常に小さく、複数のブローカーに分散されます。 ConsumeQueue は CommitLog のインデックス ファイルに相当します。消費時に、コンシューマーは、consumeQueue から commitLog でメッセージのオフセットを探し、次に commitLog でメタデータを探します。

ConsumeQueue ストレージ形式の特性により、書き込みプロセスがディスクに順番に書き込まれる (CommitLog ファイルに書き込まれる) ことが保証されます。大量のデータIOは同じcommitLogに順次書き込まれ、1Gいっぱいになると新しいものが書き込まれます。さらに、RocketMQ は合計量が 4K に達した場合にのみ PageCache からディスク (キャッシュ) へのフラッシュを強制するため、高同時書き込みパフォーマンスが抜群です。

activemq: メモリ、ディスク、データベース。少量の積み重ねをサポートします。

5. ニュース

Kafka: サポートされています。 RabbitMQ: サポートされています。クライアントはチャネルをトランザクション モードに設定します。メッセージが rabbitMq によって受信された場合にのみトランザクションは正常にコミットされます。それ以外の場合は、例外をキャッチした後にロールバックされます。トランザクションを使用するとパフォーマンスが低下します ZeroMQ: サポートされていません RocketMQ: サポートされています ActiveMQ: サポートされています

6. 負荷分散

Kafka: 負荷分散をサポートします。

1>ブローカーは通常、サーバー ノードです。同じトピックの異なるパーティションについては、Kafka はこれらのパーティションを異なるブローカー サーバーに分散するように最善を尽くします。 Zookeeper はブローカー、トピック、パーティションのメタデータ情報を保存します。パーティション リーダーは、クライアントからの生成要求を処理します。 Kafka パーティション リーダーは異なるブローカー サーバーに割り当てられ、異なるブローカー サーバーがタスクを共有できるようになります。

各ブローカーはメタデータ情報をキャッシュします。クライアントは任意のブローカーからメタデータ情報を取得してキャッシュし、メタデータ情報に基づいてリクエストを送信する場所を知ることができます。

2> Kafka のコンシューマー グループは同じトピックをサブスクライブし、負荷を分散するために各コンシューマーを同じ数のパーティションに割り当てようとします。

3> コンシューマーがコンシューマー グループに参加または離脱すると、再バランス調整がトリガーされ、各コンシューマーにパーティションが再割り当てされ、負荷が分散されます。

Kafka の負荷分散は大部分が自動で行われ、パーティションの作成も Kafka によって行われるため、多くの詳細が隠され、面倒な構成や人的過失による負荷の問題が回避されます。

4> 送信者はトピックとキーを使用して、メッセージが送信されるパーティションを決定します。キーが null の場合、ポーリング アルゴリズムを使用して、同じトピックの異なるパーティションにメッセージが均等に送信されます。キーが null でない場合、データが送信されるパーティションは、キーのハッシュコードの係数に基づいて計算されます。

rabbitmq: 負荷分散のサポートは良くありません。

1>メッセージが配信されるキューは、スイッチとキーによって決まります。スイッチ、ルーティング キー、キューはすべて手動で作成する必要があります。

rabbitmq クライアントは、メッセージを送信するためにブローカーとの接続を確立する必要があり、ブローカー上にあるスイッチとキューを事前に認識している必要があります。通常、送信先のターゲット キューを宣言する必要があります。ターゲット キューが存在しない場合は、ブローカー上にキューが作成されます。存在する場合、何も処理されず、メッセージはこのキューに送信されます。負荷の高いタスク キューのほとんどが同じブローカー上に作成されると仮定すると、このブローカーの負荷が大きくなりすぎます。 (オンラインになる前に、送信するキューを宣言せずにキューを事前に作成することはできますが、送信時にキューを作成する試みは行われず、キューが見つからないという問題が発生する可能性があります。RabbitMQ のバックアップ エクスチェンジャーは、キューが見つからないメッセージを専用のキューに保存し、後でクエリして使用できるようにします)

ミラー キュー メカニズムを使用して RabbitMQ クラスターを確立すると、この問題を解決し、マスター スレーブ アーキテクチャを形成できます。マスター ノードは異なるサーバーに均等に分散され、各サーバーが負荷を分散できるようになります。スレーブ ノードは転送のみを担当します。マスターに障害が発生した場合、最も長い時間接続されていたスレーブがマスターとして選択されます。

新しいノードがミラーリングされたキューに参加すると、同期コマンドが呼び出されない限り、キュー内のメッセージは新しいスレーブに同期されません。ただし、コマンドが呼び出された後、キューがブロックされ、実稼働環境では同期コマンドを呼び出すことができなくなります。

2> RabbitMQ キューに複数のコンシューマーがある場合、キューで受信されたメッセージはラウンドロビン方式でコンシューマーに送信されます。各メッセージはサブスクリプション リスト内の 1 人の消費者にのみ送信され、重複して送信されることはありません。

このアプローチはスケーラビリティに非常に適しており、並行プログラム用に特別に設計されています。

一部のコンシューマーに負荷の高いタスクがある場合は、basicQos を設定して、コンシューマーがチャネルに保持できる未確認メッセージの最大数を制限できます。上限に達すると、rabbitmq はこのコンシューマーにメッセージを送信しなくなります。

3>RabbitMQ の場合、クライアントとクラスター間で確立される TCP 接続は、クラスター内のすべてのノードとの接続を確立するのではなく、いずれかのノードを選択して接続を確立します。

ただし、RabbitMQ クラスターは、HAProxy、LVS テクノロジーを使用したり、クライアント上のアルゴリズムを使用して負荷分散を実現したりできます。負荷分散を導入すると、各クライアントの接続をクラスター内の各ノードに分散できるようになります。

クライアントバランシングアルゴリズム:

1) 投票方法。次のサーバーの接続アドレスを返します。

2) 加重ラウンドロビン方式。構成が高く負荷が低いマシンに高い重みを割り当てて、より多くのリクエストを処理できるようにします。構成が低く負荷が高いマシンに低い重みを割り当てて、システム負荷を軽減します。

3) ランダム法。サーバー接続アドレスをランダムに選択します。

4) 加重ランダム法。接続アドレスは確率に応じてランダムに選択されます。

5) 送信元アドレスのハッシュ方式。ハッシュ関数によって計算された値。サーバー リストのサイズに対してモジュロ演算を実行するために使用されます。

6) 最小接続数方式。現在の接続数が最も少ないサーバーの接続アドレスを動的に選択します。

zeromq: 分散型で、負荷分散をサポートしていません。これは単なるマルチスレッド ネットワーク ライブラリです。

rocketmq: 負荷分散をサポートします。

ブローカーは通常、サーバー ノードです。ブローカーはマスターとスレーブに分かれています。マスターとスレーブは同じデータを保存し、スレーブはマスターからのデータを同期します。

1>ネームサーバーは各クラスターメンバーとのハートビートを維持し、トピックブローカーのルーティング情報を保存します。同じトピックのキューは異なるサーバーに分散されます。

2> メッセージはポーリング キューによって送信され、各キューは平均量のメッセージを受信します。メッセージを送信する際には、トピック、タグ、キーを指定しますが、どのキューに配信するかは指定できません (クラスターの消費とブロードキャストの消費は、メッセージがどのキューに格納されるかとは関係がないため、意味がありません)。

タグはオプションで、Gmail が各メールに設定するタグに似ており、サーバーのフィルタリングに便利です。現在、各メッセージに対して 1 つのタグのみがサポートされているため、Notify の MessageType 概念と比較することもできます。

キーはオプションであり、このメッセージのビジネス キーワードを表します。サーバーはキーに基づいてハッシュ インデックスを作成します。設定後、コンソール システムでトピックとキーに基づいてメッセージを照会できます。ハッシュインデックスなので、注文番号や商品IDなど、キーはできる限り一意となるようにしてください。

3>RocketMQ の負荷分散戦略では、コンシューマーの数がキューの数以下になるように規定されています。コンシューマーの数がキューの数を超えると、超過分のコンシューマーはメッセージを消費できなくなります。これはカフカと一致しています。 RocketMQ は、負荷を分散するために、各コンシューマーに同じ数のキューを割り当てるように最善を尽くします。

activemq: 負荷分散をサポートします。 Zookeeper に基づいて負荷分散を実現できます。

7. クラスターモード

Kafka: 各サーバーがマスターとスレーブの両方である、自然な「リーダー スレーブ」ステートレス クラスター。

パーティション リーダーは異なる Kafka サーバーに均等に分散され、パーティション レプリカも異なる Kafka サーバーに均等に分散されます。したがって、各 Kafka サーバーにはパーティション リーダーとパーティション レプリカの両方が含まれます。各 Kafka サーバーは、特定の Kafka サーバーのスレーブであり、特定の Kafka サーバーのリーダーでもあります。

Kafka のクラスターは、ホット拡張をサポートする Zookeeper に依存しています。すべてのブローカー、コンシューマー、パーティションは、サービスをシャットダウンすることなく動的に追加および削除できます。これは、Zookeeper クラスターに依存しない MQ と比較して大きな利点です。

RabbitMQ: シンプルなクラスタリングと「レプリケーション」モードをサポートしますが、高度なクラスタリング モードは適切にサポートされていません。

RabbitMQ の各ノードは、単一ノード システムであるかクラスターの一部であるかに関係なく、メモリ ノードまたはディスク ノードのいずれかです。クラスター内の少なくとも 1 つのノードはディスク ノードである必要があります。

RabbitMQ クラスターでキューを作成する場合、クラスターはすべてのノードではなく、単一のノードにのみキュー プロセスと完全なキュー情報 (メタデータ、ステータス、コンテンツ) を作成します。

ミラーリングされたキューを導入すると、単一障害点を回避し、サービスの可用性を確保できますが、一部の重要なキューについてはミラーを手動で構成する必要があります。

zeromq: 分散型で、クラスタリングをサポートしていません。

rocketmq: 一般的には複数のペアの「マスター-スレーブ」モードが使用されますが、オープンソース版ではスレーブからマスターへの手動切り替えが必要です。

ネーム サーバーは、ノード間で情報を同期することなくクラスターに展開できる、ほぼステートレスなノードです。

ブローカーの展開は比較的複雑です。ブローカーはマスターとスレーブに分かれています。マスターは複数のスレーブに対応できますが、スレーブは 1 つのマスターにのみ対応できます。マスターとスレーブ間の対応は、同じ BrokerName と異なる BrokerId を指定することによって定義されます。 BrokerId 0 はマスターを示し、0 以外はスレーブを示します。複数のマスターを展開することもできます。各ブローカーは、ネーム サーバー クラスター内のすべてのノードとの永続的な接続を確立し、すべてのネーム サーバーにトピック情報を定期的に登録します。

プロデューサーは、ネーム サーバー クラスター内のノードの 1 つ (ランダムに選択) と永続的な接続を確立し、ネーム サーバーからトピック ルーティング情報を定期的に取得し、トピック サービスを提供するマスターと永続的な接続を確立し、マスターにハートビートを定期的に送信します。プロデューサーは完全にステートレスであり、クラスターにデプロイできます。

コンシューマーは、ネーム サーバー クラスター内のノードの 1 つ (ランダムに選択) と永続的な接続を確立し、ネーム サーバーからトピック ルーティング情報を定期的に取得し、トピック サービスを提供するマスター ノードとスレーブ ノードと永続的な接続を確立し、マスター ノードとスレーブ ノードにハートビートを定期的に送信します。コンシューマーはマスターとスレーブの両方からのメッセージをサブスクライブできます。サブスクリプション ルールはブローカーの構成によって決まります。

クライアントは最初にネームサーバーを見つけ、次にネームサーバーを通じてブローカーを見つけます。

トピックには複数のキューがあり、それらは異なるブローカー サーバーに均等に分散されます。 RocketMQ キューの概念は、基本的に Kafka パーティションの概念と同じです。 Kafka の同じトピックのパーティションは可能な限り異なるブローカーに分散され、パーティションのレプリカも異なるブローカーに分散されます。

rocketmq クラスターのスレーブはマスターからデータのバックアップを取得し、マスターは異なるブローカーに分散されます。

ActiveMQ: 「マスター/スレーブ」などの単純なクラスター モードをサポートしますが、高度なクラスター モードは適切にサポートされません。

8. 管理インターフェース

Kafka: 平均 rabbitmq: 良好 zeromq: いいえ rocketmq: いいえ activemq: 平均

IX.可用性

Kafka: 非常に高い (分散)、rabbitmq: 高い (マスタースレーブ)、zeromq: 高い。 rocketmq: 非常に高い (分散) activemq: 高い (マスタースレーブ)

10. メッセージの重複

Kafka: 少なくとも1回、最大1回をサポート

rabbitmq: 少なくとも 1 回、最大 1 回をサポートします

zeromq: 再送信メカニズムのみがあり、永続性はありません。メッセージが失われた場合、再送信は無意味です。少なくとも 1 回、最大で 1 回、または正確に 1 回のみということはありません。

RocketMQ: 少なくとも1回はサポート

ActiveMQ: 少なくとも1回はサポート

11. スループットTPS

Kafka: Kafka はメッセージをバッチで送信および消費します。送信者は複数の小さなメッセージを結合し、ブローカーに一括して送信します。コンシューマーは一度に 1 つのバッチのメッセージを取り出し、バッチで処理します。 rabbitmq: 比較的大きい zeromq: 非常に大きい rocketmq: 大きい rocketMQ の受信側はメッセージをバッチで消費し、消費するメッセージの数を毎回設定できますが、送信側はメッセージをバッチで送信しません。 ActiveMQ: 大規模

12. 購読フォームとメッセージ配信

Kafka: トピックに基づくパブリッシュ/サブスクライブ モードと、トピックに応じた定期的なマッチング。

【送信】

送信者はトピックとキーを使用して、メッセージがどのパーティションに送信されるかを決定します。キーが null の場合、ポーリング アルゴリズムを使用して、同じトピックの異なるパーティションにメッセージが均等に送信されます。キーが null でない場合、データが送信されるパーティションは、キーのハッシュコードの係数に基づいて計算されます。

【引き継ぐ】

1>コンシューマーは、グループとの提携関係とパーティションの所有権を維持するために、グループ コーディネーター ブローカーにハートビートを送信します。所有権が割り当てられると、再調整が発生しない限り (たとえば、消費者が消費者グループに参加したり、消費者グループから脱退したりする場合)、所有権は変更されません。コンシューマーは対応するパーティションからのメッセージのみを読み取ります。

2>Kafka では、コンシューマーの数がパーティションの数よりも少なくなるように制限されています。各メッセージは、同じコンシューマー グループ内の 1 つのコンシューマーによってのみ消費されます (非ブロードキャスト)。

3> Kafka の Consumer Group は同じトピックをサブスクライブし、各 Consumer に同じ数のパーティションを割り当てようとします。異なるコンシューマー グループが同じトピックを個別にサブスクライブし、同じメッセージが異なるコンシューマー グループによって処理されます。

rabbitmq: ダイレクト、トピック、ヘッダー、ファンアウトの 4 つのタイプを提供します。

【送信】

まず、キューを宣言する必要があります。このキューは作成されるか、すでに作成されています。キューは基本的なストレージ ユニットです。

交換とキーによって、メッセージがどのキューに格納されるかが決まります。

direct>bindingKeyと完全に一致するキューに送信します。

トピック> ルーティング キーは「.」を含む文字列であり、あいまい一致のために「*」と「#」を含む bingKey に対応するキューに送信されます。

ファンアウトはキーとは関係なく、交換にバインドされたすべてのキューに送信されます。

headers> はキーとは関係ありません。メッセージ コンテンツのヘッダー属性 (キーと値のペア) とバインディングのキーと値のペアが完全に一致すると、このキューに送信されます。この方法はパフォーマンスが低いため、一般的には使用されません。

【引き継ぐ】

RabbitMQ のキューは基本的なストレージ ユニットであり、パーティション分割やシャーディングは行われません。作成したキューの場合、コンシューマーはどのキューからメッセージを受信するかを指定する必要があります。

RabbitMQ キューに複数のコンシューマーがある場合、キューによって受信されたメッセージはラウンドロビン方式でコンシューマーに送信されます。各メッセージはサブスクリプション リスト内の 1 人の消費者にのみ送信され、重複して送信されることはありません。

このアプローチはスケーラビリティに非常に適しており、並行プログラム用に特別に設計されています。

一部のコンシューマーに負荷の高いタスクがある場合は、basicQos を設定して、コンシューマーがチャネルに保持できる未確認メッセージの最大数を制限できます。上限に達すると、rabbitmq はこのコンシューマーにメッセージを送信しなくなります。

zeromq: ピアツーピア (p2p)

rocketmq: トピック/メッセージタグに基づくパブリッシュ/サブスクライブ モードと、メッセージ タイプと属性に応じた定期的なマッチング

【送信】

メッセージはポーリング キューによって送信され、各キューは平均量のメッセージを受信します。メッセージを送信する際には、トピック、タグ、キーを指定しますが、どのキューに配信するかは指定できません (クラスターの消費とブロードキャストの消費は、メッセージがどのキューに格納されるかとは関係がないため、意味がありません)。

タグはオプションで、Gmail が各メールに設定するタグに似ており、サーバーのフィルタリングに便利です。現在、各メッセージに対して 1 つのタグのみがサポートされているため、Notify の MessageType 概念と比較することもできます。

キーはオプションであり、このメッセージのビジネス キーワードを表します。サーバーはキーに基づいてハッシュ インデックスを作成します。設定後、コンソール システムでトピックとキーに基づいてメッセージを照会できます。ハッシュインデックスなので、注文番号や商品IDなど、キーはできる限り一意となるようにしてください。

【引き継ぐ】

1> 放送消費。メッセージは複数のコンシューマーによって消費されます。コンシューマーが同じ ConsumerGroup に属している場合でも、メッセージは ConsumerGroup 内の各コンシューマーによって 1 回消費されます。

2>クラスターの消費。コンシューマー グループ内のコンシューマー インスタンスは、消費メッセージを均等に配布します。たとえば、トピックに 9 つのメッセージがあり、コンシューマー グループに 3 つのインスタンスがある場合、各インスタンスは 3 つのメッセージのみを消費します。つまり、各キューはメッセージを各コンシューマーに順番に配布します。

ActiveMQ: ピアツーピア (p2p)、ブロードキャスト (パブリッシュ/サブスクライブ)

ポイントツーポイント モードでは、各メッセージには 1 つのコンシューマーのみがあります。

パブリッシュ/サブスクライブ モードでは、各メッセージに複数のコンシューマーを設定できます。

【送信】

ポイントツーポイント モード: まず、作成するキューまたは作成済みのキューを指定します。

パブリッシュ/サブスクライブ モード: 最初に、作成するトピックまたは作成済みのトピックを指定します。

【引き継ぐ】

ポイントツーポイント モード: 作成されたキューに対して、コンシューマーはメッセージを受信するキューを指定する必要があります。

パブリッシュ/サブスクライブ モード: 作成されたトピックの場合、コンシューマーはサブスクライブするトピックのメッセージを指定する必要があります。

13. 連続メッセージ

Kafka: サポートされています。

プロデューサーの max.in.flight.requests.per.connection を 1 に設定すると、再試行が発生した場合でも、メッセージが送信された順序でサーバーに書き込まれるようになります。

Kafkaは同じパーティション内のメッセージが順序付けられることを保証しますが、この順序は2つの状況に分かれています。

1>キーがnullの場合、メッセージは異なるホストのパーティションに1つずつ書き込まれますが、各パーティションごとに順序付けられます。

2>キーが null でない場合、メッセージは同じパーティションに書き込まれ、このパーティション内のメッセージは順序付けられます。

RabbitMQ: サポートされていません

zeromq: サポートされていません

rocketmq: サポート

ActiveMQ: サポートされていません

14. メッセージの確認

Kafka: サポートされています。

1>送信者確認メカニズム

メッセージがパーティションに正常に書き込まれたかどうかに関係なく、ack=0

ack=1、メッセージがリーダーパーティションに正常に書き込まれた後、成功を返します。

ack=all の場合、メッセージがすべてのパーティションに正常に書き込まれた後、成功が返されます。

2> 受信者確認メカニズム

パーティション オフセットを自動または手動で送信します。 Kafka の初期バージョンでは、オフセットは Zookeeper に送信されていたため、Zookeeper に大きな負担がかかっていました。新しいバージョンの Kafka では、オフセットは Kafka サーバーに送信され、Zookeeper グループに依存しなくなりました。クラスターのパフォーマンスがより安定します。

rabbitmq: サポートされています。

1>送信者確認メカニズムでは、メッセージがすべての一致するキューに配信された後、成功が返されます。メッセージとキューが永続的である場合、ディスクへの書き込み後に成功が返されます。バッチ確認と非同期確認をサポートします。

2> 受信者の確認メカニズム、autoAck を false に設定すると明示的な確認が必要になり、autoAck を true に設定すると自動確認になります。

autoAck が false の場合、rabbitmq キューは 2 つの部分に分割されます。1 つはコンシューマーに配信されるのを待機しているメッセージで、もう 1 つは配信されたが確認を受け取っていないメッセージです。確認信号が受信されず、コンシューマーが切断された場合、RabbitMQ はメッセージをキューに再度入れ、元のコンシューマーまたは次のコンシューマーに配信するように手配します。

未確認メッセージには有効期限はありません。確認がなく、接続が切断されない場合、RabbitMQ は待機し続けます。 RabbitMQ では、メッセージを非常に長い時間処理できます。

zeromq: サポートされています。

rocketmq: サポートされています。

activemq: サポートされています。

15. メッセージのバックトラッキング

Kafka: 指定されたパーティション オフセット位置のバックトラックをサポートします。 RabbitMQ: サポートされていません。ZeroMQ: サポートされていません。RocketMQ: 指定された時点でのバックトラッキングをサポートします。 ActiveMQ: サポートされていません

16. メッセージの再試行

Kafka: サポートされていませんが可能です。

Kafka は、指定されたパーティション オフセット位置のバックトラックをサポートしており、これによりメッセージの再試行を実装できます。

RabbitMQ: サポートされていませんが、メッセージ確認メカニズムを使用して実装できます。

RabbitMQ 受信者確認メカニズム、autoAck を false に設定します。

autoAck が false の場合、rabbitmq キューは 2 つの部分に分割されます。1 つはコンシューマーに配信されるのを待機しているメッセージで、もう 1 つは配信されたが確認を受け取っていないメッセージです。確認信号が受信されず、コンシューマーが切断された場合、RabbitMQ はメッセージをキューに再度入れ、元のコンシューマーまたは次のコンシューマーに配信するように手配します。

zeromq: サポートされていません。

rocketmq: サポートされています。

メッセージの消費が失敗するほとんどのシナリオでは、即時再試行の 99% が失敗します。そのため、RocketMQ の戦略では、消費が失敗したときに、毎回同じ時間間隔で定期的に再試行します。

1> 送信者の送信メソッド自体は内部再試行をサポートしており、再試行ロジックは次のとおりです。

a) 最大 3 回試行します。

b) 送信に失敗した場合は、次のブローカーにローテーションします。

c) このメソッドにかかる合計時間は、sendMsgTimeout で設定された値 (デフォルトでは 10 秒) を超えてはなりません。時間が制限を超えた場合、再試行は行われません。

2>受信側。

コンシューマーがメッセージの消費に失敗した場合、メッセージを再度消費できるように再試行メカニズムを提供する必要があります。コンシューマー メッセージの消費失敗は、通常、次の 2 つの状況に分けられます。

デシリアライズ失敗など、メッセージ自体に関連する理由により、メッセージデータ自体を処理できません（たとえば、現在のメッセージの電話番号が

キャンセル、再チャージ不可など。時間指定の再試行メカニズム。たとえば、10 秒後に再試行します。

依存するダウンストリーム アプリケーション サービスが利用できないためです。たとえば、DB 接続が利用できない、外部システム ネットワークにアクセスできないなどです。

現在の失敗したメッセージをスキップしても、他のメッセージを使用するとエラーが発生します。この場合、次のメッセージを消費する前に 30 秒間スリープして、ブローカーがメッセージを再試行する負担を軽減できます。

ActiveMQ: サポートされていません

17. 並行性

カフカ：高

1 つのスレッドには 1 つのコンシューマーがあります。 Kafka では、コンシューマーの数がパーティションの数以下に制限されます。並列処理の度合いを高めたい場合は、コンシューマーでマルチスレッドを有効にするか、コンシューマー インスタンスの数を増やすことができます。

RabbitMQ: 非常に高い

Erlang 言語で書かれており、高い並行性パフォーマンスを備えています。

コンシューマーでマルチスレッドを有効にすることができます。最も一般的なアプローチは、1 つのチャネルを 1 つのコンシューマーに対応させ、各スレッドが 1 つのチャネルを制御し、複数のスレッドが接続の TCP 接続を再利用してパフォーマンスのオーバーヘッドを削減することです。

RabbitMQ キューに複数のコンシューマーがある場合、キューによって受信されたメッセージはラウンドロビン方式でコンシューマーに送信されます。各メッセージはサブスクリプション リスト内の 1 人の消費者にのみ送信され、重複して送信されることはありません。

このアプローチはスケーラビリティに非常に適しており、並行プログラム用に特別に設計されています。

一部のコンシューマーに負荷の高いタスクがある場合は、basicQos を設定して、コンシューマーがチャネルに保持できる未確認メッセージの最大数を制限できます。上限に達すると、rabbitmq はこのコンシューマーにメッセージを送信しなくなります。

zeromq: 高い

rocketmq: 高い

1>Rocketmq では、コンシューマーの数がキューの数以下に制限されますが、コンシューマー内でマルチスレッドを有効にすることができ、これは Kafka と一致しており、並列性を高める方法も同じです。

消費並列処理方法を変更する

a) 同じ ConsumerGroup 内で、Consumer インスタンスの数を増やすことで並列処理を向上できます。サブスクリプション キューの数を超えるコンシューマー インスタンスは無効です。

b) パラメータconsumeThreadMinとconsumeThreadMaxを変更して、単一のコンシューマの並列スレッドの数を増やす

2> 同じネットワーク接続の場合、複数のクライアント スレッドが同時に要求を送信でき、接続が再利用されてパフォーマンスのオーバーヘッドが削減されます。

ActiveMQ: 高

単一の ActiveMQ のメッセージの受信および消費速度は 1 秒あたり 10,000 件です (永続メッセージの場合は 10,000 ～ 20,000 件、非永続メッセージの場合は 20,000 件以上)。実稼働環境に 10 個の Activemq を導入すると、1 秒あたり 100,000 件を超えるメッセージのパフォーマンスを実現できます。 MQ にデプロイされる ActiveMQ ブローカーの数が増えるほど、レイテンシは低下し、システム スループットは向上します。