Nginx負載均衡與反向代理——基礎功能

熟悉Nginx的小夥伴都知道，Nginx是一個很是好的負載均衡器。除了用的很是廣泛的Http負載均衡，Nginx還能夠實現Email,FastCGI的負載均衡，甚至能夠支持基於Tcp/UDP協議的各類應用的負載均衡(好比MySQL,DNS等)。這些功能分別在Nginx的不一樣模塊實現了。負載均衡能夠當作Nginx對外提供的一種服務。

咱們先來簡單介紹下Nginx負載均衡的基本的功能。而且，咱們在下面的介紹中會同時羅列Nginx Plus(Nginx的擴展板，部分功能收費)

介紹

在多個應用程序實例之間作負載平衡是一種經常使用的優化資源利用、最大化吞吐量、減小延遲和確保容錯配置的技術。而使用Nginx能夠做爲一個高效的Http負載均衡器將流量分攤到各個服務器上，從而改善性能，增長擴展性和可靠性。

簡單配置

負載均衡的基本配置十分的簡單，在基本配置上，你能夠添加更多的指令來知足本身個性化的需求。
以下：

http {
    upstream myapp1 {
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp1;
        }
    }
}

上面，全部的請求都將被代理到服務器組myapp1上，myapp1上有三臺服務器srv1-srv3，這三臺服務器將要分攤請求。若是沒有指定負載均衡方法，那麼默認的方法是round-robin。
在nginx中，HTTP，HTTPS，FastCGI，uwsgi，SCGI均可以作反向代理，而且能夠作負載均衡，上面的例子是http的。要使用https的負載均衡，簡單的將http改成https便可。

負載均衡的經常使用算法

負載均衡的方法，
就是Http請求如何被分配到各個服務器上的算法。經常使用的負載均衡的經常使用算法有如下種：

• Round‑Robin 默認的方法，也是最簡單的一種。即Http請求按照服務器列表羅列的順序一次進行分配；
• Least Connections 在這種方式下，每一個請求被髮送到當下具備最小有效鏈接數的服務器上，固然權重也會被考慮進去。好比當下有三臺服務器A/B/C，當下各自的鏈接數是100/200/300，那麼下一個請求過來就會被分配到A服務器進行處理
• Hash 用戶定義一個Hash的Key值，好比IP或者URL，將這個Hash的Key和服務器作一次映射，每次請求過來都會按照這個映射被分配到同一臺服務器
• IP Hash (僅適用於Http負載均衡的狀況)，根據客戶端IP的前三個字節(好比IP是10.25.2.10那麼就拿10.25.2作映射)來分配請求，這個和上一種相似
• Least Time 即最少時間。新的請求將被髮往擁有最快響應時間和最少鏈接數的上游服務器。這是Nginx Plus才具備的方式

最少鏈接算法

即Least Connections這種算法。最少鏈接，顧名思義，就是當下誰的鏈接數最少請求就然該誰來處理。這是一種相對公平的方式，防止某些服務器負載太重，將請求分配到相對「悠閒」的服務器上去。基本的配置以下：

upstream myapp1 {
        least_conn;
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
}

須要指定least_conn指令。

Session一致性問題

若是負載均衡採用round-robin或者least-connected算法，同一個客戶端發送過來的不一樣請求就有可能被不一樣的server處理，這種情形下就不能保證兩次請求session的一致性。
爲了解決這個問題，能夠採用第三種負載均衡的算法，那就是ip-hash。有了IP哈希，將客戶端的IP和服務器組列表的幾個服務器之間創建一種對應關係，那麼每一個客戶端的每次請求就只能被分配到一臺server上面，從而保證session的一致性。ip-hash的方式配置以下：

upstream myapp1 {
    ip_hash;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

負載均衡權重

說是負載"均衡"，可是不是說每一個server的分配的請求是徹底同樣。前面討論的各個服務器組，裏面的各個server實際上是地位平等、利益均沾。事實上，因爲每一個server的特性可能不同，有些server硬件條件好，穩定性高，理應多處理些請求，相反另外一些不太穩定的server就應該適當的少分配請求。咱們能夠爲這些server分配不一樣的權重，來定義它們在處理請求時所扮演角色的重要性。權重用指令weight來表示，權重高表示選擇的概率更大，權重低表示選中的概率更小，權重爲0表示始終不選用。以round-robin算法爲例：

upstream myapp1 {
        server srv1.example.com weight=3;
        server srv2.example.com;
        server srv3.example.com;
}

沒有weight指令的默認其爲1。若是有5個請求過來，理想狀況下srv1就能接到3個，srv2和srv3各一個。

服務器健康檢查

反向代理的各類實現(如http/https/FastCGI)還能夠對各個server作健康檢查。若是請求一個server錯誤(如返回500，究竟如何才爲「失效」，在Nginx Plus中作了擴展)，nginx就將這個server標記爲失效的，在接下來一段時間的請求中就會避免選擇這臺server。究竟這端時間要多長才合適？有max_fails和fail_timeout參數來定義。

• max_fails
  默認是1，表示在fail_timeout時間內，有多少次對某個server的訪問失敗，就算做這臺server的正式失效(你總要給人家多表現幾回的機會撒)，默認狀況下就是1次；

• fail_timeout
  默認是10s，有兩層含義，一就是爲max_fails指令限定一個時間範圍，二就是若是server已經被標記爲失效，那麼過了這個時間後，你就應該分配個請求去試探下這個server，是否已經可用了（你總的給人家從新作人的機會）。若是仍是不可用，那麼此server繼續被標記爲失效的server，若是已經可用了那麼就從新標記爲活躍，在接下來的請求中，繼續按照round-robin/ip-hash等算法和權重給它分配請求，和日常無異。

除了這些指令以外proxy_next_upstream, backup, down, 和 keepalive 也針對負載均衡功能作了不一樣的限定。

以上這些功能是基本是Nginx的免費版本提供的，其實負載均衡裏能夠說的話題還多着呢。咱們下篇文章中談談Nginx Plus提供的更爲豐富的負載均衡的功能。