閑聊SEDA分段式事件驅動架構

SEDA是10年前提出的一個理論
目的是實現高效能的網路伺服器

由7篇論文和一個參考實現的庫組成
都在這裡 http://www.eecs.harvard.edu/~mdw/proj/seda/
有興趣的自己去看
在SEDA提出之前，
網路伺服器的模型發展經曆過兩個階段

第一個是每訪問每線程模式
每個訪問進來，都新起一個線程為其服務
比如servlet之類的處理模式

我們也可以很簡易的自己花100行代碼，寫個簡單的靜態httpserver
處理完了情況，線程銷毀掉
下次有請求，再建立
訪問量大了，線程數急速增大

而且建立和銷毀也很頻繁
導致系統本身消耗太大
為瞭解決這個問題，
線程複用的技術就出現了
這就是線程池

請求進來以後，不是建立線程處理
而是從線程池中擷取一個閒置線程來處理
訪問量大了以後，所有的線程都在忙

新來的訪問，就排隊等待或者丟棄
線程池的模型就出來了
一組線程、一個隊列、一個丟棄策略

這個模型比第一個來，可以說是質的飛躍
無論是效率還是穩定性
但是，我們都知道，
伺服器基本上是一個通用設施，對於不同的請求，不同的處理，

其處理特點是不一樣的
而且，對網路伺服器來說，後端的業務處理可能很慢
這是，線程就會被佔用，很長時間無法釋放

比如一隻在等待一個block住的本地io，之類的操作
線程一直在空轉
如果丟回線程池，
給別的任務複用
效能將會有進一步的提升

並且極大提升了系統的整體輸送量
這個就是SEDA的思想
更小粒度的複用資源
具體的做法就是stage
分段處理

前端的網路接入，中間的伺服器web處理，後端的業務處理，或者還有其他的處理，
分成多個段。
各段之間都是獨立的處理單元
都是一個前面提到的模式：一組線程、一個隊列、一個丟棄策略

這樣，web處理的線程就不會被後端很慢的業務處理線程阻塞
web服務了一個請求，丟給後端業務處理以後
直接再處理下一個請求即可

業務處理線程完成以後，通過事件通知web處理層
web處理線程，再返回給調用方
這就是事件驅動
整個流程就是SEDA

分段式，事件驅動，架構

通過分段，達到更小粒度的資源複用

同時能夠通過調整每段的線程數和隊列大小，最佳化資源配置，
畢竟有的步驟處理的慢，有的處理的快
這樣達到系統整體的更優配置

通過事件驅動，把不同階段的處理串起來

這個結構，比前面說的兩種結構
效能更高，輸送量更大，
並且每段都可以看做一個流量的緩衝，
系統更穩定
所以，目前各種要求高效能高穩定的各種中介軟體，

一般都是基於SEDA的
講完了。
提問環節