nginx和php-fpm調用方式

一.背景：

在開發中碰到一個問題，項目以nginx+php-fpm形式訪問交互，結果訪問項目時報錯以下圖：

 

二.分析：

提示很明確嘛，去看error.log（在nginx.conf或者vhost裏頭配置的，找到你對應路徑便可）

錯誤信息以下：

1 2 3

2017/09/18 10:46:21 [error] 3880#0: *92 connect() failed (111: Connection refused)   while connecting to upstream, client: 192.168.33.10, server: local.helios.com,   request: "GET /v1/room/detail.json HTTP/1.1" , upstream: "fastcgi://127.0.0.1:9000" , host: "local.helios.com"

或

1 2 3

2017 /09/18 14:30:42 [crit] 5375 #0: *43 connect() to unix:/tmp/php-cgi.sock failed (2: No such file or directory)    while connecting to upstream, client: 192.168.33.10, server: www.lnmp.org,     request: "GET /index.php?uri=look/index HTTP/1.1" , upstream: "fastcgi://unix:/tmp/php-cgi.sock:" , host: "local.helios.com"

關於問題：connect() failed (111: Connection refused) while connecting to upstream網上也有不少描述了，

1.php-fpm是否運行

1 2	ps aux | grep php-fpm // 查看是否啓動 /etc/init .d /php-fpm   或  /usr/local/php/sbin/php-fpm  // 啓動php-fpm

2.php-fpm隊列是否足夠

1 2 3

cat /proc/meminfo -u // 查看內存大，一個php-fpm平均進程佔用20MB,1G / 30MB = 33個  vi /usr/local/php/etc/php-fpm .conf  // 查看配置文件中 pm.max_children  pm.max_children = 33 // 改爲上邊的個數，可是最好留些餘地別飽和運行

3.php-fpm.conf與fastcgi.conf的監聽是否相同

1).查看php-fpm監聽方式：

1 2 3

vim /usr/local/php/etc/php-fpm .conf  listen = 127.0.0.1:9000 // 【ip+port形式】  ;listen = /tmp/php-cgi .sock

2).查看nginx指定與php-fpm通訊方式：

1 2 3 4 5 6

vi /usr/local/nginx/conf/vhost/vhost .conf  location ~\.php$ {     fastcgi_pass unix: /tmp/php-cgi .sock;【unxi domain socket形式】     fastcgi_index index.php;include fastcgi_params;             fastcgi_param  SCRIPT_FILENAME $document_root/$fastcgi_script_name;  }

三.解決：

根據上邊配置顯示，狀況已經很明顯了，本次問題屬於第三種狀況，

個人php-fpm用ip:port方式創建連接,

nginx卻用unix socket方式創建連接，

這是兩種不一樣方式，比如暗號不一樣，怎麼可能接上頭嘛！

修改操做以下：

用哪一種取決於你的PHP-FPM配置:，如下二選一便可。

方式1，統一成ip+port的形式:

1 2 3 4

php-fpm.conf:   listen = 127.0.0.1:9000  vhost.conf:   fastcgi_pass 127.0.0.1:9000;

方式2，統一成.sock的形式:

1 2 3 4

php-fpm.conf:   listen = /tmp/php-fpm .sock  vhost.conf:  fastcgi_pass unix: /tmp/php-fpm .sock;

重啓nginx與php-fpm

1 2	/etc/init .d /nginx reload  /etc/init .d /php-fpm reload

搞定，訪問再試試。

其中php-fpm.sock是一個文件,由php-fpm生成,類型是srw-rw----.

UNIX Domain Socket可用於兩個沒有親緣關係的進程,是目前普遍使

四.知識延伸：

上邊問題說到了是由於nginx與php-fpm進程通訊不匹配形成的，那他們有什麼不一樣呢？

unix socket方式

   優勢：

unix socket方式要比tcp的方式快，並且消耗資源少，由於socket之間在nginx和php-fpm的進程之間通訊，而tcp須要通過本地迴環驅動，還要申請臨時端口和tcp相關資源。

會有不少linux傻瓜面板，他們可能會有不少中 php-fpm的版本，那麼若是是不一樣版本去開不一樣的端口，而後nginx去配置的話，你要記住不少端口，sock文件即是解決這個問題最簡單的方法。

Socket是使用unix domain socket鏈接套接字/dev/shm/php-cgi.sock（不少教程使用路徑/tmp，而路徑/dev/shm是個tmpfs，速度比磁盤快得多）

   缺點：

unix socket會顯得不是那麼穩定，當併發鏈接數爆發時，會產生大量的長時緩存，在沒有面向鏈接協議支撐的狀況下，大數據包頗有可能就直接出錯並不會返回異常。

雖然sock有更少的數據拷貝和上下文切換，更少的資源佔用，可是若是數據都是錯的，那還有什麼用呢。另外使用sock的話，必須nginx和fpm在同一臺機器上

tcp方式

優勢：

從穩妥的考慮確定是使用tcp，tcp協議能保證數據的正確性，sock不能保證。

能夠跨服務器，當nginx和php-fpm不在同一臺機器上時，只能使用這種方式

缺點：

性能不如unix socket

 

更多知識：
nginx、php-fpm默認配置與性能–TCP socket仍是unix domain socket

 

5、php-fpm的理解

首先，CGI是幹嗎的？CGI是爲了保證web server傳遞過來的數據是標準格式的，方便CGI程序的編寫者。

