古人云,不患寡而患不均。
在計算機的世界,這就是大家耳熟能詳的負載均衡(load balancing),所謂負載均衡,就是說如果一組計算機節點(或者一組程式)提供相同的(同質的)服務,那麼對服務的請求就應該均勻的分攤到這些節點上。負載均衡的前提一定是“provide a single Internet service from multiple servers”, 這些提供服務的節點被稱之為server farm、server pool或者backend servers。
這裡的服務是廣義的,可以是簡單的計算,也可能是資料的讀取或者儲存。負載均衡也不是新事物,這種思想在多核CPU時代就有了,只不過在分散式系統中,負載均衡更是無處不在,這是分散式系統的天然特性決定的,分散式就是利用大量計算機節點完成單個計算機無法完成的計算、儲存服務,既然有大量計算機節點,那麼均衡的排程就非常重要。
負載均衡的意義在於,讓所有節點以最小的代價、最好的狀態對外提供服務,這樣系統吞吐量最大,效能更高,對於使用者而言請求的時間也更小。而且,負載均衡增強了系統的可靠性,最大化降低了單個節點過載、甚至crash的概率。不難想象,如果一個系統絕大部分請求都落在同一個節點上,那麼這些請求響應時間都很慢,而且萬一節點降級或者崩潰,那麼所有請求又會轉移到下一個節點,造成雪崩。
事實上,網上有很多文章介紹負載均衡的演算法,大多都是大同小異。本文更多的是自己對這些演算法的總結與思考。
一分鐘瞭解負載均衡的一切
本章節的標題和內容都來自一分鐘瞭解負載均衡的一切這一篇文章。當然,原文的標題是誇張了點,不過文中列出了在一個大型web網站中各層是如何用到負載均衡的,一目瞭然。
常見網際網路分散式架構如上,分為客戶端層、反向代理nginx層、站點層、服務層、資料層。可以看到,每一個下游都有多個上游呼叫,只需要做到,每一個上游都均勻訪問每一個下游,就能實現“將請求/資料【均勻】分攤到多個操作單元上執行”。
(1)【客戶端層】到【反向代理層】的負載均衡,是通過“DNS輪詢”實現的
(2)【反向代理層】到【站點層】的負載均衡,是通過“nginx”實現的
(3)【站點層】到【服務層】的負載均衡,是通過“服務連線池”實現的
(4)【資料層】的負載均衡,要考慮“資料的均衡”與“請求的均衡”兩個點,常見的方式有“按照範圍水平切分”與“hash水平切分”。
資料層的負載均衡,在我之前的《帶著問題學習分散式系統之資料分片》中有詳細介紹。
演算法衡量
在我看來,當我們提到一個負載均衡演算法,或者具體的應用場景時,應該考慮以下問題
第一,是否意識到不同節點的服務能力是不一樣的,比如CPU、記憶體、網路、地理位置
第二,是否意識到節點的服務能力是動態變化的,高配的機器也有可能由於一些突發原因導致處理速度變得很慢
第三,是否考慮將同一個客戶端,或者說同樣的請求分發到同一個處理節點,這對於“有狀態”的服務非常重要,比如session,比如分散式儲存
第四,誰來負責負載均衡,即誰充當負載均衡器(load balancer),balancer本身是否會成為瓶頸
下面會結合具體的演算法來考慮這些問題
負載均衡演算法
輪詢演算法(round-robin)
思想很簡單,就是提供同質服務的節點逐個對外提供服務,這樣能做到絕對的均衡。Python示例程式碼如下
1 2 3 4 5 6 7 8 9 10 |
SERVER_LIST = [ '10.246.10.1', '10.246.10.2', '10.246.10.3', ] def round_robin(server_lst, cur = [0]): length = len(server_lst) ret = server_lst[cur[0] % length] cur[0] = (cur[0] + 1) % length return ret |
可以看到,所有的節點都是以同樣的概率提供服務,即沒有考慮到節點的差異,也許同樣數目的請求,高配的機器CPU才20%,低配的機器CPU已經80%了
加權輪詢演算法(weight round-robin)
加權輪訓演算法就是在輪訓演算法的基礎上,考慮到機器的差異性,分配給機器不同的權重,能者多勞。注意,這個權重的分配依賴於請求的型別,比如計算密集型,那就考慮CPU、記憶體;如果是IO密集型,那就考慮磁碟效能。Python示例程式碼如下
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
WEIGHT_SERVER_LIST = { '10.246.10.1': 1, '10.246.10.2': 3, '10.246.10.3': 2, } def weight_round_robin(servers, cur = [0]): weighted_list = [] for k, v in servers.iteritems(): weighted_list.extend([k] * v) length = len(weighted_list) ret = weighted_list[cur[0] % length] cur[0] = (cur[0] + 1) % length return ret |
隨機演算法(random)
這個就更好理解了,隨機選擇一個節點服務,按照概率,只要請求數量足夠多,那麼也能達到絕對均衡的效果。而且實現簡單很多
1 2 3 4 |
def random_choose(server_lst): import random random.seed() return random.choice(server_lst) |
加權隨機演算法(random)
如同加權輪訓演算法至於輪訓演算法一樣,也是在隨機的時候引入不同節點的權重,實現也很類似。
1 2 3 4 5 6 7 |
def weight_random_choose(servers): import random random.seed() weighted_list = [] for k, v in servers.iteritems(): weighted_list.extend([k] * v) return random.choice(weighted_list) |
當然,如果節點列表以及權重變化不大,那麼也可以對所有節點歸一化,然後按概率區間選擇
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
def normalize_servers(servers): normalized_servers = {} total = sum(servers.values()) cur_sum = 0 for k, v in servers.iteritems(): normalized_servers[k] = 1.0 * (cur_sum + v) / total cur_sum += v return normalized_servers def weight_random_choose_ex(normalized_servers): import random, operator random.seed() rand = random.random() for k, v in sorted(normalized_servers.iteritems(), key = operator.itemgetter(1)): if v >= rand: return k else: assert False, 'Error normalized_servers with rand %s ' % rand |
雜湊法(hash)
根據客戶端的IP,或者請求的“Key”,計算出一個hash值,然後對節點數目取模。好處就是,同一個請求能夠分配到同樣的服務節點,這對於“有狀態”的服務很有必要
1 2 3 |
def hash_choose(request_info, server_lst): hashed_request_info = hash(request_info) return server_lst[hashed_request_info % len(server_lst)] |
只要hash結果足夠分散,也是能做到絕對均衡的。
一致性雜湊
雜湊演算法的缺陷也很明顯,當節點的數目發生變化的時候,請求會大概率分配到其他的節點,引發到一系列問題,比如sticky session。而且在某些情況,比如分散式儲存,是絕對的不允許的。
為了解決這個雜湊演算法的問題,又引入了一致性雜湊演算法,簡單來說,一個物理節點與多個虛擬節點對映,在hash的時候,使用虛擬節點數目而不是物理節點數目。當物理節點變化的時候,虛擬節點的數目無需變化,只涉及到虛擬節點的重新分配。而且,調整每個物理節點對應的虛擬節點數目,也就相當於每個物理節點有不同的權重
最少連線演算法(least connection)
以上的諸多演算法,要麼沒有考慮到節點間的差異(輪訓、隨機、雜湊),要麼節點間的權重是靜態分配的(加權輪訓、加權隨機、一致性hash)。
考慮這麼一種情況,某臺機器出現故障,無法及時處理請求,但新的請求還是會以一定的概率源源不斷的分配到這個節點,造成請求的積壓。因此,根據節點的真實負載,動態地調整節點的權重就非常重要。當然,要獲得接節點的真實負載也不是一概而論的事情,如何定義負載,負載的收集是否及時,這都是需要考慮的問題。
每個節點當前的連線數目是一個非常容易收集的指標,因此lease connection是最常被人提到的演算法。也有一些側重不同或者更復雜、更客觀的指標,比如最小響應時間(least response time)、最小活躍數(least active)等等。
一點思考
有狀態的請求
首先來看看“演算法衡量”中提到的第三個問題:同一個請求是否分發到同樣的服務節點,同一個請求指的是同一個使用者或者同樣的唯一標示。什麼時候同一請求最好(必須)分發到同樣的服務節點呢?那就是有狀態 — 請求依賴某些存在於記憶體或者磁碟的資料,比如web請求的session,比如分散式儲存。怎麼實現呢,有以下幾種辦法:
(1)請求分發的時候,保證同一個請求分發到同樣的服務節點。
這個依賴於負載均衡演算法,比如簡單的輪訓,隨機肯定是不行的,雜湊法在節點增刪的時候也會失效。可行的是一致性hash,以及分散式儲存中的按範圍分段(即記錄哪些請求由哪個服務節點提供服務),代價是需要在load balancer中維護額外的資料。
(2)狀態資料在backend servers之間共享
保證同一個請求分發到同樣的服務節點,這個只是手段,目的是請求能使用到對應的狀態資料。如果狀態資料能夠在服務節點之間共享,那麼也能達到這個目的。比如服務節點連線到共享資料庫,或者記憶體資料庫如memcached
(3)狀態資料維護在客戶端
這個在web請求中也有使用,即cookie,不過要考慮安全性,需要加密。
關於load balancer
接下來回答第四個問題:關於load balancer,其實就是說,在哪裡做負載均衡,是客戶端還是服務端,是請求的發起者還是請求的3。具體而言,要麼是在客戶端,根據服務節點的資訊自行選擇,然後將請求直接傳送到選中的服務節點;要麼是在服務節點叢集之前放一個集中式代理(proxy),由代理負責請求求分發。不管哪一種,至少都需要知道當前的服務節點列表這一基礎資訊。
如果在客戶端實現負載均衡,客戶端首先得知道伺服器列表,要麼是靜態配置,要麼有簡單介面查詢,但backend server的詳細負載資訊,就不適用通過客戶端來查詢。因此,客戶端的負載均衡演算法要麼是比較簡單的,比如輪訓(加權輪訓)、隨機(加權隨機)、雜湊這幾種演算法,只要每個客戶端足夠隨機,按照大數定理,服務節點的負載也是均衡的。要在客戶端使用較為複雜的演算法,比如根據backend的實際負載,那麼就需要去額外的負載均衡服務(external load balancing service)查詢到這些資訊,在grpc中,就是使用的這種辦法
可以看到,load balancer與grpc server通訊,獲得grpc server的負載等具體詳細,然後grpc client從load balancer獲取這些資訊,最終grpc client直連到被選擇的grpc server。
而基於Proxy的方式是更為常見的,比如7層的Nginx,四層的F5、LVS,既有硬體路由,也有軟體分發。集中式的特點在於方便控制,而且能容易實現一些更精密,更復雜的演算法。但缺點也很明顯,一來負載均衡器本身可能成為效能瓶頸;二來可能引入額外的延遲,請求一定先發到達負載均衡器,然後到達真正的服務節點。
load balance proxy對於請求的響應(response),要麼不經過proxy,如LVS;要麼經過Proxy,如Nginx。下圖是LVS示意圖(來源見水印)
而如果response也是走load balancer proxy的話,那麼整個服務過程對客戶端而言就是完全透明的,也防止了客戶端去嘗試連線後臺伺服器,提供了一層安全保障!
值得注意的是,load balancer proxy不能成為單點故障(single point of failure),因此一般會設計為高可用的主從結構
其他
在這篇文章中提到,負載均衡是一種推模型,一定會選出一個服務節點,然後把請求推送過來。而換一種思路,使用訊息佇列,就變成了拉模型:空閒的服務節點主動去拉取請求進行處理,各個節點的負載自然也是均衡的。訊息佇列相比負載均衡好處在於,服務節點不會被大量請求沖垮,同時增加服務節點更加容易;缺點也很明顯,請求不是事實處理的。
想到另外一個例子,比如在gunicorn這種pre-fork模型中,master(gunicorn 中Arbiter)會fork出指定數量的worker程式,worker程式在同樣的埠上監聽,誰先監聽到網路連線請求,誰就提供服務,這也是worker程式之間的負載均衡。