SEDA（Staged Event Driven Architecture）とは何ですか？
SEDA：条件の整ったスケーラブルなインターネットサービスのアーキテクチャ
「SEDAはステージングされたイベント駆動型アーキテクチャの頭字語であり、複雑なイベント駆動型アプリケーションを一連のステージはキューで接続されています。 "
これはアーキテクチャであり、SEDAには多くの実装があることを理解しています（ ウィキペディアの記事 を参照）。 「ステージ」とは何ですか？誰かが、ステージングされたイベント駆動型アーキテクチャの完全な高レベルの要約と、それが従来の（ステージングされていない？）イベント駆動型アーキテクチャとどのように異なるかを説明できますか？
ステージは「イベント」に似ています。アイデアを単純化するために、SEDAをそれらの間でメッセージを送信する一連のイベントと考えてください。
この種のアーキテクチャを使用する理由の1つは、ロジックをフラグメント化して接続し、各イベントを分離できることです。主に、低レイテンシ要件の高性能サービスが適しています。
Java TPEを使用すると、各ステージの状態、スループット、エラー、レイテンシーを監視し、パフォーマンスのボトルネックがどこにあるかをすばやく見つけることができます。また、優れた副作用として、コードを使用すると、それらを簡単にテストして、コードカバレッジを増やすことができます（私の場合）。
ちなみに、これはCassandra（NoSQL）とMule ESB（AFAIK）の内部アーキテクチャです。
元の論文を読むことをお勧めします（申し訳ありませんが、リンクが重複しています）：
これは、SEDAをモデル化するために作成したフレームワークですJava EE： http://code.google.com/p/seide/
実生活でのスレッドアーキテクチャと段階的イベントドライブアーキテクチャ：
あなたがレストランを持っていると想像してください。さて、それはどのように機能しますか？
「スレッドアーキテクチャ」の場合：
- 顧客が到着します
- ウェイター（a）は彼/彼女に行きます
- ウェイター（a）は彼/彼女を1つの利用可能なテーブルに連れて行きます
- ウェイター（a）が注文を取ります
- ウェイター（a）が注文を調理します
- ウェイター（a）がテーブルに注文する
- ウェイター（a）は、クライアントが食事を終えるまで支払いを待ちます
- ウェイター（a）はクライアントを連れ出します
この場合、ウェイターはプロセス全体を通してクライアントと一緒にいます。サーバーに10個のスレッドがある場合、10個の接続を同時に処理できます。
sEDAと：
- 顧客が到着します
- ウェイター（a）は彼/彼女に行きます
- ウェイター（a）は彼/彼女を1つの利用可能なテーブルに連れて行きます（そして別のクライアントが来るために戻ってきます）
- ウェイター（b）が注文を取ります（多くのI/O、時間がかかります）
- クックは注文を調理します
- ウェイター（c）がテーブルに注文する
- ウェイター（d）は、クライアントが食事を終えるまで支払いを待ちます
- ウェイター（e）がクライアントを連れ出します
この場合、さまざまな種類のアクターがアクティビティを実行します。これにより、時間のかからないアクティビティでアクターを再利用でき、結果がより効果的になります。確かに、これはレストランの仕組みです（おそらく、ウェイターのより多くのインスタンスが同じ人ですが、料理人は間違いなくそうではありません）。
これは極端な例であり、もちろんスレッドサーバーを使用すると、いくつかの非同期タスクを実行できます。これは理論的な例にすぎません。
ドキュメントは github で入手できます。
ドキュメントに記載されているSEDA： "SEDA内の処理の基本単位はステージです。ステージは、イベントハンドラーで構成される自己完結型のアプリケーションコンポーネントです。着信イベントキュー、およびスレッドプール...各ステージは、スケジューリングとスレッド割り当てに影響を与えるコントローラーによって管理されます。ステージスレッドは、着信イベントキューからイベントのバッチをプルし、アプリケーションが提供するイベントハンドラーを呼び出すことによって動作します。イベントハンドラーは、イベントの各バッチを処理し、他のステージのイベントキューにイベントをキューイングすることにより、0個以上のイベントをディスパッチします。 "
私にとっては、アプリケーションフローの論理的なモジュール化としてステージを設計できます。それは、機能性、関心の分離、パフォーマンス、運用および保守に基づく可能性があります。
添付のPDFは、ものを分離するためのイベントキューの必要性、コンポーネントの最大効率を達成するための論理的補償、それを超える既存のリソースを効率的に再利用する方法について言及しているので、読んでいただきたいと思います。アプリケーションは、ネットワーク、ストレージ、CPUサイクルなどのように実行されています。
平行線を引くために、最初から最後まで何かを組み立てて連続して作業した組立ラインの労働者は生産性が低下したという研究がありますが、彼らが孤立して単一の仕事をし、部分的に組み立てられたユニットを次のグループに渡すと、それらのそれぞれが彼/彼女の仕事を管理するのに効率的になりました。基本的に、何かを組み立てるフローは複数のステージに分割され、それぞれまたはグループのグループがステージで作業する責任がありました。
ここで行われたのは、各個人またはグループの周りのフレームワークと、ある個人/グループから別の個人/グループへの通信モードを有効にしてセットアップすることだけでした。これで、各個人/グループと彼の周りに設定されたフレームワークをステージと比較できます。
SEDAにイベントディメンションを追加するには、個人グループが互いにどのように通信するか、および関連するイベントの数について考えます。たとえば、ステージ1の人がステージを完了するためにナットとボルトを使い果たしたとすると、彼らはすぐに注文セクションのマネージャーにナットとボルトについて通知します。注文セクションのマネージャーが、別のステージ6の人から、ナットとボルトがなくなったという同様の要求を受け取った可能性があります。現在、彼は中央のポイント（SEDAのコントローラーのようなもの）と、注文のリクエストを保持しているすべてのエントリが配置されているExcelシート（SEDAのキューのようなもの）で要求を確認します。 2つの注文リクエスト（SEDAでのスレッドとスケジュールの管理）を送信する代わりに、それらを組み合わせて一度に注文します。
これで、複数のコンポーネントを持ち、さまざまなイベントを相互に送信し、コントローラーがそれらを消費してそれに応じて動作するようなメカニズムがソフトウェアアーキテクチャにある場合は、非常に優れた段階的なイベント駆動型のセットアップが行われている可能性があります。