高並發的epoll+線程池，業務在線程池內
我們知道，服務器並發模型通常可分為單線程和多線程模型，這裏的線程通常是指“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+線程池，業務在線程池內