Nginx的幾種負載均衡upstream

本文暫時不考慮session共享的問題，僅針對upstream的幾種方式做簡單介紹。

這樣定義：

在http{}內增長

1、默認模式（按每一個請求的時間順序交替*每一個服務器權重同樣*分配到不一樣的服務器，若是服務器掛了會自動剔除）

1. upstream callbell_ccrm {
2.         server 10.161.215.40 down; 
3.         server 10.165.32.12;
4.         server 10.165.32.13;
5.         server 10.165.32.14 backup;
6.     }

2、 分配權重（是上面一種的升級，第一種默認是權重一致，如今是可自定義weight，即訪問的比例，當前是2:1 ，一般服務器配置高的weight大，若是服務器掛了會自動剔除）

1. upstream callbell_ccrm {
2.         server 10.161.215.40 down; 
3.         server 10.165.32.12 weight=2;
4.         server 10.165.32.13 weight=1;
5.         server 10.165.32.14 backup;
6.     }

down 表示單前的server暫時不參與負載 
weight  默認爲1.weight越大，負載的權重就越大。 
max_fails ：容許請求失敗的次數默認爲1.當超過最大次數時，返回proxy_next_upstream 模塊定義的錯誤 
fail_timeout:max_fails 次失敗後，暫停的時間。 
backup： 其它全部的非backup機器down或者忙的時候，請求backup機器。因此這臺機器壓力會最輕。

注意：前兩種方式都是針對每一個請求的，因此一個用戶的屢次請求會被分配到不一樣服務器上，若是沒有實現session，會出現各類問題，此兩種方案必須在實現session共享的基礎上使用。

3、IP哈希、綁定 （按每一個請求按訪問ip的hash結果分配，這樣每一個ip的訪客都「固定」訪問一個後端服務器，不會有session的問題，若是某一臺服務器掛了會自動剔除，可是會將請求分配到別的服務器上，此時就會有session不一樣步的問題）

1.  upstream callbell_ccrm {
2.         ip_hash; #ip輪詢
3.         server 10.161.215.40; 
4.         server 10.165.32.12;
5.     }

 還能夠結合權重來使用 ip_hash 如：

1. upstream callbell_ccrm {
2.         ip_hash; #ip輪詢
3.         server 10.161.215.40 weight=3;  #權重比爲3
4.         server 10.165.32.12 weight=1;#權重比爲1
5.     }

這樣能夠根據便可經過IP來區分訪客並固定訪問一個服務器，又能夠根據權重更好利用服務器資源。

注意：同一個局域網其實出口IP都是同一個，因此都會分配到同一臺後臺服務器。

ip_hash是有缺陷的，不能在一些狀況下使用：

1.nginx不是最前端的服務器。ip_hash要求nginx必定是最前端的服務器，不然nginx得不到正確ip，就不能根據ip做hash。譬如使用的是squid爲最前端，那麼nginx取ip時只能獲得squid的服務器ip地址，用這個地址來做分流是確定錯亂的。

2.nginx的後端還有其它方式的負載均衡。假如nginx後端又有其它負載均衡，將請求又經過另外的方式分流了，那麼某個客戶端的請求確定不能定位到同一臺session應用服務器上。這麼算起來，nginx後端只能直接指向應用服務器，或者再搭一個squid，而後指向應用服務器。最好的辦法是用location做一次分流，將須要session的部分請求經過ip_hash分流，剩下的走其它後端去。

4、其餘第三方：fair  按後端服務器的響應時間來分配請求，響應時間短的優先分配。 url_hash 按url的hash來分配。