インターネット上の情報は非常に良いされている、と私は嵐に遭遇行うために自分自身を適用したとき、私はこの問題をたくさん書いている
と、次の知識は個人的な経験に焦点を当て、非常に包括的な関与していない、知識の概要を
記事のランダム検索、私はかなり良い感じ
https://www.cnblogs.com/peak-c/p/6297794.html
https://blog.csdn.net/weiyongle1996/article/details/77142245
（より詳細には、上記のリンクを、ここで彼らは知識の焦点を考えるだけ）あります
私は嵐のフレームワークを学ぶことは、次の側面に焦点を当てるべきだと思います
（もちろん、これは個人的である、または時間をかけて、認知変化は、私は別の角度から問題を見ていきます）
アーキテクチャー・システムの
知識の概念
の使用のための
チューニング説明
コード綿密な
プロジェクトのアプリケーション
アーキテクチャシステム
https://blog.csdn.net/weiyongle1996/article/details/77142245は
その公式のうち元、上記のリンクを参照することができ、私は追加することは何もありません。
図アーキテクチャは、3つの部分に分割される
雨雲マスターノード：嵐の提出、スーパバイザ・ノード管理などを担当するトポロジ
ノードからスーパーバイザ：特定のコードを実行する責任を、上記の概念は、タスクワーカー有することが重要である
飼育係分散コーディネート：飼育係機能、メタデータ管理に使用される運命、そしてその多くの優れたプロジェクトの誕生に基づいて配布され
、HBaseの、Hadoopのは、カフカ（カテゴリはまた、春の雲の中に、私は実際の状況のダボに遭遇したことができます見に注意を払うように嵐のノードを保存ユーレカへの応用）、。
システムアーキテクチャは、システム構造の突然の理解の大きな側面から人々を可能にすることです徐々にアーキテクチャ図の意味を表して理解するためには、さらなる研究で、部外者とインサイダー外観を与えるためです。
知識概念：
トポロジ：フローの概念で構成される点線接続にパターンの形状に対応する非環式有向グラフ概念有向非巡回グラフ、ストリームフロー、抽象点非循環有向グラフ組成物。
前記ユニットは、構造ボルトの口の組み合わせです。
タスク：レアル（エグゼ）のスレッドで実行スケジューリングの最小単位として、労働者に、私たちはコードを書く論理的な概念を実行するには、デフォルトでは1の対応関係である：1、それはコードによって変更することができます。
労働者：プロセスは、Javaに対応し、スーパーバイザーのセルに属するノード。
エグゼキュータ：Javaスレッド、スケジューリング部、チューニングキーに属する労働者に対応する
データソースのソース、抽象的な概念、我々のシステムの構造のほとんどが作られ、取得/入力データ処理システム、および：注ぎ口ストレージ、バック適切な場所に。
ボルト：データ処理段階、重要なノードをストリーミングは、フローを複数処理することができます。
ストリーム：炉心流量を計算します。
ストリームグループ：大規模データ計算をストリーミングし、分割統治の概念の適用、およびMapReduceのコンセプトに暴露した後、あなたは、地図の役割を知っているアリペイ毎年年次声明のアナロジーを取る、データの宝の計算量を支払うことになり、私が考えることはできません特定の番号。すべてのデータは、各年の年間法案の計算で一人一人のために計算し、一緒地図、各ユーザのデータをまとめて道（地図段階）で、その後、（削減）を計算して（特定の実装を知らないが、どんなにれますどのようにそれは、常に分割統治）の考え方をエスケープしないん。
パケットをストリーミング、分割統治の始まりです。
使用のための指示書
どこでもオンラインDEMO
説明チューニング：
次がある
スレッドの数は、
データベースへの接続数
...様々な技術プール数プールのリソース
サイクルとしてまでに処理注ぎ口、取得したデータ量maxSpoutPending
嵐のタイムアウト再送メカニズムの処理時間をTOPOLOGY_MESSAGE_TIMEOUT_SECSデフォルトの30秒、処理速度に応じて、ノードの数は、リソースを調整する
××（できるだけ小さいブロットを監視するために、ログの論理時間を行うことにより、時限方法の使用）（フォーカス）処理速度
データの量
データベースインデックス（またはインデックスのNoSQL）
観察ストームUI（スパウト監視処理圧力、処理時間、失敗の数は長い処理.bolt、治療の失敗の数、処理圧力）
コードの深さの
メッセージ確認メカニズムのAck嵐の理解
プロジェクトのアプリケーション
プロジェクトは、私は、サイト統計指標（オンラインユーザーのPVのUV番号など）により、ユーザのユーザ電気カフカに送られるサプライヤー、嵐を取ることによって、ユーザの行動、操作履歴の分析のためのシステムを使用して、エンドユーザーのストレージに提示します。
プロジェクトに遭遇した最大の問題は、メッセージの処理を繰り返すことです、嵐の前のメカニズムを理解していない、注ぎ口と考えられてきた発見のメカニズムを理解するために、（カフカで）繰り返しデータを取った、故障メカニズムのsotrm後に確認が実行されますメッセージメカニズムを繰り返します。それはあまりにも多くの時間がボルトのパフォーマンスログを印刷することで、嵐のUIで失敗し、取り扱いの際には長すぎる見つけ、プラス指数に加え、処理スレッド、メッセージ処理量を加えた注ぎ口の数は、メカニズム、大幅に強化されたパフォーマンスを噴出ことがわかりました。
並行性：単一ワーカースレッドの数は、我々は通常の方法では、別のアプリケーションが完全にマシンのパフォーマンスを利用しないように設計されなければならないかどうかを判断するために、CPUの監査に設定され、大きな問題となっていた、私たちのtomcatの一般的な同時実行だけでなく、したがって、他のソフトウェアシステムによって調整することが100+は、数千人の概念で実現するアイデア、nginxの5ワットを使用するには、網状特定のシナリオでの教義の嵐に、この時間。