メッセージキューフレームワークテクノロジーの選択

記事ディレクトリ

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

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

Kafka、RocketMQ、RabbitMQ の長所と短所の比較

そしてメッセージキューの選択

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

ここに画像の説明を挿入

がある：

ゼロMQ
Twitterの分散ログ
ActiveMQ: Apache のベテランメッセージエンジン
RabbitMQ、Kafka: AMQP のデフォルト実装。
ロケットMQ
Artemis: Apache の ActiveMQ のサブプロジェクト
Apollo: Apache の ActiveMQ のサブプロジェクトでもある、いわゆる次世代メッセージングエンジン
コマーシャルメッセージエンジン IronMQ
そして、JMS (Java Message Service) 標準を実装する OpenMQ です。

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

ここに画像の説明を挿入

デカップリング

デカップリングは、メッセージキューによって解決されるべき最も本質的な問題です。

最終的な整合性

最終的な整合性とは、2 つのシステムの状態が一貫しており、両方とも成功するか両方とも失敗することを意味します。

最終的な整合性はメッセージキューに必須の機能ではありませんが、最終的な整合性を保つためにメッセージキューを利用することは確かに可能です。

ブロードキャスト

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

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

ピークスタガリングとフロー制御

一般的な使用シナリオは、seckill ビジネスがトラフィックのピークシェービングシナリオに使用されることです。

3. Kafka、RocketMQ、RabbitMQ の比較

特性	アクティブMQ	ラビットMQ	ロケットMQ	カフカ
開発言語	ジャワ	アーラン	ジャワ	スカラ
スタンドアロンのスループット	10,000レベル	10,000レベル	10万レベル	10万レベル
適時性	ミリ秒レベル	私たちのクラス	ミリ秒レベル	msレベル以内
可用性	高 (マスター/スレーブアーキテクチャ)	高 (マスター/スレーブアーキテクチャ)	非常に高い (分散アーキテクチャ)	非常に高い (分散アーキテクチャ)
特徴	多くの企業で使用されている成熟した製品、より多くのドキュメント、さまざまなプロトコルのより優れたサポート	erlang に基づいて開発されているため、同時実行能力が非常に高く、パフォーマンスが非常に優れており、遅延が非常に低く、管理インターフェイスが豊富です。	MQ は比較的完全な機能と優れた拡張性を備えています	MQ の主要な機能のみがサポートされており、メッセージクエリやメッセージバックトラッキングなどの一部の機能は提供されていませんが、やはりビッグデータ向けに準備されており、ビッグデータの分野で広く使用されています。

1.アクティブMQ

アドバンテージ

スタンドアロンのスループット: 10,000 レベル
トピック数がスループットに与える影響:
適時性: ミリ秒レベル
可用性: 高、マスター/スレーブアーキテクチャに基づいて高可用性を実現
メッセージの信頼性: データ損失の可能性が低くなります。
機能サポート: MQ 分野の機能は非常に充実しています

欠点:

現在、公式コミュニティが ActiveMQ 5.x を保守することはますます少なくなり、大規模なスループットシナリオではあまり使用されなくなりました。

2.カフカ

ビッグデータのキラー機能として知られ、ビッグデータ分野でのメッセージ送信と言えばKafkaを避けて通ることはできませんが、ビッグデータのために生まれたこのメッセージミドルウェアは、100万レベルのTPSスループットで有名で、瞬く間にビッグデータになりました。データ分野の最愛の人であり、データの収集、送信、保存のプロセスにおいて極めて重要な役割を果たします。

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

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

アドバンテージ

