Staged Event Driven Architecture (SEDA) 介紹
作者：朱之光
http://larryzhu.bokee.com
一、前言
二、當前流行的兩種併發處理編程模型
三、SEDA架構
四、小結
五、參考文獻
一、前言
Staged Event Driven Architecture (SEDA) 是加州大學伯克利分校研究的一套優秀的高性能互聯網服務器架構模型。其設計目標是：支持大規模併發處理、簡化系統開發、支持處理監測、支持系統資源管理。本文會先對兩種目前被廣泛使用的網絡服務器架構模型進行介紹。然後對SEDA進行詳細描述。
二、當前流行的兩種併發處理編程模型
1、 多線程服務器 (Threaded Server)
工作原理：對於每一個request，dispatcher會爲其創建並分配一個線程。該線程負責這個請求的處理。這種方式 又名（Thread-per-request）。
優點：執行粒度是整個完整的處理流程。處理邏輯清晰，容易開發。
缺點：是當隨着處理請求不斷增加，導致併發執行的線程數量太多。過多的線程數量導致系統在線程調度和資源爭用上的開銷過大。引起系統性能急劇下降。導致系統處理能力下降。
改進措施：線程池（Bounded Thread Pools）
系統最多隻能創建一定數量的線程。當所有線程都飽和運行時，新到達的處理請求只能等待，或者被拋棄。
缺點：
執行粒度仍然是完整的處理流程。難以檢測系統性能瓶頸的根源以及進行相應調整。/p>
2、 事件驅動併發處理(Event-Driven Concurrency)
將處理流程分割成多個步驟，每一個步驟都實現爲一個有限狀態機（FSM）。
工作原理：所有的處理請求會作爲Event進入系統。由Scheduler負責傳遞給相應FSM。FSM的處理結果也以Event形式輸出給Scheduler。新的Event會再次被Scheduler進行轉發給下一個FSM。直至處理完成。
優點：
1、隨着處理量的增加，系統負荷是以線形增長。當達到系統飽和處理能力後。系統的處理能力不會下降。
2、由於將各個處理步驟獨立實現，可以很容易的進行系統監測和調整。
缺點：
Scheduler的設計和實現過於複雜。針對於不同的應用和系統的邏輯變更需要不同的實現。
三、SEDA架構
(近似於Event-Driven Concurrency，但是沒有其中的Scheduler)
將每一個處理步驟獨立爲一個Stage。
Stage結構：
1、 一個接受輸入的Event Queue；
2、 一個應用開發者編寫的Event Handler；
3、 一個Controller用於對執行過程進行控制。包括併發線程數量，批處理數量，…;
4、 一個Thread Pool用於併發處理；
Stage的輸入通過Event Queue獲得。Stage的輸出會以Event形式推送到其他Stage的Event Queue中。Stage之間的這種連接關係由應用開發人員指定。
帶來的問題：Event Queue儘管減少了模塊間的耦合性，但是會降低響應速度。
四、小結：
SEDA架構將應用的整個處理過程分割爲多個步驟即Stage。每個Stage可以獨立進行開發。同時Stage之間通過Event Queue來進行通信，可以降低耦合性。可以以很小的成本來適應將來的系統邏輯變化。
同時系統提供了標準的資源控制，使得應用開發人員只需要專注於實現Event Handler的內部邏輯。而無須關注多線程、資源共享、…
同時可以在運行時對於每一個Stage的運行情況進行監測以及調整。
五、參考文獻：http://www.eecs.harvard.edu/~mdw/papers/seda-sosp01.pdf