phpnginx原理
❶ 為什麼nginx只能同時處理一個php，apache環境下可以同時運行
Nginx 的工作原理在這里我就不多贅述了，網上隨便搜一下 Nginx 的工作原理，成百上千的 blog 都在討論講述，可以自己搜一下。
但我可以簡單粗暴地回答一下你的這個問題，這樣也更方便理解。
---- Apache使用線程驅動處理 http 請求：每個連接都會打開一個線程，並在發送響應時關閉線程，釋放其他線程的資源。這就是說，你每發送一個 http 請求，Apache 就會給你分配一個接待員來處理這個請求；你發 10 個請求，就有 10 個接待員，一對一的方式來處理，所以無需等待；
---- Nginx 處理 http 請求使用 Reactor 模式，基本上默認情況下，它是單線程的（但可以分叉幾個進程來利用多個內核）。這就是說，不管你發幾個 http 請求，Nginx 只有一個接待員來處理你的請求，處理完了這個請求才能接著處理下一個請求，所以請求多的時候就需要排隊；
當然，Nginx 的這個處理方式不是死的，可以根據實際情況靈活配置；如果你要深入理解，我在這里簡簡單單也說不清楚，長篇大論的 Blog 網上都有，得慢慢看。
❷ 安裝nginx+php後，Php頁面訪問時提示404，但頁面是存在的.
安裝nginx+php後，Php頁面訪問時提示404，但頁面是存在的，應該是下面的原因造成的：
這個是因為index.html 文件目錄是nginx默認安裝目錄 /usr/local/nginx/html，而info.php 把它放到了 /data/web 下造成的，可以在nginx.conf配置文檔裡面找到相應的問題。
可以按照下面測試更改：
location ~ .php$ {
root /data/web;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
include fastcgi_params;
}
nginx -t && nginx -s reload
❸ nginx和php的兩種通信方式
Nginx與PHP的兩種通信方式-unix socket和tcp socket
1、兩者Nginx配置
unix socket
需要在nginx配置文件中填寫php-fpm運行的pid文件地址。
location ~ \.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
}
tcp socket
需要在nginx配置文件中填寫php-fpm運行的ip地址和埠號。
location ~ \.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
}
2、兩者比較
從上面的圖片可以看，unix socket減少了不必要的tcp開銷，而tcp需要經過loopback，還要申請臨時埠和tcp相關資源。但是，unix socket高並發時候不穩定，連接數爆發時，會產生大量的長時緩存，在沒有面向連接協議的支撐下，大數據包可能會直接出錯不返回異常。tcp這樣的面向連接的協議，多少可以保證通信的正確性和完整性。
3、選擇建議：如果是在同一台伺服器上運行的nginx和php-fpm，並發量不超過1000，選擇unix socket，因為是本地，可以避免一些檢查操作(路由等)，因此更快，更輕。 如果面臨高並發業務，我會選擇使用更可靠的tcp socket，以負載均衡、內核優化等運維手段維持效率。
❹ nginx與php-fpm的簡單的關系流程圖
流程：
1，首先Browser通過Http協議發送一個請求到Nginx伺服器
2，Nginx服務判斷是否為靜態資源是的話直接放回，否則載入nginx.conf配置文件里的fastcgi模塊。
3，Nginx通過fastcgi_pass （默認是127.0.0.0:9000）把對應的請求按照fastcgi協議轉發到PHP-FPM,php-fpm的master進程會監聽9000埠，然後給php-fpm work進程，work進程 再調用php-cgi解析器並且生成php執行環境再去執行解析對應的PHP文件
4，解析完成再返回給nginx,然後返回給瀏覽器。
註：
1，php-fpm會生成一個master進程用於監控9000埠，負責分發給下面的work進程
2，fastcgi 是一種協議用於解析器和伺服器之間的交互
❺ 請問磚家，nginx怎麼和php交互
nginx和php交互是通過fastcgi模塊來實現的。fastcgi在nginx中是作為一個upstream實現的。可以使用如下的配置實現nginx和php的交互，從而把nginx接收到的請求轉發給php。
fastcgi_passunix:/home/wangwei/php/var/php-cgi.sock;
❻ Nginx運行原理和配置詳解（個人總結筆記）
話不多說，擼起鍵盤就是干！正所謂知其然知其所以然，個人總結了下Nginx運行原理和配置詳解，便於理解和後續復盤。
先來看這一張圖。
nginx啟動後會有 一個master進程和多個worker進程 。master進程用來管理worker進程， 一個worker進程處理一個請求 ，一個請求，只可能在一個worker進程中處理，一個worker進程，不可能處理其它進程的請求。 worker進程的個數是可以設置的，一般我們會設置與機器cpu核數一致 ，這裡面的原因與nginx的進程模型以及事件處理模型是分不開的 ，過多的worker數，只會導致進程來競爭cpu資源，從而帶來不必要的上下文切換。
PHP WEB伺服器目前最佳方式之一就是： Nginx + FastCGI（解決CGI並發重復fork問題） + PHP-FPM（管理PHP-CGI進程） 。nginx是怎麼做到把請求拋給PHP解釋來處理的呢？這個過程又是怎麼實現的呢？稍後我們來看一下參數配置。
代理，反向代理，負載均衡是Nginx常用功能。
Http代理，反向代理：作為web伺服器最常用的功能之一，尤其是反向代理。如果你和小馬之前一樣還是分不清代理和反向代理的區別，下面這個圖對理解會有所幫助。
它們的區別就是，前者知道我要找的人並知道地址在哪，代理伺服器按這個地址代為請求一下然後把他說的話返回給我。後者就是，我知道我要找誰問話但不知道地址在哪，我也不想管，代理服務你自己去找，只要幫我返回他要說的話就可以了。
負載均衡：其實也是 反向代理 的一種。負載均衡，熱備等等其實都屬於高可用范疇，Nginx提供的負載均衡策略有2種：內置策略和擴展策略。內置策略為 輪詢，加權輪詢，Ip hash 等等。擴展策略，就天馬行空，只有你想不到的沒有他做不到的啦，你可以參照所有的負載均衡演算法，給他做下實現。思考一個問題，IP hash真的能解決session共享的問題么？
我們來簡單看下兩個 配置示例 。
這個配置將請求轉發轉向mysvr 定義的伺服器列表。 注意proxy_pass配置。其實這塊也是負載均衡的配置 。如下：
在訪問網站時，由於配置了proxy_pass地址，所有請求都會先通過nginx反向代理伺服器，在伺服器將請求轉發給目的主機時，讀取upstream為 tomcatsever1的地址，讀取分發策略，配置tomcat1權重為3，所以nginx會將大部分請求發送給49伺服器上的tomcat1，也就是8080埠；較少部分給tomcat2來實現有條件的負載均衡，當然這個條件就是伺服器1、2的硬體指數處理請求能力。
負載均衡配置 還有其他的相關參數，這是只是打個樣，不贅述。
可以認為fastcgi_pass這個配置非常關鍵，將Nginx + FastCGI + PHP-FPM串連 。這個配置將PHP請求都交給 fastcgi_pass配置的PHP-FPM處理。 location分別通過正則過濾和轉發配置決定了各個請求URL將要轉發交與的處理方式 ，location /表示默認請求，location ~\.php(.*)$ 表示PHP 腳本請求全部轉發到 FastCGI處理。 使用FastCGI默認配置.。
以上配置指定了這些 靜態文件要nginx自己處理 。
NGINX負載均衡可以用於很多服務負載均衡的實現，比如做Redis服務的負載均衡，配置upstream的IP列表再配置 proxy_pass 代理即可。那要實現負載均衡除了NGINX，還有哪些呢？
根據7層OSI模型可將負載均衡分為 ：
1）二層負載均衡（一般是用虛擬mac地址方式，外部對虛擬MAC地址請求，負載均衡接收後分配後端實際的MAC地址響應）；
2）三層負載均衡（一般採用虛擬IP地址方式，外部對虛擬的ip地址請求，負載均衡接收後分配後端實際的IP地址響應）；
3）四層負載均衡（在三次負載均衡的基礎上，用 ip+port 接收請求，再轉發到對應的機器）；
4）七層負載均衡（根據虛擬的url或是IP，主機名接收請求，再轉向相應的處理伺服器）。
這其中，最常見的是四層和七層負載均衡。思考一下，NGINX的負載均衡是屬於哪一種？
關於負載均衡的架構