【Socket】兩種高效事件處理模式&并發模式

兩種高效事件處理模式&并發模式

• 遊雙-《Linux高性能伺服器程式設計》

• 本來想做個筆記的，但是發現這塊内容書中很多都感覺是有用的，是以很大篇幅的搬了過來，其中加入了我的了解，并有重點标注。

伺服器程式設計架構

• 伺服器程式種類繁多，但是基本架構都一樣，​

  ​不同之處在于邏輯處理​

  ​。
• 下圖所示，伺服器基本架構。該圖既能用來描述​

  ​一台伺服器​

  ​​，也能用來描述​

  ​一個伺服器機群​

  ​。

• 各子產品概念

子產品	單個伺服器架構	伺服器機群
I/O邏輯單元	處理客戶連接配接，讀寫網絡資料	作為接入伺服器，實作負載聚恒
邏輯單元	業務程序或線程	邏輯伺服器
網絡存儲單元	本地資料庫、檔案或緩存	資料庫伺服器
請求隊列	各單元之間的通信方式	各伺服器之間的永久TCP連接配接

I/O處理單元

• I/O處理單元是伺服器​

  ​管理用戶端連接配接的子產品​

  ​。它通常要完成一下工作:

• 等待并​

  ​接受​

  ​新的客戶連結；
• ​

  ​接收​

  ​客戶資料；
• 将伺服器響應的資料​

  ​傳回​

  ​給用戶端。

• 資料的收發不一定在I/O處理單元中執行，也可能在邏輯單元中執行，具體在何處執行取決于事件處理模式。
• 對于一個伺服器機群來說，I/O處理單元是一個專門的接入伺服器。它實作負載均衡，從所有邏輯伺服器中選取​

  ​負荷最小​

  ​的一台來為新客戶服務。

邏輯單元

• 一個邏輯單元通常是一個​

  ​程序或線程​

  ​。

• 它​

  ​分析并處理客戶資料​

  ​​，然後将結果​

  ​傳遞​

  ​​給I/O處理單元或者直接​

  ​發送​

  ​給用戶端。
• 具體使用哪種方式取決于事件處理模式。

• 對伺服器機群而言，一個邏輯單元本身就是一台邏輯伺服器。伺服器通常擁有多個邏輯單元， 以實作對多個客戶任務的​

  ​并行​

  ​處理。

網絡存儲單元

• 網絡存儲單元可以是資料庫、緩存和檔案，甚至是一台獨立的伺服器。
• 它不是必須的，例如:ssh、telnet等登入伺服器就不需要這個單元。

請求隊列

• 請求隊列是​

  ​各個單元之間通信方式的抽象​

  ​。

• I/O處理單元接收到客戶請求時，需要以某種方式來​

  ​通知​

  ​一個邏輯單元來處理該請求。
• 同樣，多個邏輯單元同時通路一個存儲單元時，也需要采用某種機制來​

  ​協調​

  ​處理競态條件。

• 請求隊列通常被實作為​

  ​池​

  ​的一部分。
• 對于伺服器機群而言，請求隊列是各台伺服器之間預先建立的、靜态的、永久的TCP連結。

• 這種TCP連接配接能​

  ​提高伺服器之間交換資料的效率，因為它避免了動态建立TCP導緻的額外系統開銷​

  ​。

兩種高效的事件處理模式

• 伺服器通常需要處理三類事件:

• I/O事件
• 信号
• 定時事件

• 下面介紹兩種高效的事件處理模式: Reactor與Proactor。

• ​

  ​同步I/O模型通常用于實作Reactor模式​

  ​​，​

  ​異步I/O模型則用于實作Proactor模式​

  ​​。可以以使用同步I/O模型去​

  ​模拟​

  ​Proactor模式。

Reactor模式

• Reactor模式中，​

  ​主線程隻負責監聽檔案描述符上是否有事件發生​

  ​​，有的話就立即将該事件​

  ​通知​

  ​​工作線程(即，邏輯單元，下同)除此之外，主線程​

  ​不做任何其它實質性的工作​

  ​。
