摘要：關(guān)于過程中如何細(xì)節(jié)控制一致性，穩(wěn)定性，信號(hào)控制，控制等等，敬請(qǐng)期待小拽的進(jìn)一步探索處理流程和模塊啟動(dòng)進(jìn)程后，請(qǐng)求在內(nèi)部是如何流轉(zhuǎn)的，內(nèi)部包括哪些模塊處理過程請(qǐng)求到達(dá)后首先讀取，中初始時(shí)間便從此開始。

由于性能問題，需要將 apache + php5.2 升級(jí)到 nginx + php7，對(duì)于nginx的性能和熱加載早有耳聞，why nginx so diao。小拽進(jìn)行了初探，有任何疑問或不準(zhǔn)確的地方，歡迎直接開炮?。。?/p>

nginx 是當(dāng)前的使用最廣泛的webserver ,支持http正向/反向代理，支持TCP/UDP層代理，來看下netcraft的數(shù)據(jù)

nginx在全部網(wǎng)站中占比達(dá)到18%，在top millon busest 達(dá)到28%，而且一直在增加。當(dāng)下最時(shí)尚的webserver非nginx莫屬

更全數(shù)據(jù)可以參考：【netcraft】

深入了解nginx之前，先泛泛的了解下nginx的幾個(gè)特點(diǎn)

性能好

非阻塞IO/高并發(fā),支持文件IO

多worker，thread pool

基于rbtree的定時(shí)器

系統(tǒng)特性的持續(xù)支持

功能強(qiáng)大

webserver/cache/keepalive/pipeline等等

各種upstream的支持【fastcgi/http/...】

輸出靈活【chunk/zip/...】

在不斷的發(fā)展 http2,tcp,udp,proxy...

運(yùn)維的友好【這個(gè)對(duì)于開發(fā)和部署很重要】

配置非常規(guī)范【個(gè)人認(rèn)為：約定及規(guī)范是最好的實(shí)踐】

熱加載和熱更新【后文會(huì)詳細(xì)介紹，能在二進(jìn)制的層面熱更新】

日志強(qiáng)大【真的很強(qiáng)的，很多變量支撐】

擴(kuò)展強(qiáng)大

下圖是nginx、apache和lighttpd的一個(gè)對(duì)比。系統(tǒng)壓力，內(nèi)存占用，upstream支持等多個(gè)方面都非常不錯(cuò)

一句話簡述nginx的運(yùn)行方式：master-worker多進(jìn)程模式運(yùn)行，單線程/非阻塞執(zhí)行

如下官方圖：nginx 啟動(dòng)后生成master，master會(huì)啟動(dòng)conf數(shù)量的worker進(jìn)程，當(dāng)用戶的請(qǐng)求過來之后，由不同的worker調(diào)起執(zhí)行線程，非阻塞的執(zhí)行請(qǐng)求。這種運(yùn)行方式相對(duì)于apache的進(jìn)程執(zhí)行相對(duì)輕量很多，支撐的并發(fā)性也會(huì)高很多。

nginx是master-worker進(jìn)程工作模式，那么nginx是如何管理master啟程，怎么做到熱加載的？

官方圖很贊，在更換配置之后，master生成新的worker，直到原有的worker全部任務(wù)結(jié)束kill掉之后。從現(xiàn)象上作證，也就是在relaod配置之后，短時(shí)間可能出現(xiàn)超過conf數(shù)量的進(jìn)程，更新完成后，進(jìn)程會(huì)完全改變。

不更新、直接替換，這種設(shè)計(jì)思路在代碼部署中也很常見，包括mysql遷移，代碼更新，服務(wù)嘗試，很值的學(xué)習(xí)。

了解了worker的熱加載之后，理解master就非常簡單了，通過信號(hào)控制，同時(shí)存在兩個(gè)master，逐步替代。

關(guān)于replace過程中如何細(xì)節(jié)控制一致性，穩(wěn)定性，信號(hào)控制，log控制等等，敬請(qǐng)期待小拽的進(jìn)一步探索！

啟動(dòng)進(jìn)程后，請(qǐng)求在nginx內(nèi)部是如何流轉(zhuǎn)的，nginx內(nèi)部包括哪些模塊？

【post header】請(qǐng)求到達(dá)后首先讀取header，log中request time初始時(shí)間便從此開始。

【rewrite】請(qǐng)求相關(guān)的配置和參數(shù)

【pre-access】預(yù)處理階段，頻率控制，高頻絕句

【acess】權(quán)限控制，白名單，403，access deny ，靜態(tài)文件開放等均有這個(gè)模塊產(chǎn)生

