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