• 讀寫資料，接收新的連接配接，以及處理客戶請求(業務邏輯)均在​

  ​工作線程​

  ​中完成。
• 使用同步I/O模型(以epoll_wait為例)實作的Reactor模式的工作流程:

1. 主線程往epoll核心事件表中​

   ​注冊​

   ​socket上的讀就緒事件。(監聽socket與連接配接socket成功建立連接配接後，以下socket都指的是連接配接socket)
2. 主線程調用epoll_wait​

   ​等待​

   ​socket上有資料可讀。
3. 當socket上有資料可讀時，epoll_wait​

   ​通知​

   ​​主線程。主線程則将socket可讀事件​

   ​放入​

   ​請求隊列。
4. 睡眠在請求隊列上的某個工作線程被​

   ​喚醒​

   ​​，它從連接配接socket讀取資料，并​

   ​處理​

   ​客戶請求，然後往epoll核心事件表中注冊該socket上的寫就緒事件。
5. 主線程調用epoll_wait​

   ​等待​

   ​scoket可寫。
6. 當socket可寫時，epoll_wait​

   ​通知​

   ​​主線程。主線程将socket可寫事件​

   ​放入​

   ​請求隊列。
7. 睡眠在請求隊列上的某個工作線程被​

   ​喚醒​

   ​​，它往socket上​

   ​寫入​

   ​伺服器處理客戶請求的結果。

• 總結: 主線程僅負責監聽socket看是否有發生事件，然後就通知工作線程讀取，處理資料，如為寫事件(即，要應答)，再在epoll核心事件表上注冊該連接配接socket的可寫事件，然後再由某個工作線程接管，處理，執行應答，讀事件同理。
• Reactor模式工作流程圖如下所示:

• 工作線程從請求隊列中取出事件後，将​

  ​根據事件的類型決定如何處理​

  ​它。

• 對于​

  ​可讀​

  ​​事件，執行​

  ​讀資料和處理請求​

  ​的操作；
• 對于​

  ​可寫​

  ​​事件，執行​

  ​寫資料​

  ​的操作；

• 是以，如上圖所示的Reactor模式中，沒必要區分所謂的“讀工作線程”和“寫工作線程”。

Proactor模式

• 與Reactor模式不同，​

  ​Proactor模式将所有I/O操作都交給主線程和核心來處理​

  ​，工作線程僅僅負責業務邏輯。
• 是以，Proactor模式更符合伺服器基本架構圖中的描述。
• 使用異步I/O模型(以aio_read和aio_write為例)實作的Proactor模式的工作流程:

1. 主線程調用aio_read函數向核心​

   ​注冊socket上的讀完成事件​

   ​​，并告訴核心使用者​

   ​讀緩沖區的位置​

   ​​，以及讀操作完成時​

   ​如何通知​

   ​應用程式(這裡以信号為例，詳情請參考sigevent的man手冊)。
2. 主線程​

   ​繼續處理其它邏輯​

   ​。
3. 當socket上的資料被​

   ​讀入使用者緩沖區後​

   ​​，核心使用者​

   ​向應用程式發送一個信号​

   ​​，以​

   ​通知應用程式資料已經可用​

   ​。
4. 應用程式​

   ​預先定義好的信号處理函數選擇一個工作線程來處理客戶請求​

   ​​。工作線程處理完客戶請求之後，調用aio_write函數向核心​

   ​注冊socket上的寫完成事件​

   ​​，并告訴核心使用者​

   ​寫緩沖區的位置​

   ​​，以及寫操完成時​

   ​如何通知​

   ​應用程式(仍以信号為例)。

• 總結: 核心使用者與主線程進行I/O操作，由信号通知主線程喚醒一個工作線程進行處理資料(業務邏輯)，業務處理完，再交給核心使用者與主線程進行I/O操作(伺服器應答)。
• Proactor模式工作流程圖如下圖所示:

• 上圖中，連接配接socket上的讀寫事件是​

  ​通過aio_read/aio_write向核心注冊的​

  ​​，是以​

  ​核心将通過信号來向應用程式報告連接配接socket上的讀寫事件​

  ​。
