Alibaba の Double 11 フラッシュセールなどの高同時実行ビジネス シナリオでは、メッセージ キュー ミドルウェアがトラフィックのピーク削減と分離において重要な役割を果たします。

今日は以下の内容について議論します:

完全なメッセージ キューとは何ですか? Kafka、RocketMQ、RabbitMQ の長所と短所、およびメッセージ キューの選択の比較。

最も完全な MQ メッセージ キューは何ですか?

では、業界でよく知られているメッセージ エンジンは何でしょうか?次の図に示すように:

これには、現在よく知られているメッセージ エンジンがほぼすべてリストされています。これには以下が含まれます。

ゼロMQ

Twitterの分散ログ

ActiveMQ: Apache の古いメッセージング エンジン

RabbitMQ、Kafka: AMQP のデフォルト実装。

ロケットMQ

Artemis: Apache ActiveMQ のサブプロジェクト

Apollo: Apache ActiveMQのサブプロジェクトで、次世代のメッセージングエンジンとして知られています。

商用メッセージングエンジン IronMQ

そして、JMS (Java Message Service) 標準を実装する OpenMQ です。

MQメッセージキューの技術的応用

1. デカップリング

分離は、メッセージ キューが解決する必要がある最も重要な問題です。

2. 最終的な一貫性

結果的一貫性とは、2 つのシステムの状態が一貫性を保ち、両方が成功するか、両方が失敗するかのいずれかであることを意味します。

最終的な一貫性はメッセージ キューの必須の機能ではありませんが、最終的な一貫性を必要とする処理を実行するためにメッセージ キューを利用することができます。

3. 放送

メッセージ キューの基本的な機能の 1 つはブロードキャストです。

メッセージ キューでは、メッセージがキューに配信されたかどうかだけを気にすればよいのです。誰がサブスクライブしたいかは下流の問題であり、開発と共同デバッグの作業負荷が大幅に軽減されることは間違いありません。

4. ピークシフトとフロー制御

典型的な使用シナリオとしては、フラッシュセール事業をトラフィックピーク削減のために利用することが挙げられます。

この記事は長いため、メッセージ キューの比較に焦点を当てます。詳細なアプリケーション シナリオについては、「トラフィック ピーク シェービングとは何ですか?」を参照してください。フラッシュセールビジネスのピークシェービングシナリオを解決する方法。

Kafka、RocketMQ、RabbitMQ の比較

1. アクティブMQ

アドバンテージ：

単一マシンスループット: 10,000

トピック量がスループットに与える影響:

適時性: ms レベル

可用性: 高、高可用性を実現するマスタースレーブアーキテクチャに基づく

メッセージの信頼性: データ損失の可能性が低い

機能サポート：MQ分野の機能は非常に充実しています

欠点:

現在、公式コミュニティによる ActiveMQ 5.x のメンテナンスはますます少なくなっており、大規模なスループットのシナリオで使用されることはほとんどありません。

2. カフカ

ビッグデータのキラーアプリとして知られる Kafka は、ビッグデータ分野でのメッセージ伝送には欠かせません。ビッグデータ用に作成されたこのメッセージ ミドルウェアは、数百万 TPS のスループットで有名であり、データの収集、転送、保存のプロセスで重要な役割を果たし、急速にビッグデータ分野の寵児となっています。

Apache Kafka はもともと LinkedIn によって独自の設計に基づく分散コミット ログ システムとして実装され、後に Apache プロジェクトの一部になりました。

LinkedIn、Uber、Twitter、Netflixなどの大手企業でも採用されています。

アドバンテージ：

パフォーマンスは良好で、単一マシンの書き込み TPS は 1 秒あたり約 100 万レコードです。利点はスループットが高いことです。

適時性: ms レベル

可用性: 非常に高い。 Kafka は分散されており、1 つのデータの複数のコピーが存在します。数台のマシンがダウンしても、データは失われず、使用不能にはなりません。

コンシューマーは Pull メソッドを使用してメッセージを取得します。メッセージは順番通りです。制御により、すべてのメッセージが消費され、1 回だけ消費されることを保証できます。

優れたサードパーティの Kafka Web 管理インターフェイス Kafka-Manager があります。

これはロギング分野では比較的成熟しており、多くの企業やオープンソース プロジェクトで使用されています。

