高並發的epoll+線程池，業務線上程池內

標籤：send   event   作業   輪詢   其他   瓶頸   請求   利用   業務   

我們知道，伺服器並行存取模型通常可分為單線程和多執行緒模式，這裡的線程通常是指“I/O線程”，即負責I/O操作，協調分配任務的“管理線程”，而實際的請求和任務通常交由所謂“工作者線程”處理。通常多執行緒模式下，每個線程既是I/O線程又是工作者線程。所以這裡討論的是，單I/O線程+多工作者線程的模型，這也是最常用的一種伺服器並行存取模型。我所在的項目中的server代碼中，這種模型隨處可見。它還有個名字，叫“半同步/半非同步“模型，同時，這種模型也是生產者/消費者（尤其是多消費者）模型的一種表現。

這種架構主要是基於I/O多工的思想（主要是epoll，select/poll已淘汰），通過單線程I/O多工，可以達到高效並發，同時避免了多線程I/O來回切換的各種開銷，思路清晰，易於管理，而基於線程池的多工作者線程，又可以充分發揮和利用多線程的優勢，利用線程池，進一步提高資源複用性和避免產生過多線程。

 

瓶頸在於IO密集度。
線程池你開10個線程當然可以一上來全部accept阻塞住，這樣用戶端一連上來便會自動啟用一個線程去處理，但是設想一下，如果10個線程全部用掉了，第11個用戶端就會發生丟棄。這樣為了實現”高並發“你得不斷加大線程池的數量。這樣會帶來嚴重的記憶體佔用和線程切換的時延問題。
於是前置事件輪詢設施的方案就應運而生了，
主線程輪詢負責IO，作業交給線程池。
在高並發下，10W個用戶端上來，就主線程負責accept，放到隊列中，不至於發生沒有及時握手而丟棄掉串連的情況發生，而作業線程從隊列中認領作業，做完回複主線程，主線程負責write。這樣可以用極少的系統資源處理大數量串連。
在低並發下，比如2個用戶端上來，也不會出現100個線程hold住在那從而發生系統資源浪費的情況。

正確實現基本線程池模型的核心：
主線程負責所有的 I/O 操作，收齊一個請求所有資料之後如果有必要，交給背景工作執行緒進行處理 。處理完成之後，把需要寫回的資料還給主線程去做寫回 / 嘗試寫回資料直到阻塞，然後交回主線程繼續。
這裡「如果有必要」的意思是：經過測量，確認這個處理過程中所消耗的 CPU 時間（不包括任何 I/O 等待，或者相關的 I/O 等待操作無法用 epoll 接管）相當顯著。如果這個處理過程（不包含可接管的 I/O 操作）不顯著，則可以直接放在主線程裡解決。
這個「必要」與否的前提不過三個詞：假設，分析，測量。

所以，一個正確實現的線程池環境鐘，用 epoll + non-blocking I/O 代替 select + blocking I/O 的好處是，處理大量 socket 的時候，前者效率比後者高，因為前者不需要每次被喚醒之後重新檢查所有 fd 判斷哪個 fd 的狀態改變可以進行讀寫了。

 

關鍵

1、單I/O 線程epoll

實現單I/O線程的epoll模型是本架構的第一個技術要點，主要思想如下： 

單線程建立epoll並等待，有I/O請求（socket）到達時，將其加入epoll並從線程池中取一個空閑工作者線程，將實際的業務交由工作者線程處理。

偽碼：

建立一個epoll執行個體;while(server running){    epoll等待事件;    if(新串連到達且是有效串連)    {        accept此串連;        將此串連設定為non-blocking;
　　     為此串連設定event(EPOLLIN | EPOLLET ...);

        將此串連加入epoll監聽隊列;        從線程池取一個空閑工作者線程並處理此串連;    }    else if(讀請求)    {        從線程池取一個空閑工作者線程並處理讀請求;    }    else if(寫請求)    {        從線程池取一個空閑工作者線程並處理寫請求;    }    else        其他事件;     }

 

2、線程池實現

server啟動時，建立一定數量的工作者線程加入線程池，如（20個），供I/O線程來取用；

每當I/O線程請求空閑工作者線程時，從池中取出一個空閑工作者線程，處理相應請求；

當請求處理完畢，關閉相應I/O串連時，回收相應線程並放回線程池中供下次使用；

若請求空閑工作者線程池時，沒有空閑工作者線程，可作如下處理：

(1)若池中"管理"的線程總數不超過最大允許值，可建立一批新的工作者線程加入池中，並返回其中一個供I/O線程使用；

(2)若池中"管理"的線程總數已經達到最大值，不應再繼續建立新線程， 則等待一小段時間並重試。注意因為I/O線程是單線程且不應被阻塞等待在此處，所以其實對線程池的管理應由一個專門的管理線程完成，包括建立新工作者線程等工作。此時管理線程阻塞等待（如使用條件變數並等待喚醒），一小段時間之後，線程池中應有空閑工作者線程可使用。否則server負荷估計是出了問題。

 

epoll是linux下高並發伺服器的完美方案，因為是基於事件觸發的，所以比select快的不只是一個數量級。 單線程epoll，觸發量可達到15000，但是加上業務後，因為大多數業務都與資料庫打交道，所以就會存在阻塞的情況，這個時候就必須用多線程來提速。   業務線上程池內，這裡要加鎖才行。測試結果2300個/s   測試載入器：stressmark 因為加了適用與ab的代碼，所以也可以適用ab進行壓力測試。 char buf[1000] = {0};
sprintf(buf,"HTTP/1.0 200 OK\r\nContent-type: text/plain\r\n\r\n%s","Hello world!\n");
send(socketfd,buf, strlen(buf),0);

 

高並發的epoll+線程池，業務線上程池內