結(jié)論

先說(shuō)答案，Nginx之所以支持高并發(fā)，是因?yàn)樗腔趀poll的異步及非阻塞的事件驅(qū)動(dòng)模型。 在這個(gè)模型下，Nginx服務(wù)端可以同一時(shí)間接收成千上萬(wàn)個(gè)客戶端請(qǐng)求而不阻塞。這是因?yàn)镹ginx會(huì)把一個(gè)一個(gè)的客戶端請(qǐng)求注冊(cè)成事件給到系統(tǒng)內(nèi)核，而這個(gè)事件管理器完全由系統(tǒng)內(nèi)核管理，Nginx只負(fù)責(zé)注冊(cè)和接收通知。下面再來(lái)詳細(xì)聊聊具體原因。

Nginx架構(gòu)

Nginx啟動(dòng)時(shí)，先啟動(dòng)一個(gè)master進(jìn)程，然后再根據(jù)配置文件里定義的參數(shù)來(lái)啟動(dòng)對(duì)應(yīng)數(shù)量的worker進(jìn)程。

所以，Nginx是多進(jìn)程模式，多個(gè)進(jìn)程之間不會(huì)相互影響，多個(gè)worker進(jìn)程還可以配置成使用不同的CPU來(lái)工作，從而提高了Nginx處理請(qǐng)求速度。

Nginx的異步非阻塞機(jī)制

首先理解同步和異步的概念，這兩個(gè)概念是從客戶端與服務(wù)端通信交互方式來(lái)說(shuō)。

同步，指服務(wù)端接收到客戶端請(qǐng)求后，必須處理完該請(qǐng)求后（發(fā)送處理結(jié)果給客戶端），才會(huì)接收客戶端發(fā)送來(lái)的下一個(gè)請(qǐng)求。

異步，指服務(wù)端還沒(méi)有處理完客戶端請(qǐng)求（沒(méi)有發(fā)送處理結(jié)果給客戶端），就已經(jīng)接收下一個(gè)客戶端發(fā)來(lái)的請(qǐng)求了。

再來(lái)理解阻塞和非阻塞的概念。這兩個(gè)概念是從服務(wù)器內(nèi)部處理請(qǐng)求的方式來(lái)說(shuō)的。

阻塞，指服務(wù)器接收到請(qǐng)求后，如果遇到IO阻塞，當(dāng)前線程會(huì)被掛起，直到IO完成后喚醒當(dāng)前線程，當(dāng)前線程期間不會(huì)去處理其他事情。

非阻塞，指服務(wù)器接收到請(qǐng)求后，如果遇到IO阻塞，當(dāng)前線程不會(huì)掛起，而是會(huì)立即返回去執(zhí)行下一個(gè)調(diào)用。

同步與異步，重點(diǎn)在于消息通知的方式。阻塞與非阻塞，重點(diǎn)在于等消息時(shí)候的行為。

事件驅(qū)動(dòng)模型

上面提到的異步非阻塞機(jī)制，Nginx是通過(guò)基于事件的驅(qū)動(dòng)模型來(lái)實(shí)現(xiàn)的。這個(gè)模型下，客戶端發(fā)起的所有請(qǐng)求在服務(wù)端都會(huì)被標(biāo)記為一個(gè)事件，Nginx會(huì)把這些事件收集到“事件收集器”里，然后再把這些事件交給內(nèi)核去處理。

對(duì)于Nginx服務(wù)器來(lái)說(shuō)，客戶端A的請(qǐng)求連接到服務(wù)端時(shí)，服務(wù)端進(jìn)程（Nginx worker process）會(huì)處理該請(qǐng)求，此進(jìn)程在沒(méi)有返回給客戶端A結(jié)果時(shí)，它又去處理了客戶端B的請(qǐng)求。 服務(wù)端把客戶端A以及客戶端B發(fā)來(lái)的請(qǐng)求作為事件交給了“事件收集器”，而“事件收集器”再把收集到的事件交由“事件發(fā)送器”發(fā)送給“事件處理器”進(jìn)行處理。 最后“事件處理器”處理完該事件后，通知服務(wù)端進(jìn)程，服務(wù)端進(jìn)程再把結(jié)果返回給客戶端A、客戶端B。 在這個(gè)過(guò)程中，服務(wù)端進(jìn)程做的事情屬于用戶級(jí)別的，而事件處理這部分工作屬于內(nèi)核級(jí)別的。 也就是說(shuō)這個(gè)事件驅(qū)動(dòng)模型是需要操作系統(tǒng)內(nèi)核來(lái)作為支撐的。

Nginx支持的事件驅(qū)動(dòng)模型

Nginx支持的事件驅(qū)動(dòng)模型有：select, poll, epoll, rtsig, kqueue, /dev/poll, eventport等，最常用的是前三種。

Select模型：首先會(huì)創(chuàng)建所關(guān)注事件的描述符集合。會(huì)分別創(chuàng)建讀（Read）事件、寫(xiě)（Write）事件、異常發(fā)生（Exception）事件三類(lèi)描述符集合來(lái)收集三類(lèi)描述符。然后調(diào)用底層提供的select()函數(shù)，等待事件發(fā)生。最后輪詢所有事件描述符集合中的每一個(gè)描述符，檢查是否有相應(yīng)的事件發(fā)生，然后處理事件。

Poll模型：與select的基本實(shí)現(xiàn)方式相同，只不過(guò)創(chuàng)建關(guān)注的描述符集合時(shí)，不分成三個(gè)集合，而是一個(gè)集合包括所有描述符。

Epoll模型：當(dāng)描述符比較多時(shí)，遍歷描述符集合、然后查找每個(gè)描述符是否有相應(yīng)事件發(fā)生這一過(guò)程會(huì)效率較低。Epoll選擇將描述符列表的管理交給內(nèi)核復(fù)制，一旦有事件發(fā)生，內(nèi)核會(huì)將有事件發(fā)生的描述符列表通知給進(jìn)程，這樣避免了應(yīng)用程序輪詢整個(gè)描述符列表。Epoll會(huì)通過(guò)相關(guān)調(diào)用，通知內(nèi)核創(chuàng)建一個(gè)N個(gè)描述符的事件列表，然后給這些描述符設(shè)置所關(guān)注的事件，并把他添加到內(nèi)核的事件列表中，在編碼過(guò)程中也可以通過(guò)相關(guān)調(diào)用對(duì)事件列表中的描述符進(jìn)行動(dòng)態(tài)地刪除和修改。