寫在前面的話
大概一年多以前,我看了一些ligty的代碼,并且在這里給出了一些自己的分析,這部分應該到了狀態機部分,后來由于我沒有繼續跟進ligty的代碼,或者說,不再像最初那樣對它感興趣,所以也就沒有再跟進了.
最近,我開始看一些nginx的代碼,和當初閱讀ligty一樣,我不知道我會看到哪兒,分析的有多么深,所以,作為讀者的您,還是把這一系列文章看作是個人的一些學習筆記好了,我隨時看到一些我覺得可以分享的點,隨時在這里更新一下,但是,我不能保證更新的頻率和數量了.
順便說一句,Nginx的更新似乎非常的頻繁,隔個幾天就有個新的版本,不知道為什么,這在我之前跟進過的開源代碼中屬于比較少見的了,而這里的分析,是基于0.7.61版本的代碼.
============== 分割線 ==============
首先分析的是nginx中的進程管理部分.
之前分析過ligty的monitor+worker模型,簡單的說就是主進程負責創建子進程,然后主進程就阻塞在wait函數上,一旦有子進程退出,這個函數會返回,然后再次創建出新的worker進程來.
Nginx中的進程管理與這個類似.同樣是worker子進程負責真正的干活.但是,Nginx中,master進程(其實就是ligty中的monitor進程,也就是程序最開始啟動時的進程,也就是所有worker進程的父進程)對子進程的控制更多,不僅僅關注子進程是否退出了,簡單的總結如下:
1) 進程之間通過socketpair來進行通信,因此,每次創建了一個新的子進程之后,需要同時創建出對應的socketpair,還要把自己的socketpair告訴已經創建好的兄弟子進程.
2) master進程的主循環中主要完成以下幾個工作:比如子進程退出,比如用戶發出指令要求重新加載配置文件,比如用戶發出指令說更新了新的二進制文件,等等,所有這些工作,其實都是以信號的形式來區分,發出不同的信號意味著不同的動作.Nginx中所謂的“熱更新配置文件”，“熱更新程序”等都是通過這個來實現的。
3) worker進程的主循環除了一般的監聽網絡I/O事件如客戶端連接上來,可讀/寫之外,還需要將自己的socketpair加入到監聽socket中,因為master進程就是通過向這些子進程的socketpair發送信號來通知子進程完成不同的操作.
以上,就是Nginx中進程管理的大致模型了,其實看明白了,也不復雜.
我不打算羅列代碼了,在
這里,有一份更加詳細的涉及代碼的分析.
可以看到,Nginx和ligty一樣,都沒有采用非常復雜的進程模型,都是多進程 + 非阻塞I/O + 多路復用I/O處理的網絡模型,這在我之前提到
半同步半異步模式時也提到過.