linuxnginx負載均衡

㈠ 負載均衡：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負載均衡策略是什麼

當一台伺服器的單位時間內的訪問量越大時，伺服器壓力就越大，大到超過自身承受能力時，伺服器就會崩潰。為了避免伺服器崩潰，讓用戶有更好的體驗，通過負載均衡的方式來分擔伺服器壓力。

建立很多很多伺服器，組成一個伺服器集群，當用戶訪問網站時，先訪問一個中間伺服器，在讓這個中間伺服器在伺服器集群中選擇一個壓力較小的伺服器，將該訪問請求引入該伺服器。

如此以來，用戶的每次訪問，都會保證伺服器集群中的每個伺服器壓力趨於平衡，分擔了伺服器壓力，避免了伺服器崩潰的情況。

nginx實現反向代理負載均衡

a、本地使用Windows系統，然後使用VirutalBox安裝一個虛擬的Linux系統。

在本地的Windows系統上分別安裝nginx（偵聽8080埠）和apache（偵聽80埠）。在虛擬的Linux系統上安裝apache（偵聽80埠）。這樣相當於擁有了1台nginx在前端作為反向代理伺服器；後面有2台apache作為應用程序伺服器，可以看作是小型的server cluster。

b、nginx用來作為反向代理伺服器，放置到兩台apache之前，作為用戶訪問的入口。

㈢ nginx負載均衡怎麼訪問資料庫

nginx 是一個輕量級的、高性能的 web server 主要可以干兩件事情：

1、直接作為http server(代替apache，對PHP需要FastCGI處理器支持)；
2、作為反向代理伺服器實現負載均衡

以下我們就來舉例說明如何使用 nginx 實現負載均衡。因為nginx在處理並發方面的優勢，現在這個應用非常常見。當然了Apache的 mod_proxy和mod_cache結合使用也可以實現對多台app server的反向代理和負載均衡，但是在並發處理方面apache還是沒有 nginx擅長。

方法/步驟
1
一、環境：
a. 我們本地是Windows系統，然後使用VirutalBox安裝一個虛擬的Linux系統。
在本地的Windows系統上分別安裝nginx(偵聽8080埠)和apache(偵聽80埠)。在虛擬的Linux系統上安裝apache(偵聽80埠)。
這樣我們相當於擁有了1台nginx在前端作為反向代理伺服器；後面有2台apache作為應用程序伺服器(可以看作是小型的server cluster。;-) )；

b. nginx用來作為反向代理伺服器，放置到兩台apache之前，作為用戶訪問的入口；
nginx僅僅處理靜態頁面，動態的頁面(php請求)統統都交付給後台的兩台apache來處理。
也就是說，可以把我們網站的靜態頁面或者文件放置到nginx的目錄下；動態的頁面和資料庫訪問都保留到後台的apache伺服器上。

c. 如下介紹兩種方法實現server cluster的負載均衡。
我們假設前端nginx(為127.0.0.1:80)僅僅包含一個靜態頁面index.html；
後台的兩個apache伺服器(分別為localhost:80和158.37.70.143:80)，一台根目錄放置phpMyAdmin文件夾和test.php(裡面測試代碼為print 「server1「;)，另一台根目錄僅僅放置一個test.php(裡面測試代碼為 print 「server2「;)。