パフォーマンスは非常に優れており、1 台のマシンで書き込まれる TPS は 1 秒あたり約 100 万個であり、最大の利点は高いスループットです。
適時性: ミリ秒レベル
可用性: 非常に高い、Kafka は分散されている、1 つのデータの複数のコピー、数台のマシンがダウンしている、データ損失なし、可用性不能なし
コンシューマーはプルメソッドを使用してメッセージを取得します。メッセージは順序どおりに並べられ、制御を通じてすべてのメッセージが確実に消費され、一度だけ消費されることが保証されます。
優れたサードパーティの Kafka Web 管理インターフェイス Kafka-Manager があります。
ログ分野では比較的成熟しており、多くの企業や複数のオープンソースプロジェクトで使用されています。
機能サポート: 機能は比較的単純で、主に単純な MQ 機能をサポートしており、ビッグデータ分野でのリアルタイムコンピューティングとログ収集が大規模に使用されています。

欠点:

単一の Kafka マシンに 64 を超えるキュー/パーティションがある場合、負荷は大幅に増加します。キューが増えるほど負荷が高くなり、メッセージ送信の応答時間が長くなります。
短いポーリング方式を使用すると、リアルタイムのパフォーマンスはポーリング間隔に依存します。
消費失敗は再試行をサポートしません
メッセージの順序はサポートされていますが、エージェントがダウンすると、メッセージの順序が狂います。
コミュニティの更新が遅い

3.うさぎMQ

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

アドバンテージ：

erlang 言語の特性により、mq はより優れたパフォーマンスと高い同時実行性を備えています。
スループットは 10,000 レベルに達し、MQ 機能は比較的完成されています
堅牢、安定、使いやすく、クロスプラットフォーム、複数言語のサポート、完全なドキュメント。
オープンソースによって提供される管理インターフェイスは非常に優れており、使いやすいです
高いコミュニティ活動

欠点:

アーラン開発の場合、ソースコードを読んで理解することが難しく、基本的な機能はオープンソースコミュニティの迅速なメンテナンスやバグ修正に依存しており、二次的な開発やメンテナンスにはつながりません。
RabbitMQ は実装メカニズムが重いため、スループットは低くなります。
より複雑なインターフェイスとプロトコルを学習する必要があり、学習とメンテナンスのコストが比較的高くなります。

4.ロケットMQ

RocketMQ は Alibaba のオープンソース製品で、Java 言語で実装され、設計中に Kafka を参照し、独自のいくつかの改良を加えています。

RocketMQ は、注文、トランザクション、リチャージ、ストリームコンピューティング、メッセージプッシュ、ログストリーム処理、Binglog 配布などのシナリオで Alibaba Group で広く使用されています。

アドバンテージ：

スタンドアロンのスループット: 100,000 レベル
可用性: 非常に高い分散アーキテクチャ
メッセージの信頼性: パラメーターの最適化と構成後、メッセージは損失ゼロを達成できます。
関数のサポート: MQ 関数はより完全、または分散され、優れたスケーラビリティを備えています。
10億レベルのメッセージ蓄積をサポートし、蓄積によるパフォーマンスの低下を引き起こしません
ソースコードはJavaなので、自分でソースコードを読み込んで自社のMQをカスタマイズして制御することができます。

欠点:

サポートされているクライアント言語はそれほど多くありませんが、現在 Java と C++ ですが、C++ は未熟であり、コミュニティは
一般的に活発です
。JMS およびその他のインターフェイスは mq コアに実装されていません。一部のシステムでは、多くのコードを変更する必要があります。移行する

4. メッセージキューの選択に関する提案

カフカ

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

大企業であれば選ぶのがおすすめですが、ログ収集機能があれば間違いなくKafkaが第一候補です。

ロケットMQ

金融インターネット分野向けに誕生したこのサービスは、特に電子商取引での注文控除やビジネスのピークカットなど、高い信頼性のシナリオが求められ、大量のトランザクションが殺到すると、バックエンドの処理が間に合わなくなる可能性があります。

RocketMQ は安定性の点でより信頼できる可能性があります。これらのビジネスシナリオは Ali Double 11 で何度もテストされています。ビジネスに上記の同時シナリオがある場合は、RocketMQ を選択することをお勧めします。

ラビットMQ

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

データ量がそれほど大きくない場合、小規模企業は比較的機能が充実した RabbitMQ を選択することを好みます。

以上がKafka、RocketMQ、RabbitMQの長所と短所の比較です。