併發模型SEDA

參考：https://blog.csdn.net/codewar/article/details/51217738

　　    https://blog.csdn.net/zhihui1017/article/details/50502825

一、多線程併發模型

應用程序開發中常常會採用多線程模型，其工做原理通常是對於每個request，dispatcher會爲其建立並分配一個線程。該線程負責這個請求的處理。這種模式的有點事處理邏輯清晰，容易開發，處理粒度是整個完整的處理流程。

 

可是這麼作也有明顯的缺陷，隨着處理請求不斷增長，會致使併發執行的線程數量過多（雖然成熟的框架愛都會對線程池規模進行控制，可是線程池數量的控制也是一個技術活），過多的線程的數量會致使系統在線程調度和資源徵用搶佔上開銷過大（線程上下文切換代價很高），引發系統性能急劇降低，以下圖所示：

 

二、事件驅動模型   

       同時，咱們也能看到，不少系統也傾向於使用事件驅動模型，該模型的模型圖以下圖所示：

        該模型的思想爲：將處理流程分割成多個步驟，每個步驟都實現爲一個有限狀態機（FSM），全部的處理請求會做爲事件進入系統，由調度器負責傳遞給相應的狀態機，狀態機的處理結果也以事件的形式傳給調度器，新的事件將再次被調度器轉發給下一個狀態機進行處理，直至處理完成。該模型的優勢在於，因爲將各個處理步驟獨立實現，能夠很容易的進行系統監測和調整。可是其缺點也不容忽視，即：因爲Scheduler的設計和實現過於複雜，針對於不一樣的應用和系統的邏輯變動須要不一樣的實現，致使採用這一模型構建出的系統將十分龐大和難以控制。
      

階段性事件驅動（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將一個請求的處理過程分解爲一系列的階段，階段之間經過事件隊列聯繫，開發人員只負責每一個階段的服務邏輯以及階段間的鏈接邏輯，而由各個階段自身負責資源管理以及負載適應功能。使用這種解耦拆分可使系統達到高併發性、對負載變化的良好適應性以及高度的可縮放性。