引言
負載均衡是什麼呢,我們首先來看看wiki對這個名詞的解釋:
負載均衡（Load balancing）是一種計算機技術，用來在多個計算機（計算機集羣）、網絡連接、CPU、磁盤驅動器或其他資源中分配負載，以達到最優化資源使用、最大化吞吐率、最小化響應時間、同時避免過載的目的。 使用帶有負載均衡的多個服務器組件，取代單一的組件，可以通過冗餘提高可靠性。負載均衡服務通常是由專用軟件和硬件來完成。 主要作用是將大量作業合理地分攤到多個操作單元上進行執行，用於解決互聯網架構中的高併發和高可用的問題。
是的,我們可以清楚的看到負載均衡是一種將請求均勻的分攤到多臺服務器上的技術,當我們使用一個合理的負載均衡算法時,理論上整個集羣的負載能力是線性提升的.當然這個的概念也可擴展至單機多CPU.一般來說負載均衡分爲以下兩種:
- 一種是
請求負載均衡,即將用戶的請求均衡地分發到不同的服務器進行處理. - 另一種是
數據負載均衡,即將用戶更新的數據分發到不同的存儲服務器.
其實負載均衡這個概念還是非常普遍的,從網絡層的角度來看,有基於DNS,IP,HTTP等協議的負載均衡算法,其實這些也屬於基於請求.而在應用層,也有相應的負載均衡算法,如下:
基於請求的負載均衡
- 簡單輪詢
- 加權輪詢
- 加權輪詢改進(Nginx)
- 隨機策略
基於數據的負載均衡
- 一致性哈希(以及一些改進,比如虛擬節點,有限負載)
- 哈希槽
- 基於關鍵字
我們可以看到其實在基於數據的負載均衡中所展現的算法其實就是數據分片中使用的算法,因爲數據分片也要求數據的負載均衡,也就是我們所說的基於數據的負載均衡.
至於基於請求和基於數據的負載均衡其中具體細節我們就不再說了,其他博客說的很清楚,那麼如何在我們的項目中選擇這些算法呢?其實主要基於如下幾個條件:
服務器節點的異構性(即各個服務器節點的處理能力).也就是我們每一個服務器的資源是不同的(可以是算力,可以是存儲能力),顯然一般的簡單輪詢無法做到對於擁有不同異構性服務器節點的負載均衡,而加權輪詢則可很好的解決這個問題.就這樣也可以看出簡單輪詢其實是適合每個請求的請求資源是相近的.服務器處理請求的開銷.我們每一個請求的開銷是不同的,如何根據不同的請求選擇合適的服務器呢?有兩種方法,一種是使用單體調度的思路,即每個從節點會向主節點彙報自己的空閒資源,當請求到來時,主節點通過資源調度算法選擇一個合適的從節點來處理該請求;第二種是是使用一致性哈希,從哈希函數上入手,讓請求所需的資源和服務器節點的空閒資源與哈希函數掛鉤,即通過將資源作爲自變量帶入哈希函數進行計算,從而映射到哈希環中.當然這一切都需要我們能夠計算資源.請求是否有狀態(處理請求的過程是否完全依賴於請求).這其實就是每個請求之間是否有因果關係,典型的就是HTTP的短連接,顯然每一個請求只依賴於自己請求的url或者額外數據而與其他http請求無關,這就是典型的無狀態請求.這也意味同一個請求可以分佈到不同的節點上,這就意味着其適合於輪詢,隨機這類算法.當遇到有狀態的請求時,顯然我們需要多個請求落在同一個節點上或者全部節點收斂於一致狀態來保證數據一致性.此時我們就可以使用哈希相關的負載均衡算法,當然也有類似於cookie這樣的解決方式.
總結
以上三點其實是我真正想說的點,根據不同的業務需求我們需要去選擇不同的負載均衡算法,耳熟能詳的:Nginx使用了輪詢算法,Dubbo使用了隨機算法,Redis使用了哈希槽,Memcache使用了一致性哈希(帶虛擬節點).
參考:
有狀態和無狀態