Ⅰ php負載均衡 下面怎麼得到真實ip
1、打開文件：/etc/httpd/conf/httd.conf。
2、在文件中查找：」CustomLog」，找到如下配置塊: 查看到當前使用的LogFormat為」combined」 (如果實際啟用的為其他日誌格式，替換相應的格式定義即可)。
#
# For a single logfile with access, agent, and referer information
# (Combined Logfile Format), use the following directive:
#
CustomLog logs/access_log combined
3、在文件中查找：」LogFormat」,找到如下配置塊（combined格式定義）:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
將其修改為：
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" \"%{X-Forwarded-For}i\" " combined
4、保存並關閉文件/etc/httpd/conf/httd.conf。
5、重啟Apache服務。
你試試吧，我也要努力在後盾人學習，一起加油吧@(*^ｪ^)@
Ⅱ nginx負載均衡 加速php，動靜分離是怎麼實現的
一個簡單的負載均衡的示例，把www.domain.com均衡到本機不同的埠，也可以改為均衡到不同的地址上。http { : upstream myproject { : server 127.0.0.1:8000 weight=3; : server 127.0.0.1:8001; : server 127.0.0.1:8002; : server 127.0.0.1:8003; : } : server { : listen 80; : server_name www.domain.com; : location / { : proxy_pass http://myproject; : } : } }
Ⅲ 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的負載均衡是屬於哪一種？
關於負載均衡的架構
Ⅳ 負載均衡：F5，Haproxy，lvs, nginx
閱讀本文前，需熟悉OSI七層參考模型。
常見的負載均衡設備，有F5，Haproxy，lvs, nginx等。
F5是商用硬體負載均衡，性能很好，但是價格昂貴，除了負載均衡，還有應用交換、會話交換、狀態監控等眾多功能。
F5一般做四層負載均衡，但也支持七層負載均衡。
Haproxy(以下簡稱ha)是軟嘩唯歲件負載均衡，開源，一般做七層負載均衡，但也支持四層負載均衡。
linux Virtual Server(以下簡稱lvs)是軟體負載均衡，開源，二層或四層負載均衡，已集成到linux內核，自身有完備的熱備方案（keepalived+lvs），穩定性極強。
nginx也是軟體負載均衡，開源，通過反向代理實現負載均衡，是七層負載均衡，性能不如上面的幾個。
tips1
有些公司，測試環境用ha/lvs/nginx，生產環境用F5。
tips2
nginx做web伺服器時，一般做靜態資源伺服器和php的web伺服器，所以很多公司，會採用F5+nginx或者ha+nginx的架構
tips3
微服務中的ribbon屬於客戶端負載均衡，上面的幾種都是服務端負載均衡
二層負載均衡
在數據鏈路層通過修改mac地址實現，如lvs的DR模式（直接路由模式）
三層負載均衡
在網路層通過DNAT協議修改目標地址實現
四層負載均衡
用ip+埠實現請求轉發
備註：tcp報文里並沒有ip，但是四層負載均衡可以用ip+埠，是因為server可以拿到ip
七層負載均衡
通過重新發起http請求實現，即client把請求發給lb，lb把請求代發給server，再把server的響應返回給client，因此七層負載均衡也經常被稱為代理，七層負載均衡設備也被稱為代理設備。
七層負載均衡常用於內網與外網的通信，比如內網無法直接訪問外網，需要通過代理設備代發http請求，這種情況下，代理設備需要配置雙網卡，以同時與內外網路通信。
由於山寬需要重發http請求，七層負載均衡性能較差，但是更智能和安全，因為應用層可以獲取甚至修改請求的真實內容（即應用數據），比如cookie、url等，可以做一些智能的操作，比如根據cookie/url轉發請求，也可以做一些安全操作，比如過濾特定報文、防止SYN Flood攻擊等。
使用七層負載均衡時，服務的性能受限於代理設備的網卡帶寬。
常見的負載均衡策略，有輪詢、加權輪詢、ip_hash、cookie、url_hash，根據伺服器響應時間轉發、根據最少連接轉發等等。
備註：nginx可以安裝第三方插件，使用第三方實現的策略
輪詢：按伺服器列表順序轉發請求，輪詢是nginx默認的策略，本策略適合伺服器配置相當、請求無狀態（即不依賴session）的場景
加權輪詢：如果不同伺服器配置不同，可以為配亂睜置高的伺服器增加權重
ip_hash：根據ip哈希結果轉發，可以實現同一用戶持續請求同一伺服器（即會話保持），適合有狀態（即依賴session）的場景，對png、jpg、js、css等靜態資源的請求，不適合使用本策略
cookie：根據特定cookie轉發請求，一般也是用於實現會話保持，比如為伺服器A、B分別增加service-flag=a、service-flag=b的cookie，後續請求根據cookie轉發
可以參考 haproxy實現會話保持
url_hash：根據url哈希結果轉發，同一個介面始終請求同一台伺服器，一般配合緩存使用，緩存介面返回結果
根據伺服器響應時間轉發：優先轉發到響應時間較快的伺服器
根據最少連接轉發：優先轉發到連接數較少的伺服器
F5有一些特有的負載均衡策略：利用從應用程序和伺服器收集到的各項性能指標，分析並轉發
負載均衡有兩個步驟：
1.根據什麼演算法選擇真實服務端，即負載均衡策略，如輪詢、加權輪詢、ip_hash、cookie、url_hash等；
2.把請求轉發到真實伺服器，轉發方式有二層到七層負載均衡
keepalived軟體一開始是專為lvs設計的，後來加入了可以實現高可用的VRRP (Virtual Router Rendancy Protocol ,虛擬路由器冗餘協議）功能，因此，keepalived還可以作為nginx、haproxy、mysql等服務的高可用解決方案。
以nginx為例，為了防止nginx本身由於宕機等原因導致網站不可用，一般會搭兩套nginx反向代理，用keepalived提供一個VIP。
一般情況下，VIP只在nginx主節點上工作，如果nginx主節點不可用了，VIP會自動漂移到從節點，自動漂移的原理即VRRP協議。
VIP漂移到從節點後，如果主節點恢復正常了，VIP是否漂移回主節點，取決於當前模式是搶占模式還是非搶占模式。
下圖是一張簡單的架構圖，解釋如下：
以上觀點純屬個人意見，如果錯誤，歡迎指出，有些地方寫的很簡單，是因為我也不懂~
Ⅳ 用nginx作為負載均衡伺服器，PHP代碼放在哪
lnmp架構 直接放nginx的web文件夾中，通過cgi解析php返回給nginx，如果是lnmpa架構，就是多了個apache,nginx負責分發請求，然後apache調用php_mod解析php,最後返回給nginx
如果是負載均衡，nginx分發請求，每個請求可能請求不同的伺服器，但是每個伺服器的網站程序應該是一致的，並且每個伺服器上都部署了php環境和程序，然後返回給請求者nginx輸出頁面。
Ⅵ Nginx反向代理實現負載均衡配置圖解
負載均衡配置是超大型機器需要考慮的一些問題 同時也是數據安全的一種做法 下面我來介紹在nginx中反向代理 負載均衡配置圖解 大家可參考本文章來操作首先簡單的介紹下修改默認的nginx conf 大概在 ~ 行 去掉前面的#號 重啟nginx
#location ~ php$ {# proxy_pass ;#}改為 location ~ php$ { proxy_pass // : ;}
分別訪問 出現如下圖已經能夠針對不同請求訪問伺服器了
這樣當我們訪問 l的時候 前端的nginx會自動進行響應 當訪問 /test php的時候(這個時候nginx目錄下根本就沒有該文件) 但是通過上面的設置location ~ php$(表示
訪問php頁面test php : 的Apache進行響應
訪問目錄phpMyAdmin下的頁面的話 : 的Apache進行響應
修改原始默認的nginx conf的server模塊部分（大概在 ~ 行）
#location ~ php$ {# proxy_pass ;#}修改為 location ^~ /phpMyAdmin/ { proxy_pass : ;} location ~ php$ { proxy_pass : ;}
上面第一個部分location ^~ /phpMyAdmin/ 表示不使用; index index
2.在配置文件nginx.conf的模塊中添加伺服器集群server cluster的定義。Tw.WinGWit.
upstream myCluster { server 192.168.2.3:8080 ; server 192.168.2.2:80 ; server 192.168.2.8:80 ;}
表示這個server cluster包含3台伺服器
3.然後在server模塊中定義負載均衡
location ~ .php$ { proxy_pass //myCluster ; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;}
proxy_pass //myCluster ; 這里的名字和上面的cluster的名字相同
配置好後，當訪問頁面，nginx目錄下根本沒有該文件，但是它會自動將其pass到myCluster定義的伺服器群，分別由上述的3台伺服器中的一台來做處理。
上面在定義upstream的時候每個server之後沒有定義權重，表示兩者均衡；如果希望某個更多響應的話，可以加weight
upstream myCluster { server 192.168.2.3:8080 weight=5; server 192.168.2.2:80 ; server 192.168.2.8:80 ;}
這樣表示5/7的幾率訪問第一個server,1/7訪問第二個、第三個。另外還可以定義max_fails和fail_timeout等參數。
所以我們使用nginx的反向代理伺服器reverse proxy server的功能，將其布置到多台apache server的前端。
nginx僅僅用來處理靜態頁面響應和動態請求的代理pass，後台的apache伺服器來對前台pass過來的動態頁面進行處理並返回給nginx。
Ⅶ 同台電腦nginx負載均衡後,第二個網站的PHP擴展啟動不起來
1、upstream 名稱最好不要用localhost
2、server_name 一般不帶埠號的。
3、location ~ .php$ {} 里配置有點復雜，完全可以簡化一下。
location~.php${
roothtml2;
fastcgi_pass127.0.0.1:9000;
fastcgi_indexindex.php;
includefastcgi.conf;
}