前言
負載均衡演算法數量較多，而且可以根據一些業務特性進行定製開發，拋開細節上的差異，根據演算法期望達到的目的，大體上可以分為下面幾類。
任務平分類：負載均衡系統將收到的任務平均分配給伺服器進行處理，這裡的「平均」可以是絕對數量的平均，也可以是比例或者權重上的平均。
負載均衡類：負載均衡系統根據伺服器的負載來進行分配，這裡的負載並不一定是通常意義上我們說的「cpu 負載」，而是系統當前的壓力，可以用cpu 負載來衡量，也可以用連線數、 i/o 使用率、網絡卡吞吐量等來衡量系統的壓力。
效能最優類：負載均衡系統根據伺服器的響應時間來進行任務分配，優先將新任務分配給響應最快的伺服器。
hash 類：負載均衡系統根據任務中的某些關鍵資訊進行 hash 運算，將相同hash 值的請求分配到同一臺伺服器上。常見的有源位址 hash、目標位址hash、 session id hash、使用者 id hash 等。
接下來我介紹一下負載均衡演算法以及它們的優缺點。
輪詢加權輪詢
負載均衡系統根據伺服器權重進行任務分配，這裡的權重一般是根據硬體配置進行靜態配置的，採用動態的方式計算會更加契合業務，但複雜度也會更高。
加權輪詢是輪詢的一種特殊形式，其主要目的就是為了解決不同伺服器處理能力有差異的問題。例如，集群中有新的機器是 32 核的，老的機器是 16 核的，那麼理論上我們可以假設新機器的處理能力是老機器的 2 倍，負載均衡系統就可以按照 2:1 的比例分配更多的任務給新機器，從而充分利用新機器的效能。加權輪詢解決了輪詢演算法中無法根據伺服器的配置差異進行任務分配的問題，但同樣存在無法根據伺服器的狀態差異進行任務分配的問題。
負載最低優先
負載均衡系統將任務分配給當前負載最低的伺服器，這裡的負載根據不同的任務型別和業務場景，可以用不同的指標來衡量。例如：
1、 lvs 這種 4 層網路負載均衡裝置，可以以「連線數」來判斷伺服器的狀態，伺服器連線數越大，表明伺服器壓力越大。
2、 nginx 這種 7 層網路負載系統，可以以「http 請求數」來判斷伺服器狀態（nginx 內建的負載均衡演算法不支援這種方式，需要進行擴充套件）。
3、如果我們自己開發負載均衡系統，可以根據業務特點來選擇指標衡量系統壓力。如果是 cpu 密集型，可以以「cpu 負載」來衡量系統壓力；如果是 i/o密集型，可以以「i/o 負載」來衡量系統壓力。
負載最低優先的演算法解決了輪詢演算法中無法感知伺服器狀態的問題，由此帶來的代價是複雜度要增加很多。例如：
1、 最少連線數優先的演算法要求負載均衡系統統計每個伺服器當前建立的連線，其應用場景僅限於負載均衡接收的任何連線請求都會**給伺服器進行處理，否則如果負載均衡系統和伺服器之間是固定的連線池方式，就不適合採取這種演算法。例如，lvs 可以採取這種演算法進行負載均衡，而乙個通過連線池的方式連線 mysql 集群的負載均衡系統就不適合採取這種演算法進行負載均衡。
2、 cpu 負載最低優先的演算法要求負載均衡系統以某種方式收集每個伺服器的cpu 負載，而且要確定是以 1 分鐘的負載為標準，還是以 15 分鐘的負載為標準，不存在 1 分鐘肯定比 15 分鐘要好或者差。不同業務最優的時間間隔是不一樣的，時間間隔太短容易造成頻繁波動，時間間隔太長又可能造成峰值來臨時響應緩慢。
負載最低優先演算法基本上能夠比較完美地解決輪詢演算法的缺點，因為採用這種演算法後，負載均衡系統需要感知伺服器當前的執行狀態。當然，其代價是複雜度大幅上公升。通俗來講，輪詢可能是 5 行**就能實現的演算法，而負載最低優先演算法可能要 1000 行才能實現，甚至需要負載均衡系統和伺服器都要開發**。負載最低優先演算法如果本身沒有設計好，或者不適合業務的執行特點，演算法本身就可能成為效能的瓶頸，或者引發很多莫名其妙的問題。所以負載最低優先演算法雖然效果看起來很美好，但實際上真正應用的場景反而沒有輪詢（包括加權輪詢）那麼多。
效能最優類
負載最低優先類演算法是站在伺服器的角度來進行分配的，而效能最優優先類演算法則是站在客戶端的角度來進行分配的，優先將任務分配給處理速度最快的伺服器，通過這種方式達到最快響應客戶端的目的。
和負載最低優先類演算法類似，效能最優優先類演算法本質上也是感知了伺服器的狀態，只是通過響應時間這個外部標準來衡量伺服器狀態而已。因此效能最優優先類演算法存在的問題和負載最低優先類演算法類似，複雜度都很高，主要體現在：
1、 負載均衡系統需要收集和分析每個伺服器每個任務的響應時間，在大量任務處理的場景下，這種收集和統計本身也會消耗較多的效能。
2、 為了減少這種統計上的消耗，可以採取取樣的方式來統計，即不統計所有任務的響應時間，而是抽樣統計部分任務的響應時間來估算整體任務的響應時間。取樣統計雖然能夠減少效能耗，但使得複雜度進一步上公升，因為要確定合適的取樣率，取樣率太低會導致結果不準確，取樣率太高會導致效能消耗較大，找到合適的取樣率也是一件複雜的事情。
3、 無論是全部統計還是取樣統計，都需要選擇合適的週期：是 10 秒內效能最優，還是 1 分鐘內效能最優，還是 5 分鐘內效能最優……沒有放之四海而皆準的週期，需要根據實際業務進行判斷和選擇，這也是一件比較複雜的事情，甚至出現系統上線後需要不斷地調優才能達到最優計。
hash 類
負載均衡系統根據任務中的某些關鍵資訊進行 hash 運算，將相同 hash 值的請求分配到同一臺伺服器上，這樣做的目的主要是為了滿足特定的業務需求。例如：
1、 源位址 hash
將**於同乙個源 ip 位址的任務分配給同乙個伺服器進行處理，適合於存在事務、會話的業務。例如，當我們通過瀏覽器登入網上銀行時，會生成乙個會話資訊，這個會話是臨時的，關閉瀏覽器後就失效。網上銀行後台無須持久化會話資訊，只需要在某台伺服器上臨時儲存這個會話就可以了，但需要保證使用者在會話存在期間，每次都能訪問到同乙個伺服器，這種業務場景就可以用源位址 hash 來實現。
2、 id hash
將某個 id 標識的業務分配到同乙個伺服器中進行處理，這裡的 id 一般是臨時性資料的 id（如 session id）。例如，上述的網上銀行登入的例子，用 sessionid hash 同樣可以實現同乙個會期間，使用者每次都是訪問到同一臺伺服器的目的。
高效能負載均衡之演算法
昨天說的是高效能負載均衡之分類架構 今天的內容可以說是昨天的擴充套件和補充，主要跟大家講將高效能負載均衡的演算法，高效能負載均衡演算法數量也不少，而且可以根據一些業務特性進行定製開發，拋開細節上的差異，根據演算法期望達到的目的，大體可以分為這麼幾類 1 任務平分類 負載均衡系統將接收到的任務平均分配...
Nginx Tomcat搭建高效能負載均衡集群
nginx 1.8.0 apache tomcat 6.0.33 實現高效能負載均衡的tomcat集群 2 然後解壓兩個tomcat，分別命名為apache tomcat 6.0.33 1和apache tomcat 6.0.33 2 3 然後修改這兩個tomcat的啟動埠，分別為18080和280...
Nginx Tomcat搭建高效能負載均衡集群
nginx 1.8.0 apache tomcat 6.0.33 實現高效能負載均衡的tomcat集群 2 然後解壓兩個tomcat，分別命名為apache tomcat 6.0.33 1和apache tomcat 6.0.33 2 3 然後修改這兩個tomcat的啟動埠，分別為18080和280...