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

本文目錄一覽：

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

Nginx：基本原理篇

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

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

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

Nginx 采用accept-mutex來解決驚群問題：當一個請求到達的時候，只有競爭到鎖的worker進程才會驚醒處理請求，其他進程會繼續(xù)等待，結(jié)合 timer_solution 配置的最大的超時時間繼續(xù)嘗試獲取accept-mutex

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

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

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

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

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

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

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

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

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

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

Nginx 常用功能

參考文章：

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

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

先來看這一張圖。

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

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

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

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

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

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

我們來簡單看下兩個 配置示例 。

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

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

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

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

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

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

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

1）二層負載均衡（一般是用虛擬mac地址方式，外部對虛擬MAC地址請求，負載均衡接收后分配后端實際的MAC地址響應）；

2）三層負載均衡（一般采用虛擬IP地址方式，外部對虛擬的ip地址請求，負載均衡接收后分配后端實際的IP地址響應）；

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

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

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

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

502 Bad Gateway

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

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

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

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

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

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

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

FastCGI原理

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

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

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

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

Nginx不支持對外部程序的直接調(diào)用或者解析，所有的外部程序（包括PHP）必須通過FastCGI接口來調(diào)用。FastCGI接口在Linux下是socket（這個socket可以是文件socket，也可以是ip socket）。為了調(diào)用CGI程序，還需要一個FastCGI的wrapper（wrapper可以理解為用于啟動另一個程序的程序），這個wrapper綁定在某個固定socket上，如端口或者文件socket。當Nginx將CGI請求發(fā)送給這個socket的時候，通過FastCGI接口，wrapper接收到請求，然后派生出一個新的線程，這個線程調(diào)用解釋器或者外部程序處理腳本并讀取返回數(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運行原理的介紹就聊到這里吧，感謝你花時間閱讀本站內(nèi)容，更多關(guān)于php nginx運行原理、phpnginx運行原理的信息別忘了在本站進行查找喔。