nginx是乙個效能非常強的高併發處理伺服器，他可以支援百萬級併發的需求
當nginx啟動時候，master在80埠監聽，他的作用僅僅是監聽，與客戶端連線的是worker，例如現在在nginx.conf裡配置worker_processes 3，那麼master就會fork三個worker程序用於處理客戶連線，當有乙個客戶端連線過來的時候，3個worker就會去搶這個客戶連線，nginx採用互斥鎖accept_mutex進行執行緒互斥，搶到鎖的worker 1就會去處理這個客戶連線，其餘的worker繼續等待。
當worker 1處理完client 1的請求並返回後，client 1的這次連線才算是徹底結束，下一次再請求，workers又會重複上面的搶鎖過程。
傳統伺服器的事件處理方式一般採用bio的方式，可以比喻成乙個worker對乙個client，當這個client的請求處理占用時間過長，會直接導致其他client請求排隊等待worker空閒，這種情況在nginx中簡單粗暴的處理方式就是增加更多的worker_processes，建立更多的workern對clientn的方式，但是這種方式肯定是錯誤的，大量的worker程序會造成伺服器cpu滿負荷運轉，成本是不可接受的。
use epoll，linux的epoll模型，linux直接內建epoll，因此部署在linux上的nginx其單個worker程序是有能力同時處理7w左右的請求的，當然如果伺服器配置夠高，cpu夠多記憶體夠大，單個work程序併發數量甚至可以達到百萬級別，這也就是為什麼一台nginx可以做到百萬、千萬甚至億級併發的原因。
因此在配置nginx的worker_processes時，一般根據cpu數量配置或者配置n-1個。
那麼就需要涉及到另外乙個引數：events裡的worker_connections，這個引數是配置單個worker處理連線數的上限，預設值是1024。這個引數需要根據伺服器硬體條件決定，如果配置過高可能導致伺服器cpu滿負荷執行，配置過低又會導致client連線卡頓出現阻塞現象，因此這個值實際配置需要通過壓力測試來決定了。
前面提到的epoll也是配置在events裡面的，nginx預設使用就是epoll，也可以不用手動配置。
1、worker搶占機制
2、事件處理模型epoll的非同步非阻塞性質，一種多路復用器的模式
3、master監聽協調作用，當乙個worker處理client被阻塞的時候，worker不會等待而是會去處理其他的連線請求
同步阻塞bio： 我去上廁所，這個時候坑位都滿了，我必須等待坑位釋放了，我才能上吧？！此時我啥都不幹，站在廁所裡盯著，過了一會有人出來了，我就趕緊蹲上去。同步非阻塞nio： 我去上廁所，這個時候坑位都滿了，沒關係，哥不急，我出去抽根菸，過會回來看看有沒有空位，如果有我就蹲，如果沒有我出去接著抽菸或者玩會手機。
非同步阻塞： 我去上廁所，這個時候坑位都滿了，沒事我等著，等有了新的空位，讓他通知我就行，通知了我，我就蹲上去。
非同步非阻塞aio： 我去上廁所，這個時候坑位都滿了，沒事，我一點也不急，我去廁所外面抽根菸再玩玩手機，等有新的坑位釋放了，會有人通知我的，通知我了，我就可以進去蹲了。
Nginx程序模型
這篇主要是閱讀這篇博文的筆記。nginx採用的也是大部分http伺服器的做法，master，worker模型，基本的事件處理都是放在worker中，master負責一些全域性初始化，以及對worker的管理。nginx中的master和worker之間是通過socketpair來實現的，每次fork...
Nginx程序模型
目錄 1.nginx管理 工作程序模式 2.驚群 問題 為了支援現在流行的多cpu和多核架構，nginx使用了管理程序和工作程序的設計。架構設計如下圖所示 管理程序為工作程序的父程序，負責外部指令的接收，工作程序的狀態監管，負載均衡等 工作程序負責客戶端請求的處理和響應，工作程序一般是按照cpu的核...
002 nginx的程序模型
一 概述 nginx的高效能是大家所了解的,nginx之所以擁有這麼好的效能和它的程序模型是分不開的.當nginx啟動的時候,它會以後臺程序的方式進行,然後nginx會啟動乙個master程序和多個worker程序.也就是說,nginx是採用多程序的方式程序的.現在我們需要了解一下master程序和...