• 是以，​

  ​主線程上的epoll_wait調用僅能用來檢測監聽socket上的連接配接請求事件​

  ​，而不能用來檢測連接配接socket上的讀寫事件。

對比&總結

• Reactor模式與Proactor相對比:
• I/O操作:

• Reactor: 工作線程來完成。

• 對應socket上可以讀(寫)資料了，​

  ​喚醒一個工作線程在對應socket上讀(寫)​

  ​。

• Proactor: 主線程和核心來完成。

• 對應socket上可以讀(寫)資料了，​

  ​核心使用者後讀取​

  ​​完成通知應該程式，由定義好的信号處理函數選擇一個​

  ​工作線程進行資料業務處理​

  ​​，然後通知​

  ​核心可以寫回去了​

  ​（伺服器應答）。

• 資料業務處理:

• Reactor: 工作線程來完成。
• Proactor: 工作線程來完成。

模拟Proactor模式

• 使用同步I/O方式模拟出Proactor模式。
• 原理是: ​

  ​主線程執行讀寫操作​

  ​​，讀寫完成之後，主線程向工作線程通知這一"完成事件"。從​

  ​工作線程​

  ​​的角度來看，它們就​

  ​直接擷取了資料讀寫的結果​

  ​，接下來要做的隻是對讀寫的結果進行邏輯處理。
• 使用同步I/O模型(仍以epoll_wait為例)模拟出的Proactor模式的工作流程如下:(其中socket為連接配接socket)

1. ​

   ​主線程​

   ​​往epoll核心事件表中​

   ​注冊socket上的讀就緒事件​

   ​。
2. ​

   ​主線程​

   ​​調用epoll_wait​

   ​等待socket上有資料可讀​

   ​。
3. 當socket上有資料可讀時，epoll_wait通知主線程。​

   ​主線程​

   ​​從socket上循環​

   ​讀取資料​

   ​​，将讀取到的資料封裝成一個請求對象并​

   ​插入到請求隊列​

   ​中。
4. 睡眠在請求隊列上的某個​

   ​工作線程被喚醒​

   ​​，它獲得請求對象并​

   ​處理客戶請求​

   ​​，然後往epoll核心表中​

   ​注冊socket上的寫就緒事件​

   ​。
5. ​

   ​主線程​

   ​調用epoll_wait等待socket可讀。
6. 當socket可寫時，epoll_wait​

   ​通知主線程​

   ​​。​

   ​主線程往socket上寫入伺服器處理客戶請求的結果​

   ​。

• 總結: 主線程負責I/O操作，工作線程僅負責資料的處理(業務邏輯)。
• 工作流程如下圖所示:

兩種高效的并發模式

• 并發程式設計的目的是讓程式“同時”執行多個任務。
• 如果程式是​

  ​計算密集型​

  ​​的，并發程式設計并沒有優勢，反而由于任務的​

  ​切換使效率降低​

  ​。
• 如果程式是​

  ​I/O密集型​

  ​​的，比如經常讀寫檔案，通路資料等，因為I/O操作的速度遠沒有CPU的計算速度快，是以讓程式​

  ​阻塞于I/O操作将浪費大量的CPU時間​

  ​。

• 如果程式有多個執行線程，則目前被I/O操作所阻塞的執行線程可​

  ​主動放棄​

  ​CPU(由作業系統來排程)，并将執行線程轉移到其他線程。
• 這樣一來，CPU就可以做更加有意義的事情(除非所有線程都同時被I/O操作所阻塞)，而不是等待I/O操作完成，進而顯著提升CPU的使用率。

• 實作上: 并發程式設計主要有​

  ​多程序​

  ​​和​

  ​多線程​

  ​兩種方式。
• 對于下圖來說，​

  ​并發模式是指I/O處理單元和多個邏輯單元之間協調完成任務的方法​

  ​。
• 伺服器主要有兩種并發程式設計模式：

• 半同步/半異步模式(half-sync/half-async)
• 上司者/追随者模式(Leader/Followers)

