本篇文章給大家談?wù)刾hpnginx運(yùn)行原理，以及php nginx運(yùn)行原理對(duì)應(yīng)的知識(shí)點(diǎn)，希望對(duì)各位有所幫助，不要忘了收藏本站喔。

本文目錄一覽：

• 1、Nginx：基本原理篇
• 2、Nginx運(yùn)行原理和配置詳解（個(gè)人總結(jié)筆記）
• 3、502 Bad Gateway
• 4、nginx和php-fpm之間是怎樣通信的

Nginx：基本原理篇

Nginx的IO通常使用epoll，epoll函數(shù)使用了I/O復(fù)用模型。與I/O阻塞模型比較，I/O復(fù)用模型的優(yōu)勢(shì)在于可以同時(shí)等待多個(gè)（而不只是一個(gè)）套接字描述符就緒。Nginx的epoll工作流程如下：

2 . 當(dāng)一個(gè)client連接到來時(shí)，所有accept的work進(jìn)程都會(huì)受到通知，但只有一個(gè)進(jìn)程可以accept成功，其它的則會(huì)accept失敗，Nginx提供了一把共享鎖accept_mutex來保證同一時(shí)刻只有一個(gè)work進(jìn)程在accept連接，從而解決驚群問題

驚群現(xiàn)象：驚群效應(yīng)就是當(dāng)一個(gè)fd的事件被觸發(fā)時(shí)，所有等待這個(gè)fd的線程或進(jìn)程都被喚醒。一般都是socket的accept()會(huì)導(dǎo)致驚群，很多個(gè)進(jìn)程都block在server socket的accept()，一但有客戶端進(jìn)來，所有進(jìn)程的accept()都會(huì)返回，但是只有一個(gè)進(jìn)程會(huì)讀到數(shù)據(jù)，就是驚群。

Nginx 采用accept-mutex來解決驚群問題：當(dāng)一個(gè)請(qǐng)求到達(dá)的時(shí)候，只有競(jìng)爭(zhēng)到鎖的worker進(jìn)程才會(huì)驚醒處理請(qǐng)求，其他進(jìn)程會(huì)繼續(xù)等待，結(jié)合 timer_solution 配置的最大的超時(shí)時(shí)間繼續(xù)嘗試獲取accept-mutex

I/O 復(fù)用接口有select 和 epoll 兩種模型，首先介紹一下這兩種模型的執(zhí)行方式：

由于網(wǎng)絡(luò)響應(yīng)時(shí)間的延遲使得大量TCP連接處于非活躍狀態(tài)，但調(diào)用select()還是會(huì)對(duì) 所有的socket進(jìn)行一次線性掃描 ，會(huì)

調(diào)用一次epoll_wait()獲得就緒文件描述符時(shí)，返回的并不是實(shí)際的描述符，而是一個(gè)代表就緒描述符數(shù)量的值，拿到這些值去epoll指定的一個(gè)數(shù)組中依次取得相應(yīng)數(shù)量的文件描述符即可，這里使用內(nèi)存映射（mmap）技術(shù)， 避免了復(fù)制大量文件描述符帶來的開銷。

在select/poll時(shí)代，服務(wù)器進(jìn)程每次都把這100萬個(gè)連接告訴操作系統(tǒng)(從用戶態(tài)復(fù)制句柄數(shù)據(jù)結(jié)構(gòu)到內(nèi)核態(tài))，讓操作系統(tǒng)內(nèi)核去查詢這些套接字上是否有事件發(fā)生，輪詢完后，再將句柄數(shù)據(jù)復(fù)制到用戶態(tài)，讓服務(wù)器應(yīng)用程序輪詢處理已發(fā)生的網(wǎng)絡(luò)事件，這一過程資源消耗較大，因此，select/poll一般只能處理幾千的并發(fā)連接。

epoll的設(shè)計(jì)和實(shí)現(xiàn)與select完全不同。epoll通過在Linux內(nèi)核中申請(qǐng)一個(gè)簡易的文件系統(tǒng)，把原先的select/poll調(diào)用分成了3個(gè)部分：

