問答專欄Q & A COLUMN
選用多線程還是IO多路復用必須要看場景的！
選擇select還是epoll也是需要看場景的！
如果是短連接，服務器使用線程池(多線程)處理完畢，馬上進行釋放，保證活躍的線程所需要的內存和CPU效率是在服務器承受范圍之內，那么多線程比IO多路復用效果要好，因為無論是select還是epoll都需要去額外的監聽，監聽到需要數據處理，才調用回調函數，分配處理線程去執行，這段時間有性能和資源的消耗，這種情況無疑是多線程模型更有優勢！
如果是長連接，因為連接長時間不釋放，服務端需要保持線程去維護連接，這時候所有空閑的連接都相當于一個阻塞的狀態，而且多線程需要的內存資源比較多，高并發的情況服務器直接死機了！而使用IO多路復用，用來維持連接的線程只有一個(或幾個)，不會有多余的內存開銷，這時候IO多路復用的優勢得以體現！
如果確定選擇IO多路復用，又該選擇select/epoll哪種模型呢？
首先來看下select和epoll的本質區別:都有一個監聽線程去監聽事件，但是select采取輪詢的方式，不管有多少連接過來都要一一輪詢，有通信數據就處理，而epoll是把所有socket對應的文件掛在紅黑樹上，而活躍的放在一張雙向鏈表中，只處理這個鏈表中的連接！如果有新的連接需要處理，從紅黑樹上塞到鏈表中進行處理！
比如1000個連接中，只有十個有數據傳輸，select需要從1000個中遍歷出這10個，然后進行處理，而epoll模型只需要從鏈表中取出來即可使用！
由此可見，如果是少量連接，同時大量連接都是活躍的情況下，select可能稍微略勝一籌，但如果是大量連接，且活躍數占比少的情況，epoll堪稱完美模型，在可預見的范圍中，epoll增加連接，性能幾乎不衰減！
寫一個類似epoll的處理模型，會對以后的高并發，多線程處理大有助益，更多的技術分享，敬請關注。。。
評論0
加載中...
多線程和用select/epoll是沒有關聯的，在select和epoll模型里也可以使用多線程進行io處理，select/epoll 的出現是為了解決一個線程對應一個請求時阻塞線程的問題，基于epoll的事件模型，解決了線程的阻塞問題即一個線程可以為多個請求服務
評論0
加載中...
多線程既每個線程負責處理一個用戶連接，當等待數據（如讀寫數據）時線程被阻塞掛起，數據就緒后線程恢復執行。優點是開發相對簡單，缺點是處理并發能力差一些。
IO復用是事件驅動的方式，既等待數據時線程保存處理當前連接的上下文，然后線程切換去處理其它數據就緒的請求。優點是處理并發的能力強，缺點是開發相對復雜一些。一些開源的庫，如libevent，可以讓事件驅動的開發更容易。
Web服務器Apache和Nginx分別對應上面的兩種模式。Nginx就是以高性能高并發著稱。
在問題描述中每分鐘2K的請求，如果能夠在一秒內就能完成一個請求的處理，并發在每秒30到40之間，那多線程模式就可以了，40個線程就能達到要求；如果每個請求要一分鐘才能處理完，那并發連接數就是2K,創建2k個線程可能就不大現實。可以考慮基于事件驅動的方式。
具體選擇那種的關鍵還是看，同時保持多大的并發連接。
評論0
加載中...0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答
