⑴ 接觸過的Nginx的負載均衡演算法有哪些
Nginx 官方默認的幾種負載均衡的演算法
①Round-Robin RR輪詢（默認） 一次一個的來（理論上的，實際實驗可能會有間隔）
②weight 權重 權重高多分發一些 伺服器硬體更好的設置權重更高一些
③ip_hash 同一個IP，所有的訪問都分發到同一個web伺服器
第三方模塊實現的調度演算法 需要編譯安裝第三方模塊
④fair 根據後端伺服器的繁忙程度 將請求發到非繁忙的後端伺服器
⑤url_hash 如果客戶端訪問的url是同一個，將轉發到同一台後端伺服器
看你在學習Nginx的知識，推薦你去看黑馬程序員視頻庫，裡面有它的學習視頻，講解的很詳細哦！
⑵ 12《Nginx 入門教程》Nginx負載均衡(上)
負載均衡，其英文簡稱Load Balancing，是一種計算機技術。用來在多個計算機（計算機集群）、網路連接、CPU、磁碟驅動器或其他資源中分配負載，以達到最優化資源使用、最大化吞吐率、最小化響應時間、同時避免過載的目的。宏觀上的意思是將負載（工作任務，訪問請求）進行平衡、分攤到多個操作單元（伺服器，組件）上進行執行以解決高性能，單點故障（高可用），擴展性（水平伸縮）等高流量下常見的問題。
由於載均衡技術是要對網路傳輸中的報文控制，因此會涉及到網路七層模型，因此負載均衡分類可以按照網路層次進行分類，比如二層、三層、四層、七層負載均衡。其中最常見的是四層和七層負載均衡。此外，還有其他方面進行分類的，有軟體負載均衡、硬體負載均衡等。
負載均衡伺服器對外依然提供一個VIP（虛IP），集群中不同的機器採用相同IP地址，但是機器的MAC地址不一樣。當負載均衡伺服器接受到請求之後，通過改寫報文的目標MAC地址的方式將請求轉發到目標機器實現負載均衡。
和二層負載均衡類似，負載均衡伺服器對外依然提供一個VIP（虛IP），但是集群中不同的機器採用不同的IP地址。當負載帆並喚均衡伺服器接受到請求之後，根據不同的負載均衡演算法，通過IP將請求轉發至不同的真實伺服器。
四層負載均衡工作在OSI模型的傳輸層，由於在傳輸層，只有TCP/UDP協議，這兩種協議中除了包含源IP、目標IP以外，還包含源埠號及目的埠號。四層負載均衡伺服器在接受到客戶端請求後，以後通過修改數據包的地址信息（IP+埠號）將流量轉發到應用伺服器。
七層負載均衡工作在 OSI 模型的應用層，應用層協議較多，常用 http、dns 等。七層負載就可以基於這些協議來負載。這些應用層協議中會包含很多有意義的內容。比如同一個 Web 伺服器的負載均衡，除了根據 IP 加埠進行負載外，還可根據七層的 URL、瀏覽器類別、語言來決定是否要進行負載均衡。
業界已經有很多開源的負載均衡工具，大部分是工作在第四層和第七層的。代表的開源工具有 Nginx/LVS/Haproxy。值得一提的是，LVS 是國內前淘寶網高級研究員章文嵩博士的作品。LVS 主要用來做四層負載均衡，Nginx 和 Haproxy 主要是做七層的負載均衡，但它們都支持四層的負載均衡，例如在 Nginx 中的 stream 模塊除了支持四層的反向代理功能，也支持四層負載均衡功能。
負載均衡演算法可以分成兩大類，一類是靜態的負載均衡演算法，常見的有輪詢、權重等；另一大類動態的負載均衡演算法，常見的有最少的連接、最快響應、服務類型、服務質量等等，還有很多策略，不同的軟體會實現不同的負載均衡演算法。
Nginx 的 stream 模塊和 http 模塊分別支持四層和七層模塊的負載均衡。其用法和支持的負載均衡策略大致相同。首先使用 upstream 指令塊 和 server 指令指定上游的服務，upstream 指令的用法如下:
官網示例如下:
這里定義了4台上游伺服器，分別用域名, ip+port、socket 形式指定地址，後面跟上若干配置參數。默認情況下，upstream 指令塊中採用的是加權 Round-Robin 負載均衡演算法。該演算法通過加權輪詢的方式訪問 upstream 中 server 指令指定的上游服務。此時，在server 指令中我們可以添加一些關於服蔽瞎務的靜態配態凱置，比如指定服務的權重(weight)、server 的最大並發連接數(max_conns)、max_fails 和 fail_timeout 等。
除了默認的 Round-Robin 演算法外，Nginx 中常用的負載均衡策略還有基於客戶端 ip 地址的 Hash 演算法。該演算法以客戶端的 ip 地址作為 hash 演算法的關鍵字，映射到特定的上游伺服器中，當然也可以根據客戶段的其他 key 來進行 hash 演算法。涉及的配置指令為 ip_hash 和 hash，用法如下:
最後 Nginx 中一種常用的動態負載均衡演算法是最少連接數演算法。該演算法會從所有的上游伺服器中找到並發連接數最少的一個，然後將請求轉發給它，如果出現多個最少連接數的伺服器，則會在這些最少連接數的伺服器中繼續應用 Round-Robin 演算法。配置該策略的指令為 least_conn，其指令格式如下：
當然, Nginx 中的負載均衡策略還有很多，就不在此一一介紹了。可以仔細研讀官方文檔進行進一步學習
本小節只是介紹了負載均衡的相關知識，以及對應 Nginx 中的配置指令，後面一節會實戰 Nginx 的負載均衡功能，同時測試多種負載均衡演算法。
⑶ 使用 Nginx 限流
Nginx不顫虛僅可以做Web伺服器、做反向代理、負載均衡，還可以做限流系統。此處我們就Nginx為例，介紹一下如何配置一個限流系統。
Nginx使用的限流演算法是漏桶演算法。
（1）安裝Nginx。
如果你的linux是Ubuntu或Debian，使用apt-get安裝，在命令行中輸入以下命令：
如果是CentOS，使用yum安裝，在命令行中輸入以下命令：
（2）找到Nginx所使用的配置文件所在的位置。在Ubuntu和Debian是在如下位茄局燃置：
而CentOS則是在如下位置：
（3）在http塊中，配置基礎的限流配置：
其中4到8行定義的是一個伺服器介面。而第2行和第6行配合完成了一個限流設置，下面解釋一下這兩行做的事情：
limit_req_zone命令在Nginx的配置文件中專門用於定義限流，它必須被放在http塊中，否則無法生效，因為該命令只在http中被定臘皮義。
該欄位包含三個參數：
第一個參數，就是鍵（key），即值$binary_remote_addr所在的位置，它代表的是我們的限流系統限制請求所用的鍵。
此處，我們使用了$binary_remote_addr，它是Nginx內置的一個值，代表的是客戶端的IP地址的二進製表示。因此換言之，我們的示例配置，是希望限流系統以客戶端的IP地址為鍵進行限流。
對Nginx有經驗的讀者可能還知道有一個Nginx內置值為binary_remote_addr是Nginx的社區推薦用值，因為它是二進製表達，佔用的空間一般比字元串表達的$remote_addr要短一些，在寸土寸金的限流系統中尤為重要。
第二個參數是限流配置的共享內存佔用（zone）。為了性能優勢，Nginx將限流配置放在共享內存中，供所有Nginx的進程使用，因為它佔用的是內存，所以我們希望開發者能夠指定一個合理的、既不浪費又能存儲足夠信息的空間大小。根據實踐經驗，1MB的空間可以儲存16000個IP地址。
該參數的語法是用冒號隔開的兩個部分，第一部分是給該部分申請的內存一個名字，第二部分是我們希望申請的內存大小。
因此，在該聲明中，我們聲明了一個名叫mylimit（我的限制）的內存空間，然後它的大小是10M，即可以存儲160000個IP地址，對於實驗來說足夠了。
第三個配置就是訪問速率（rate）了，格式是用左斜杠隔開的請求數和時間單位。這里的訪問速率就是最大速率，因此10r/s就是每秒10個請求。通過這台Nginx伺服器訪問後端伺服器的請求速率無法超過每秒10個請求。
注意到第5行聲明了一個資源位置/test/，因此我們第6行的配置就是針對這個資源的，通俗地說，我們在第6行的配置是針對特定API的，這個API就是路徑為/test/的API，而其真正路徑就是第8行聲明的 http://backend 。注意，這個URL是不存在的，實際操作中，讀者需要將它換成你已經開發好的業務邏輯所在的位置，Nginx在這里的作用只是一個反向代理，它自己本身沒有資源。
第6行中，我們使用limit_req命令，聲明該API需要一個限流配置，而該限流配置所在位置（zone）就是mylimit。
這樣一來，所有發往該API的請求會先讀到第6行的限流配置，然後根據該限流配置mylimit的名稱找到聲明在第2行的參數，然後決定該請求是否應該被拒絕。
但是這樣還不夠。不要忘了，Nginx使用的漏桶演算法，不是時間窗口演算法，我們前文介紹中說過，漏桶演算法是有兩個參數可以配置的！
（4）配置峰值。Nginx漏桶演算法的峰值屬性在API中設置。參數名為burst。如下：
在第6行中，我們只需要在聲明limit_req的同時，指定burst就可以了，此處我們指定burst為20，即漏桶演算法中我們的「桶」最多可以接受20個請求。
這樣一個Nginx的限流系統就配置完畢了，但實際操作中，我們還可能需要很多別的功能，下面筆者就介紹幾個很有用的配置技巧。
相對於傳統的漏桶演算法慢吞吞地轉發請求的缺陷，Nginx實現了一種漏桶演算法的優化版，允許開發者指定快速轉發，而且還不影響正常的限流功能。開發者只需要在指定limit_req的一行中指定burst之後指定另一個參數nodelay，就可以在請求總數沒有超過burst指定值的情況下，迅速轉發所有請求了。如下所示：
您可能會擔憂：這種情況下，會不會出現所有請求都被快速轉發，然後接下來又有沒有超過burst數量的請求出現，再次被快速轉發，就好像固定窗口演算法的漏洞一樣，從而超過我們本來希望它能限制到的上限數量呢？答案是不會。Nginx的快速轉發是這樣實現的：
舉例而言，配置如上所示，假如在某個瞬時有25個請求進入系統，Nginx會先轉發20個（或21個，取決於瞬時情況），然後拒絕剩下的4個請求，並將當前桶中數量標為0，然後接下來的每100毫秒，緩慢恢復1個空位。
這樣我們可以看到，Nginx既做到了快速轉發消息，又不會讓後端伺服器承擔過多的流量。
限流系統會提前拒絕請求，因此，我們在業務伺服器上是肯定看不到這些請求的。假如我們收到一個報告說某用戶在使用網站的時候出現錯誤，但是我們在業務伺服器上又找不到相關的日誌，我們如何確定是不是限流造成的呢？
只有限流系統的日誌才能說明問題。因此，我們需要Nginx列印出它拒絕掉的請求的信息。但同時，Nginx列印的限流日誌默認是錯誤（error），如果我們設置了一個基於日誌錯誤掃描的警報，它掃到的限流錯誤，真的是我們希望給自己發警報的情況嗎？
配置請求的位置就在資源中，使用的命令是limit_req_log_level，如下：
在第7行中，我們將Nginx的日誌改為了警告（warn）。
限流的HTTP標准響應狀態碼是429，但是如果讀者拿上述的配置文件直接去測試，會發現Nginx返回的是503（服務不可用）。到底應該返回什麼狀態碼，是一個偏程序哲學的問題，此處我們不討論，我們只討論：如何讓Nginx返回我們指定的狀態碼？
答案也是在同一個資源中，它的配置命令是limit_req_status，然後我們指定它為429即可：
除了以上功能以外，Nginx還支持很多復雜先進的限流功能，可以訪問 https://docs.nginx.com/nginx/admin-guide/security-controls/controlling-access-proxied-http/ 作進一步的了解。
⑷ 軟體架構中，負載均衡有哪些調度演算法
謝邀！
負載均衡調度演算法也叫負載均衡方法有很多種，下面以使用比較廣的nginx為例說說軟體負載均衡的調度演算法：
nginx默認的調度演算法，按照時間順序逐一分配後台伺服器
在server後加weigth，weight值越高，後台伺服器分配概率越大，下圖是說ip為102的後台服務分配概率是ip為101後台服務的兩倍
按照訪問ip的hash分配，增加ip_hash關鍵字，同一ip訪問相同的後台服務
按照訪問url的hash分配，增加url_hash關鍵字，同一url訪問相同的後台服務
按照最少連接數方式分配，增加least_conn關鍵字，哪個後台服務連接數少就分配哪個
按照最短響應時間分配，增加fair關鍵字，響應時間短的後台服務優先分配
⑸ Nginx的功能與特性
Nginx在過去的10年裡，作為Web伺服器行業里的新生代迅速崛起。Nginx由俄羅斯工程師Igor Sysoev編寫，2004年10月4日發布了第一個公眾版本：1.0.1。Apache一直占據Web伺服器行業的第一，但自2008年開始，它的市場份額在潛移默化的轉移到Nginx身上。直至今日，據Netcraft的統計顯示，全世界排名前100萬的網站中有超過27%的網並櫻站在使用Nginx作為Web伺服器。Nginx迅速在一向穩定的Web伺服器行業崛起並站穩跟腳.
1 、靜態HTTP伺服器
Nginx是一個HTTP伺服器，可以將伺服器上的靜態文件（如HTML、圖片）通過HTTP協議展現給客戶端。
2、反向代理伺服器
客戶端請求Nginx，Nginx請求應用伺服器，然後將結果返回給客戶端，此時Nginx就是反向代理伺服器。
3、負載均衡
當網站訪問量非常大，將同一個應用部署在多台伺服器上，將大量用戶的請求分配給多台機器處理。同時帶來的好處是，其中絕畢叢一台伺服器萬一掛了，只要還有其他伺服器正常運行，就不會影響用戶使用。Nginx可以通過反向代理來實現負載均衡，並能使用3種自帶策略及2種第三方策略。
（1）RR（默認，每個請求按時間順序逐一分配到不同的後端伺服器）
（2）權重（指定輪詢幾率，weight和訪問比率成正比，用於後端伺服器性能不均的情況）
（3）ip-hash（以上配置會將請求輪詢分配到應用伺服器，也就是一個客戶端的多次請求，有可能會由多台不同的伺服器處理（若存在登錄session時則需要重復登錄）。ip-hash根據客戶端ip地址的hash值將請求分配給固定的某一個伺服器處理）
（4）fair（第三方 按後端伺服器的響應時間來分配請求，響應時間短的優先分配）
（5）url_hash（第三方 按訪問url的hash結果來分配請求，使每個url定向到同一個後端伺服器，後端伺服器為緩存時比較有效。 在upstream中加入hash語句，server語句中不能寫入weight等其他的參數，hash_method是使用的hash演算法）
4、虛擬主機
有的網站訪問量大，需要負載均衡。有的網站，由於訪問量太小，需要節省成本，將多個網站部署在同一台伺服器上。例如將www.a.com和www.b.com兩個網站部署在同一台伺服器上，兩個域名解析到同一個IP地址，但是用戶通過兩個域名卻可以打開兩個完全不同的網站，互相不影響，就像訪問兩個伺服器一樣，所以叫兩個虛擬主機。
在伺服器8080和8081分別開了一個應用，客戶端通過不同的域名訪問，根據server_name可以反向代理到對應的應用伺服器。虛擬主機的原理數虛是通過HTTP請求頭中的Host是否匹配server_name來實現的，另外，server_name配置還可以過濾有人惡意將某些域名指向你的主機伺服器。
1、IO多路復用epoll
2、輕量級
3、CPU親和（affinity）
4、sendfile
⑹ nginx 負載均衡之一致性hash，普通hash
哈希負載均衡原理
ngx_http_upstream_hash_mole支持普通的hash及一致性hash兩種負載均衡演算法，默認的是普通的hash來進行負載均衡。
nginx 普通的hash演算法支持配置http變數值作為hash值計算的key，通過hash計算得出的hash值和總權重的余數作為挑選server的依據；nginx的一致性hash(chash)演算法則要復雜一些。這里會對一致性hash的機制原理作詳細的說明。
一致性hash演算法的原理
一致性hash用於對hash演算法的改進，後端伺服器在配置的server的數量發生變化後，同一個upstream server接收到的請求會的數量和server數量變化之間會有變化。尤其是在負載均衡配置的upstream server數量發生增長後，造成產生的請求可能會在後端的upstream server中並不均勻，有的upstream server負載很低，有的upstream server負載較高，這樣的負載均衡的效果比較差，可能對upstream server造成不良的影響。由此，產生了一致性hash演算法來均衡。
那麼為什麼一致性hash演算法能改善這種情況呢？這里引用網上資料的一致性hash演算法的圖例。
因為對於hash(k)的范圍在int范圍，所以我們將0~2^32作為一個環。其步驟為：
1，求出每個伺服器的hash（伺服器ip）值，將其配置到一個 0~2^n 的圓環上（n通常取32）。
2，用同樣的方法求出待存儲對象的主鍵 hash值，也將其配置到這個圓環上，然後從數據映射到的位置開始順時針查找，將數據分布到找到的第一個伺服器節點上。
其分布如圖：
除了上邊的優點，其實還有一個優點：對於熱點數據，如果發現node1訪問量明顯很大，負載高於其他節點，這就說明node1存儲的數據是熱點數據。這時候，為了減少node1的負載，我們可以在熱點數據位置再加入一個node，用來分擔熱點數據的壓力。
雪崩效應
接下來我們來看一下，當有節點宕機時會有什麼問題。如下圖：
如上圖，當B節點宕機後，原本存儲在B節點的k1，k2將會遷移到節點C上，這可能會導致很大的問題。如果B上存儲的是熱點數據，將數據遷移到C節點上，然後C需要承受B+C的數據，也承受不住，也掛了。。。。然後繼續CD都掛了。這就造成了雪崩效應。
上面會造成雪崩效應的原因分析：
如果不存在熱點數據的時候，每台機器的承受的壓力是M/2(假設每台機器的最高負載能力為M)，原本是不會有問題的，但是，這個時候A伺服器由於有熱點數據掛了，然後A的數據遷移至B，導致B所需要承受的壓力變為M（還不考慮熱點數據訪問的壓力），所以這個失敗B是必掛的，然後C至少需要承受1.5M的壓力。。。。然後大家一起掛。。。
所以我們通過上面可以看到，之所以會大家一起掛，原因在於如果一台機器掛了，那麼它的壓力全部被分配到一台機器上，導致雪崩。
怎麼解決雪崩問題呢，這時候需要引入虛擬節點來進行解決。
虛擬節點
虛擬節點，我們可以針對每個實際的節點，虛擬出多個虛擬節點，用來映射到圈上的位置，進行存儲對應的數據。如下圖：
如上圖：A節點對應A1，A2，BCD節點同理。這時候，如果A節點掛了，A節點的數據遷移情況是:A1數據會遷移到C2，A2數據遷移到D1。這就相當於A的數據被C和D分擔了，這就避免了雪崩效應的發送，而且虛擬節點我們可以自定義設置，使其適用於我們的應用。
ngx_http_upstream_consistent_hash
該模塊可以根據配置參數採取不同的方式將請求均勻映射到後端機器，比如：
指令
語法：consistent_hash variable_name
默認值：none
上下文：upstream
配置upstream採用一致性hash作為負載均衡演算法，並使用配置的變數名作為hash輸入。
參考文檔：
https://www.cnblogs.com/FengGeBlog/p/10615345.html
http://www.ttlsa.com/nginx/nginx-upstream-consistent-hash-mole/
⑺ nginx負載均衡有個伺服器不分發
Nginx負載均衡在默認情況下會按照預設的演算法（如輪詢、IP Hash等）將請求分發給多個後端伺服器，從而實現負載均衡的效果。如果發現有一個伺服器沒有收到請求，可能是因為該伺服器處於宕機、網路不嘩絕物通或者配置宏凳錯誤的狀態。以下是一些解決該問題的方法：
1. 檢查後端伺服器的狀態：使用ping命令或者其他網路工具檢查伺服器的網路狀態是否正常，確認伺服器是否能夠正常響應請求。如果伺服器處於宕機的狀態，應當先排除伺服器硬體故障或者系統配置錯誤的問題。
2. 檢查Nginx的配置文件：檢查Nginx的配置文件中是否正確指定了所有需要負載均衡的後端伺服器，並按照負載均衡演算法進行分配。可以使用Nginx的命令行工具或者日誌文件來查看默認或者自定義的負載均衡演算法的狀態和效果。
3. 檢查Nginx的日誌文件：Nginx的日誌文件可以記錄被分發到每個後端伺服器的請求數量和狀態，可以使用日誌文件來查看是否有伺服器沒有接收到請求，並可以進一步確認問題的具體原因。
4. 調整負載均衡的配置參數：根據具體情況，可以調整Nginx的負載均衡演算法、調整Node間的權重或者調整最大連接數等參數，以優化亂液負載均衡的效果和性能。
希望以上方法對您有所幫助，如有其他問題，請聯系Nginx官方技術支持或者社區。
⑻ 13《Nginx 入門教程》Nginx負載均衡(下)
這一小節中，我們將實戰 Nginx 的四層和七層負載均衡功能。條件有限，使用一台公網主機，在上面搭建好 Nginx 服務。公網 IP 為 180.76.152.113。
首先會進行簡單的四層負載均衡實驗，不會涉及多種負載均衡演算法，只使用默認的 Round-Robin演算法。在後續的七層負載均衡實驗中，會重點測試不同的負載均衡策略，完成相關實驗。
首先在 nginx.conf 中添加如下 stream 指令塊配置:
上述配置用埠3000和3001模擬兩個上游伺服器，然後在 upstream 指令塊中指定這兩個上游伺服器的地址，同時給第一個設置權重為2。由於默認採用的是加權的 Round-Robin 演算法，默認伺服器的權重為1。設置為2，表明3次請求中，2次會轉發到3000埠，一次會轉發到3001埠，下面的測試也驗證了這一點。
和四層的配置其實差不多，在七層中除了告畝測試最基本的，我們還將測試前面提到的幾種負載均衡策略，進一步熟悉 Nginx 中的負載均衡配置。
在 nginx.conf 中添加如下的 http 指令塊:
上述配置中，我們用8000，8001和8002三個埠模擬了3個上游伺服器，默認使用輪詢負載均衡演算法，而且三個的權重均為1。進行如下的 http 請求操作，可以看到 Nginx 轉發 http 請求會均勻地分配到3個伺服器上。
我們打開 ip_hash 指令的注釋，這個時候默認是使用客戶端的 ip 地址作為 hash 的 key，然後重啟 Nginx 服務並進行如下的命令行操作：
接下來，注釋 ip_hash 指令，我們打開 hash user_$arg_username 這行配置的注釋， hash 指令可以讓我們根據我們設置的 key 進行 hash，然後根據 hash 值選擇上游的伺服器。具體測試參看下面的 Linux 命令：
這里我們可以看到，在請求中帶上 username 參數，Nginx 中配置敬友畝的 hash 演算法會根據請求中帶的 username 參數作為 key 去進行 hash，然後在根據 hash 結果映射上游伺服器。username 相同時，選擇的上游亮森伺服器肯定是一樣的，只有在 username 的值發生變化時，返回的響應才可能有變化。
今天我們完成了幾個測試實驗，主要是針對 Nginx 的四層和七層的負載均衡功能進行了測試。這個功能在微服務部署中會有較多的應用。因為高流量企業為保證服務的高可用性，往往會水平擴展多個相同功能的服務，部署在多台主機上，這個時候負載均衡技術就能派上用場了，而 Nginx 提供了完善的負載均衡功能以及多種負載均衡演算法，能滿足大部分企業的需求，如果還不夠，可以通過編寫內部開發模塊並集成到 Nginx，實現相應的需求。所以說 Nginx 是非常值得學習和深入研究的。
⑼ nginx負載均衡輪詢演算法中,哪個關鍵字代表權重
本文主要和大家分享nignx負載均衡演算法，希望能幫助到大家。
一、Nginx負載均衡演算法
1、輪詢（默認）
每個請求按時間順序逐一分配到不同的後端服務，如果後端某台伺服器死機，自動剔除故障系統，使用戶訪問不受影響。
2、weight（輪詢權值）
weight的值越大分配到的訪問概率越高，主要用於後端每台伺服器性能不均衡的情況下。或者僅僅為在主從的情況下設置不同的權值，達到合理有效的地利用主機資源。
3、ip_hash源地址哈希法
源地址哈希的思想是根據獲取客戶端的IP地址，通過哈希函數計算得到的一個數值，用該數值對伺服器列表的大小進行取模運算，得到的結果便是客服端要訪問伺服器的序號。採用源地址哈希法進行負載均衡，同一IP地址的客戶端，當後端伺服器列表不變時，它每次都會映射到同一台後端伺服器進行訪問。
4、fair
比 weight、ip_hash更加智能的負搜孝載均衡演算法，fair演算法可以根據頁面大小和載入時間長短智能地進行負載均衡，也就是根據後端伺服器的響應時間 來分配請求，響應時間短的優先分配。Nginx本身不支持汪者fair，如果需要這種調度演算法，則必須安裝upstream_fair模塊。
5、url_hash
按訪問的URL的哈希結果來分配請求，使每個URL定向到一台後端伺服器，可以進一步提高後端緩存伺服器的效率。Nginx本身不支持url_hash，如果需要這種調度演算法，則必須安裝Nginx的hash軟體包。
一、輪詢（默認）
每個請求按時間順序逐一分配到不同的後端伺服器，如果後端伺服器down掉，能自動剔除。
二、weight
指定輪詢幾率，weight和訪問比率成正比，用於後端伺服器性能不均的情況。
例如：
upstream bakend {
server 192.168.0.14 weight=10;
server 192.168.0.15 weight=10;
}
三、ip_hash
每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個後端伺服器，可以解決session的問題。
例如：
upstream bakend {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}
四、fair（第三方）
按後端伺服器的響應時間來分配請求，響應時間短的優先分配。
upstream backend {
server server1;
server server2;
fair;
}
五、困漏薯url_hash（第三方）
按訪問url的hash結果來分配請求，使每個url定向到同一個後端伺服器，後端伺服器為緩存時比較有效。
例：在upstream中加入hash語句，server語句中不能寫入weight等其他的參數，hash_method是使用的hash演算法
upstream backend {
server squid1:3128; // 10.0.0.10:7777
server squid2:3128; //10.0.0.11:8888
hash $request_uri;
hash_method crc32; }
二、Nginx負載均衡調度狀態
在Nginx upstream模塊中，可以設定每台後端伺服器在負載均衡調度中的狀態，常用的狀態有：
1、down，表示當前的server暫時不參與負載均衡
2、backup，預留的備份機器。當其他所有的非backup機器出現故障或者忙的時候，才會請求backup機器，因此這台機器的訪問壓力最低
3、max_fails，允許請求失敗的次數，默認為1，當超過最大次數時，返回proxy_next_upstream模塊定義的錯誤。
4、fail_timeout，請求失敗超時時間，在經歷了max_fails次失敗後，暫停服務的時間。max_fails和fail_timeout可以一起使用。
如果Nginx沒有僅僅只能代理一台伺服器的話，那它也不可能像今天這么火，Nginx可以配置代理多台伺服器，當一台伺服器宕機之後，仍能保持系統可用。具體配置過程如下：
1. 在http節點下，添加upstream節點。
upstream linuxidc {
server 10.0.6.108:7080;
server 10.0.0.85:8980;
}
2. 將server節點下的location節點中的proxy_pass配置為：http:// + upstream名稱，即「
http://linuxidc」.
location / {
root html;
index index.html index.htm;
proxy_pass http://linuxidc;
}
3. 現在負載均衡初步完成了。upstream按照輪詢（默認）方式進行負載，每個請求按時間順序逐一分配到不同的後端伺服器，如果後端伺服器down掉，能自動剔除。雖然這種方式簡便、成本低廉。但缺點是：可靠性低和負載分配不均衡。適用於圖片伺服器集群和純靜態頁面伺服器集群。
除此之外，upstream還有其它的分配策略，分別如下：
weight（權重）
指定輪詢幾率，weight和訪問比率成正比，用於後端伺服器性能不均的情況。如下所示，10.0.0.88的訪問比率要比10.0.0.77的訪問比率高一倍。
upstream linuxidc{
server 10.0.0.77 weight=5;
server 10.0.0.88 weight=10;
}
ip_hash（訪問ip）
每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個後端伺服器，可以解決session的問題。
upstream favresin{
ip_hash;
server 10.0.0.10:8080;
server 10.0.0.11:8080;
}
fair（第三方）
按後端伺服器的響應時間來分配請求，響應時間短的優先分配。與weight分配策略類似。
upstream favresin{
server 10.0.0.10:8080;
server 10.0.0.11:8080;
fair;
}
url_hash（第三方）
按訪問url的hash結果來分配請求，使每個url定向到同一個後端伺服器，後端伺服器為緩存時比較有效。
注意：在upstream中加入hash語句，server語句中不能寫入weight等其他的參數，hash_method是使用的hash演算法。
upstream resinserver{
server 10.0.0.10:7777;
server 10.0.0.11:8888;
hash $request_uri;
hash_method crc32;
}
upstream還可以為每個設備設置狀態值，這些狀態值的含義分別如下：
down 表示單前的server暫時不參與負載.
weight 默認為1.weight越大，負載的權重就越大。
max_fails ：允許請求失敗的次數默認為1.當超過最大次數時，返回proxy_next_upstream 模塊定義的錯誤.
fail_timeout : max_fails次失敗後，暫停的時間。
backup： 其它所有的非backup機器down或者忙的時候，請求backup機器。所以這台機器壓力會最輕。
upstream bakend{ #定義負載均衡設備的Ip及設備狀態
ip_hash;
server 10.0.0.11:9090 down;
server 10.0.0.11:8080 weight=2;
server 10.0.0.11:6060;
server 10.0.0.11:7070 backup;
}
感興趣的小夥伴請關注我，我們一起學習，一起成長!
贊
⑽ nginx限流演算法
1.令牌桶
演算法思想：
*令牌以固定速率產生，並緩存到令牌桶中；
*令牌桶放滿時，多餘的令牌被丟棄；
*請求要消耗等比例的令牌才能被處理；
*令牌不夠時，請求段辯被緩存。
2.漏桶
*來不及流出的水存在水桶中（緩沖），以固定速率流出；
*水桶滿後水溢出（丟棄）。
*這個演算法的核心是：緩存請求、勻速處理、多餘的請求直接丟棄。
總結：
相比漏桶演算法，令牌桶演算法不同之處在於它不但有一隻「桶」握渣缺，還有個隊列，這個桶是用來存放令牌的，隊列才是用來存放請求的。 從作用上來說，漏桶和令牌桶演算法最明顯的區別就是是否允許突發流量(burst)的處理，漏桶演算法能夠強行限制數據的實時傳輸（處理）速率，對突發流量不做額處理；而令牌桶演算法能夠在限制數據的平均傳輸速率的同時允許某種程梁埋度的突發傳輸。
Nginx按請求速率限速模塊使用的是漏桶演算法，即能夠強行保證請求的實時處理速度不會超過設置的閾值。
Nginx主要有兩種限速方式：按連接數限速(ngx_http_limit_conn_mole)、按請求速率限速(ngx_http_limit_req_mole)。
用php實現