2
二、針對不同請求 的負載均衡：
a. 在最簡單地構建反向代理的時候 (nginx僅僅處理靜態不處理動態內容，動態內容交給後台的apache server來處理)，我們具體的設置為：在nginx.conf中修改：
復制代碼 代碼如下:
location ~ \.php$ {
proxy_pass 158.37.70.143:80 ;
}
這樣當客戶端訪問localhost:8080/index.html的時候，前端的nginx會自動進行響應；
當用戶訪問localhost:8080/test.php的時候(這個時候nginx目錄下根本就沒有該文件)，但是通過上面的設置 location ~ \.php$(表示正則表達式匹配以.php結尾的文件，詳情參看location是如何定義和匹配的) ，nginx伺服器會自動pass給 158.37.70.143的apache伺服器了。該伺服器下的test.php就會被自動解析，然後將html的結果頁面返回給nginx，然後 nginx進行顯示(如果nginx使用memcached模塊或者squid還可以支持緩存)，輸出結果為列印server2。
如上是最為簡單的使用nginx做為反向代理伺服器的例子；
b. 我們現在對如上例子進行擴展，使其支持如上的兩台伺服器。
我們設置nginx.conf的server模塊部分，將對應部分修改為：
復制代碼 代碼如下:
location ^~ /phpMyAdmin/ {
proxy_pass 127.0.0.1:80 ;
}
location ~ \.php$ {
proxy_pass 158.37.70.143:80 ;
}
上面第一個部分location ^~ /phpMyAdmin/，表示不使用正則表達式匹配(^~)，而是直接匹配，也就是如果客戶端訪問的 URL是以http://localhost:8080/phpMyAdmin/ 開頭的話(本地的nginx目錄下根本沒有phpMyAdmin目錄)，nginx會自動pass到127.0.0.1:80 的Apache伺服器，該伺服器對phpMyAdmin目錄下的頁面進行解析，然後將結果發送給nginx，後者顯示；
如果客戶端訪問URL是http://localhost/test.php 的話，則會被pass到158.37.70.143:80 的apache進行處理。
因此綜上，我們實現了針對不同請求的負載均衡。
如果用戶訪問靜態頁面index.html，最前端的nginx直接進行響應；
如果用戶訪問test.php頁面的話，158.37.70.143:80 的Apache進行響應；
如果用戶訪問目錄phpMyAdmin下的頁面的話，127.0.0.1:80 的Apache進行響應；

3
三、 訪問同一頁面 的負載均衡：
即用戶訪問http://localhost:8080/test.php 這個同一頁面的時候，我們實現兩台伺服器的負載均衡 (實際情況中，這兩個伺服器上的數據要求同步一致，這里我們分別定義了列印server1和server2是為了進行辨認區別)。
a. 現在我們的情況是在windows下nginx是localhost偵聽8080埠；
兩台apache，一台是127.0.0.1:80(包含test.php頁面但是列印server1)，另一台是虛擬機的158.37.70.143:80(包含test.php頁面但是列印server2)。

b. 因此重新配置nginx.conf為：
首先在nginx的配置文件nginx.conf的http模塊中添加，伺服器集群server cluster(我們這里是兩台)的定義：
復制代碼 代碼如下:
upstream myCluster {
server 127.0.0.1:80 ;
server 158.37.70.143:80 ;
}
表示這個server cluster包含2台伺服器
〉然後在server模塊中定義，負載均衡：
復制代碼 代碼如下:
location ~ \.php$ {
proxy_pass http://myCluster ; #這里的名字和上面的cluster的名字相同
proxy_ www.gzlij.comredirect 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;
}
這樣的話，如果訪問http://localhost:8080/test.php 頁面的話，nginx目錄下根本沒有該文件，但是它會自動將其pass到myCluster定義的服務區機群中，分別由127.0.0.1:80;或者158.37.70.143:80;來做處理。
上面在定義upstream的時候每個server之後沒有定義權重，表示兩者均衡；如果希望某個更多響應的話例如：
復制代碼 代碼如下:
upstream myCluster {
server 127.0.0.1:80 weight=5;
server 158.37.70.143:80 ;
}

4
綜上，我們使用nginx的反向代理伺服器reverse proxy server的功能，將其布置到多台apache server的前端。
nginx僅僅用來處理靜態頁面響應和動態請求的代理pass，後台的apache server作為app server來對前台pass過來的動態頁面進行處理並返回給nginx。
通過以上的架構，我們可以實現nginx和多台apache構成的機群cluster的負載均衡。
兩種均衡：
1)可以在nginx中定義訪問不同的內容，代理到不同的後台server； 如上例子中的訪問phpMyAdmin目錄代理到第一台server上；訪問test.php代理到第二台server上；
2)可以在nginx中定義訪問同一頁面，均衡 (當然如果伺服器性能不同可以定義權重來均衡)地代理到不同的後台server上。 如上的例子訪問test.php頁面，會均衡地代理到server1或者server2上。
實際應用中，server1和server2上分別保留相同的app程序和數據，需要考慮兩者的數據同步。