SEAD架構介紹

因爲這個架構沒怎麼學習，只是簡單作一下記錄，聽說 Cassandra就是用架構實現的

1、傳統併發模型的缺點

基於線程的併發

特色：
每任務一線程
直線式的編程
使用資源昂高，
context切換代價高，競爭鎖昂貴
太多線程可能致使吞吐量降低，響應時間暴漲。

 

基於事件的併發模型

特色：
單線程處理事件
每一個併發流實現爲一個有限狀態機
應用直接控制併發
負載增長的時候，吞吐量飽和
響應時間線性增加
 

2、SEDA架構

特色：
(1)服務經過queue分解成stage:
   每一個stage表明FSM的一個狀態集合
   Queue引入了控制邊界
(2)使用線程池驅動stage的運行:
   將事件處理同線程的建立和調度分離
   Stage能夠順序或者並行執行
   Stage可能在內部阻塞，給阻塞的stage分配較少的線程

一、Stage-可靠構建的基礎

(1)應用邏輯封裝到Event Handler
   接收到許多事件，處理這些事件，而後派發事件加入其餘Stage的queue
   對queue和threads沒有直接控制
   Event queue吸納過量的負載，有限的線程池維持併發
(2)Stage控制器
  負責資源的分配和調度
  控制派發給Event Handler的事件的數量和順序
  Event Handler可能在內部丟棄、過濾、重排序事件。

二、應用=Stage網絡
   (1)有限隊列 
        入隊可能失敗，若是隊列拒絕新項的話
        阻塞在滿溢的隊列上來實現吸納壓力
        經過丟棄事件來下降負載
   (2) 隊列將Stage的執行分解
        引入了顯式的控制邊界
        提供了隔離、模塊化、獨立的負載管理
   (3)方便調試和profile
        事件的投遞可顯
        時間流可跟蹤
        經過監測queue的長度發現系統瓶頸

三、動態資源控制器

(1)、線程池管理器
目標： 決定Stage合理的併發程度
操做：
觀察queue長度，若是超過閥值就添加線程
移除空閒線程

(2)、批量管理器
目的：低響應時間和高吞吐量的調度
操做：
Batching因子：Stage一次處理的消息數量
小的batching因子：低響應時間
大的batching因子：高吞吐量

嘗試找到具備穩定吞吐量的最小的batching因子
觀察stage的事件流出率
當吞吐量高的時候下降batching因子，低的時候增長

3、小結
   SEDA主要仍是爲了解決傳統併發模型的缺點，經過將服務器的處理劃分各個Stage，利用queue鏈接起來造成一個pipeline的處理鏈，而且在Stage中利用控制器進行資源的調控。資源的調度依據運行時的狀態監視的數據來進行，從而造成一種反應控制的機制，而stage的劃分也簡化了編程，而且經過queue和每一個stage的線程池來分擔高併發請求並保持吞吐量和響應時間的平衡。簡單來講，我看中的是服務器模型的清晰劃分以及反應控制。

 總結：

        這種架構最典型的實現方法就是經過消息隊列中間件解耦，而後根據不一樣的業務，將不一樣業務消息發送到不一樣MQ中，而後在MQlistener中將消息放到線程池，編寫對應的業務處理代碼。這些業務代碼在線程池中執行，能夠大幅度提升併發性。

示意圖