寫在前面的話
大概一年多以前,我看了一些ligty的代碼,并且在這里給出了一些自己的分析,這部分應(yīng)該到了狀態(tài)機(jī)部分,后來由于我沒有繼續(xù)跟進(jìn)ligty的代碼,或者說,不再像最初那樣對它感興趣,所以也就沒有再跟進(jìn)了.
最近,我開始看一些nginx的代碼,和當(dāng)初閱讀ligty一樣,我不知道我會(huì)看到哪兒,分析的有多么深,所以,作為讀者的您,還是把這一系列文章看作是個(gè)人的一些學(xué)習(xí)筆記好了,我隨時(shí)看到一些我覺得可以分享的點(diǎn),隨時(shí)在這里更新一下,但是,我不能保證更新的頻率和數(shù)量了.

順便說一句,Nginx的更新似乎非常的頻繁,隔個(gè)幾天就有個(gè)新的版本,不知道為什么,這在我之前跟進(jìn)過的開源代碼中屬于比較少見的了,而這里的分析,是基于0.7.61版本的代碼.

============== 分割線 ==============
首先分析的是nginx中的進(jìn)程管理部分.
之前分析過ligty的monitor+worker模型,簡單的說就是主進(jìn)程負(fù)責(zé)創(chuàng)建子進(jìn)程,然后主進(jìn)程就阻塞在wait函數(shù)上,一旦有子進(jìn)程退出,這個(gè)函數(shù)會(huì)返回,然后再次創(chuàng)建出新的worker進(jìn)程來.

Nginx中的進(jìn)程管理與這個(gè)類似.同樣是worker子進(jìn)程負(fù)責(zé)真正的干活.但是,Nginx中,master進(jìn)程(其實(shí)就是ligty中的monitor進(jìn)程,也就是程序最開始啟動(dòng)時(shí)的進(jìn)程,也就是所有worker進(jìn)程的父進(jìn)程)對子進(jìn)程的控制更多,不僅僅關(guān)注子進(jìn)程是否退出了,簡單的總結(jié)如下:

1) 進(jìn)程之間通過socketpair來進(jìn)行通信,因此,每次創(chuàng)建了一個(gè)新的子進(jìn)程之后,需要同時(shí)創(chuàng)建出對應(yīng)的socketpair,還要把自己的socketpair告訴已經(jīng)創(chuàng)建好的兄弟子進(jìn)程.

2) master進(jìn)程的主循環(huán)中主要完成以下幾個(gè)工作:比如子進(jìn)程退出,比如用戶發(fā)出指令要求重新加載配置文件,比如用戶發(fā)出指令說更新了新的二進(jìn)制文件,等等,所有這些工作,其實(shí)都是以信號的形式來區(qū)分,發(fā)出不同的信號意味著不同的動(dòng)作.Nginx中所謂的“熱更新配置文件”，“熱更新程序”等都是通過這個(gè)來實(shí)現(xiàn)的。

3) worker進(jìn)程的主循環(huán)除了一般的監(jiān)聽網(wǎng)絡(luò)I/O事件如客戶端連接上來,可讀/寫之外,還需要將自己的socketpair加入到監(jiān)聽socket中,因?yàn)閙aster進(jìn)程就是通過向這些子進(jìn)程的socketpair發(fā)送信號來通知子進(jìn)程完成不同的操作.

以上,就是Nginx中進(jìn)程管理的大致模型了,其實(shí)看明白了,也不復(fù)雜.
我不打算羅列代碼了,在這里,有一份更加詳細(xì)的涉及代碼的分析.

可以看到,Nginx和ligty一樣,都沒有采用非常復(fù)雜的進(jìn)程模型,都是多進(jìn)程 + 非阻塞I/O + 多路復(fù)用I/O處理的網(wǎng)絡(luò)模型,這在我之前提到半同步半異步模式時(shí)也提到過.