基於SEDA的異步框架設計與實現
二、為什么使用SEDA
目前，面對並發環境，主流互聯網服務器編程模型有兩種：多線程模型以及事件驅動模型。但是這兩個模型都不足以解決這個問題。我們來首先看一下這兩種編程模型。
1、多線程並發模型
多線程並發模型是目前最普遍的服務器編程模型，該模型的架構如下圖所示：
該模型針對每一個請求，會為其創建並分配一個線程。該線程負責這個請求的處理。該模型的優點：執行粒度是整個完整的處理流程。處理邏輯清晰，容易開發。但與此同時缺點也很明顯：如果處理過程中某一步驟出現長時間調用（例如網絡通信、I/O磁盤讀寫等），則會阻塞后續的請求，造成資源的浪費。並且，當隨着處理請求不斷增加，導致並發執行的線程數量太多。過多的線程數量導致系統在線程調度和資源爭用上的開銷過大。引起系統性能急劇下降。導致系統處理能力下降。
2、事件驅動模型
同時，我們也能看到，很多系統也傾向於使用事件驅動模型，該模型的模型圖如下圖所示：
該模型的思想為：將處理流程分割成多個步驟，每一個步驟都實現為一個有限狀態機（FSM），所有的處理請求會作為事件進入系統，由調度器負責傳遞給相應的狀態機，狀態機的處理結果也以事件的形式傳給調度器，新的事件將再次被調度器轉發給下一個狀態機進行處理，直至處理完成。該模型的優點在於，由於將各個處理步驟獨立實現，可以很容易的進行系統監測和調整。但是其缺點也不容忽視，即：由於Scheduler的設計和實現過於復雜，針對於不同的應用和系統的邏輯變更需要不同的實現，導致采用這一模型構建出的系統將十分龐大和難以控制。
綜上所述，主流的多線程編程模型以及事件驅動編程模型雖然都各有其優勢，但同時也都有其不可避免的缺陷，並不適合在高並發的環境下進行成熟系統的開發。所以這就是為什么我們要選擇其他的模式來進行系統開發。以下介紹SEDA架構思想。
3、階段性事件驅動（SEDA）模型
針對上述現有主流並發架構之缺陷，若能夠實現一種良好支持高並發，並且能夠對性能需求自適應的架構，則將在很大程度上優化和提升服務器性能，既能夠提高運行速度，又可以減少服務器壓力，實現了公司利益與用戶體驗的雙贏。因此，為汲取多線程與事件驅動模型之優點，最大程度規避這兩者之缺點，以實現較好的高並發服務器架構，SEDA便應運而生。
SEDA(Staged Event Driven Architecture)是一種階段性事件驅動的服務器應用程序架構。它是Matt Welsh博士於加州大學伯克利分校提出的一個高性能應用服務器模型。SEDA架構整合了多線程的服務器模型和事件驅動的服務器模型的優勢，它可以高效地管理和控制服務器資源，良好地適應高並發環境，SEDA被設計成一個可伸縮的高可用服務器架構。
應用服務器之請求處理步驟通常是復雜的、基於事件驅動處理的有窮狀態機（FSM），所以實現服務器程序過程就類似用程序實現有窮狀態機過程。下圖所示的即是一基於SEDA模型http服務器有窮機狀態圖：
SEDA架構能對有窮狀態機進行分析，爾后將相關狀態聚集在同一Stage中，Stage間采用隊列的方式來進行通信。每一個Stage皆完全獨立，均擁有自己的線程池，以及為了專門處理到達這一步驟所必須進行的工作。所有的Stage均通過自身事件隊列連接在一起，構成完整的請求處理網絡。性能控制器和動態線程池依請求的繁忙程度動態來調整線程池的大小，以達到系統資源的最有分配。每一個Stage由下述四部分組成：
(1) 事件隊列：用以維持Stage間之通信。
(2) 事件處理器：用以執行請求到這一個Stage中所應執行的工作。
(3) 線程池：用以提供事件處理器且可以並發執行事件處理之環境。
(4) 性能控制器：用以對該Stage資源（線程數、隊列長度等等）進行調整。
通過這四部分的協作配合，每一個Stage都可以很好地運行，並且可以控制資源的使用。已經過Stage處理完，若沒有后續工作，即可以回收線程池中的線程，來供給其他Stage使用。Stage結構如下圖所示。
在SEDA架構中，基本的處理單元稱為階段（Stage），一個階段由事件隊列、動態線程池、事件處理器和一個性能控制器四個組件構成。SEDA將一個請求的處理過程分解為一系列的階段，階段之間通過事件隊列聯系，開發人員只負責每個階段的服務邏輯以及階段間的連接邏輯，而由各個階段自身負責資源管理以及負載適應功能。使用這種解耦拆分可以使系統達到高並發性、對負載變化的良好適應性以及高度的可縮放性。