半同步/半異步模式

• 這裡的半同步/半異步模式中的“同步"與”異步“與I/O模型中的“同步"與”異步“是完全​

  ​不同的概念​

  ​。
• I/O模型中:

• “同步"與”異步“區分的是核心向應用程式通知的是​

  ​何種I/O事件​

  ​(是就緒事件還是完成事件);
• 以及該由​

  ​誰來完成I/O讀寫​

  ​(是應用程式還是核心)。

• 在并發模式中:

• "同步"指的是程式完全按照代碼序列的​

  ​順序執行​

  ​；
• “異步”指的是程式的執行需要由​

  ​系統事件來驅動​

  ​。

• 常見的系統事件包括中斷、信号等。

• 下圖a描述了同步的讀操作，下圖b描述了異步的讀操作。

• 按照​

  ​同步方式運作的線程稱為同步線程​

  ​​,按照​

  ​異步方式運作的線程稱為異步線程​

  ​。
• 相比于同步線程，`異步線程的執行效率更高，實時性強。——(異步線程優點)

• 但編寫以異步方式執行的程式相對​

  ​複雜，難于調試和擴充​

  ​​，而且​

  ​不适合于大量的并發​

  ​。——(異步線程缺點)

• 同步線程則相反，雖然它​

  ​效率相對較低​

  ​​，​

  ​實時性較差​

  ​​，但是​

  ​邏輯簡單​

  ​。——(同步線程優缺點)

• 是以，對于像伺服器這種及要求​

  ​較好的實時性​

  ​​，又要求​

  ​能同時處理多個客戶請求​

  ​的應用程式，我們就應該同時使用同步線程與異步線程來實作，即采用半同步/半異步模式來實作。

• 半同步/半異步模式中:

• ​

  ​同步線程用于處理客戶邏輯，相當于伺服器基本架構圖中的邏輯單元​

  ​；
• ​

  ​異步線程用于處理I/O請求， 相當于伺服器基本架構圖中的I/O處理單元。​

  ​

• 工作線程處理I/O操作，是以半同步/半異步模式采用的是Reactor事件處理模式。
• ​

  ​異步線程監聽​

  ​​到客戶請求後，就将其​

  ​封裝成請求對象并插入請求隊列​

  ​中。請求隊列将​

  ​通知​

  ​某個工作在同步模式的​

  ​工作線程​

  ​來讀取并處理該請求對象。具體選擇哪個工作線程來為新的客戶請求伺服器，則取決于​

  ​請求隊列​

  ​的設計。

• 比如最簡單的輪流選取工作線程的Round Robin算法，也可以通過條件變量或信号量來随機地選擇一個工作線程。

• 半同步/半異步模式的工作流程如下圖所示:

半同步/半反應堆模式

• 在伺服器程式中，如果結合考慮兩種事件處理模式的幾種I/O模型，則半同步/半異步模式就存在多種​

  ​變體​

  ​。
• 其中一種就叫做半同步/半反應堆模式(half-sync/half-reactive)，如下圖所示:
• half-reactive展現在工作線程讀寫連接配接socket上的資料，詳見下面。

• 如上圖所示，​

  ​異步線程隻有一個，由主線程來充當​

  ​​，它負責​

  ​監聽所有socket上的事件​

  ​。

• 如果​

  ​監聽socket​

  ​​上有​

  ​可讀事件發生​

  ​​(監聽socket在服務端當然隻能發生可讀事件，哪有自己給自己發消息的，即在監聽socket上寫)，即有新的連接配接到來，主線程就​

  ​接受以得到新的連接配接socket​

  ​​，然後往epoll核心事件表中​

  ​注冊​

  ​該socket的讀寫事件。
• 如果​

  ​連接配接socket​

  ​​上有​

  ​讀寫事件發生​

  ​​，即有新的客戶請求到來或有資料要發送至用戶端，主線程就将該​

  ​連接配接socket插入請求隊列​

  ​中。

• 所有​

  ​工作線程都睡眠在請求隊列上​

  ​​，當有任務到來時，它們将通過​

  ​競争​

  ​​(比如申請互斥鎖)來獲得任務的​

  ​接管權​

  ​​。這種競争機制使得隻有​

  ​空閑​

  ​​的工作線程才有機會來​

  ​處理新任務​

  ​，這是很合理的。

• 上圖中，主線程插入請求中隊列中的任務是​

  ​就緒的連接配接socket​

  ​(即，該連接配接socket上有讀寫事件發生)。
• 這說明該圖所示的半同步/半反應堆模式采用的事件處理模式是​

  ​Reactor模式​

  ​​，它要求​

  ​工作線程自己從socket上讀取客戶資料和往socket上寫入伺服器應答​

  ​。

• 這就是其名字(half-reactive)的含義。

• 半同步/半反應堆也可以​

  ​模拟Proactor事件處理模式​

  ​​，即由​

  ​主線程完成資料的讀寫​

  ​。在這種情況下：

• ​

  ​主線程​

  ​​一般會将應用程式資料、任務類型等資訊​

  ​封裝成一個任務對象​

  ​(即把對應socket上的資料讀出來，封裝到一個任務對象中)；
• 然後将其(或者指向該任務對象的一個指針)​

  ​插入請求隊列​

  ​；
• ​

  ​工作線程​

  ​​從請求隊列中​

  ​取得​

  ​​任務對象之後，即可​

  ​處理​

  ​之，無需讀寫操作。

• 半同步/半反應堆模式存在如下缺點:
• ​

  ​主線程和工作線程共享請求隊列​

  ​。

• 主線程往請求隊列中添加任務，或者工作線程從請求隊列中取出任務，都需要對請求隊列加鎖保護，進而白白耗費CPU時間。

• ​

  ​每個工作線程在同一時間隻能處理一個客戶請求​

  ​。

• 如果客戶數量較多，而工作線程較少，則請求隊列中獎​

  ​堆積很多任務對象，用戶端的響應速度将越來越慢​

  ​。
• 如果通過增加工作線程來解決這一問題，則工作線程的​

  ​切換也将耗費大量CPU時間​

  ​。

相對高效的半同步/半異步模式

• 下圖描述了一種相對高效的半同步/半異步模式，它的​

  ​每個工作線程都能同時處理多個客戶連接配接​

  ​。

• 上圖中:
• ​

  ​主線程隻管理監聽socket，連接配接socket由工作線程來管理​

  ​。

• 當有新的連接配接到來時，主線程就接受之并将​

  ​新傳回的連接配接socket派發給某個工作線程​

  ​。
• 此後​

  ​該連接配接socket上的任何I/O操作都由被選中的工作線程​

  ​來處理，直到客戶關閉連接配接。

• 主線程派發socket的最簡單的方式，是往它和工作線程之間的​

  ​管道​

  ​裡寫資料。
• 工作線程檢測到​

  ​管道上有資料可讀時​

  ​，就分析是否是一個新的客戶連接配接到來。
• 如果是，則把該新的連接配接socket上的讀寫事件注冊到自己的epoll核心事件表中。

• ​

  ​以後該連接配接socket上的所有I/O事件都由此工作線程進行監聽與操作,直到客戶關閉連接配接。​

  ​
• (與上面重複了，這裡再寫一遍我想印象會深一些。)

• 如上圖所示，每個線程(主線程與工作線程)都維持自己的事件循環，它們各自獨立地監聽不同的事件。
• 是以，在這種高效的半同步/半異步模式中，​

  ​每個線程都工作在異步模式​

  ​，是以它并非嚴格意義上的半同步/半異步模式。

上司者/追随者模式

• 上司者/追随者模式是​

  ​多個工作線程輪流獲得事件源集合，輪流監聽、分發并處理事件​

  ​的一種模式。

• 在任意時間點，程式都​

  ​僅有一個上司者線程，它負責監聽I/O事件。​

  ​
• 其它線程都是追随者,它們休眠線上程池中等待成為新的上司者。
• 目前的上司者如果​

  ​檢測到I/O事件​

  ​​，首先要從線程池中​

  ​推選出新的上司者線程​

  ​​，​

  ​然後處理I/O事件​

  ​。
• 此時，​

  ​新的上司者等待新的I/O事件​

  ​​，而​

  ​原來的上司者則處理目前檢測到的I/O事件​

  ​，二者實作了并發。

• 上司者/追随者模式包含如下幾個元件:

• 句柄集(HandleSet)
• 線程集(ThreadSet)
• 事件處理器(EventHandler)
• 具體的事件處理器(ConcreteEventHandler)

• 它們的關系如下圖所示:

• 句柄集:

• 句柄(Handle)用于表示​

  ​I/O資源​

  ​​，在Linux下通常就是一個​

  ​檔案描述符​

  ​。
• 句柄集管理衆多句柄，它使用wait_for_event方法來​

  ​監聽​

  ​​這些句柄上的I/O事件，并将其中的​

  ​就緒事件通知給上司者線程​

  ​。
• 上司者線程調用綁定到Handle上的事件處理器來處理事件。
• 上司者将Handle和事件處理器綁定是通過調用句柄集中的register_handle方法實作的。

• 線程集:

• ​

  ​線程集是所有工作線程(包括上司者線程和追随者線程)的管理者​

  ​。
• 它負責各個線程之間的​

  ​同步​

  ​​，以及新上司者線程的​

  ​推選​

  ​。
• 線程集中的線程在任一時間必處于如下​

  ​三種狀态之一​

  ​；

• Leader: 線程單目前處于​

  ​上司者身份​

  ​​，負責​

  ​等待​

  ​句柄集上的I/O事件。
• Processing: 線程​

  ​正在處理事件​

  ​。

• 上司者檢測到I/O事件之後，可以​

  ​轉移​

  ​​到Processing狀态來處理事件，并調用promote_new_leader方法​

  ​推選​

  ​​新的上司者；也可以​

  ​指定​

  ​​其他追随者來​

  ​處理​

  ​​事件(Event Handoff),此時上司者的地位​

  ​不變​

  ​。
• 當處于Processing狀态的線程處理完事件之後，如果目前線程集中​

  ​沒有​

  ​​上司者，則它将​

  ​成為新的上司者​

  ​​，否則它就​

  ​直接轉變為追随者​

  ​。

• Follower: 線程目前處于​

  ​追随者身份​

  ​​，通過調用線程集的join方法​

  ​等待成為新的上司者​

  ​​，也可能被目前的上司者​

  ​指定來處理新的任務​

  ​。

• 如下圖所示這三種狀态之間的轉換關系:

• 需要注意的是，上司者線程推選新的上司者和追随者等待成為新的上司者，這兩個操作都将修改線程集，是以線程集提供一個成員Synchronizer來同步這兩個操作，以​

  ​避免競态​

  ​條件。
• 事件處理器和具體的事件處理器:

• 事件處理器通常包含一個過多個回調函數(handle_event)。這些​

  ​回調函數用于處理事件對應的業務邏輯​

  ​。
• 事件處理器在使用前需要被​

  ​綁定到某個句柄上​

  ​​，當該句柄上​

  ​有事件發生時​

  ​​，上司者就​

  ​執行與之綁定的事件處理器中的回調函數​

  ​。
• 具體的事件處理器是事件處理器的派生類，它們必須​

  ​重新實作基類handle_event方法，以處理特定的任務​

  ​。

• 綜上所述，上司者/追随者工作流程如下圖所示:

• 由于​

  ​上司者線程自己監聽I/O事件并處理客戶請求​

  ​​，因而上司者/追随者模式​

  ​不需要線上程之間傳遞任何額外的資料​

  ​​，也​

  ​無須​

  ​​像半同步/半反應堆那樣線上程之間​

  ​同步​

  ​​對請求隊列的​

  ​通路​

  ​。
• 但上司者/追随者的一個明顯缺點是​

  ​僅支援一個事件源集合​

  ​，是以也無法像高效的半同步/半異步模式那樣，讓每個工作線程獨立地管理多個客戶連結。