【content】這個(gè)模塊會(huì)調(diào)用upstream產(chǎn)生內(nèi)容，這個(gè)階段最重要此處調(diào)起了工作線程，調(diào)用fastcgi，http，以及各種操作產(chǎn)生內(nèi)容均在此處。性能優(yōu)化可能需要確認(rèn)程序執(zhí)行時(shí)間，對(duì)應(yīng)access log中的upstream time 由此產(chǎn)生，記錄了nginx中程序運(yùn)行的全量時(shí)間，而request - upstream 就是網(wǎng)絡(luò)傳輸和預(yù)處理時(shí)間。

【filter】內(nèi)容過濾，包括gzip壓縮，返回等在此處

【log】日志的產(chǎn)生

【重定向】沒有這個(gè)模塊，所有的進(jìn)行智能單向走，有了這個(gè)，在任何階段都可以產(chǎn)生返回，例如client主動(dòng)階段產(chǎn)生499的log，過程可能就是1-》2-》8-》7 over

摘自某ppt的一個(gè)圖，如侵權(quán)，請(qǐng)盡快聯(lián)系小拽

各個(gè)階段的主要狀態(tài)機(jī)可以參考:【跳轉(zhuǎn)】

了解了worker的工作模式和worker的內(nèi)部主要模塊，那么worker是如何管理請(qǐng)求的？

官方闡述：It’s well known that NGINX uses an asynchronous, event?driven approach to handling connections. This means that instead of creating another dedicated process or thread for each request (like servers with a traditional architecture), it handles multiple connections and requests in one worker process. To achieve this, NGINX works with sockets in a non?blocking mode and uses efficient methods such as epoll and kqueue.

核心詞：異步，事件驅(qū)動(dòng)，鏈接控制

解釋的很清楚，nginx并不是通過每個(gè)請(qǐng)求都創(chuàng)建線程，而是通過內(nèi)部管理的調(diào)度分配。
如下圖：此處不翻譯了，大家直接看原版
epoll詳解：【跳轉(zhuǎn)】

官方說明

Let’s return to our poor sales assistant who delivers goods from a faraway warehouse. But he has become smarter (or maybe he became smarter after being beaten by the crowd of angry clients?) and hired a delivery service. Now when somebody asks for something from the faraway warehouse, instead of going to the warehouse himself, he just drops an order to a delivery service and they will handle the order while our sales assistant will continue serving other customers. Thus only those clients whose goods aren’t in the store are waiting for delivery, while others can be served immediately.

小拽認(rèn)為簡而言之：結(jié)合實(shí)際情況，除了空閑被動(dòng)給，更多的通過事件驅(qū)動(dòng)主動(dòng)要，通過這種方式在執(zhí)行資源緊缺的情況下，達(dá)到一個(gè)執(zhí)行資源的優(yōu)化部署，如下圖。

線程池官網(wǎng)詳解：【跳轉(zhuǎn)】

請(qǐng)求的具體調(diào)度基于事件，例如網(wǎng)絡(luò)IO,磁盤IO,定時(shí)器等均可以對(duì)事件進(jìn)行阻塞，當(dāng)阻塞的事件空閑時(shí)，發(fā)出調(diào)度請(qǐng)求，完成處理。
需要額外提一下，nginx的定時(shí)器基于rbtree，紅黑樹的快速插入和查詢保證了nginx事件調(diào)度的高效性
事件框架的處理模型

性能：nginx 工作模式是master-worker進(jìn)程方式，執(zhí)行請(qǐng)求是有更輕量線程完成。

熱加載：nginx 替換非更新的方式是nginx熱加載的本質(zhì)

功能強(qiáng)大：nginx upstream是在線程層面調(diào)度，兼容多種，所以可以擴(kuò)展很多功能強(qiáng)大

處理流程：主要的流程過程和模塊分離清晰。

請(qǐng)求處理：通過自身的管理，線程池，異步事件驅(qū)動(dòng)等當(dāng)來完成任務(wù)調(diào)度

再次強(qiáng)調(diào)：初探nginx，有疑問或不準(zhǔn)確的地方，請(qǐng)直接開炮?。?！

netcraft：https://news.netcraft.com/arc...

nginx的線程調(diào)度設(shè)計(jì)：https://www.nginx.com/blog/in...

epoll詳述：http://man7.org/linux/man-pag...

http://yaocoder.blog.51cto.co...

線程池：https://www.nginx.com/blog/th...

【轉(zhuǎn)載請(qǐng)注明：【【nginx學(xué)習(xí)一】基本原理學(xué)習(xí) | 靠譜崔小拽 】