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

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

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

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

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

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

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

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

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