說到負載均衡，我想說它天生就是不公平的。為什么這么說呢？請你想象這么一個場景，一塊蛋糕切成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。下面我畫張圖片簡單說明這個模型：

?

?

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

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

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

• 1、基于輪詢的均衡策略：

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

• 2、基于最少連接數的均衡策略：

  最少連接，也就是說nginx會判斷后端集群服務器中哪個Server當前的 Active Connection 數是最少的，那么對于每個新進來的request,nginx將該request分發給對應的Server.

• 3、基于ip-hash的均衡策略：

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

• 4、基于加權輪詢的均衡策略：

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

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

二、Nginx 不同均衡策略的配置介紹

• 1、基于輪詢的均衡策略：

這個是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~

• 2、基于最少連接數的均衡策略：

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

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

該策略還是比較人性化的，可以按照機器的實際情況進行剛需分配。

• 3、基于ip-hash的均衡策略：

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

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

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

• 4、基于加權輪詢的均衡策略：

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

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

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

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

• 1、健康檢查

  不僅人需要體檢，機器也是需要體檢的，那么就當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還是活著的，沒有毛病的。

• 2、更多配置

  針對上面upstream塊中的server指令，其格式為：server address [parameters];，里邊的parameters可以有很多的參數類型，比如說指定某臺Server不參與負載均衡等。具體配置詳見官網鏈接，點擊此處傳送門。

總結

以上是生活随笔為你收集整理的Nginx 学习 —— 负载均衡的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。