單服務器無論如何優化，無論採用多好的硬件，總會有一個性能天花板，當單服務器的性能無法滿足業務需求時，就需要設計高性能集羣來提升系統整體的處理性能。
高性能集羣的本質很簡單，通過增加更多的服務器來提升系統整體的計算能力。由於計算本身存在一個特點：同樣的輸入數據和邏輯，無論在哪臺服務器上執行，都應該得到相同的輸出。因此高性能集羣設計的複雜度主要體現在任務分配這部分，需要設計合理的任務分配策略，將計算任務分配到多臺服務器上執行。
高性能集羣的複雜性主要體現在需要增加一個任務分配器，以及爲任務選擇一個合適的任務分配算法。對於任務分配器，現在更流行的通用叫法是“負載均衡器”。但這個名稱有一定的誤導性，會讓人潛意識裏認爲任務分配的目的是要保持各個計算單元的負載達到均衡狀態。
而實際上任務分配並不只是考慮計算單元的負載均衡，不同的任務分配算法目標是不一樣的，有的基於負載考慮，有的基於性能（吞吐量、響應時間）考慮，有的基於業務考慮。考慮到“負載均衡”已經成爲了事實上的標準術語，這裏我也用“負載均衡”來代替“任務分配”，但請你時刻記住，負載均衡不只是爲了計算單元的負載達到均衡狀態。
負載均衡分類
常見的負載均衡系統包括3種：DNS負載均衡、硬件負載均衡和軟件負載均衡。
DNS負載均衡
DNS是最簡單也是最常見的負載均衡方式，一般用來實現地理級別的均衡。例如，北方的用戶訪問北京的機房，南方的用戶訪問深圳的機房。DNS負載均衡的本質是DNS解析同一個域名可以返回不同的IP地址。例如，同樣是www.baidu.com，北方用戶解析後獲取的地址是61.135.165.224（這是北京機房的IP），南方用戶解析後獲取的地址是14.215.177.38（這是深圳機房的IP）。
下面是DNS負載均衡的簡單示意圖：
DNS負載均衡實現簡單、成本低，但也存在粒度太粗、負載均衡算法少等缺點。仔細分析一下優缺點，其優點有：
-
簡單、成本低：負載均衡工作交給DNS服務器處理，無須自己開發或者維護負載均衡設備。
-
就近訪問，提升訪問速度：DNS解析時可以根據請求來源IP，解析成距離用戶最近的服務器地址，可以加快訪問速度，改善性能。
缺點有：
-
更新不及時：DNS緩存的時間比較長，修改DNS配置後，由於緩存的原因，還是有很多用戶會繼續訪問修改前的IP，這樣的訪問會失敗，達不到負載均衡的目的，並且也影響用戶正常使用業務。
-
擴展性差：DNS負載均衡的控制權在域名商那裏，無法根據業務特點針對其做更多的定製化功能和擴展特性。
-
分配策略比較簡單：DNS負載均衡支持的算法少；不能區分服務器的差異（不能根據系統與服務的狀態來判斷負載）；也無法感知後端服務器的狀態。
針對DNS負載均衡的一些缺點，對於時延和故障敏感的業務，有一些公司自己實現了HTTP-DNS的功能，即使用HTTP協議實現一個私有的DNS系統。這樣的方案和通用的DNS優缺點正好相反。
硬件負載均衡
硬件負載均衡是通過單獨的硬件設備來實現負載均衡功能，這類設備和路由器、交換機類似，可以理解爲一個用於負載均衡的基礎網絡設備。
目前業界典型的硬件負載均衡設備有兩款：F5和A10。這類設備性能強勁、功能強大，但價格都不便宜，一般只有“土豪”公司纔會考慮使用此類設備。普通業務量級的公司一是負擔不起，二是業務量沒那麼大，用這些設備也是浪費。
硬件負載均衡的優點是：
-
功能強大：全面支持各層級的負載均衡，支持全面的負載均衡算法，支持全局負載均衡。
-
性能強大：對比一下，軟件負載均衡支持到10萬級併發已經很厲害了，硬件負載均衡可以支持100萬以上的併發。
-
穩定性高：商用硬件負載均衡，經過了良好的嚴格測試，經過大規模使用，穩定性高。
-
支持安全防護：硬件均衡設備除具備負載均衡功能外，還具備防火牆、防DDoS攻擊等安全功能。
硬件負載均衡的缺點是：
-
價格昂貴：最普通的一臺F5就是一臺“馬6”，好一點的就是“Q7”了。
-
擴展能力差：硬件設備，可以根據業務進行配置，但無法進行擴展和定製。
軟件負載均衡
軟件負載均衡通過負載均衡軟件來實現負載均衡功能，常見的有Nginx和LVS，其中Nginx是軟件的7層負載均衡，LVS是Linux內核的4層負載均衡。4層和7層的區別就在於協議和靈活性，Nginx支持HTTP、E-mail協議；而LVS是4層負載均衡，和協議無關，幾乎所有應用都可以做，例如，聊天、數據庫等。
軟件和硬件的最主要區別就在於性能，硬件負載均衡性能遠遠高於軟件負載均衡性能。Ngxin的性能是萬級，一般的Linux服務器上裝一個Nginx大概能到5萬/秒；LVS的性能是十萬級，據說可達到80萬/秒；而F5性能是百萬級，從200萬/秒到800萬/秒都有（數據來源網絡，僅供參考，如需採用請根據實際業務場景進行性能測試）。
當然，軟件負載均衡的最大優勢是便宜，一臺普通的Linux服務器批發價大概就是1萬元左右，相比F5的價格，那就是自行車和寶馬的區別了。
除了使用開源的系統進行負載均衡，如果業務比較特殊，也可能基於開源系統進行定製（例如，Nginx插件），甚至進行自研。
下面是Nginx的負載均衡架構示意圖：
軟件負載均衡的優點：
-
簡單：無論是部署還是維護都比較簡單。
-
便宜：只要買個Linux服務器，裝上軟件即可。
-
靈活：4層和7層負載均衡可以根據業務進行選擇；也可以根據業務進行比較方便的擴展，例如，可以通過Nginx的插件來實現業務的定製化功能。
其實下面的缺點都是和硬件負載均衡相比的，並不是說軟件負載均衡沒法用。
-
性能一般：一個Nginx大約能支撐5萬併發。
-
功能沒有硬件負載均衡那麼強大。
-
一般不具備防火牆和防DDoS攻擊等安全功能。
負載均衡典型架構
前面我們介紹了3種常見的負載均衡機制：DNS負載均衡、硬件負載均衡、軟件負載均衡，每種方式都有一些優缺點，但並不意味着在實際應用中只能基於它們的優缺點進行非此即彼的選擇，反而是基於它們的優缺點進行組合使用。具體來說，組合的基本原則爲：
-
DNS負載均衡用於實現地理級別的負載均衡；
-
硬件負載均衡用於實現集羣級別的負載均衡；
-
軟件負載均衡用於實現機器級別的負載均衡。
以一個假想的實例來說明一下這種組合方式，如下圖所示。
整個系統的負載均衡分爲三層。
-
地理級別負載均衡：www.xxx.com部署在北京、廣州、上海三個機房，當用戶訪問時，DNS會根據用戶的地理位置來決定返回哪個機房的IP，圖中返回了廣州機房的IP地址，這樣用戶就訪問到廣州機房了。
-
集羣級別負載均衡：廣州機房的負載均衡用的是F5設備，F5收到用戶請求後，進行集羣級別的負載均衡，將用戶請求發給3個本地集羣中的一個，我們假設F5將用戶請求發給了“廣州集羣2”。
-
機器級別的負載均衡：廣州集羣2的負載均衡用的是Nginx，Nginx收到用戶請求後，將用戶請求發送給集羣裏面的某臺服務器，服務器處理用戶的業務請求並返回業務響應。
需要注意的是，上圖只是一個示例，一般在大型業務場景下才會這樣用，如果業務量沒這麼大，則沒有必要嚴格照搬這套架構。例如，一個大學的論壇，完全可以不需要DNS負載均衡，也不需要F5設備，只需要用Nginx作爲一個簡單的負載均衡就足夠了。
負載均衡算法
負載均衡算法數量較多，而且可以根據一些業務特性進行定製開發，拋開細節上的差異，根據算法期望達到的目的，大體上可以分爲下面幾類。
-
任務平分類：負載均衡系統將收到的任務平均分配給服務器進行處理，這裏的“平均”可以是絕對數量的平均，也可以是比例或者權重上的平均。
-
負載均衡類：負載均衡系統根據服務器的負載來進行分配，這裏的負載並不一定是通常意義上我們說的“CPU負載”，而是系統當前的壓力，可以用CPU負載來衡量，也可以用連接數、I/O使用率、網卡吞吐量等來衡量系統的壓力。
-
性能最優類：負載均衡系統根據服務器的響應時間來進行任務分配，優先將新任務分配給響應最快的服務器。
-
Hash類：負載均衡系統根據任務中的某些關鍵信息進行Hash運算，將相同Hash值的請求分配到同一臺服務器上。常見的有源地址Hash、目標地址Hash、session id hash、用戶ID Hash等。
接下來介紹一下負載均衡算法以及它們的優缺點。
輪詢
負載均衡系統收到請求後，按照順序輪流分配到服務器上。
輪詢是最簡單的一個策略，無須關注服務器本身的狀態，例如：
-
某個服務器當前因爲觸發了程序bug進入了死循環導致CPU負載很高，負載均衡系統是不感知的，還是會繼續將請求源源不斷地發送給它。
-
集羣中有新的機器是32核的，老的機器是16核的，負載均衡系統也是不關注的，新老機器分配的任務數是一樣的。
需要注意的是負載均衡系統無須關注“服務器本身狀態”，這裏的關鍵詞是“本身”。也就是說，只要服務器在運行，運行狀態是不關注的。但如果服務器直接宕機了，或者服務器和負載均衡系統斷連了，這時負載均衡系統是能夠感知的，也需要做出相應的處理。例如，將服務器從可分配服務器列表中刪除，否則就會出現服務器已經宕機了，任務還不斷地分配給它，這明顯是不合理的。
總而言之，“簡單”是輪詢算法的優點，也是它的缺點。
加權輪詢
負載均衡系統根據服務器權重進行任務分配，這裏的權重一般是根據硬件配置進行靜態配置的，採用動態的方式計算會更加契合業務，但複雜度也會更高。
加權輪詢是輪詢的一種特殊形式，其主要目的就是爲了解決不同服務器處理能力有差異的問題。例如，集羣中有新的機器是32核的，老的機器是16核的，那麼理論上我們可以假設新機器的處理能力是老機器的2倍，負載均衡系統就可以按照2:1的比例分配更多的任務給新機器，從而充分利用新機器的性能。
加權輪詢解決了輪詢算法中無法根據服務器的配置差異進行任務分配的問題，但同樣存在無法根據服務器的狀態差異進行任務分配的問題。
負載最低優先
負載均衡系統將任務分配給當前負載最低的服務器，這裏的負載根據不同的任務類型和業務場景，可以用不同的指標來衡量。例如：
-
LVS這種4層網絡負載均衡設備，可以以“連接數”來判斷服務器的狀態，服務器連接數越大，表明服務器壓力越大。
-
Nginx這種7層網絡負載系統，可以以“HTTP請求數”來判斷服務器狀態（Nginx內置的負載均衡算法不支持這種方式，需要進行擴展）。
-
如果我們自己開發負載均衡系統，可以根據業務特點來選擇指標衡量系統壓力。如果是CPU密集型，可以以“CPU負載”來衡量系統壓力；如果是I/O密集型，可以以“I/O負載”來衡量系統壓力。
負載最低優先的算法解決了輪詢算法中無法感知服務器狀態的問題，由此帶來的代價是複雜度要增加很多。例如：
-
最少連接數優先的算法要求負載均衡系統統計每個服務器當前建立的連接，其應用場景僅限於負載均衡接收的任何連接請求都會轉發給服務器進行處理，否則如果負載均衡系統和服務器之間是固定的連接池方式，就不適合採取這種算法。例如，LVS可以採取這種算法進行負載均衡，而一個通過連接池的方式連接MySQL集羣的負載均衡系統就不適合採取這種算法進行負載均衡。
-
CPU負載最低優先的算法要求負載均衡系統以某種方式收集每個服務器的CPU負載，而且要確定是以1分鐘的負載爲標準，還是以15分鐘的負載爲標準，不存在1分鐘肯定比15分鐘要好或者差。不同業務最優的時間間隔是不一樣的，時間間隔太短容易造成頻繁波動，時間間隔太長又可能造成峯值來臨時響應緩慢。
負載最低優先算法基本上能夠比較完美地解決輪詢算法的缺點，因爲採用這種算法後，負載均衡系統需要感知服務器當前的運行狀態。當然，其代價是複雜度大幅上升。通俗來講，輪詢可能是5行代碼就能實現的算法，而負載最低優先算法可能要1000行才能實現，甚至需要負載均衡系統和服務器都要開發代碼。
負載最低優先算法如果本身沒有設計好，或者不適合業務的運行特點，算法本身就可能成爲性能的瓶頸，或者引發很多莫名其妙的問題。所以負載最低優先算法雖然效果看起來很美好，但實際上真正應用的場景反而沒有輪詢（包括加權輪詢）那麼多。
性能最優類
負載最低優先類算法是站在服務器的角度來進行分配的，而性能最優優先類算法則是站在客戶端的角度來進行分配的，優先將任務分配給處理速度最快的服務器，通過這種方式達到最快響應客戶端的目的。
和負載最低優先類算法類似，性能最優優先類算法本質上也是感知了服務器的狀態，只是通過響應時間這個外部標準來衡量服務器狀態而已。因此性能最優優先類算法存在的問題和負載最低優先類算法類似，複雜度都很高，主要體現在：
-
負載均衡系統需要收集和分析每個服務器每個任務的響應時間，在大量任務處理的場景下，這種收集和統計本身也會消耗較多的性能。
-
爲了減少這種統計上的消耗，可以採取採樣的方式來統計，即不統計所有任務的響應時間，而是抽樣統計部分任務的響應時間來估算整體任務的響應時間。採樣統計雖然能夠減少性能消耗，但使得複雜度進一步上升，因爲要確定合適的採樣率，採樣率太低會導致結果不準確，採樣率太高會導致性能消耗較大，找到合適的採樣率也是一件複雜的事情。
-
無論是全部統計還是採樣統計，都需要選擇合適的週期：是10秒內性能最優，還是1分鐘內性能最優，還是5分鐘內性能最優……沒有放之四海而皆準的週期，需要根據實際業務進行判斷和選擇，這也是一件比較複雜的事情，甚至出現系統上線後需要不斷地調優才能達到最優設計。
Hash類
負載均衡系統根據任務中的某些關鍵信息進行Hash運算，將相同Hash值的請求分配到同一臺服務器上，這樣做的目的主要是爲了滿足特定的業務需求。例如：
-
源地址Hash
將來源於同一個源IP地址的任務分配給同一個服務器進行處理，適合於存在事務、會話的業務。例如，當我們通過瀏覽器登錄網上銀行時，會生成一個會話信息，這個會話是臨時的，關閉瀏覽器後就失效。網上銀行後臺無須持久化會話信息，只需要在某臺服務器上臨時保存這個會話就可以了，但需要保證用戶在會話存在期間，每次都能訪問到同一個服務器，這種業務場景就可以用源地址Hash來實現。
-
ID Hash
將某個ID標識的業務分配到同一個服務器中進行處理，這裏的ID一般是臨時性數據的ID（如session id）。例如，上述的網上銀行登錄的例子，用session id hash同樣可以實現同一個會話期間，用戶每次都是訪問到同一臺服務器的目的。