程序數與併發數不存在很直接的關係。這取決取 server 採用的工作方式。如果乙個 server 採用乙個程序負責一
個 request 的方式，那麼程序數就是併發數。那麼顯而易見的，就是會有很多程序在等待中。等什麼？最多的應該是
等待網路傳輸。
nginx 的非同步非阻塞工作方式正是利用了這點等待的時間。在需要等待的時候，這些程序就空閒出來待命了。因
此表現為少數幾個程序就解決了大量的併發問題。apache 是如何利用的呢，簡單來說：同樣的 4 個程序，如果採用
乙個程序負責乙個 request 的方式，那麼，同時進來 4 個 request 之後，每個程序就負責其中乙個，直至會話關閉。
期間，如果有第 5 個 request 進來了。就無法及時反應了，因為 4 個程序都沒幹完活呢，因此，一般有個排程程序，
每當新進來了乙個 request，就新開個程序來處理。nginx 不這樣，每進來乙個 request，會有乙個 worker 程序去
處理。但不是全程的處理，處理到什麼程度呢？處理到可能發生阻塞的地方，比如向上游（後端）伺服器** request，
並等待請求返回。那麼，這個處理的 worker 不會這麼傻等著，他會在傳送完請求後，註冊乙個事件： 「如果 upstream
返回了，告訴我一聲，我再接著幹」。於是他就休息去了。此時，如果再有 request 進來，他就可以很快再按這種方
式處理。而一旦上游伺服器返回了，就會觸發這個事件， worker 才會來接手，這個request 才會接著往下走。
由於 web server 的工作性質決定了每個 request 的大部份生命都是在網路傳輸中，實際上花費在 server機器
上的時間片不多。這是幾個程序就解決高併發的秘密所在。web server 剛好屬於網路 io 密集型應用，不算是計算密
集型。非同步，非阻塞，使用 epoll，和大量細節處的優化。也正是 nginx 之所以然的技術基石。
nginx 非同步非阻塞多程序模型
master程序負責 呼叫各module的初始化函式，讀取解析nginx配置檔案，模組module 解析執行 nginx.conf 配置檔案流程分析 充當整個程序組與使用者的互動介面，接收使用者操作訊號管理worker程序，nginx核心程序模型 worker程序負責 搶占程序鎖，從監聽套接字中獲取...
Nginx深入詳解之多程序網路模型
一 程序模型 nginx之所以為廣大碼農喜愛，除了其高效能外，還有其優雅的系統架構。與memcached的經典多執行緒模型相比，nginx是經典的多程序模型。nginx啟動後以daemon的方式在後台執行，後台程序包含乙個master程序和多個worker程序，具體如下圖 圖1 nginx多程序模型...
Nginx程序模型
這篇主要是閱讀這篇博文的筆記。nginx採用的也是大部分http伺服器的做法，master，worker模型，基本的事件處理都是放在worker中，master負責一些全域性初始化，以及對worker的管理。nginx中的master和worker之間是通過socketpair來實現的，每次fork...