ディレクトリ
まず、メッセージングミドルウェアの知識... 1
1、概要... 1
2、メッセージングミドルウェアの構成... 1
3メッセージングミドルウェアパターン分類... 2
長所メッセージングミドルウェア... 3 4
メッセージミドルウェア・アプリケーションのシナリオ5 ... 4
6つのメッセージングミドルウェア共通プロトコル... 6
7共通MQメッセージングミドルウェアの紹介... 7
7.1 RocketMQ ... 7
7.2 RabbitMQの... 7
7.3 ActiveMQの.. 8
Redisの7.4。8
7.5カフカ。8
7.6 ZeroMQ .. 9
8、メインメッセージングは比較ミドルウェア... 9
第二に、展開のRabbitMQ。10
1、インストールの依存関係... 10
2、理由のRabbitMQアーランベースの環境、あなたはアーラン環境をインストールする必要がありますので... 10
図3に示すように、取付RabbitMQの.. 11
まず、メッセージングミドルウェア知識
1.概要
メッセージキューは、徐々に、内部の通信システムを意味する企業のコアとなっています。これは、低い結合、信頼できる配信、ブロードキャスト、トラフィック制御、最終的な一貫性と一連の機能、非同期RPCの主な手段の1つを有します。今日の主流のメッセージングミドルウェアの多くは、このようなベテランのActiveMQの、RabbitMQの、ホットカフカ、アリババが開発RocketMQようとそうであります。
図2に示すように、メッセージの組成ミドルウェア
2.1ブローカー
コア・メッセージング・サービスを提供するサーバとして、メッセージサーバ、
2.2プロデューサー
ブローカーへの生産メッセージを担当し、発信元のビジネスのニュースプロデューサー、
2.3消費者
消費者のニュース、ビジネスの処理側は、ブローカーとビジネスロジックの処理からメッセージを取得するための責任があります
2.4トピック
テーマは、サブスクリプションモデルの統一コレクションで発表された、さまざまなプロデューサーは、放送ニュースのために、別の加入者にMQサーバで分散トピックにメッセージを送信します
2.5キュー
キュー、PTPモード、特定のメッセージは、特定のキューの生産者に送信され、消費者は、特定のキューにサブスクライブ受信完了したメッセージを指定
2.6メッセージ
メッセージ本体、固定フォーマットサービスデータをカプセル化するために符号化されたデータパケットにより定義される異なる通信プロトコルに従って、メッセージの送信を実現します
メッセージミドルウェアパターン分類3
3.1 ポイント
PTPポイント：通信ベアラキューとして使用します
説明：
メッセージプロデューサの生産キューにメッセージを送信し、キューメッセージコンシューマと消費者のメッセージから取られました。
メッセージが消費された後、消費者が消費されたメッセージへのメッセージを消費することはできませんので、キューはもはや、保存されません。キューは、複数の消費者をサポートしていますが、メッセージのために、それだけで消費者が消費することができるだろう。
3.2 パブリッシュ/サブスクライブ
パブ/サブパブリッシュ・サブスクライブ（ブロードキャスト）：通信キャリアとして使用トピック
説明：
複数のメッセージの消費者（サブスクリプション）のメッセージを消費存在しながらニュースプロデューサー（リリース）が話題に発表されます。そして、ポイントさまざまな方法でポイントに、トピックに投稿されたメッセージはすべてのサブスクライバによって消費されます。
複数の消費者が消費メッセージプロデューサの生産キューにメッセージを送信するために、負荷分散を達成するためのキュー。消費者が利用できない場合ただし、メッセージは、消費者が利用可能になるまでのメッセージが保存されます、消費者を受け入れることができます。
このメッセージを取得することができ、それは1からNの加入者にありパブリッシュおよびサブスクライブ、あなたがメッセージを投稿するとき、すべてのサービスのこのトピックを購読するトピックを達成することは、メッセージのコピーを取得することができます。
メッセージングミドルウェアの4利点
4.1 デカップリング
直接的な相互作用呼び出し関係との間のシステムていないが、メッセージの送信を介して、システムは、侵襲性、低い結合がないように。
4.2 システムの応答時間を改善します
例えば、支払いを完了するためのロジックの元のセットは、完全に論理的ないくつかの注文状況、計算メンバーシップ・ポイント、物流、流通の通知を変更するために関連することができる、アーキテクチャ設計によるMQは、緊急かつ重要なことができます（必要応答するためにすぐに）ビジネスコールに方法、より少ない消費者の取り扱いのためのキューにMQキューの応答メッセージを要求する使用。
4.3 ビッグデータ処理アーキテクチャのためのサービスを提供するために、
ビッグデータ、メッセージキュー、またリアルタイム処理アーキテクチャの統合、パフォーマンスデータ処理のためのサポートを提供するという文脈での統合などのメッセージが。
4.4のJava Message Serviceの--JMS
Javaのメッセージングサービス（Java Message Serviceの、JMS）アプリケーション・プログラム・インターフェースAPIは、メッセージを送信するには、2つのアプリケーション、または分散システム間のメッセージ指向ミドルウェア（MOM）にJavaプラットフォームで、非同期通信。
P2Pとパブリッシュ/サブスクライブ・メッセージング・モードでのJMS：ポイント（ポイント、キューポイント）をポイントし、パブリッシュ・サブスクライブもともとJMSによって定義された（トピック、パブリッシュ/サブスクライブ）。二つのモードまたは問題を解決するための主な違いは、消費（マルチサブスクリプション）を繰り返すことができ、メッセージ・キューに送信されます。
メッセージミドルウェア・アプリケーションのシナリオ5
5.1 非同期通信
一部の企業は、希望もすぐにメッセージを処理する必要はありません。これは、ユーザーがメッセージをキューに入れすることができ、非同期メッセージキューの処理機構を提供しますが、すぐにそれに対処しません。その後、必要な時にそれらを処理するために行く、番号を入れてキューに配置されているメッセージの数を考えてみてください。
プログラムは、10件の同時要求を処理することができますが、100回の要求に、あなたはゆっくりと処理ミドルウェア、にこれらの要求を置くことができますが、応答が比較的高い、すぐに対処されるリアルタイムの要件は、適用されません。インクルード
5.2 デカップリング
エンジニアリング、異種システムのための適応の間に強い依存を減らします。将来は、プロジェクトのニーズを満たすものを予測するために、プロジェクトの開始の開始時に、それは非常に困難です。暗黙のメッセージシステムを挿入することによって、界面層に基づくデータは、プロセスは、界面の両側に実装されるべきアプリケーションの変更は、独立して念、プロセスの途中で両側にプロセスを拡張または変更することができる場合に発生します彼らは、同じインターフェイスの制約に従ってください。
5.3 冗長性
いくつかのケースでは、データを処理するプロセスが失敗します。データは永続的である場合を除き、それ以外の場合は失われます。彼らは完全にデータ損失のリスクを避けるために、この方法により、処理されるまで永続化のためのメッセージキューデータ。多くが使用するメッセージキュー「挿入 - 取得 - 削除する」パラダイムを、キューから削除メッセージの前に、あなたは治療システムを必要とし、明らかに安全であるというメッセージがあなたのデータの保全性を確保するために処理されていることを示しますあなたが使用して終了するまで。
5.4 スケーラビリティ
メッセージキューがあなたのプロセスを分離するので、そのチームへのメッセージの頻度を高め、プロセスが長く、追加の処理工程ができるもので、非常に簡単です。コード、無調整パラメータを変更する必要はありません。拡張を容易に配布。
5.5 過負荷
トラフィックの急激な増加の場合、アプリケーションは、役割を果たし続けるために必要がありますが、このトラフィックのバーストを予測するために抽出することはできません。それは莫大な無駄になり、スタンバイ上のリソースをコミットするために、標準のようなAピーク瞬時のアクセスを扱うことができるかどうか。メッセージキューは、重要なコンポーネントへのアクセス破裂圧力に耐えることが可能となりますが、要求のバーストをオーバーロードし、完全に崩壊しないだろう。
5.6 リカバリ
システム障害の構成要素の一部は、システム全体に影響を与えないとき。メッセージキューは、メッセージがまだシステム復旧後に処理することができますキューに入れられたので、メッセージ処理プロセスがハングアップしてもいることを、プロセス間の結合低減します。
5.7 確実にするために
ほとんどの使用シナリオでは、注文データの処理は非常に重要です。ほとんどの元々のメッセージ・キューを発注し、データを特定の順序で処理されることを保証することができます。
5.8 バッファ
いずれのクリティカルなシステムでは、我々は、処理時間を必要と異なる要素を持つことになります。ヘルプにバッファ層によってメッセージキューが最大効率の作業を行い、バッファがシステムを流れるデータの速度を制御し、最適化するのに役立ちます。システムの応答時間を調整します。
5.9 データストリーム処理
大量のデータのような、分散システムによって生成されたストリーム：、データを監視し、ビジネスのロギングユーザーの行動を、これらのフローのためのリアルタイムまたはバッチデータ収集要約すると、現在のビッグデータ分析は、インターネットの基本的な技術であり、メッセージキューを介してこれを行いますデータ収集のタイプが最良の選択です。
6一般的なプロトコルメッセージミドルウェア
6.1 AMQPのプロトコル
AMQPは、すなわちアドバンストメッセージキュープロトコルは、ユニファイドメッセージングサービス、アプリケーション層の規格アドバンストメッセージキュープロトコルを提供するために、メッセージ指向ミドルウェアの設計のためのオープンな標準のアプリケーション層のプロトコルです。このプロトコルのクライアントに基づいており、メッセージングミドルウェアのメッセージを送信することができ、異なるプログラミング言語でとのようなクライアント/ミドルウェアの異なる製品の制限の対象ではありません。
長所：信頼性、汎用性
6.2 MQTTの契約
MQTT（メッセージキューテレメトリ交通、メッセージキューテレメトリ交通）はIBMによって開発されたインスタントメッセージングプロトコルである、それは物事の重要な部分になる可能性があります。プロトコルは、（そうツイッター経由して、ホームネットワークなど）の通信プロトコルをすべてのプラットフォーム、ほとんどすべての記事と外部ネットワークが接続され、センサやアクチュエータとして使用されているをサポートしています。
利点：簡易フォーマット、小さな帯域幅、移動通信端末、PUSH、組み込みシステム
6.3ストンププロトコル
ストンプは、（ストリーミングテキスト配向メッセージプロトコル）は、テキストストリーム指向のメッセージプロトコルは、MOM（メッセージ指向ミドルウェア、メッセージ指向ミドルウェア）、単純なテキスト・プロトコルの設計です。STOMPは、任意のクライアントSTOMPのメッセージブローカ（ブローカー）相互作用を可能にすること、接続、相互運用可能なフォーマットを提供します。
長所：コマンドモード（非話題\キューモード）
6.4のXMPP プロトコル
XMPP（拡張メッセージングおよびプレゼンスプロトコル、拡張可能なメッセージングとプレゼンスプロトコル）プロトコルは、XML（Extensible Markup Language）に基づいて、およびインスタントメッセージング（IM）とオンラインサイトの検出に使用されます。サーバ間の準リアルタイムオペレーティング適しています。コアはストリーミングXMLに基づいており、今回の合意は、最終的にインターネットユーザーにもそれらの異なるオペレーティングシステムとブラウザが、インターネット上で誰にインスタントメッセージを送信することを可能にします。
利点：一般的な開示、互換性、拡張性の高い、高度なセキュリティが、それは大きな帯域幅を占有し、XML形式でエンコード
6.5 その他のTCP / IPベースのカスタムプロトコル
（例えば：Redisの、カフカ、zeroMqなど）いくつかの特定のフレーム厳密MQの仕様に従っていない彼らの必要性に応じて、しかし、プロトコルのTCP \ IPスイートにネットワークソケット・インタフェース、MQ関数を介して送信、自分自身をカプセル化。
7共通MQは、ミドルウェアの紹介メッセージング
7.1 RocketMQ
オープンソース・アリ、以前Metaqとして知られているメッセージングミドルウェアのキューモデル、下で配布、名前の3.0バージョンはRocketMQ、MQのセットを達成するためにJavaを使用してアリカフカリファレンスデザインに変更しました。内部MQ製品のアリ品種は（、metaqに通知）、統合のみコア機能を維持し、他のすべての実行時に頼るだけでなく、他のオープンソース製品上のアリとの最も単純化のコア機能は、異なるシナリオの下で、この認識に基づいていることを確認しながら、 MQアーキテクチャは、主に注文取引システムに使用します。
これは、次の特性があります。
- 厳格なメッセージの順序を保証するために、
- メッセージフィルタリングを提供します
- 豊富な情報プルモデルを提供
- 効率的な加入者レベルのスケーラビリティ
- リアルタイムニュースメカニズムを購読します
- 一億件のメッセージ蓄積容量
公式にはカフカのからいくつかのコントラスト差の異なる提供：
https://rocketmq.apache.org/docs/motivation/
7.2のRabbitMQ
オープンソースのメッセージキュー自体は、多くのプロトコルをサポートして使用してErlangで書かれた：それは非常にヘビー級になるようにAMQP、XMPP、SMTP、STOMPは、それは、また真で、エンタープライズクラスの開発に適しています。ブローカー・アーキテクチャを実現しながら、核となるアイデアは、プロデューサがキュー、クライアントに送信されたときに中心にキューイングする前に、メッセージキューに直接メッセージを送信しないです。（ルーティング）、ロードバランシング（負荷分散）ルーティング、データの永続性は非常に良いサポートを持っています。マルチエンタープライズレベルのためのESBの統合。
7.3 ActiveMQの
アパッチのサブプロジェクト。完全にJavaおよびJ2EE 1.4仕様JMS1.1 JMSプロバイダ実装の使用をサポートし、少量のコードを効率的に高度なアプリケーションシナリオを実装することができます。で-VM、TCP、SSL、NIO、UDP、マルチキャスト、JGroupsのとJXTAトランスポート：のようなプラグイン可能なトランスポートプロトコルのサポート、。RabbitMQの、ZeroMQ、ActiveMQのサポート、複数の言語、一般的に使用されるクライアントC ++、Javaや.NET ,,のPython、PHP、Rubyとそうで。
Redisの7.4
キー値のNoSQLデータベースの開発と保守のC言語の開発を使用すると、キー値のデータベース・ストレージ・システムですが、非常に有効であるが、それはMQ機能、それが使用する軽量キューサービスとして使用することができますをサポートしています。チームと運用チームのRabbitMQとRedisのために、100万回を実施し、10万記録された実行時間に一度。試験データは、データ128バイト、512バイト、1K 10Kと4種類のサイズに分割されています。実験は：パフォーマンスデータは、Redisの比較的小さいチームは、RabbitMQのよりも高く、かつデータサイズが10Kを超える場合、Redisのは耐えられない遅い缶があるとき、チームは関係なく、データサイズの、Redisのは非常に良好なパフォーマンスを示してきたとき、しかし、チームのパフォーマンスのRabbitMQはRedisのよりもはるかに低いです。
7.5カフカ
：サブApacheの下で、分散の高性能実装を使用してメッセージキューシステムは、以下の特性を有する購読/スカラパブリッシュ
- 高速永続:,メッセージは、ディスク読み出しシーケンスのオーバーヘッドとゼロコピー機構を介してO（1）で永続的であってもよいです。
- 高スループット：共通のサーバ上率スループットは10W /秒のいずれかで達成することができます。
- 高集積：消費者の長い時間をオフラインでサポートトピック、メッセージが大きな蓄積します。
- 完全分散システム：ブローカー、プロデューサー、消費者は、複雑な均衡を自動化する飼育係によっては、自動的に配布用のネイティブサポートされています。
- 、ログデータとのHadoopシステムのオフライン分析用と同じ制限が、リアルタイム処理を必要とし、これは実行可能な解決策である：Hadoopのは、パラレルデータのロードをサポートします。
7.6 ZeroMQ
多くの場合、金融アプリケーションで使用される高スループット/低遅延のシナリオの開発のために設計された最速の知られているメッセージキューイングシステム、リアルタイムデータ通信のシナリオを重視。アドバンスト/複雑なキューが良くないのRabbitMQを有効ZMQが、開発者は技術、高い開発コストの組み合わせのために独自のフレームワークを必要としています。だから、ZeroMQは、ユニークな非ミドルウェアパターンを持つアプリケーション自体がサービスロジックの役割を完了ZeroMQ APIを使用することであるため、ソケットライブラリのように、あなたは、メッセージングサーバやミドルウェアをインストールして実行する必要があります。しかし、唯一の非永続キューZeroMQは、ダウンマシンならば、データが失われます。例えば：Twitterの送信データストリームとしてストームZeroMQを使用。
ZeroMQソケットは、トランスポート層から独立している：すべてのトランスポート層プロトコルのZeroMQソケットは、均一なAPIインターフェイスを定義します。デフォルトの内部サポートプロセス（インプロセス）、プロセス間（IPC）、マルチキャスト、TCPプロトコルは、単にプレフィックスを変更は、異なるプロトコル間の接続文字列を切り替えます。分散型でTCP通信へのローカルプロセス間通信からいつでもスイッチのコストを最小限に抑えることができます。接続確立プロセスの背後にZeroMQ、論理的な切断と再接続。
特長：
- ロックフリーキューモデル：クロススレッド（クライアントとのセッション）交換チャネル管との間のデータの間の相互作用、ロックフリーキューアルゴリズムCAS、非同期イベントは、パイプの両端に登録され、リードまたはパイプにメッセージを書き込みます読み書き時に、自動的にイベントがトリガされます。
- バッチ処理アルゴリズム：バッチメッセージ、最適化の適応性のために、バッチは、受信したメッセージを送ることができます。
- スレッド結合切り替えることなく、マルチコアCPUの下で：伝統的なマルチスレッドモード、セマフォまたはクリティカルセクションとは異なり、zeroMQは、複数のスレッド間を避けるために、結合ワーカースレッドを実行するために、マルチコア、各コアの利点をフルに活用しますCPUは、オーバーヘッド切り替えます。
8、比較の主要なメッセージングミドルウェア
総合選択のRabbitMQ
第二に、展開のRabbitMQ
1、インストールの依存関係
yumをインストールGCCのglibc-develのメイクのncurses-develのopensslの-develのxmlto socatに関するwgetの
RabbitMQのerlangベースの環境なぜなら2、あなたはアーラン環境をインストールする必要がありますので、
RabbitMQのとアーランの対応バージョンを確認します
https://www.rabbitmq.com/which-erlang.html
wgetのhttps://packages.erlang-solutions.com/erlang/rpm/centos/7/x86_64/esl-erlang_22.0.7-1~centos~7_amd64.rpm
RPM -ivh --nodeps ESL-erlang_22.0.7-1〜CentOSの〜7_amd64.rpm＃インストール
3、インストールのRabbitMQ
インストール
wgetのhttps://github.com/rabbitmq/rabbitmq-server/releases/download/v3.8.0/rabbitmq-server-3.8.0-1.el7.noarch.rpm
RPM -ivh --nodepsのRabbitMQサーバ-3.8.0-1.el7.noarch.rpm
コンソールのRabbitMQを有効に
RabbitMQの-プラグインはrabbitmq_managementを有効にします
ブート
上のchkconfigのRabbitMQのサーバ
スタートストップを再起動します
systemctl開始RabbitMQの-server.service
systemctlストップRabbitMQの-server.service
systemctl再起動RabbitMQの-server.service
オープンポート（ファイアウォールがオフになっている、必要とされていません）
ファイアウォール-CMD --zone =公共--add-ポート= 5672 / tcpの--permanent
ファイアウォール-CMD --zone =公共--add-ポート= 15672 / tcpの--permanent
ファイアウォール-cmdを--reload
ファイアウォール-CMD --list-ポート
ログイン
http：// IP：15672 /
ユーザー名：ゲスト、パスワード：ゲスト
出现ユーザーのみを経由してローカルホストにログインすることができます
39行程度のvi /usr/lib/rabbitmq/lib/rabbitmq_server-3.8.0/ebin/rabbit.app
将{loopback_users、[<< "ゲスト" >>]}、
{loopback_users、[]}に、
再起動
systemctl再起動RabbitMQの-server.service
すべてのユーザーを見ます
rabbitmqctlのlist_users
ゲストユーザを削除します
rabbitmqctlのDELETE_USERのゲスト
管理者のユーザー管理ユーザーのパスワードを作成します。
rabbitmqctl ADD_USER管理者の管理
adminロールの設定
rabbitmqctl set_user_tags管理者の管理者
管理者のためのアクセス許可を設定します
rabbitmqctl set_permissions -p /管理者 '*' '*' '*'