1、基于輪詢(xún)的均衡策略：

這個(gè)是Nginx默認的均衡算法，如果你不進(jìn)行相關(guān)的配置，默認會(huì )執行該策略，配置如下：

可以看出，nginx負載均衡使用到的指令不多，其中比較重要的兩個(gè)是upstream和proxy_pass,upstream塊定義一個(gè)后端小集群，里邊配置相關(guān)的Server組成這個(gè)集群，同時(shí)upstream為這個(gè)集群起個(gè)相應的名字，本實(shí)例叫myapp1.proxy_pass處于location塊中，表示對于所有符合/的request，將會(huì )交給哪個(gè)集群進(jìn)行處理，本實(shí)例為http://myapp1。

但又一點(diǎn)我們需要注意，上面http://myapp1中myapp1必須是upstream起的名字，對于協(xié)議是使用http還是https,都無(wú)所謂，如果你的協(xié)議使用https，則將http直接改成https即可。另外，如果你在upstream中的server指令中指定了協(xié)議名，那么在proxy_pass指令中就不需要加上協(xié)議名稱(chēng)了。

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

該策略處理負載，小編認為還是有缺陷的，不能防止某臺Server出現負載過(guò)高的情況。因為如果有些請求執行時(shí)間過(guò)長(cháng)，而系統的并發(fā)量卻非常大，那么就可能導致某臺Server出現request堆積，負載過(guò)高，snowslide is possible~

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

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

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

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

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

既然相同客戶(hù)端的請求能被同一臺Server進(jìn)行處理，那么相同客戶(hù)端的會(huì )話(huà)Session就可以實(shí)現持久化了。

4、基于加權輪詢(xún)的均衡策略：

基于加權輪詢(xún)的策略就不需要過(guò)多講解了，就是在輪詢(xún)的基礎上加上個(gè)權重信息

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

以上就是四種nginx負載均衡策略的介紹。