Srinath，科學家，軟體架構師。Apache Axis2項目的聯合創始人，Apache Software基金會的成員，WSO2流處理器（wso2.com/analytics）的聯席架構師。 Srinath通過不懈的努力最終總結出了30條架構原則，他主張架構師的角色應該由開發團隊本身去扮演，而不... ...
轉載自：https://blog.csdn.net/DataScientist/article/details/7184248 修改了一些錯別字，調整優化了一下格式，修複了一些鏈接
SEDA高性能互聯網伺服器架構模型（1）
最近研究雲存儲相關的系統，Oceanstore和Cassandra都用到了SEDA編程模型。 （註：關於Cassandra的代碼結構和SEDA模型的使用情況可以參考這篇文章： http://prettyprint.me/2010/05/02/understanding-cassandra-code-base/，裡面還有一張時間序列圖來說明程式的流程。 （轉載說：文章已不存在，博客還在：http://prettyprint.me/prettyprint.me/index.html）） Staged Event Driven Architecture (SEDA) 是加州大學伯克利分校研究的一套優秀的高性能互聯網伺服器架構模型。 其設計目標是：支持大規模併發處理、簡化系統開發、支持處理監測、支持系統資源管理。 它的核心思想是把一個請求處理過程分成幾個Stage，不同資源消耗的Stage使用不同數量的線程來處理，Stage間使用事件驅動的非同步通信模式。 http://www.eecs.harvard.edu/~mdw/papers/seda-sosp01.pdf這篇文章是介紹SEDA最好的材料。（轉載說：文章已不存在，同pdf見：https://www.mdw.la/papers/seda-sosp01.pdf，或https://github.com/mdwelsh/mdwelsh.github.io/blob/main/papers/seda-sosp01.pdf） 傳統的高性能伺服器處理模型無非就是兩種：多線程處理模型和事件驅動處理模型。 關於這兩種模型網上有很多資料了。http://www.iteye.com/topic/432134這篇文章（轉載說：文章已經不存在）把多線程模型和SEDA模型的實驗對比以數字的形式展現出來了。而且詳細描述了為什麼多線程模型在某些場合不適用。簡單理解就是傳統多線程模型有的時候由於處理邏輯不同的線程對資源的需求不同，會導致有些CPU空閑，而另外一些CPU卻浪費了大量的時間線上程的調度上，資源利用率不高。本質原因就是不同線程的處理邏輯對資源的需求不同。 SEDA模型處理的流程是：一個請求被分成多個stage處理，每一個stage各做各的，一個請求的多個stage可以串列化也可以並行化。stage外部使用Event-Driven，新到的請求放到event queue中，整個SEDA框架從該Stage對應的thread pool中的挑選一個線程運行Event Handler來處理事件，Event Handler處理完後將請求派發到下一個stage。 下麵是一個基於SEDA的處理流程：
對於SEDA中的每一個stage，它由上面的三部分構成：
1） 輸入的event queue。SEDA中的event queue是限定大小的，代碼里是通過鏈表來實現的。所以如果event queue的大小到達閾值，新到的event會被拒絕或轉發到特定的stage。
2）thread pool：這個線程池對應用是通明的，並且每個stage的線程池是相互獨立的。針對請求量及特點，線程池可以靜態的調節，不至於某個stage的線程池耗盡所有的資源。
3）event handler，event handler接受event，做詳細的用戶指定的邏輯處理後將event分發到其餘stage。event handler需要應用開發者編寫。
針對各個stage運行時的狀態，SEDA引入resource controller來調解stage的資源分派和調節參數等。焦點的兩個Controller是thread pool controller和batching controller。thread pool controller用來控制threadpool的運轉時大小，比如當event queue很大時，就多分配些線程，反之則減少線程數。batching controller用來節制event handler同時處理的event的併發量（batching factor），當batching factor增大時，增長了吞吐量但event均勻相應時間會變長，當batching factor變小時，環境相同。batching controller的控制結果使得batching factor的高低動搖來控制吞吐量和響合時間。這兩個controller類似操作系統里進程調度的原則，在延遲和吞吐量中選擇平衡。
下麵是http://www.eecs.harvard.edu/~mdw/papers/seda-sosp01.pdf這個文章中介紹的一個基於SEDA的HTTP的實現。整個請求的過程分為以下幾個Stage: Socket listen,Socket read, HttpParse, PageCache, CacheMiss, file I/O, HttpSend, Socket write等，不同stage有不同的thread pool和controller，並配置不同的參數，各個stage之間通過Event queue來傳遞消息。下一篇文章我將從源代碼的角度分析這個HTTP伺服器。
目前EMC的Atmos產品和Google的產品中都有用到SEDA。而國內互聯網企業由於實際工程應用中往往開發效率和運行效率要綜合考慮。而SEDA的開發效率相對較低，所以現在看國內各廠高負載高併發系統開發還是傳統多線程占主導。
PS:http://matt-welsh.blogspot.com/2010/07/retrospective-on-seda.html
這是SEDA的作者最近對這個系統的回顧中反思了他當初設計系統的得失。（需要FQ）
A Retrospective on SEDA
————————————————
版權聲明：本文為CSDN博主「DataScientist」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/DataScientist/article/details/7184248