調(diào)用epoll_create()建立一個(gè)epoll對(duì)象(在epoll文件系統(tǒng)中為這個(gè)句柄對(duì)象分配資源)

調(diào)用epoll_ctl向epoll對(duì)象中添加這100萬個(gè)連接的套接字

調(diào)用epoll_wait收集發(fā)生的事件的連接

只需要在進(jìn)程啟動(dòng)時(shí)建立一個(gè)epoll對(duì)象，然后在需要的時(shí)候向這個(gè)epoll對(duì)象中添加或者刪除連接。同時(shí)，epoll_wait的效率也非常高，因?yàn)檎{(diào)用epoll_wait時(shí)，并沒有一股腦的向操作系統(tǒng)復(fù)制這100萬個(gè)連接的句柄數(shù)據(jù)，內(nèi)核也不需要去遍歷全部的連接。

apache 采用的select模型，nginx采用epoll模型，nginx 處理請(qǐng)求是異步非阻塞的，而apache則是阻塞型的，在高并發(fā)下nginx 能保持低資源低消耗高性能。在Apache+PHP（prefork）模式下，如果PHP處理慢或者前端壓力很大的情況下，很容易出現(xiàn)Apache進(jìn)程數(shù)飆升，從而拒絕服務(wù)的現(xiàn)象。

Nginx 常用功能

參考文章：

Nginx運(yùn)行原理和配置詳解（個(gè)人總結(jié)筆記）

話不多說，擼起鍵盤就是干！正所謂知其然知其所以然，個(gè)人總結(jié)了下Nginx運(yùn)行原理和配置詳解，便于理解和后續(xù)復(fù)盤。

先來看這一張圖。

nginx啟動(dòng)后會(huì)有 一個(gè)master進(jìn)程和多個(gè)worker進(jìn)程 。master進(jìn)程用來管理worker進(jìn)程， 一個(gè)worker進(jìn)程處理一個(gè)請(qǐng)求 ，一個(gè)請(qǐng)求，只可能在一個(gè)worker進(jìn)程中處理，一個(gè)worker進(jìn)程，不可能處理其它進(jìn)程的請(qǐng)求。 worker進(jìn)程的個(gè)數(shù)是可以設(shè)置的，一般我們會(huì)設(shè)置與機(jī)器cpu核數(shù)一致 ，這里面的原因與nginx的進(jìn)程模型以及事件處理模型是分不開的 ，過多的worker數(shù)，只會(huì)導(dǎo)致進(jìn)程來競(jìng)爭(zhēng)cpu資源，從而帶來不必要的上下文切換。

PHP WEB服務(wù)器目前最佳方式之一就是： Nginx + FastCGI（解決CGI并發(fā)重復(fù)fork問題） + PHP-FPM（管理PHP-CGI進(jìn)程） 。nginx是怎么做到把請(qǐng)求拋給PHP解釋來處理的呢？這個(gè)過程又是怎么實(shí)現(xiàn)的呢？稍后我們來看一下參數(shù)配置。

代理，反向代理，負(fù)載均衡是Nginx常用功能。

Http代理，反向代理：作為web服務(wù)器最常用的功能之一，尤其是反向代理。如果你和小馬之前一樣還是分不清代理和反向代理的區(qū)別，下面這個(gè)圖對(duì)理解會(huì)有所幫助。

它們的區(qū)別就是，前者知道我要找的人并知道地址在哪，代理服務(wù)器按這個(gè)地址代為請(qǐng)求一下然后把他說的話返回給我。后者就是，我知道我要找誰問話但不知道地址在哪，我也不想管，代理服務(wù)你自己去找，只要幫我返回他要說的話就可以了。

負(fù)載均衡：其實(shí)也是 反向代理 的一種。負(fù)載均衡，熱備等等其實(shí)都屬于高可用范疇，Nginx提供的負(fù)載均衡策略有2種：內(nèi)置策略和擴(kuò)展策略。內(nèi)置策略為 輪詢，加權(quán)輪詢，Ip hash 等等。擴(kuò)展策略，就天馬行空，只有你想不到的沒有他做不到的啦，你可以參照所有的負(fù)載均衡算法，給他做下實(shí)現(xiàn)。思考一個(gè)問題，IP hash真的能解決session共享的問題么？

我們來簡單看下兩個(gè) 配置示例 。

這個(gè)配置將請(qǐng)求轉(zhuǎn)發(fā)轉(zhuǎn)向mysvr 定義的服務(wù)器列表。 注意proxy_pass配置。其實(shí)這塊也是負(fù)載均衡的配置 。如下：

在訪問網(wǎng)站時(shí)，由于配置了proxy_pass地址，所有請(qǐng)求都會(huì)先通過nginx反向代理服務(wù)器，在服務(wù)器將請(qǐng)求轉(zhuǎn)發(fā)給目的主機(jī)時(shí)，讀取upstream為 tomcatsever1的地址，讀取分發(fā)策略，配置tomcat1權(quán)重為3，所以nginx會(huì)將大部分請(qǐng)求發(fā)送給49服務(wù)器上的tomcat1，也就是8080端口；較少部分給tomcat2來實(shí)現(xiàn)有條件的負(fù)載均衡，當(dāng)然這個(gè)條件就是服務(wù)器1、2的硬件指數(shù)處理請(qǐng)求能力。

負(fù)載均衡配置 還有其他的相關(guān)參數(shù)，這是只是打個(gè)樣，不贅述。

可以認(rèn)為fastcgi_pass這個(gè)配置非常關(guān)鍵，將Nginx + FastCGI + PHP-FPM串連 。這個(gè)配置將PHP請(qǐng)求都交給 fastcgi_pass配置的PHP-FPM處理。 location分別通過正則過濾和轉(zhuǎn)發(fā)配置決定了各個(gè)請(qǐng)求URL將要轉(zhuǎn)發(fā)交與的處理方式 ，location /表示默認(rèn)請(qǐng)求，location? ~\.php(.*)$ 表示PHP 腳本請(qǐng)求全部轉(zhuǎn)發(fā)到 FastCGI處理。 使用FastCGI默認(rèn)配置.。

以上配置指定了這些 靜態(tài)文件要nginx自己處理 。

NGINX負(fù)載均衡可以用于很多服務(wù)負(fù)載均衡的實(shí)現(xiàn)，比如做Redis服務(wù)的負(fù)載均衡，配置upstream的IP列表再配置 proxy_pass 代理即可。那要實(shí)現(xiàn)負(fù)載均衡除了NGINX，還有哪些呢？

根據(jù)7層OSI模型可將負(fù)載均衡分為 ：

1）二層負(fù)載均衡（一般是用虛擬mac地址方式，外部對(duì)虛擬MAC地址請(qǐng)求，負(fù)載均衡接收后分配后端實(shí)際的MAC地址響應(yīng)）；

2）三層負(fù)載均衡（一般采用虛擬IP地址方式，外部對(duì)虛擬的ip地址請(qǐng)求，負(fù)載均衡接收后分配后端實(shí)際的IP地址響應(yīng)）；

3）四層負(fù)載均衡（在三次負(fù)載均衡的基礎(chǔ)上，用 ip+port 接收請(qǐng)求，再轉(zhuǎn)發(fā)到對(duì)應(yīng)的機(jī)器）；

4）七層負(fù)載均衡（根據(jù)虛擬的url或是IP，主機(jī)名接收請(qǐng)求，再轉(zhuǎn)向相應(yīng)的處理服務(wù)器）。

這其中，最常見的是四層和七層負(fù)載均衡。思考一下，NGINX的負(fù)載均衡是屬于哪一種？

關(guān)于負(fù)載均衡的架構(gòu)

502 Bad Gateway

502badgateway要先找到nginx配置的路徑。

然后找到nginx所在的error日志文件來查看具體原因。

如果是客戶端瀏覽器配置的問題，以360瀏覽器為例，出現(xiàn)502BadGateway可能是設(shè)置了代代理導(dǎo)致的。

取消瀏覽器代理之后，刷新一下就可以訪問了。

502BadGateway是一種報(bào)錯(cuò)提示，這一錯(cuò)誤并不意味著上游服務(wù)器已關(guān)閉（無響應(yīng)網(wǎng)關(guān)/代理），而是上游服務(wù)器和網(wǎng)關(guān)/代理不同意的協(xié)議交換數(shù)據(jù)。

鑒于互聯(lián)網(wǎng)協(xié)議是相當(dāng)清楚的，它往往意味著一個(gè)或兩個(gè)機(jī)器已不正確或不完全編程。

nginx和php-fpm之間是怎樣通信的

FastCGI原理

FastCGI是一個(gè)運(yùn)用于Http Server和動(dòng)態(tài)腳本語言間通信的接口，多數(shù)流行的Http Server都支持FastCGI，包括Apache、Nginx和lighttpd等。同時(shí)，F(xiàn)astCGI也被許多腳本語言支持，其中就有PHP。

FastCGI接口方式采用C/S結(jié)構(gòu)，可以將HttP服務(wù)器和腳本解析服務(wù)器分開，同時(shí)在腳本解析服務(wù)器上啟動(dòng)一個(gè)或者多個(gè)腳本解析守護(hù)進(jìn)程。當(dāng)HttP服務(wù)器每次遇到動(dòng)態(tài)程序時(shí)，可以將其直接交付給FastCGI進(jìn)程來執(zhí)行，然后將得到的結(jié)果返回給客戶端。這種方式可以讓HttP服務(wù)器專一地處理靜態(tài)請(qǐng)求或者將動(dòng)態(tài)腳本服務(wù)器的結(jié)果返回給客戶端，這在很大程度上提高了整個(gè)應(yīng)用系統(tǒng)的性能。

Nginx+php-fpm實(shí)現(xiàn)原理

Nginx本身不會(huì)對(duì)PHP進(jìn)行解析，終端對(duì)PHP頁面的請(qǐng)求將會(huì)被Nginx交給FastCGI進(jìn)程監(jiān)聽的IP地址及端口，由php-fpm作為動(dòng)態(tài)解析服務(wù)器處理，最后將處理結(jié)果再返回給nginx。其實(shí)，Nginx就是一個(gè)反向代理服務(wù)器。Nginx通過反向代理功能將動(dòng)態(tài)請(qǐng)求轉(zhuǎn)向后端php-fpm，從而實(shí)現(xiàn)對(duì)PHP的解析支持，這就是Nginx實(shí)現(xiàn)PHP動(dòng)態(tài)解析的原理。

Nginx不支持對(duì)外部程序的直接調(diào)用或者解析，所有的外部程序（包括PHP）必須通過FastCGI接口來調(diào)用。FastCGI接口在Linux下是socket（這個(gè)socket可以是文件socket，也可以是ip socket）。為了調(diào)用CGI程序，還需要一個(gè)FastCGI的wrapper（wrapper可以理解為用于啟動(dòng)另一個(gè)程序的程序），這個(gè)wrapper綁定在某個(gè)固定socket上，如端口或者文件socket。當(dāng)Nginx將CGI請(qǐng)求發(fā)送給這個(gè)socket的時(shí)候，通過FastCGI接口，wrapper接收到請(qǐng)求，然后派生出一個(gè)新的線程，這個(gè)線程調(diào)用解釋器或者外部程序處理腳本并讀取返回?cái)?shù)據(jù)；接著，wrapper再將返回的數(shù)據(jù)通過FastCGI接口，沿著固定的socket傳遞給Nginx；最后，Nginx將返回的數(shù)據(jù)發(fā)送給客戶端。

Nginx 簡單配置

location ~ \.php$ {

root /home/admin/web/nginx/html/;

fastcgi_pass 127.0.0.1:9000;

fastcgi_index index.php;

fastcgi_param SCRIPT_FILENAME /home/admin/web/nginx/html/$fastcgi_script_name;

include fastcgi_params;

}

phpnginx運(yùn)行原理的介紹就聊到這里吧，感謝你花時(shí)間閱讀本站內(nèi)容，更多關(guān)于php nginx運(yùn)行原理、phpnginx運(yùn)行原理的信息別忘了在本站進(jìn)行查找喔。