[[122758]]

負載主機可以提供很多種負載均衡方法，也就是我們常說的調度方法或算法：

輪循(Round Robin)

這種方法會將收到的請求循環分配到服務器集群中的每臺機器，即有效服務器。如果使用這種方式，所有的標記進入虛擬服務的服務器應該有相近的資源容量以及負載形同的應用程序。如果所有的服務器有相同或者相近的性能那么選擇這種方式會使服務器負載形同。基于這個前提，輪循調度是一個簡單而有效的分配請求的方式。然而對于服務器不同的情況，選擇這種方式就意味著能力比較弱的服務器也會在下一輪循環中接受輪循，即使這個服務器已經不能再處理當前這個請求了。這可能導致能力較弱的服務器超載。

加權輪循(Weighted Round Robin)

這種算法解決了簡單輪循調度算法的缺點：傳入的請求按順序被分配到集群中服務器，但是會考慮提前為每臺服務器分配的權重。管理員只是簡單的通過服務器的處理能力來定義各臺服務器的權重。例如，能力***的服務器A給的權重是100，同時能力***的服務器給的權重是50。這意味著在服務器B接收到***個請求之前前，服務器A會連續的接受到2個請求，以此類推。

最少連接數(Least Connection)

以上兩種方法都沒有考慮的是系統不能識別在給定的時間里保持了多少連接。因此可能發生，服務器B服務器收到的連接比服務器A少但是它已經超載，因為服務器B上的用戶打開連接持續的時間更長。這就是說連接數即服務器的負載是累加的。這種潛在的問題可以通過“最少連接數”算法來避免：傳入的請求是根據每臺服務器當前所打開的連接數來分配的。即活躍連接數最少的服務器會自動接收下一個傳入的請求。接本上和簡單輪詢的原則相同：所有擁有虛擬服務的服務器資源容量應該相近。值得注意的是，在流量率低的配置環境中，各服務器的流量并不是相同的，會優先考慮***臺服務器。這是因為，如果所有的服務器是相同的，那么***個服務器優先，直到***臺服務器有連續的活躍流量，否則總是會優先選擇***臺服務器。

最少連接數慢啟動時間(Least Connection Slow Start Time)

對最少連接數和帶權重的最小連接數調度方法來說，當一個服務器剛加入線上環境是，可以為其配置一個時間段，在這段時間內連接數是有限制的而且是緩慢增加的。這為服務器提供了一個‘過渡時間’以保證這個服務器不會因為剛啟動后因為分配的連接數過多而超載。這個值在L7配置界面設置。

加權最少連接(Weighted Least Connection)

如果服務器的資源容量各不相同，那么“加權最少連接”方法更合適：由管理員根據服務器情況定制的權重所決定的活躍連接數一般提供了一種對服務器非常平衡的利用，因為他它借鑒了最少連接和權重兩者的優勢。通常，這是一個非常公平的分配方式，因為它使用了連接數和服務器權重比例;集群中比例***的服務器自動接收下一個請求。但是請注意，在低流量情況中使用這種方法時，請參考“最小連接數”方法中的注意事項。

基于代理的自適應負載均衡(Agent Based Adaptive Balancing)

除了上述方法之外，負載主機包含一個自適用邏輯用來定時監測服務器狀態和該服務器的權重。對于非常強大的“基于代理的自適應負載均衡”方法來說，負載主機以這種方式來定時檢測所有服務器負載情況：每臺服務器都必須提供一個包含文件，這個文件包含一個0~99的數字用來標明改服務器的實際負載情況(0=***，99=超載，101=失敗，102=管理員禁用)，而服務器同構http get方法來獲取這個文件;同時對集群中服務器來說，以二進制文件形式提供自身負載情況也是該服務器工作之一，然而，并沒有限制服務器如何計算自身的負載情況。根據服務器整體負載情況，有兩種策略可以選擇：在常規的操作中，調度算法通過收集的服務器負載值和分配給該服務器的連接數的比例計算出一個權重比例。因此，如果一個服務器負載過大，權重會通過系統透明的作重新調整。和加權輪循調度方法一樣，不正確的分配可以被記錄下來使得可以有效的為不同服務器分配不同的權重。然而，在流量非常低的環境下，服務器報上來的負載值將不能建立一個有代表性的樣本;那么基于這些值來分配負載的話將導致失控以及指令震蕩。因此，在這種情況下更合理的做法是基于靜態的權重比來計算負載分配。當所有服務器的負載低于管理員定義的下限時，負載主機就會自動切換為加權輪循方式來分配請求;如果負載大于管理員定義的下限，那么負載主機又會切換回自適應方式。

固定權重(Fixed Weighted)

***權重只有在其他服務器的權重值都很低時才使用。然而，如果***權重的服務器下降，則下一個***優先級的服務器將為客戶端服務。這種方式中每個真實服務器的權重需要基于服務器優先級來配置。

加權響應(Weighted Response)

流量的調度是通過加權輪循方式。加權輪循中所使用的權重是根據服務器有效性檢測的響應時間來計算。每個有效性檢測都會被計時，用來標記它響應成功花了多長時間。但是需要注意的是，這種方式假定服務器心跳檢測是基于機器的快慢，但是這種假設也許不總是能夠成立。所有服務器在虛擬服務上的響應時間的總和加在一起，通過這個值來計算單個服務物理服務器的權重;這個權重值大約每15秒計算一次。

源IP哈希(Source IP Hash)

這種方式通過生成請求源IP的哈希值，并通過這個哈希值來找到正確的真實服務器。這意味著對于同一主機來說他對應的服務器總是相同。使用這種方式，你不需要保存任何源IP。但是需要注意，這種方式可能導致服務器負載不平衡。