Nginx 學習系列（二） ------------- 負載均衡

說到負載均衡，我想說它天生就是不公平的。爲何這麼說呢？請你想象這麼一個場景，一塊蛋糕切成5份，如今要將它分給A、B、C3我的，基於公平原則，咱們說每一個人正常能夠分到5/3份，可是，5/3份很明顯很差進行劃分，誒碰巧這個時候A中午沒有吃飯，能多吃幾份，B、C肚子偏飽，1份便可，基於不公平原則，咱們分給A3份蛋糕，B、C個一份，這樣按照必定策略將資源進行劃分的方式，是一種均衡的策略。

在web應用中，一個web應用（或者說某個服務）在生產環境中通常是集羣部署，而後採用負載均衡硬件(F5)或者軟件（nginx）將請求分發到不一樣的服務主機中進行處理，很明顯，這裏的蛋糕就至關於咱們的web request，假設有5個request進來，基於必定的均衡策略，咱們可能會將其中的3個request交給A服務器去處理，B、C服務器各處理1個request。下面我畫張圖片簡單說明這個模型：

那麼使用負載均衡有什麼好處呢？首先優化資源利用率，最大化吞吐量，減小延遲，再者系統的伸縮性和可靠性也獲得了相應的保障。

1、Nginx 負載均衡及相關策略介紹

負載均衡技術少不了相關的均衡策略，Nginx 中提供了 4 種均衡策略，咱們能夠根據具體的業務場景選擇合適的均衡策略。下面分別介紹這 4 中均衡策略：

• 一、基於輪詢的均衡策略：

  輪詢嘛，就是說對進到nginx的request按照遍歷的方式進行分發，若是request 1 分發到 Server A，那麼request 2將被分發到 Server B,......以此循環類推

• 二、基於最少鏈接數的均衡策略：

  最少鏈接，也就是說nginx會判斷後端集羣服務器中哪一個Server當前的 Active Connection 數是最少的，那麼對於每一個新進來的request,nginx將該request分發給對應的Server.

• 三、基於ip-hash的均衡策略：

  咱們都知道，每一個請求的客戶端都有相應的ip地址，該均衡策略中，nginx將會根據相應的hash函數，對每一個請求的ip做爲關鍵字，獲得的hash值將會決定將請求分發給相應Server進行處理

• 四、基於加權輪詢的均衡策略：

  加權輪詢，很顯然這個策略跟咱們開題引入的場景是同樣的，nginx會給Server配置相應的權重，權重越大，接收的request數將會越多

上面的均衡策略其實都很是很好理解，可是若是想了解其實現原理，能夠看源代碼，可是小編就算了，我是看不懂C、C++的。

2、Nginx 不一樣均衡策略的配置介紹

• 一、基於輪詢的均衡策略：

這個是Nginx默認的均衡算法，若是你不進行相關的配置，默認會執行該策略，配置以下：

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

        location / {
            proxy_pass http://myapp1;
        }
    }
}
複製代碼

能夠看出，nginx負載均衡使用到的指令很少，其中比較重要的兩個是upstream和proxy_pass,upstream塊定義一個後端小集羣，裏邊配置相關的Server組成這個集羣，同時upstream爲這個集羣起個相應的名字，本實例叫myapp1.proxy_pass處於location塊中，表示對於全部符合/的request，將會交給哪一個集羣進行處理，本實例爲http://myapp1。

但又一點咱們須要注意，上面http://myapp1中myapp1必須是upstream起的名字，對於協議是使用http仍是https,都無所謂，若是你的協議使用https，則將http直接改爲https便可。另外，若是你在upstream中的server指令中指定了協議名，那麼在proxy_pass指令中就不須要加上協議名稱了。

nginx負載均衡使用反向代理實現，也就是咱們上面使用到的proxy_pass指令，支持的協議不止是http和https,同時還支持FastCGI、uwsgi、SCGI、memcached、gRPC，若是你須要使用除了http、https外的其餘協議，咱們不能使用proxy_pass指令了，應該轉而使用相應的指令，如fastcgi_pass、uwsgi_pass、scgi_pass、memcached_pass、grpc_pass。

該策略處理負載，小編認爲仍是有缺陷的，不能防止某臺Server出現負載太高的狀況。由於若是有些請求執行時間過長，而系統的併發量卻很是大，那麼就可能致使某臺Server出現request堆積，負載太高，snowslide is possible~

• 二、基於最少鏈接數的均衡策略：

該策略主要使用了least_conn指令，具體配置以下：

upstream myapp1 {
        least_conn;
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }
複製代碼

該策略仍是比較人性化的，能夠按照機器的實際狀況進行剛需分配。

• 三、基於ip-hash的均衡策略：

固然了，若是咱們想實現這樣一個功能，咱們想讓對於相同客戶端的請求每次都被分發到同一個Server進行處理，上面兩種策略都是不作到。此策略可確保來自同一客戶端的請求始終定向到同一服務器，但此服務器不可用時除外。相關配置以下：

upstream myapp1 {
    ip_hash;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}
複製代碼

既然相同客戶端的請求能被同一臺Server進行處理，那麼相同客戶端的會話Session就能夠實現持久化了。

• 四、基於加權輪詢的均衡策略：

基於加權輪詢的策略就不須要過多講解了，就是在輪詢的基礎上加上個權重信息

upstream myapp1 {
    server srv1.example.com weight=3;
    server srv2.example.com;
    server srv3.example.com;
}
複製代碼

這種策略適合Server機器處理能力有區別的狀況。

3、nginx 負載均衡更多高級特性及配置

• 一、健康檢查

  不只人須要體檢，機器也是須要體檢的，那麼就當nginx就是那位體檢醫生吧！nginx健康檢查是什麼呢？當咱們一個request進來被分發到相應的Server進行處理後，nginx會檢查該request執行是否超時，是否執行失敗了等狀況，而後作出相應的處理---好比說當nginx檢查出Server A執行某request時報出502錯誤了，那麼下次nginx負載均衡時就會在upstream塊中將Server A排除掉，不分發請求給到Server A了。

  對於健康檢查的功能，nginx提供了基本兩個指令，即max_fails和fail_timeout,也就是說當nginx檢查到某Server發生錯誤的request數達到max_fails或者執行某request執行時間超過fail_timeout了，若是發生超時了，nginx將開始使用實時請求優雅地探測Server，若是有響應，則認爲對應的Server仍是活着的，沒有毛病的。

• 二、更多配置

  針對上面upstream塊中的server指令，其格式爲：server address [parameters];，裏邊的parameters能夠有不少的參數類型，好比說指定某臺Server不參與負載均衡等。具體配置詳見官網連接，點擊此處傳送門。