高性能負載均衡
分類及架構
高性能集羣的複雜度主要體現在需要增加一個任務分配器，以及爲任務選擇一個合適的任務分配算法，負載均衡不只是爲了計算單元的負載達到均衡狀態
負載均衡分類
DNS負載均衡
是最簡單也是最常見的負載均衡方式，一般用來實現地理級別的均衡
優點
簡單、成本低：負載均衡工作交給DNS服務器處理，無須自己開發或者維護負載均衡設備
就近訪問，提升訪問速度：DNS解析時可以根據請求來源IP，解析成距離用戶最近的服務器地址，可以加快訪問速度，改善性能
缺點
更新不及時：DNS緩存的時間比較長，修改DNS配置後，由於緩存的原因，還有很多用戶會繼續訪問修改前的IP，這樣的訪問會失敗
分配策略比較簡單：DNS負載均衡支持的算法少；不能區分服務器差異，也無法感知後端服務器的狀態
硬件負載均衡
通過單獨的硬件設備來實現負載均衡功能。業界典型設備有F5和A10
優點
功能強大：全面支持各層級的負載均衡，支持全面的負載均衡算法，支持全局負載均衡
性能強大：可以支持100萬以上的併發（軟件一般能支持到10萬級）
穩定性高：商用硬件負載均衡，經過了良好的嚴格測試，經過大規模使用，穩定性高。
支持安全防護：硬件均衡設備除具備負載均衡功能外，還具備防火牆，防DDoS攻擊等安全功能
缺點
價格昂貴
擴張能力差：硬件設備，可以根據業務進行配置，但無法進行擴展和定製
軟件負載均衡
通過負載均衡軟件來實現負載均衡功能，常見的有Nginx和LVS，其中Nginx軟件的7層負載均衡，LVS是Linux內核的4層負載均衡。4層和7層的區別在於協議和靈活性，nginx支持HTTP、E-mail協議；而LVS是4層負載均衡，和協議無關，幾乎所有應用都可以做，例如，聊天，數據庫等
優點
簡單：無論是部署還是維護都比較簡單
便宜：只要買個Linux服務器，裝上軟件即可
靈活：
4層和7層負載均衡可以根據業務進行選擇；也可以根據業務進行比較方便的擴展，例如可以通過Nginx的插件來實現業務的定製化功能
缺點
性能一般，功能沒有硬件負載均衡那麼強大
一般不具備防火牆和防DDoS攻擊等安全功能
算法
算法期望達到的目的分類
任務平分類
負載均衡系統將收到的任務平均分配給服務器進行處理，平均可以是絕對數量的平均，也可以是比率或者權重上的平均
負載均衡類
負載均衡系統根據服務器的負載來進行分配。負載值系統當前的壓力，可以是cpu負載、連接數、IO使用率，網卡吞吐量等
性能最優類
負載均和系統根據任務中的某些關鍵信息進行Hash運算，將相同Hash值的請求分配給響應最快的服務器
Hash類
負載均衡系統將任務中的的某些關鍵信息進行Hash運算，將相同Hash值的請求分配到同一臺服務器。常見的又源地址Hash、目標地址Hash、session ID Hash、用戶ID Hash等
輪詢
負載均衡系統收到請求後，按照順序輪流分配到服務器上。輪詢是最簡單的一個策略，無須關注服務器本身的狀態。只要服務器在運行，運行狀態是不關注的
加權輪詢
負載均衡系統根據服務器權重進行任務分配，這裏的權重一般是根據硬件配置進行靜態配置的，採用動態的方式會更加契合業務，但是複雜度也會更高
主要目的是解決不同服務器處理能力有差異的問題，但同樣存在無法根據服務器狀態的差異進行任務分配的問題
負載最低優先
負載均衡系統將任務分配給當前負載最低的服務器，這裏的負載根據不同任務類型和業務場景，可以有不同的指標來衡量
不同的指標衡量
LVS這種4層網絡負載設備，可以以“連接數”來判斷服務器的狀態，服務器連接數越大，表明服務器壓力越大
nginx這種7層網絡負載系統，可以以“HTTP請求數”來判斷服務器狀態
負載最低優先的算法解決來輪詢算法中無法感知服務器狀態的問題，由此帶來的代價是複雜度增加很多
最少連接數優先的算法邀請負載均衡系統統計每個服務器當前建立的連接，其應用場景僅限於負載均衡接收的任何連接請求都會轉給服務器進行處理，否則如果負載均衡系統和服務器之間是固定的連接池方式，就不適合採取
CPU負載最低優先的算法邀請負載均衡系統以某種方式收集每個服務器的CPU負載，而且要確定以多少時間間隔爲標準，時間間隔太短容易造成波動，太長可能造成峯值來臨時響應緩慢
負載最低優先算法基本上能夠比較完美地解決輪詢算法的缺點，因爲採用這種算法後負載均衡算法需要感知服務器當前運行狀態。但其代價是複雜度大幅上升，如果算法本身沒有設計好，算法本身可能成爲系統瓶頸。所以負載最低優先算法雖然效果看起來美好但實際上真正應用的場景反而沒有輪詢那麼多
性能最優類
負載最低優先類算法是站在服務端的角度來進行分配的，性能最優優先算法是站在客戶端的角度來進行分配的，優先將任務分配給處理速度最快的服務器，通過這種方式達到最快響應客戶端的目的
性能最優優先類算法本質上也是感知類服務器的狀態，只是通過響應時間這個外部標準來衡量服務器狀態
存在問題複雜度都很高
需要收集和分析每個服務器每個任務的響應時間，在大量任務處理的場景下，這種收集和統計本身也會消耗較多的性能
爲降低性能可採取採樣方式統計，但複雜度進一步提升，因爲要確定合適的採樣率，採用太低導致結果不準確，太高性能消耗較大
無論是全部統計還是採樣統計，都需要選擇合適的週期，但也是一件比較複雜的事情
Hash類
負載均衡系統根據任務中的某些關鍵信息進行Hash運算，將相同Hash值的請求分配到同一臺服務器上
源地址Hash
將來源同一個源IP地址的任務分配給同一個服務器處理，適用於存在事務，會話的業務。例如；當我們通過瀏覽器登陸時會生成一個會話信息，這個會話是臨時的，瀏覽器關掉後就失效，但需要保證用戶在會話存在期間，每次都能訪問到同一個服務器。
ID Hash
將某個ID標識的業務分配到同一個服務器中進行處理，這裏的ID一般是臨時性數據的ID（如sessionId）用戶每次訪問到同一臺服務器的目的