web server（好比說nginx）只是內容的分發者。好比，若是請求/index.html，那麼web server會去文件系統中找到這個文件，發送給瀏覽器，這裏分發的是靜態數據。好了，若是如今請求的是/index.php，根據配置文件，nginx知道這個不是靜態文件，須要去找PHP解析器來處理，那麼他會把這個請求簡單處理後交給PHP解析器。Nginx會傳哪些數據給PHP解析器呢？url要有吧，查詢字符串也得有吧，POST數據也要有，HTTP header不能少吧，好的，CGI就是規定要傳哪些數據、以什麼樣的格式傳遞給後方處理這個請求的協議。仔細想一想，你在PHP代碼中使用的用戶從哪裏來的。

當web server收到/index.php這個請求後，會啓動對應的CGI程序，這裏就是PHP的解析器。接下來PHP解析器會解析php.ini文件，初始化執行環境，而後處理請求，再以規定CGI規定的格式返回處理後的結果，退出進程。web server再把結果返回給瀏覽器。

好了，CGI是個協議，跟進程什麼的不要緊。那fastcgi又是什麼呢？Fastcgi是用來提升CGI程序性能的。

提升性能，那麼CGI程序的性能問題在哪呢？"PHP解析器會解析php.ini文件，初始化執行環境"，就是這裏了。標準的CGI對每一個請求都會執行這些步驟（不閒累啊！啓動進程很累的說！），因此處理每一個時間的時間會比較長。這明顯不合理嘛！那麼Fastcgi是怎麼作的呢？首先，Fastcgi會先啓一個master，解析配置文件，初始化執行環境，而後再啓動多個worker。當請求過來時，master會傳遞給一個worker，而後當即能夠接受下一個請求。這樣就避免了重複的勞動，效率天然是高。並且當worker不夠用時，master能夠根據配置預先啓動幾個worker等着；固然空閒worker太多時，也會停掉一些，這樣就提升了性能，也節約了資源。這就是fastcgi的對進程的管理。

那PHP-FPM又是什麼呢？是一個實現了Fastcgi的程序，被PHP官方收了。

你們都知道，PHP的解釋器是php-cgi。php-cgi只是個CGI程序，他本身自己只能解析請求，返回結果，不會進程管理（皇上，臣妾真的作不到啊！）因此就出現了一些可以調度php-cgi進程的程序，好比說由lighthttpd分離出來的spawn-fcgi。好了PHP-FPM也是這麼個東東，在長時間的發展後，逐漸獲得了你們的承認（要知道，前幾年你們但是抱怨PHP-FPM穩定性太差的），也愈來愈流行。

好了，最後來回來你的問題。網上有的說，fastcgi是一個協議，php-fpm實現了這個協議

對。

有的說，php-fpm是fastcgi進程的管理器，用來管理fastcgi進程的

對。php-fpm的管理對象是php-cgi。但不能說php-fpm是fastcgi進程的管理器，由於前面說了fastcgi是個協議，彷佛沒有這麼個進程存在，就算存在php-fpm也管理不了他（至少目前是）。 有的說，php-fpm是php內核的一個補丁

之前是對的。由於最開始的時候php-fpm沒有包含在PHP內核裏面，要使用這個功能，須要找到與源碼版本相同的php-fpm對內核打補丁，而後再編譯。後來PHP內核集成了PHP-FPM以後就方便多了，使用--enalbe-fpm這個編譯參數便可。

有的說，修改了php.ini配置文件後，沒辦法平滑重啓，因此就誕生了php-fpm

是的，修改php.ini以後，php-cgi進程的確是沒辦法平滑重啓的。php-fpm對此的處理機制是新的worker用新的配置，已經存在的worker處理完手上的活就能夠歇着了，經過這種機制來平滑過分。

還有的說PHP-CGI是PHP自帶的FastCGI管理器，那這樣的話幹嘛又弄個php-fpm出

不對。php-cgi只是解釋PHP腳本的程序而已。

fastCGI

FastCGI是一個可伸縮地、高速地在HTTP Server和動態腳本語言間通訊的接口，它採用C/S結構，能夠將HTTP服務和腳本解析服務器分開，當HTTP服務器遇到動態請求時，會將請求轉發給FastCGI進程，FastCGI進程執行動態腳本後再將結果返回給HTTP服務器，HTTP服務器最後將結果輸出給瀏覽器，這在很大程度上提升了請求的相應速度。

 

實現FastCGI有幾種方式：php-CGI、php-FPM、Spawn-FCGI

nginx結合FastCGI工做原理以下圖：

 

 

php-CGI是PHP自帶的fastCGI管理器，有兩個問題，

① 變動php.ini時必須重啓php-cgi才能生效

② php-cgi進程崩潰或者被殺死後php就不能運行

php-fpm是從php5.3.3以後新加入的管理器，在更改php配置以後不須要重啓，且因爲加入守護進程，因此即便被殺死以後也能快速重啓。

Spawn-fcgi是一個通用的fastcgi管理器，而不只僅只針對php一種腳本語言。但它在效率、cup佔用方面都不如php-fpm.

php-fpm

php-fpm是一個獨立的進程，因此須要與nginx進行通訊，有兩種通訊方式：

①tcp ②socket

這兩種配置方式都須要修改nginx配置文件（/etc/nginx/sites-available/default）和fpm配置文件(/etc/php/7.0/fpm/pool.d/www/conf)

① tcp

1 2 3 4 5 6

nginx配置文件： fastcgi_pass 127.0.0.1:9000; php-fpm配置文件： listen = 127.0.0.1:9000 #重啓nginx service nginx restart

② socket

1 2 3 4 5 6

nginx配置文件： fastcgi_pass unix: /run/php/php7 .0-fpm.sock; php-fpm配置文件： listen = /run/php/php7 .0-fpm.sock #重啓php-fpm service php-fpm restart

lnmp組合調用邏輯關係圖：

lnmp FastCGI調用PHP MYSQL關係邏輯圖：

 

做者：羅阿紅 出處：http://www.cnblogs.com/luoahong/