㈠ 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/
㈡ 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和F5的優缺點對比
這是網上摘抄的文章，正好想了解一下負載均衡，看這篇文章寫隱搜的比較易懂，就。。。。
對於數據流量過大的網路中，往往單一設備無法承擔，需要多台設備進行數據分流，而負載均衡器就是用來將數據分流到多台設備的一個轉發器。
目前有許多不同的負載均衡技術用以滿足不同的應用需求，如軟/硬體負載均衡、本地/全局負載均衡、更高網路層負載均衡，以及鏈路聚合技術。
騰訊、淘寶、新浪等大型門戶及商業網站使用的是軟負載均衡器Nginx，而農行用的是F5硬負載均衡器，這里就簡單介紹下這兩種技術：
一.軟體負載均衡解決方案
在一台伺服器的操作系統上，安裝一個附加軟體來實現負載均衡，如Nginx負載均衡（我們管理系統平台使用的也是這款均衡器）。它的優點是基於特定環境、配置簡單、使用靈活、成本低廉，可以滿足大部分的負載均衡需求。
1.什麼是Nginx
Nginx ("engine x") 是一個高性能的HTTP和反向代理伺服器，也是一個IMAP/POP3/SMTP代理伺服器。可以說Nginx是目前使用最為廣泛的HTTP軟負載均衡器，其將源代碼以類BSD許可證的形式發布（商業友好），同時因高效的性能、穩定性、豐富的功能集、示例配置文件和低系統資源的消耗而聞名於業界。像騰訊、淘寶、新浪等大型門戶及商業網站都採用Nginx進行HTTP網站的數據分流。
2.Nginx的功能特點
a.工作在網路的7層之上，可以針對http應用做一些分流的策略，比如針對域名、目錄結構；
b.Nginx對網路的依賴比較小含或；
c.Nginx安裝和配置比較簡單，測試起來比較方便；
d.也可以承擔高的負載壓力且穩定，一般能支撐超過1萬次的並發；
e.Nginx可以通過埠檢測到伺服器內部的故障，比如根據伺服器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另一個節點，不過其中缺點就是不支持url來檢測；
f.Nginx對請求的非同步處理可以幫助節點伺服器減輕負載；
g.Nginx能支持http和Email，這樣就在適用范圍上面小很多；
h.不支持Session的保持、對Big request header的支持不是很好，另外默認的只有Round-robin和IP-hash兩種負載均衡演算法。
3.Nginx的原理
Nginx採用的是反向代理技術，代理伺服器來接受internet上的連接請求，然後將請求轉發給內部網路上的伺服器，並將從伺服器上得到的結果返回給internet上請求連接的客戶端，此時代理伺服器對外就表現為一個伺服器。反向代理負載均衡技術是把將來自internet上的連接請求以反向代理的方式動態地轉發給內部網路上的多台伺服器進行處理，從而達到負載均衡的目的。
二.硬體負載均衡解決方案
直接在伺服器和外部網路間安裝負載均衡設備，這種設備我們通常稱之為負載均衡器。由於專門的設備完成專門的任務，獨立於操作系統，整體性能得到大量提高，加上多樣化的負載均衡策略，智能化的流量管理，可達到最佳的負載均衡需求。一般而言，硬體負載均衡在功能、談攜伍性能上優於軟體方式，不過成本昂貴，比如最常見的就是F5負載均衡器。
1.什麼是F5 BIG-IP
F5負載均衡器是應用交付網路的全球領導者F5 Networks公司提供的一個負載均衡器專用設備，F5 BIG-IP LTM 的官方名稱叫做本地流量管理器，可以做4-7層負載均衡，具有負載均衡、應用交換、會話交換、狀態監控、智能網路地址轉換、通用持續性、響應錯誤處理、IPv6網關、高級路由、智能埠鏡像、SSL加速、智能HTTP壓縮、TCP優化、第7層速率整形、內容緩沖、內容轉換、連接加速、高速緩存、Cookie加密、選擇性內容加密、應用攻擊過濾、拒絕服務(DoS)攻擊和SYN Flood保護、防火牆—包過濾、包消毒等功能。
2.F5 BIG-IP用作HTTP負載均衡器的主要功能
a.F5 BIG-IP提供12種靈活的演算法將所有流量均衡的分配到各個伺服器，而面對用戶，只是一台虛擬伺服器。
b.F5 BIG-IP可以確認應用程序能否對請求返回對應的數據。假如F5 BIG-IP後面的某一台伺服器發生服務停止、死機等故障，F5會檢查出來並將該伺服器標識為宕機，從而不將用戶的訪問請求傳送到該台發生故障的伺服器上。這樣，只要其它的伺服器正常，用戶的訪問就不會受到影響。宕機一旦修復，F5 BIG-IP就會自動查證應用已能對客戶請求作出正確響應並恢復向該伺服器傳送。
c.F5 BIG-IP具有動態Session的會話保持功能。
d.F5 BIG-IP的iRules功能可以做HTTP內容過濾，根據不同的域名、URL，將訪問請求傳送到不同的伺服器。
三.方案優缺點對比
1.基於硬體的方式(F5)
優點：能夠直接通過智能交換機實現,處理能力更強，而且與系統無關，負載性能強更適用於一大堆設備、大訪問量、簡單應用。
缺點：成本高，除設備價格高昂，而且配置冗餘，很難想像後面伺服器做一個集群，但最關鍵的負載均衡設備卻是單點配置；無法有效掌握伺服器及應用狀態。
硬體負載均衡，一般都不管實際系統與應用的狀態，而只是從網路層來判斷，所以有時候系統處理能力已經不行了，但網路可能還來 得及反應（這種情況非常典型，比如應用伺服器後面內存已經佔用很多，但還沒有徹底不行，如果網路傳輸量不大就未必在網路層能反映出來）。
2.基於軟體的方式(Nginx)
優點：基於系統與應用的負載均衡，能夠更好地根據系統與應用的狀況來分配負載。這對於復雜應用是很重要的，性價比高，實際上如果幾台伺服器，用F5之類的硬體產品顯得有些浪費，而用軟體就要合算得多，因為伺服器同時還可以跑應用做集群等。
缺點：負載能力受伺服器本身性能的影響，性能越好，負載能力越大。
國內據說迪普和深信服做的不錯，手頭沒有啥資料，就不介紹了。
㈣ 負載均衡基本介紹
【負載均衡架構部分轉自】 58沈劍 [架構師之路]( https://mp.weixin.qq.com/s
負載均衡： 是分布式系統架構設計中必須考慮的因素之一，它通常是指，將請求/數據【均勻】分攤到多個操作單元上執行，負載均衡的關鍵在於【均勻】
常見的負載均衡方案：
【客戶端層】到【反向代理層】的負載均衡，是通過「DNS輪詢」實現的：DNS-server對於一個域名配置了多個解析ip，每次DNS解析請求來訪問DNS-server，會輪詢返回這些ip，保證每個ip的解析概率是相同的。這些ip就是nginx的外網ip，以做到每台nginx的請求分配也是均衡的。
【反向代理層】到【站點層】的負載均衡，是通過「nginx」實現的。通過修改nginx.conf，可以實現多種負載均衡策略：
【站點層】到【服務層】的負載均衡，是通過「服務連接池」實現的。
上游連接池會建立與下游服務多個連接，每次請求會「隨機」選取連接來訪問下游服務。（也即是rpc框架實現的）
在數據量很大的情況下，由於數據層（db，cache）涉及數據的水平切分，所以數據層的負載均衡更為復雜一些，它分為「數據的均衡」，與「請求的均衡」。
數據的均衡是指 ：水平切分後的每個服務（db，cache），數據量是差不多的。
請求的均衡是指 ：水平切分後的每個服務（db，cache），請求量是差不多的。
（1）按照range水平切分
（2）按照id哈希水平切分
[圖片上傳中...(-6b2508-1561902875888-0)]
常見的負載均衡系統包括 3 種：DNS 負載均衡、硬體負載均衡和軟體負載均衡。
硬體負載均衡是通過單獨的硬體設備來實現負載均衡功能，這類設備和路由器、交換機類似，可以理解為一個用於負載均衡的基礎網路設備。比如業界非常出名的F5
缺點：
（1）價格實在非常昂貴
（2）擴展性不強
軟體負載均衡通過負載均衡軟體來實現負載均衡功能，常見的有 Nginx 和 LVS。
nginx和F5： https://blog.csdn.net/chabale/article/details/8956717
nginx和lvs比較： https://blog.51cto.com/hzcto/2086691
lvs： https://www.cnblogs.com/liwei0526vip/p/6370103.html
ELB： https://aws.amazon.com/cn/elasticloadbalancing/
SLB： https://help.aliyun.com/proct/27537.html
題目：日活躍用戶 1000 萬的論壇的負載均衡集群，該如何設計呢？
（1）評估流量
1000萬DAU，換算成秒級（一天12小時），平均約等於232。
考慮每個用戶操作次數，假定10，換算成平均QPS=2320。
考慮峰值是均值倍數，假定5，換算成峰值QPS=11600。
考慮靜態資源、圖片資源、服務拆分等，流量放大效應，假定10，QPS 10=116000。
（2）容量規劃
考慮高可用、異地多活，QPS 2=232000。
考慮未來半年增長，QPS*1.5=348000。
（3）方案設計
可以用三級導流：
第一級，DNS，確定機房，以目前量級，可以不考慮。
第二級，確定集群，擴展優先，則選Haproxy/LVS，穩定優先則選F5。
第三級，Nginx+KeepAlived，確定實例。
（4）架構圖
接入層技術：
缺點：
優點：
缺點：
優點：
缺點：
缺點：
nginx畢竟是軟體，性能比tomcat好，但總有個上限，超出了上限，還是扛不住。lvs就不一樣了，它實施在操作系統層面；f5的性能又更好了，它實施在硬體層面；它們性能比nginx好很多，例如每秒可以抗10w，這樣可以利用他們來擴容。
99.9999%的公司到這一步基本就能解決接入層高可用、擴展性、負載均衡的問題。 假設還扛不住的話，就要考慮使用硬體設備f5等。如果還是扛不住，那麼只有DNS來擴容了。
水平擴展，才是解決性能問題的根本方案，能夠通過加機器擴充性能的方案才具備最好的擴展性。 facebook，google，的PV是不是超過80億呢，它們的域名只對應一個ip么，終點又是起點，還是得通過DNS輪詢來進行擴容：
比如購買了阿里雲或者aws。那麼基本會使用雲廠商提供的負載均衡中間件，比如aws（elb）、阿里雲（slb）。這個負載均衡軟體可以認為是 lvs+keepalived的高可用負載均衡服務
後端的service有可能部署在硬體條件不同的伺服器上：
1）如果對標最低配的伺服器「均勻」分攤負載，高配的伺服器的利用率不足；
2）如果對標最高配的伺服器「均勻」分攤負載，低配的伺服器可能會扛不住；
（1）通過「靜態權重」標識service的處理能力
優點： 簡單，能夠快速的實現異構伺服器的負載均衡。
缺點： 權重是固定的，無法自適應動態調整，而很多時候，伺服器的處理能力是很難用一個固定的數值量化。
（2）通過「動態權重」標識service的處理能力
提問：通過什麼來標識一個service的處理能力呢？
回答：其實一個service能不能處理得過來，能不能響應得過來，應該由調用方說了算。調用服務，快速處理了，處理能力跟得上；調用服務，處理超時了，處理能力很有可能跟不上了。
動態權重設計：
例如：
（1）設置一個閾值，超過閾值直接丟棄
（2）藉助「動態權重」來實施過載保護
案例策略：
1）service的負載均衡、故障轉移、超時處理通常是RPC-client連接池層面來實施的
2）異構伺服器負載均衡，最簡單的方式是靜態權重法，缺點是無法自適應動態調整
3）動態權重法，可以動態的根據service的處理能力來分配負載，需要有連接池層面的微小改動
4）過載保護，是在負載過高時，service為了保護自己，保證一定處理能力的一種自救方法
5）動態權重法，還可以用做service的過載保護