单机最大负载_分布式高可靠之负载均衡，今天看了你肯定会
到目前為止，我已經為你介紹了分布式起源、分布式協調與同步、分布式資源管理與負載調度、分布式計算技術、分布式通信技術和分布式數據存儲。
可以說，掌握了這些內容，基本上就掌握了分布式的關鍵技術。然而，只有可靠的分布式系統才能真正應用起來。那么，分布式系統的可靠性又是如何實現的呢？
不要著急，接下來幾篇文章，我會和你一起學習分布式可靠性相關的知識，包括負載均衡、流量控制、故障隔離和故障恢復。
在這其中，負載均衡是分布式可靠性中非常關鍵的一個問題或技術，在一定程度上反映了分布式系統對業務處理的能力。比如，早期的電商搶購活動，當流量過大時，你可能就會發現有些地區可以購買，而有些地區因為服務崩潰而不能搶購。這，其實就是系統的負載均衡出現了問題。
接下來，我們就一起來打卡分布式高可靠之負載均衡。
什么是負載均衡？
先舉個例子吧。以超市收銀為例，假設現在只有一個窗口、一個收銀員：
- 一般情況下，收銀員平均 2 分鐘服務一位顧客，10 分鐘可以服務 5 位顧客；
- 到周末高峰期時，收銀員加快收銀，平均 1 分鐘服務一位顧客，10 分鐘最多服務 10 位顧客，也就是說一個顧客最多等待 10 分鐘；
- 逢年過節，顧客數量激增，一下增加到 30 位顧客，如果仍然只有一個窗口和一個收銀員，那么所有顧客就只能排隊等候了，一個顧客最多需要等待 30 分鐘。這樣購物體驗，就非常差了。
那有沒有解決辦法呢？
當然有。那就是新開一個收銀窗口，每個收銀窗口服務 15 個顧客，這樣最長等待時間從 30 分鐘縮短到 15 分鐘。但如果，這兩個窗口的排隊顧客數嚴重不均衡，比如一個窗口有 5 個顧客排隊，另一個窗口卻有 25 個顧客排隊，就不能最大化地提升顧客的購物體驗。
所以，盡可能使得每個收銀窗口排隊的顧客一樣多，才能最大程度地減少顧客的最長排隊時間，提高用戶體驗。
看完這個例子，你是不是想到了一句話“不患寡，而患不均”？這，其實就是負載均衡的基本原理。
通常情況下，負載均衡可以分為兩種：
- 一種是請求負載均衡，即將用戶的請求均衡地分發到不同的服務器進行處理；
- 另一種是數據負載均衡，即將用戶更新的數據分發到不同的存儲服務器。
我在（數據分布方式之哈希與一致性哈希，我就是個神算子）文章分享數據分布方法時，提到：數據分布算法很重要的一個衡量標準，就是均勻分布?？梢?#xff0c;哈希和一致性哈希等，其實就是數據負載均衡的常用方法。那么今天，我就與你著重說說服務請求的負載均衡技術吧。
分布式系統中，服務請求的負載均衡是指，當處理大量用戶請求時，請求應盡量均衡地分配到多臺服務器進行處理，每臺服務器處理其中一部分而不是所有的用戶請求，以完成高并發的請求處理，避免因單機處理能力的上限，導致系統崩潰而無法提供服務的問題。
比如，有 N 個請求、M 個節點，負載均衡就是將 N 個請求，均衡地轉發到這 M 個節點進行處理。
服務請求的負載均衡方法
通常情況下，計算機領域中，在不同層有不同的負載均衡方法。比如，從網絡層的角度，通常有基于 DNS、IP 報文等的負載均衡方法；在中間件層（也就是我們專欄主要講的分布式系統層），常見的負載均衡策略主要包括輪詢策略、隨機策略、哈希和一致性哈希等策略。
今天，我著重與你分析的就是，中間件層所涉及的負載均衡策略。接下來，我們就具體看看吧。
輪詢策略
輪詢策略是一種實現簡單，卻很常用的負載均衡策略，核心思想是服務器輪流處理用戶請求，以盡可能使每個服務器處理的請求數相同。生活中也有很多類似的場景，比如，學校宿舍里，學生每周輪流打掃衛生，就是一個典型的輪詢策略。
在負載均衡領域中，輪詢策略主要包括順序輪詢和加權輪詢兩種方式。
首先，我們一起看看順序輪詢。假設有 6 個請求，編號為請求 1~6，有 3 臺服務器可以處理請求，編號為服務器 1~3，如果采用順序輪詢策略，則會按照服務器 1、2、3 的順序輪流進行請求。
如表所示，將 6 個請求當成 6 個步驟：
?
最終的處理結果是，服務器 1 處理請求 1 和請求 4，服務器 2 處理請求 2 和請求 5，服務器 3 處理請求 3 和請求 6。
接下來，我們看一下加權輪詢。
加權輪詢為每個服務器設置了優先級，每次請求過來時會挑選優先級最高的服務器進行處理。比如服務器 1~3 分配了優先級{4，1，1}，這 6 個請求到來時，還當成 6 個步驟，如表所示。
?
最終的處理結果是，服務器 1 處理請求 1~4，服務器 2 處理請求 5，服務器 3 會處理請求 6。
以上就是順序輪詢和加權輪詢的核心原理了。輪詢策略的應用比較廣泛，比如 Nginx 默認的負載均衡策略就是一種改進的加權輪詢策略。我們具體看看它的核心原理吧。
首先，我來解釋下 Nginx 輪詢策略需要用到的變量吧。
- weight：配置文件中為每個服務節點設置的服務節點權重，固定不變。
- effective_weight：服務節點的有效權重，初始值為 weight。在 Nginx 的源碼中有一個最大失敗數的變量 max_fails，當服務發生異常時，則減少相應服務節點的有效權重，公式為 effective_weight = effective_weight - weight / max_fails；之后再次選取本節點，若服務調用成功，則增加有效權重，effective_weight ++ ，直至恢復到 weight。
- current_weight：服務節點當前權重，初始值均為 0，之后會根據系統運行情況動態變化。
假設，各服務器的優先級是{4，1，1}，我還是將 6 個請求分為 6 步來進行講解，如表所示：
?
最終的處理結果為，服務器 1 處理請求 1、2、4、6，服務器 2 處理請求 3，服務器 3 會處理請求 5。
可以看到，與普通的加權輪詢策略相比，這種輪詢策略的優勢在于，當部分請求到來時，不會集中落在優先級較高的那個服務節點。
還是上面的例子，假設只有 4 個請求，按照普通的加權輪詢策略，會全部由服務器 1 進行處理，即{1,1,1,1}；而按照這種平滑的加權輪詢策略的話，會由服務器 1 和 2 共同進行處理，即{1,1,2,1}。
輪詢策略的優點就是，實現簡單，且對于請求所需開銷差不多時，負載均衡效果比較明顯，同時加權輪詢策略還考慮了服務器節點的異構性，即可以讓性能更好的服務器具有更高的優先級，從而可以處理更多的請求，使得分布更加均衡。
但輪詢策略的缺點是，每次請求到達的目的節點不確定，不適用于有狀態請求的場景。并且，輪詢策略主要強調請求數的均衡性，所以不適用于處理請求所需開銷不同的場景。
但輪詢策略的缺點是，每次請求到達的目的節點不確定，不適用于有狀態請求的場景。并且，輪詢策略主要強調請求數的均衡性，所以不適用于處理請求所需開銷不同的場景。比如，有兩個服務器（節點 A 和節點 B）性能相同，CPU 個數和內存均相等，有 4 個請求需要處理，其中請求 1 和請求 3 需要 1 個 CPU，請求 2 和請求 4 需要 2 個 CPU。根據輪詢策略，請求 1 和請求 3 由節點 A、請求 2 和請求 4 由節點 B 處理。由此可見，節點 A 和節點 B 關于 CPU 的負載分別是 2 和 4，從這個角度來看，兩個節點的負載并不均衡。
綜上所述，輪詢策略適用于用戶請求所需資源比較接近的場景。
隨機策略
隨機策略也比較容易理解，指的就是當用戶請求到來時，會隨機發到某個服務節點進行處理，可以采用隨機函數實現。這里，隨機函數的作用就是，讓請求盡可能分散到不同節點，防止所有請求放到同一節點或少量幾個節點上。
如圖所示，假設有 5 臺服務器 Server 1~5 可以處理用戶請求，每次請求到來時，都會先調用一個隨機函數來計算出處理節點。這里，隨機函數的結果只能是{1,2,3,4,5}這五個值，然后再根據計算結果分發到相應的服務器進行處理。比如，圖中隨機函數計算結果為 2，因此該請求會由 Server2 處理。
?
這種方式的優點是，實現簡單，但缺點也很明顯，與輪詢策略一樣，每次請求到達的目的節點不確定，不適用于有狀態的場景，而且沒有考慮到處理請求所需開銷。除此之外，隨機策略也沒有考慮服務器節點的異構性，即性能差距較大的服務器可能處理的請求差不多。
因此，隨機策略適用于，集群中服務器節點處理能力相差不大，用戶請求所需資源比較接近的場景
比如，我在前面文章中提到的 RPC 框架 Dubbo，當注冊中心將服務提供方地址列表返回給調用方時，調用方會通過負載均衡算法選擇其中一個服務提供方進行遠程調用。關于負載均衡算法，Dubbo 提供了隨機策略、輪詢策略等。
哈希和一致性哈希策略
無論是輪詢還是隨機策略，對于一個客戶端的多次請求，每次落到的服務器很大可能是不同的，如果這是一臺緩存服務器，就會對緩存同步帶來很大挑戰。尤其是系統繁忙時，主從延遲帶來的同步緩慢，可能會造成同一客戶端兩次訪問得到不同的結果。解決方案就是，利用哈希算法定位到對應的服務器
哈希和一致性哈希，是數據負載均衡的常用算法。我在（數據分布方式之哈希與一致性哈希，我就是個神算子）文章介紹哈希與一致性哈希時，提到過：數據分布算法的均勻性，一方面指數據的存儲均勻，另一方面也指數據請求的均勻。
數據請求就是用戶請求的一種，哈希、一致性哈希、帶有限負載的一致性哈希和帶虛擬節點的一致性哈希算法，同樣適用于請求負載均衡。
所以，哈希與一致性策略的優點是，哈希函數設置合理的話，負載會比較均衡。而且，相同 key 的請求會落在同一個服務節點上，可以用于有狀態請求的場景。除此之外，帶虛擬節點的一致性哈希策略還可以解決服務器節點異構的問題。
但其缺點是，當某個節點出現故障時，采用哈希策略會出現數據大規模遷移的情況，采用一致性哈希策略可能會造成一定的數據傾斜問題。同樣的，這兩種策略也沒考慮請求開銷不同造成的不均衡問題。
應用哈希和一致性哈希策略的框架有很多，比如 Redis、Memcached、Cassandra 等，你可以再回顧下（數據分布方式之哈希與一致性哈希，我就是個神算子）文章中的相關內容。
除了以上這些策略，還有一些負載均衡策略比較常用。比如，根據服務節點中的資源信息（CPU，內存等）進行判斷，服務節點資源越多，就越有可能處理下一個請求；再比如，根據請求的特定需求，如請求需要使用 GPU 資源，那就需要由具有 GPU 資源的節點進行處理等。
對比分析
以上，就是輪詢策略、隨機策略、哈希和一致性哈希策略的主要內容了。接下來，我再通過一個表格對比下這三種方法，以便于你學習和查閱。
總結
今天，我主要帶你學習了分布式高可靠技術中的負載均衡。
首先，我以超市收銀為例，與你介紹了什么是負載均衡。負載均衡包括數據負載均衡和請求負載均衡，我在前面中介紹的數據分布其實就是數據的負載均衡，所以我今天重點與你分享的是請求的負載均衡。
然后，我與你介紹了常見的負載均衡策略，包括輪詢策略、隨機策略、哈希和一致性哈希策略。其中，輪詢策略和隨機策略，因為每次請求到達的目的節點不確定，只適用于無狀態請求的場景；而哈希和一致性哈希策略，因為相同 key 的請求會落在同一個服務節點上，所以可以用于有狀態請求的場景。
最后，我再通過一張思維導圖來歸納一下今天的核心知識點吧。
?
加油，相信通過本講的學習，你對分布式系統中的負載均衡有了一定的理解，也可以進一步對電商系統、火車票系統等涉及的請求負載均衡的問題進行分析了。加油，行動起來吧！
在下方公眾號【架構師修煉】菜單中可自行獲取專屬架構視頻資料，無套路分享，包括不限于 java架構、python系列、人工智能系列、架構系列，以及最新面試、小程序、大前端均無私奉獻，你會感謝我的哈！下一篇預告：分布式流量控制
往期精選
分布式數據之緩存技術，一起來揭開其神秘面紗
分布式數據復制技術，今天就教你真正分身術
數據分布方式之哈希與一致性哈希，我就是個神算子
分布式存儲系統三要素，掌握這些就離成功不遠了
想要設計一個好的分布式系統，必須搞定這個理論
分布式通信技術之發布訂閱，干貨滿滿
分布式通信技術之遠程調用：RPC
消息隊列Broker主從架構詳細設計方案，這一篇就搞定主從架構
消息中間件路由中心你會設計嗎，不會就來學學
消息隊列消息延遲解決方案，跟著做就行了
秒殺系統每秒上萬次下單請求，我們該怎么去設計
【分布式技術】分布式系統調度架構之單體調度，非掌握不可
CDN加速技術，作為開發的我們真的不需要懂嗎？
煩人的緩存穿透問題，今天教就你如何去解決
分布式緩存高可用方案，我們都是這么干的
每天百萬交易的支付系統，生產環境該怎么設置JVM堆內存大小
你的成神之路我已替你鋪好，沒鋪你來捶我
創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎總結
以上是生活随笔為你收集整理的单机最大负载_分布式高可靠之负载均衡，今天看了你肯定会的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 出境跟团游第三批目的地名单公布 同程旅行
- 下一篇： 小米手环8 Pro官宣！1.74英寸炫彩