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