機能サポート: 機能は比較的シンプルで、主に単純な MQ 機能をサポートしており、ビッグデータ分野でのリアルタイム コンピューティングやログ収集に広く使用されています。

欠点:

単一の Kafka マシンに 64 を超えるキュー/パーティションがある場合、負荷が大幅に増加します。キューの数が増えるほど負荷が高くなり、メッセージ送信の応答時間が長くなります。

ショートポーリングを使用する場合、リアルタイムのパフォーマンスはポーリング間隔によって異なります。

消費失敗は再試行をサポートしません。

メッセージの順序をサポートしますが、プロキシがダウンすると、メッセージの順序が乱れます。

コミュニティはゆっくりと更新されます。

3. ラビットMQ

RabbitMQ は 2007 年にリリースされました。AMQP (Advanced Message Queuing Protocol) に基づく再利用可能なエンタープライズ メッセージング システムであり、最も主流のメッセージング ミドルウェアの 1 つです。

RabbitMQの利点:

Erlang 言語の特性により、MQ は優れたパフォーマンスと高い並行性を備えています。

スループットは10,000レベルに達し、MQ機能は比較的完成している

堅牢で安定しており、使いやすく、クロスプラットフォームで、複数の言語をサポートし、完全なドキュメントを備えています。

オープンソースで提供される管理インターフェースは素晴らしく、使いやすい

コミュニティは非常に活発です。

RabbitMQ の欠点:

Erlang 開発はソースコードを理解するのが難しく、その基本機能はオープンソース コミュニティに依存して迅速に保守およびバグ修正を行うため、二次開発や保守には適していません。

RabbitMQ は実装メカニズムが重いため、スループットが低くなります。

比較的複雑なインターフェースとプロトコルを学習する必要があり、学習コストと保守コストが高くなります。

4. ロケットMQ

RocketMQ は、Java で実装された Alibaba のオープンソース製品です。これは Kafka を参考に設計され、独自の改良が加えられています。

RocketMQ は、注文、取引、再チャージ、ストリーム コンピューティング、メッセージ プッシュ、ログ ストリーミング処理、binglog 配信などのシナリオで Alibaba グループで広く使用されています。

RocketMQ の利点:

単一マシンスループット: 100,000

可用性: 非常に高い分散アーキテクチャ

メッセージの信頼性: パラメータの最適化と構成後、メッセージの損失がゼロになることが保証されます。

機能サポート: MQ は機能が比較的充実しており、分散化されており、スケーラビリティに優れています。

10億レベルのメッセージ蓄積をサポートし、蓄積によるパフォーマンスの低下は発生しません。

ソースコードはJavaなので、自分でソースコードを読み、自社のMQをカスタマイズして制御することができます。

RocketMQ の欠点:

サポートされているクライアント言語は多くなく、現在は Java と C++ ですが、C++ はまだ成熟していません。

平均的なコミュニティ活動

JMS インターフェースは MQ コアに実装されていないため、一部のシステムでは移行するために大量のコードを変更する必要があります。

メッセージキューの選択に関する推奨事項

1. カフカ

Kafka の主な特徴は、メッセージの消費を Pull モデルに基づいて処理し、高いスループットを追求することです。本来の目的はログ収集・送信であり、大量のデータを生成するインターネットサービスのデータ収集業務に適しています。

大企業でのご利用におすすめです。ログ収集機能があれば、間違いなく Kafka を選ぶべきです。

2. ロケットMQ

金融インターネット分野向けに誕生し、特に電子商取引における注文減額やビジネスのピークカットなど、高い信頼性が求められるシナリオに適しています。大量のトランザクションが流入すると、バックエンドが時間内に処理できない可能性があります。

安定性の点では、RoketMQ の方が信頼できるかもしれません。これらのビジネス シナリオは、Alibaba の Double 11 期間中に何度もテストされています。ビジネスで上記のような同時シナリオが発生する場合は、RocketMQ を選択することをお勧めします。

3. ラビットMQ

RabbitMQ: Erlang 言語自体の並行性の利点を組み合わせることで、パフォーマンスが向上し、コミュニティがより活発になりますが、二次開発やメンテナンスには適していません。ただし、RabbitMQ コミュニティは非常に活発であり、開発プロセス中に発生したバグを解決することができます。

データ量がそれほど大きくない場合、中小企業はより充実した機能を備えた RabbitMQ を優先する必要があります。