Nginx之負載均衡配置（一）

　　前文咱們聊了下nginx做爲反向代理服務器，代理後端動態應用服務器的配置，回顧請參考http://www.javashuo.com/article/p-shwjfeog-dh.html；今天咱們來聊一聊nginx做爲反向代理服務器，代理一組服務器的配置（負載均衡）；前邊咱們只說到了nginx怎麼去代理後端服務器響應客戶端的請求，它在響應客戶端請求的流程是這樣的，用戶請求發送到nginx代理服務器上，此時nginx服務器扮演的就是服務端的角色，客戶端是沒法感知後端服務器的存在，而用戶的報文被nginx接收後，nginx代理服務器它會把用戶的請求報文拆開看，用戶請求的資源，而後把用戶的請求資源，拿到本身的location中進行匹配，若是匹配到了，就按照匹配到的location中定義的代理規則進行代理，在這以前nginx首先會看本身的緩存是否存在用戶請求的資源，若是有，它就從緩存中響應用戶，若是沒有，它就扮演客戶端的角色，從新對用戶請求從新封裝請求報文，發送給後端服務器，後端服務器收到請求後，把對應資源響應給nginx代理服務器，nginx會把後端服務器響應的資源，先緩存一份（若是容許緩存的話），而後在封裝響應報文，響應客戶端；從這樣一個過程來看，nginx它既當服務器角色，又當客戶端角色，並且nginx是能夠把用戶的報文拆開，而後再封裝；這是nginx做爲代理服務器代理後端服務器響應客戶端請求的一個過程（後端服務器是一個的狀況）；若是後端服務器有多個，都是提供者相同的服務，此時咱們該怎麼把客戶端的請求代理到後端多臺服務器呢？

　　首先咱們來了解下nginx的upstream模塊，nginx的upstream模塊有兩個，一個是基於http協議的upstream，它主要是基於http協議定義後端服務器組，還有一個就是基於tcp協議的upstream，它主要是基於tcp協議定義後端服務器組；咱們先說nginx的http裏的upstream模塊吧！！！

　　1、ngx_http_upstream_module：此模塊用於定義一組服務器，而後被proxy_pass、fastcgi_pass、uwsgi_pass、scgi_pass和memcached_pass指令引用的服務器組。意思很簡單，就是把相同的多臺服務器歸併成一組服務器，而後nginx基於各類協議的代理，把請求代理到該組上，從而實現把用戶請求代理到後端多臺服務器上

　　一、upstream name {……}：此指令只能用於http配置段中，意思是定義一組後端服務器組；

　　二、server address [parameters]:此指令用於upstream配置段中，表示定義upstream配置段中的server成員，以及相關的參數；其中地址的格式支持IP地址加端口的形式，支持unix path路徑，也支持主機名或域名加端口的形式；parameters表示參數，經常使用的參數有weight=number權重，默認是1，max_fails=number表示失敗嘗試最大次數；超出此處指定的次數，nginx將失敗的server標記爲不可用；fail_timeout=time表示設置將服務器標記爲不可用狀態的超時時長；max_conns表示當前的服務器的最大併發鏈接數；backup表示將服務器標記爲「備用」，既全部服務器均不可用時，此服務器纔會被啓用，有點相似LVS裏的sorry server的角色；down表示將服務器標記爲「不可用」

　　三、least_conn：此指令表示最少鏈接調度算法，當server擁有不一樣的權重時表示wlc算法

　　四、ip_hash：此指令相似lvs裏的sh算法（源地址哈希算法），同一客戶端地址始終調度到同一臺服務器上；

　　五、hash key [consistent]：基於指定的key的hash表示實現對請求的調度，此處的key能夠是文本、變量、或者兩者的組合；做用是將請求分類，將同一類請求發往同一個upstream的server進行響應；

　　六、keepalive connections：爲每一個worker進程保留的空閒的長鏈接數量；

　　示例：

