併發計算模型BSP與SEDA

 

1    BSP批量同步並行計算

BSP(Bulk Synchronous Parallel)批量同步並行計算用來解決併發編程難的問題。名字聽起來有點矛盾，又是同步又是並行的。由於計算被分組成一個個超步(super-step)，超步內並行計算而且結點間不能通訊。在超步之間設置同步柵欄(barrier synchronization)，計算完成後相互通訊，所有完成後才能繼續下一個超步。

2 SEDA階段式事件驅動架構

SEDA(staged event-driven architecture)分階段的事件驅動架構。它不一樣於經典的基於線程的併發處理架構，也區別於現今流行的事件驅動。

 

 

Ø  基於線程的併發：資源使用率高(上下文切換，鎖爭奪)，過多的線程難以實現高吞吐量、低響應時間。傳統作法是限制總的線程數。

Ø  事件驅動的併發：用少許事件處理線程配合許多狀態機(FSM)，提供高效和可擴展的併發性能。FSM間沒有錯誤和性能隔離，而且FSM代碼不能阻塞。

事件驅動的有限狀態機在Web服務器中很常見。

 

接下來要說的就是SEDA了，它具備如下特色：

Ø  將服務分解爲用隊列分隔開的階段

Ø  每階段執行請求處理的一部分

Ø  階段內事件驅動(非阻塞的)

Ø  隊列的引入方便了執行邊界的隔離

Ø  每階段包含一個線程池

Ø  然而線程不對應用程序暴露

Ø  線程池的大小根據須要會自動擴張或收縮

能夠看出關鍵詞有三個：階段、隊列、線程池。

隊列

首先，經過隊列咱們可以實施一些控制策略(admission control policy)。例如經過閥值、速率控制是否入隊仍是阻塞(將壓力反彈回去, backpressure)、服務降級、丟棄。

其次，各個線程只在階段內執行，實現了性能隔離、模塊化和獨立的加載管理。

最後，顯式的事件分發使應用程序可以追蹤事件流，監控隊列長度來檢測瓶頸。

線程池

觀察輸入隊列長度，動態添加線程，或移除空閒線程。觀察輸出速率，找到高吞吐量與低響應時間的平衡點。

吞吐量與響應時間的關係

「計算機系統的整體性能標準是吞吐量和響應時間。

吞吐量是對單位時間內完成的工做量的量度。示例包括：每分鐘的數據庫事務；每秒傳送的文件千字節數；每秒讀或寫的文件千字節數；每分鐘的 Web 服務器命中數

響應時間是提交請求和返回該請求的響應之間使用的時間。示例包括：數據庫查詢花費的時間；將字符回顯到終端上花費的時間；訪問 Web 頁面花費的時間

這些度量之間的關係很複雜。有時可能以響應時間爲代價而獲得較高的吞吐量，而有時候又要以吞吐量爲代價獲得較好的響應時間。在其餘狀況下，一個單獨的更改可能對二者都有提升。可接受的性能基於合理的吞吐量與合理的響應時間相結合。

一般，平均響應時間越短，系統吞吐量越大；平均響應時間越長，系統吞吐量越小。可是，系統吞吐量越大， 未必平均響應時間越短。由於在某些狀況（例如，不增長任何硬件配置）吞吐量的增大，有時會把平均響應時間做爲犧牲，來換取一段時間處理更多的請求。

舉個例子：一個理髮店，只有一個理髮師、一把理髮椅子、一張方便客人等待的長凳。理髮師一次只能處理一個客戶，其餘等待的用戶顯得很不耐煩，外面打算進來理髮的人也放棄了在這家店理髮的打算……有一天，理髮師有錢了，他多買了2把理髮椅子。這樣他能夠同時給3我的理髮：當其中一我的理到必定階段須要調整或定型的時候，他就轉向另一個客戶爲其服務，依次類推。這樣，他發現一天內他能夠理的人數比之前增多了，可是還會有一些後來的客戶抱怨等待時間太長。後來，理髮師招了2名學徒幫他一塊兒幹活。他發現這樣一來天天的理髮效率增長了將近2倍，並且客戶的等待時間也明顯減小。可是成本增多了，理髮用具、洗髮水、發工資，這讓他以爲開個理髮店也要精打細算。「

以上面Web服務器中的事件驅動有限狀態機爲例，經過SEDA改造後，其架構就變爲：

FSM中的各個狀態被劃分紅一系列的階段，由不一樣的隊列隔離開。每一個階段能被獨立管理，而且階段間能夠或串行或並行或二者組合的方式地執行。 

參考資料

1 The Staged Event-Driven Architecture for Highly-Concurrent Server Applications

2 SEDA: An Architecture for Scalable, Well-Conditioned Internet Services