ストーム並列処理の「タスク」とは
素晴らしい記事「 ストームトポロジの並列処理を理解する 」に従ってTwitterストームを学習しようとしています
しかし、「タスク」の概念に少し混乱しています。タスクはコンポーネント（スパウトまたはボルト）の実行中のインスタンスですか？複数のタスクを持つエグゼキューターは、実際には同じコンポーネントがエグゼキューターによって複数回実行されると言っていますが、私は正しいですか？
さらに、一般的な並列処理の意味で、Stormは注ぎ口またはボルト用の専用スレッド（executor）を生成しますが、executor（thread）が並列処理に貢献しているのは複数のタスク？スレッドは複数のタスクを持っていると思います。スレッドは順次実行されるため、スレッドを一種の「キャッシュされた」リソースにするだけで、次のタスク実行のために新しいスレッドが生成されるのを防ぎます。私は正しいですか？
調査にもっと時間をかけた後、私は自分でそれらの混乱を解消するかもしれませんが、私たちはどちらもstackoverflowが大好きです;-)
前もって感謝します。
免責事項：私は 記事 を上記の質問で参照したように書きました。
しかし、「タスク」の概念に少し戸惑っています。タスクはコンポーネント（注ぎ口またはボルト）の実行中のインスタンスですか？複数のタスクを持つエグゼキューターは、実際には同じコンポーネントがエグゼキューターによって複数回実行されると言っていますが、私は正しいですか？
はい、そうです。
さらに、一般的な並列処理の意味では、Stormは注ぎ口またはボルト用の専用スレッド（executor）を生成しますが、複数のタスクを持つexecutor（thread）が並列処理に寄与するのは何ですか？
エグゼキューターごとに複数のタスクを実行しても、並列処理のレベルは向上しません。エグゼキューターは常に、そのすべてのタスクに使用する1つのスレッドを持っています。つまり、タスクはエグゼキューターで順次実行されます。
この記事で書いたように、次のことに注意してください。
- エグゼキュータースレッドの数は、トポロジの開始後に変更できます（
storm rebalanceコマンドを参照）。 - トポロジのタスク数は静的です。
そして、定義により、#executors <= #tasksの不変式があります。
したがって、エグゼキュータスレッドごとに2つ以上のタスクがある理由の1つは、トポロジをオフラインにすることなく、将来的にstorm rebalanceコマンドを使用してトポロジを拡張/拡大できる柔軟性を提供することです。たとえば、15台のマシンのStormクラスターから始めて、来週さらに10個のボックスが追加されることを知っているとします。ここでは、トポロジを15の初期ボックスで既に25マシンの予想される並列処理レベルで実行することを選択できます（もちろん、25ボックスより低速です）。追加の10個のボックスが統合されると、トポロジをstorm rebalanceして、ダウンタイムなしで25個すべてのボックスをフルに活用できます。
エグゼキューターごとに2つ以上のタスクを実行するもう1つの理由は、（主に機能的な）テストのためです。たとえば、開発マシンまたはCIサーバーが、マシンで実行されている他のすべてのものと並んで2つのエグゼキューターを実行できるだけの強力な場合でも、30のタスク（ここでは、エグゼキューターあたり15）を実行して、次のようなコードかどうかを確認できます。カスタムストームのグループ化は期待どおりに機能しています。
実際には、通常、エグゼキューターごとに1つのタスクを実行します。
PS：Stormが実際にスポーンすることに注意してください 裏でいくつかのスレッド 。たとえば、各エグゼキューターには、発信タプルの処理を担当する独自の「送信スレッド」があります。たとえば、「システムレベル」のバックグラウンドスレッドもあります。 「あなたの」スレッドと一緒に実行されるタプルの確認。 IIRC the Storm UIは、「あなたの」スレッドに加えて、それらの攻撃スレッドをカウントします。