　　定義一組服務器名爲webserver

  　　提示：upstream 只能用於定義在http配置段中，它表示定義一組服務器，名爲webserver ，後續調度直接將用戶請求代理到該組上便可；

  　　提示：以上配置表示將用戶訪問www.proxy.com時將用戶請求代理到webserver這個組上的服務器，默認狀況下是輪詢的；

 　　提示：能夠看到客戶端的請求是能夠經過nginx把請求代理到後端一組服務器上，從上面的響應結果來看，咱們不配置任何權重，它默認就是輪詢的（固然上面的結果也有重複的，這個還不太清楚爲何會重複，多是每一個報文的響應速度不同吧，但總的響應是同樣的每一個後端服務器各佔一半）；固然咱們也是能夠給不一樣的服務器加上不一樣的權重，此時nginx做爲調度器就是使用的加權輪詢，以下配置

  　　提示：以上配置表示 192.168.0.20這臺服務器的權重是5，0.22的權重是2，意思就是7個請求中，0.20處理5個請求，0.22處理2個請求；

 　　假如咱們後端服務器有一臺服務出現故障，nginx會不會把用戶的請求調度到出現故障的服務器上呢？咱們知道在lvs作調度器時，前端lvs會把用戶的請求調度到出現故障的服務器上，咱們須要藉助keepalived或者其餘輔助服務去實現對後端服務器作健康狀態監測，才能把用戶的請求不調度到有故障的後端服務器上，nginx會不會呢？

　　提示：能夠看到nginx不會把用戶的請求調度到有故障的服務器上，這是由於nginx自身就有對後端服務器作健康狀態監測的機制，可以及時的發現後端服務器的健康狀態，及時的將服務不可用的後端主機從集羣中下線，固然這種下線是當服務不可用時，自動觸發的動做，咱們也能夠人爲的把後端服務器標記爲不可用狀態，一般在作灰度發佈時可能用到，直接在服務器後面明確用down來標記該服務器，不接受任何請求；

　　提示：以上配置表示把0.22這臺主機從webserver組中下線，下線的意思就是再也不往上調度請求；固然此時的組中服務器就只用0.20這一臺主機，用戶請求也只能調度到這臺上，因此用戶無論怎麼請求，nginx都只會把請求調度到0.20這臺後端主機上；

　　假如後面的兩臺主機都宕機了，此時用戶訪問咱們的網站會不會像lvs那樣，有sorry server 來給用戶說sorry 呢？

　　提示：能夠看到當後端主機所有宕機後，沒有像lvs裏的有sorry server出來給用戶說sorry 或者響應客戶端請求的；在nginx裏sorry server裏的配置很簡單，只須要在服務器的後面打上backup的標籤便可

　　提示：以上配置表示把127.0.0.1:80做爲sorry server ,意思是組裏的正常被代理的主機所有宕機後，這臺主機纔會被調度，當組裏主機有一臺恢復正常，這臺主機就不被調度，用戶請求將調度到正常的那一臺主機上；

　　提示：能夠看到當後端主機所有宕機後，sorry server就會被調度；

　　提示：當後端主機恢復時，sorry server 就不會被調度，用戶的請求將會被代理至恢復的那臺主機上；

　　以上就是nginx做爲負載均衡的經常使用配置，接下來咱們在說說調度算法

　　基於源地址hash算法

　　提示：以上配置表示同一源地址的客戶端請求將會調度到後端某一臺server上進行響應

　　提示：能夠看到同一客戶段始終被調度到一臺server上進行響應，這種就叫作源地址綁定；除了以上ip_hash;來指定綁定源地址，還能夠經過hash key來指定，以上配置等同hash $remote_addr;

　　基於用戶請求的uri進行綁定，用戶請求同一uri始終調度到某一server上響應，這樣作的好處可使緩存命中提升；

　　提示：以上配置表示綁定用戶請求的rui，不一樣的用戶請求同一rui時，nginx會始終把同一rui的請求調度到同一臺server上進行響應；

　　提示：能夠看到同一客戶端請求不一樣的uri時，會根據請求的uri隨機調度到某一臺server上進行響應；從上面的配置實例咱們能夠知道咱們把什麼看成key來hash，就能夠實現基於什麼來綁定後端服務器，好比基於用戶請求的uri看成hash對象，那麼用戶請求同一uri就會被調度到同一server上進行響應，若是基於用戶源ip地址看成hash對象，那麼同一源IP地址的用戶，不論請求什麼uri都會被調度到同一server進行響應；按這個邏輯咱們能夠綁定用戶的信息來作調度；

　　以上就是nginx做爲七層代理http請求的負載均衡的經常使用配置；總結一點nginx做爲負載均衡使用其中核心的思想就是把同類服務的服務器先歸併到一個組裏，而後基於不一樣協議的代理來把用戶的請求反代到該組上，而後基於某種調度算法來實現把用戶請求調度到某一臺server進行響應；