メッセージキューのI.概要
メッセージキューミドルウェアは、主にデカップリング、非同期メッセージング、トラフィックおよびその他の問題フロントカット、高性能、高可用性、スケーラブルなアーキテクチャおよび最終的な一貫性のアプリケーションを解決するために、分散システム、重要な構成要素です。現在、より多くのメッセージキューを使用すると、ActiveMQの、RabbitMQの、ZeroMQ、カフカ、MetaMQ、RocketMQを持っています
第二に、メッセージキューのシナリオ
以下は、メッセージキューは、一般的に実用的なアプリケーションシナリオで使用されている説明します。非同期処理、デカップリングの適用は、前部及び交通情報通信を4つのシーンカット。
2.1非同期処理
シーンの説明：ユーザー登録した後、あなたが登録したメールやSMSの登録を送信する必要があります。1.従来の方法は、二つの連続様式を有する2平行に
A、シリアル：データベースに正常に登録情報の後、登録したメールを送信して、登録SMSを送信します。以上の3つのタスクが完了した後、クライアントに返します。
B、パラレル：データベースに正常に登録情報の後に、とは、登録SMSを送信、登録されたメールを送信します。以上の3つのタスクが完了した後、クライアントに返します。違いは、処理時間のシリアル、パラレル方法を向上させることができるということです
各サービス・ノードは、他のネットワークオーバーヘッドなどを考慮しない3つの50ミリ秒クロックを使用することは、時間が直列に150ミリ秒は、並列時間は100ミリ秒であってもよいものとします。
単位時間あたりのCPUによって処理された要求の数が一定であるため、CPU1 100秒のスループットと仮定する。シリアルモード要求の量は、一秒のCPU内で処理することができる7倍（150分の1000）です。要求の並列処理の量は、10（100分の1000）で
要約：上記の場合で説明したように、システム（並行性、スループット、応答時間の量）の伝統的な方法の性能がボトルネックになります。どのようにこの問題を解決するには？
メッセージキューを導入し、サービスロジックは、必ずしも意志非同期処理。次のように変換した後、構造は以下の通りであります：
上記の規則によれば、ユーザの応答時間は50ミリ秒であるデータベースに登録情報に対応する時間です。登録メッセージの後、SMSメッセージキューは直接書き戻される送るので、メッセージキューの書き込み速度が速く、無視することができ、ユーザーの応答時間は50ミリ秒です。QPSあたり20にシステムスループットすることがアーキテクチャの変更。連続3倍は、並列に3倍、比較して増加しました。
デカップリングの2.2応用
シーン記述：ユーザの注文後、注文システムは、在庫システムに通知する必要があります。伝統的なアプローチは、インターフェースの在庫システムの注文システムコールということです。図は次のとおりです。
従来のモデルの欠点：在庫システムにアクセスできない場合は、受注マイナス在庫が順序は、システムのカップリング受注や在庫システムの障害が発生し、その結果、失敗します
どのような問題を解決するには？以下に示すように、アプリケーション・プログラムのメッセージキューの導入後：
注文システム：単一のユーザー、永続性を完了するための処理システムの後、単一の成功メッセージキューにメッセージを書き込み、ユーザーの注文を返す
単一のメッセージへのサブスクリプション、プル/プッシュ方式を使用して、情報取得受注、在庫：在庫システムを注文の情報システム、インベントリ操作
の場合：次のシングル在庫システムが正常に動作することができないとき。通常の順序には影響しませんが、順序ので、注文システムは、メッセージキューは、もはや他の追従動作を懸念している書き込みません。アプリケーションシステムと在庫管理システムを実現するためのデカップリング
2.3フローフロントをカット
フローフロントは、一般的に広くラッシュ又はスパイク活動に使用されるメッセージキュー一般的なシナリオ、グループに切断されます。
シナリオ：スパイク活動、通常ので、あまりにも多くのトラフィックの、トラフィックの急増につながるには、アプリケーションがハングアップします。この問題を解決するために、一般的には、フロントエンドアプリケーションでメッセージキューを追加する必要があります。
、数の活動を制御することができ
、B、短い時間の用途に圧倒されたトラフィックを緩和することができます
ユーザの要求は、サーバーは、最初に書かれたメッセージ・キューを受け取ります。キューサイズが最大数を超えた場合、ユーザの要求または廃棄されたが、直接エラーページにジャンプします。
スパイクサービス情報要求メッセージキュー、その後の処理を行います
2.4ログ処理
ログ処理は、カフカのアプリケーション、ログ転送を解決するために多くの問題としてログ処理とメッセージキューを意味します。次のようにアーキテクチャの簡素化
クライアントのログ収集は、書き込みキューカフカによって書かれた時限ログデータの収集を担当し
たデータは、受信、記憶および転送を担当してログインし、カフカのメッセージキュー
のコンシューマサブスクリプションを、データカフカキューをログ：ログ処理アプリケーション
2.5メッセージ・コミュニケーションズ
消息通讯是指，消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯。比如实现点对点消息队列，或者聊天室等
点对点通讯：
客户端A和客户端B使用同一队列，进行消息通讯。
聊天室通讯：
客户端A，客户端B，客户端N订阅同一主题，进行消息发布和接收。实现类似聊天室效果。
以上实际是消息队列的两种消息模式，点对点或发布订阅模式。模型为示意图，供参考。
三、消息中间件示例
3.1电商系统
消息队列采用高可用，可持久化的消息中间件。比如Active MQ，Rabbit MQ，Rocket Mq。
（1）应用将主干逻辑处理完成后，写入消息队列。消息发送是否成功可以开启消息的确认模式。（消息队列返回消息接收成功状态后，应用再返回，这样保障消息的完整性）
（2）扩展流程（发短信，配送处理）订阅队列消息。采用推或拉的方式获取消息并处理。
（3）消息将应用解耦的同时，带来了数据一致性问题，可以采用最终一致性方式解决。比如主数据写入数据库，扩展应用根据消息队列，并结合数据库方式实现基于消息队列的后续处理。
3.2日志收集系统
分为Zookeeper注册中心，日志收集客户端，Kafka集群和Storm集群（OtherApp）四部分组成。
Zookeeper注册中心，提出负载均衡和地址查找服务
日志收集客户端，用于采集应用系统的日志，并将数据推送到kafka队列
Kafka集群：接收，路由，存储，转发等消息处理
Storm集群：与OtherApp处于同一级别，采用拉的方式消费队列中的数据
转自https://blog.csdn.net/wqc19920906/article/details/82193593