序文
メッセージキューは、徐々に、内部の通信システムを意味する企業のコアとなっています。これは、低い結合、信頼できる配信、ブロードキャスト、トラフィック制御、最終的な一貫性と一連の機能、非同期RPCの主な手段の1つを有します。こうしたベテランのActiveMQの、RabbitMQのように、今日の主流のメッセージングミドルウェアの多くがありますが、ホットカフカ、アリババはそうでRocketMQとを開発しました。今日は主に相違点について説明し、次のいくつかの主流のメッセージングミドルウェアに連絡すること。
1.はじめに--ActiveMQ主流メッセージングミドルウェア
ActiveMQのは、Apacheのによって生成され、ActiveMQのは、完全にJMS1.1仕様とJ2EE 1.4 JMSプロバイダの実装です。それは、非常に高速だ複数の言語やクライアントプロトコルをサポートし、非常に簡単に、エンタープライズアプリケーション環境に埋め込むことができ、多くの高度な機能を持っています。
1.1特長
- ApacheのActiveMQのは、ソース・メッセージ・バスを開くために、最も人気のある、強力な能力を生産し、それは完全にサポートJMSメッセージングミドルウェア仕様です
- その豊富なAPIは、複数のクラスタモードは、業界のベテラン・メッセージング・ミドルウェア、広く中小企業で使用を構築するために彼を有効に！
- MQメトリック：サービスのパフォーマンス、データストレージ、クラスタアーキテクチャ。
ActiveMQのは、他のMQのパフォーマンスと比較するため、ActiveMQのは今あまり使用されていることがより一般的です。今、並行性の高いシナリオは、ビッグデータはどこでも見ることができます。MQの選択にこの時間ならば、ActiveMQのは不十分になります。
ターゲットをMQ測定し、3つの主要分野がありますサービスのパフォーマンス、データストレージ、クラスタアーキテクチャのサービス性能：ActiveMQの性能が特に良好ではない、大規模な並行性の面は、常にそのようなブロックされたような小さな問題、種々のであろうメッセージの、過剰な蓄積、いくつかのいくつかの遅延の問題のように。データ保存：ActiveMQのデフォルトKahaDBメモリストレージ。C内に格納されているに基づいて、Google LevelDb：のような、いくつかの高性能ストレージに使用することができます。メッセージは、信頼性を保証するために、またはMySQLのOracleデータベースを使用することができるである場合。クラスタアーキテクチャ：非常に多くの年のための人気のActiveMQは、他のコンポーネントAPIとの統合も非常に最適です。それは同時実行のシナリオの下では特に大きくない場合には、ActiveMQのも良い選択です。ActiveMQのクラスタアーキテクチャモデルも非常に良いですので。
1.2アーキテクチャパターン
ネットワークモード
基本的に2つの接続構成を作るために、中間NEWWORKゲートウェイと、スタンバイモードを統合し、あなたは、分散クラスタを実現することができます。
1.3まとめ
利点：
- クロスプラットフォーム（Javaプラットフォームに依存しないで書かれた、ActiveMQのは、ほぼすべてのJVM上で実行することができます）
- あなたは、JDBCを使用することができます。データはデータベースに永続化することができます。JDBCを使用してActiveMQのは、パフォーマンスを低下させることができますが、データベースは、ほとんどの開発者は記憶媒体に親しまれてきたが
- JMS仕様のサポート：JMS仕様のサポートは、統一されたインタフェースを提供します
- 自動再接続エラーをサポートし、メカニズムを再試行してください
- 安全機構がありますが：キュー/トピックを認証および認可するため史郎、JAASおよびその他のセキュリティ設定メカニズムをサポートしています
- 完璧なモニタリング：WebConsoleに、JMX、シェルコマンドライン、JolokiaのRESTfulなAPIを含め、音の監視を持っています
- フレンドリーなインターフェース：WebConsoleには症例の大部分を満たすために提供さ、例えばhawtioとして使用することができる多くのサードパーティコンポーネントは、あります
短所：
- コミュニティ活動として高くはないのRabbitMQ
- 他のユーザーからのフィードバックによると、それは不可解な問題になり、メッセージが失われます
- 現在の焦点は、アポロ5.xの少ないメンテナンスをactivemq6.0製品を置きます
- キューのアプリケーションシナリオの何千ものには適していません
2.主流のメッセージングミドルウェアの導入--Kafka
Apacheのカフカは、分散パブリッシュ・サブスクライブ・メッセージングシステムです。もともとはLinkedInのユニークなデザインに基づいていたが、後にApacheプロジェクトの一部となるように、提出された分散システムログ（分散コミットログ）として実装されています。カフカのパフォーマンス、効率性、および優れた持続性を延長することができます。そのパーティション機能は、あなたがコピーすることができますし、フォールトトレランスは、その優れた特性です。
2.1特長
現在、メッセージングシステムを予定してトップレベルのApacheプロジェクトに属している-カフカLinkedInは、オープンソースの分散リリースです。カフカの主な特徴は、消費者のメッセージ、高スループットの追求、目的に対処するためのプルモデルは、ログの収集と伝達のために開始することで与えられています。0.8バージョンでは、レプリケーションをサポートするために始めた、トランザクションをサポートしていません、繰り返しメッセージが失われ、エラーは必須ではありません、インターネットデータ収集業務データサービスの大規模な数を生成するのに適し。ここでは、スループットのみに焦点を当てるカフカ見ることができます。したがって、カフカを使用した場合、サービスはメッセージが繰り返されることを可能にするかどうかに注意を払う、エラーを失いました。許可された場合は、カフカが最も適切です。その性能は最高ですので。でも、安価なサーバー上で、データの量は、第2のスタンドアローンあたり以上100Kをサポートすることができます。だから、パフォーマンスが非常に良いですです。カフカであれば、十分なメモリがあるように、十分に大きなスループットとすることができる、記憶するための専用メモリを使用します。カフカので読んでいないと、ディスクに書き込みます。
- 高速永続性：メッセージがオーバーヘッドの（1）Oで永続的であってもよいです。
- 高スループット：一般的なサーバーのスループット・レートで10W /秒のいずれかで達成することができます。
- 完全分散システム：ブローカー、生産と消費者は、分散自動、自動負荷分散のためのネイティブサポートされています。
- サポート同期および非同期レプリケーション高可用性機構の二種類。
- バッチサポートデータ伝送と引っ張っ。
- ゼロコピー技術（ゼロコピー）：IO低減ステップは、システムのスループットを向上させるために、
- データ移行、ユーザーに対して透過的展開。
- ダウンタイムの延長機なし。
- その他の機能：情報のプルモデルの富、効率的な加入者の水平スケーリング、リアルタイムのニュース購読、億件のメッセージの蓄積容量は、定期的メカニズムを削除します
2.2アーキテクチャパターン
カフカのアーキテクチャモデル
飼育係は、協調管理を依存し、すべてのカフカレプリカがデータ同期であることができます。あなたが言う場合：データは最初のノードに落ちる、それはrepilicateコピーとなりますので、各ノードのデータで実行がありますされ、データの3点の合計があります。それらの1つがダウンした場合は、だけでなく、他の二つのノードからデータを取得しました。配置シナリオの提案：部屋を横切って展開します。マシンがあってもダウンし、データは問題ありません。サイト全体がダウンしている場合。だから、我々のデータは失われます。これは、大企業が検討する必要があるオフサイトディザスタリカバリを。もちろん、カフカは、パフォーマンス、信頼性、および関係高いデータを集中しました。
2.3まとめ
利点：
- リッチクライアント言語：Javaや.NET、PHP、Rubyの、Pythonの、移動して、他の言語のサポート。
- 高性能：単一書き込み約1,000,000 TPS /秒、10バイトのメッセージ・サイズ、
- これは、理論的には無制限のメッセージが積み重なるサポートし、高い可用性と信頼性、完全分散型アーキテクチャ、およびレプリカのメカニズムを提供します。
- サポートバッチ操作。
- プル方法を使用した消費者は、メッセージを取得します。すべてのメッセージが消費され、一度だけ消費されることを保証するために制御することにより、注文したメッセージ。
- 優れたサードパーティKafkaWeb管理インターフェイスカフカ-Managerがあります。
- ログ内のより成熟した分野、多くの企業は、オープンソース・プロジェクトを使用しています。
短所：
- カフカ以上64スタンドアロンキュー/パーティションが明らかに舞い上がる現象負荷が起こるのだろうとき。複数のキュー、負荷が高いほど、応答時間が長いメッセージの送信となります。
- リアルタイムのポーリング間隔に応じて、短いポーリングモードを使用します。
- 消費者の障害が再試行をサポートしていません。
- サポートメッセージシーケンスが、ダウンプロキシ後、メッセージが順不同で生成されます。
- コミュニティ更新遅くなります。
3.主流メッセージングミドルウェアの導入--RocketMQ
RocketMQアリオープンソースのメッセージング・ミドルウェアは、すでにまた、Apacheのトップレベルプロジェクトのためのインキュベーターです。Java言語は、カフカを参照して設計されており、自分の改善点のいくつか、カフカよりも良いニュースの信頼性を作りました。RocketMQ内部アリは広くストリーミング、binglog分布および他のシーンを記録し、プッシュ通知、注文、取引、再充電、ストリーム・コンピューティングで使用されています。
3.1特長
次のようにコア機能は次のとおりです。
- メッセージシーケンス、メッセージシーケンス消費者を確認してください。
- これは、モードを引っ張り、加工の富を提供します。
- 効率的な加入者は、水平方向に拡張することができます。
- 何百万人もの蓄積能力のレベルのメッセージを運びます。
3.2アーキテクチャパターン
モード2デュアルマスターモード（マスタから）RocketMQクラスタアーキテクチャモデル1.Masterスレーブ。3.デュアルデュアルマスタースレーブモード。4.マルチマスターマルチスレーブモード。マルチマスタモードから5。多くのオプションから選択します。
ように、オープンソースのリファレンス・デザインモードのたくさん。
クラスタトポロジ
3.3まとめ
利点：
- スタンドアローンの10,000人以上の永続キューをサポートしています。
- 永続的な、第1の書き込みシステムページキャッシュされているRocketMQすべてのメッセージ、そしてブラシディスクは、ディスクは、データメモリを持っていることを確認することができ、およびアクセスに、メモリから直接読み取ります。
- モデルは、単純なインターフェイス使いやすい（多くの場面でJMSインタフェースを非常に実用的ではない）です。
- パフォーマンスは非常に良いですが、あなたはブローカー内のメッセージの大量の蓄積を許可することができます。
- これは、クラスタの消費、ラジオ消費を含め、消費パターンの多様性をサポートしています。
- 分散型のスケーラブルな設計のすべての側面は、マスタースレーブと可用性をサポートしています。
- すぐにアップデートのより積極的なバージョンの開発。
短所：
- 多くのクライアント言語をサポートする、JavaやC ++はCを成熟されていない、今++
- メンテナンスRocketMQは、専門家チームが必要
- Business Editionの料金は、外部から提供されていない多くの機能があります。
- コア内でMQ JMSインタフェースを実装していません。
4.なぜRabbitMQの？
1.ActiveMQは、パフォーマンスが非常に良いではないので、非常に同時シナリオに直接配ります。これは完璧なAPI、あなたは中小企業で使用するには、インターネットに行くことができます。ビジネスがあれば必要2.kafka、高いパフォーマンスに重点、メッセージの配信の信頼性。あなたはカフカを選択することはできません。あなたには、いくつかのログがそれを収集しない場合でも、カフカは非常に良いです。カフカのパフォーマンスは非常に良いですので。3.RocketMQは、それは非常に良いています。それは、信頼性、分散型のもの、拡張をサポートのレベルを満たすために、高性能で、メッセージの何百万、数百のレベルはそうでマスタとスレーブの切り替え、蓄積、および。それのMQすべての利点は、基本的には満足しています。しかし、その最大の欠点：料金の商用版。だから、外部から提供されていない多くの機能を持っています。
他の3 MQ MQは、それを選択することができ、そこされたん？RabbitMQの - はい、これも学習MQです。
主流のメッセージングミドルウェアを導入--RabbitMQ
2007年にリリースRabbitMQのは、それが最も主流のメッセージング・ミドルウェアの一つであり、再利用可能なエンタープライズメッセージングシステムに基づいてAMQP（アドバンスト・メッセージキュー・プロトコル）に完成しました。
5.1特長
RabbitMQはAMQPプロトコルに基づいて達成するアーラン言語開発したオープンソースのメッセージキューイングシステムです。AMQP主な機能は、キューのメッセージ、ルーティングされ（点を含むとパブリッシュ/サブスクライブ）、信頼性、安全性。より多くの企業システム内で使用されるAMQPプロトコル、データの一貫性、高い安定性と信頼性要件シナリオは、パフォーマンスとスループット要件が依然として続いています。RabbitMQのの信頼性は、データが百パーセントを失っていないことを保証するために、非常に良いです。キューを使用することができミラーリング、その安定性は非常に良好です。だから、私たちの金融部門のインターネット。非常に高いデータ要件の安定性と信頼性の下で、我々はRabbitMQのを選ぶだろう。もちろんそうではないカフカ良好なパフォーマンスが、パフォーマンスはAvtiveMQよりもはるかに優れています。あなたはまた、彼の最適化性能の一部を行うことができます。デュアル・アーキテクチャを構築することができるリモートライブのRabbitMQ、ディスクやメモリの記憶方法を含む各ノードを使用することができます。
RabbitMQのクラスタアーキテクチャ
図は、我々はRabbitMQのクラスタ化された3つのノードのセットとして使用することができるということであると言う、当然のことながら、多くのグループを持つことができます。ノードとノードの間でミラーキューを使用しました。このことから、データは百パーセントを失っていないことを確認することが可能です。HA-プロキシ、TCPレベルの負荷：フロントエンドのロードバランシングは、このような負荷分散構成要素として、行うことができます。あなたは、高可用性が必要な場合は、やるkeepalivedの高可用性構成の助けを必要としています。例えばそれはRabbtMQのノードへのルートを持っている、指定されたロード・バランシング・アセンブリを経由する仮想フロントエンドVIP、VIPを追加します。これは、全体のRabbitMQクラスタアーキテクチャです。非常に完全達成することができ、高い可用性とパフォーマンスも超安定性、非常に良いです。そして、様々なクラスタの回復手段があります。たとえば、次のいずれかのノードがハングアップ、またはディスクが損傷され、それはまた、メッセージ修復することができます。これらの利点に基づいて、我々は学ぶのRabbitMQを取る必要があります。
図6の比較。
文末
個人的なマイクロチャネル公衆番号へようこそ注意：Coderのプログラムの最新オリジナルな技術に関する記事と無料の学習教材のため、多くのブティックマインドマップ、インタビューデータ、PMPの準備資料あなたがリードするために、待っているあなたは、いつでも、どこでも技術的な知識を習得することができます！QQのグループを作成します：315 211 365を、私たちは一緒にグループ交換研究に歓迎します。ありがとうございます！また、必要としている友人の側に導入することができます。
記事に含ま
Githubの：github.com/CoderMerlin...
Gitee：gitee.com/573059382/c ...歓迎の注意と星〜
参考記事：
「簡潔RabbitMQのメッセージング・ミドルウェア」
推奨読書：