原文：Intro to Load Balancing for Developers – The Algorithms
posted on Tuesday, March 31, 2009 11:02 PM
- Random: This load balancing method randomly distributes load across the servers available, picking one via random number generation and sending the current connection to it. While it is available on many load balancing products, its usefulness is questionable except where uptime is concerned – and then only if you detect down machines.
- 隨機：此負載均衡算法在可用的服務器間隨機分發請求，通過生成隨機數隨機挑選一台服務器，並將當前連接發給它。系統對需要進行負載均衡的服務器建立一個數組（array），使用隨機數生成器來決定誰將獲得下一個連接。
Plain Programmer Description: The system builds an array of Servers being load balanced, and uses the random number generator to determine who gets the next connection… Far from an elegant solution, and most often found in large software packages that have thrown load balancing in as a feature.
- Round Robin: Round Robin passes each new connection request to the next server in line, eventually distributing connections evenly across the array of machines being load balanced. Round Robin works well in most configurations, but could be better if the equipment that you are load balancing is not roughly equal in processing speed, connection speed, and/or memory.
- 輪詢：將請求依次順序循環地分發給服務器，從1到N然后重新開始。此種均衡算法適合於服務器組中的所有服務器都有相同的軟硬件配置並且平均服務請求相對均衡的情況。
Plain Programmer Description: The system builds a standard circular queue and walks through it, sending one request to each machine before getting to the start of the queue and doing it again. While I’ve never seen the code (or actual load balancer code for any of these for that matter), we’ve all written this queue with the modulus function before. In school if nowhere else.
- Weighted Round Robin (called Ratio on the BIG-IP): With this method, the number of connections that each machine receives over time is proportionate to a ratio weight you define for each machine. This is an improvement over Round Robin because you can say “Machine 3 can handle 2x the load of machines 1 and 2”, and the load balancer will send two requests to machine #3 for each request to the others.
- 權重：根據服務器的不同處理能力，給每個服務器分配不同的權值，使其能夠接受相應權值數的服務請求。例如：服務器A的權值被設計成1，B的權值是3，C的權值是6，則服務器A、B、C將分別接受到10%、30％、60％的服務請求。此種均衡算法能確保高性能的服務器得到更多的使用率，避免低性能的服務器負載過重。
Plain Programmer Description: The simplest way to explain for this one is that the system makes multiple entries in the Round Robin circular queue for servers with larger ratios. So if you set ratios at 3:2:1:1 for your four servers, that’s what the queue would look like – 3 entries for the first server, two for the second, one each for the third and fourth. In this version, the weights are set when the load balancing is configured for your application and never change, so the system will just keep looping through that circular queue. Different vendors use different weighting systems – whole numbers, decimals that must total 1.0 (100%), etc. but this is an implementation detail, they all end up in a circular queue style layout with more entries for larger ratings.
- Dynamic Round Robin (Called Dynamic Ratio on the BIG-IP): is similar to Weighted Round Robin, however, weights are based on continuous monitoring of the servers and are therefore continually changing. This is a dynamic load balancing method, distributing connections based on various aspects of real-time server performance analysis, such as the current number of connections per node or the fastest node response time. This Application Delivery Controller method is rarely available in a simple load balancer.
- 動態比率：類似於權重，不過權重值是隨着對服務器持續的監控而變化的。這是一個動態的負載均衡算法，基於對服務器性能的實時分析，如連接數或響應時間。
Plain Programmer Description: If you think of Weighted Round Robin where the circular queue is rebuilt with new (dynamic) weights whenever it has been fully traversed, you’ll be dead-on.
- Fastest: The Fastest method passes a new connection based on the fastest response time of all servers. This method may be particularly useful in environments where servers are distributed across different logical networks. On the BIG-IP, only servers that are active will be selected.
- 最快模式：傳遞連接給那些響應速度最快的服務器。這種算法可能對於服務器處於不同的邏輯網絡中的情況特別有用。均衡器記錄着每個服務器的響應時間並選擇最快的那一個。這非常直接了當，但是可能會導致擁塞，因為當前的響應時間並不一定真的還是1s或是2s了。
- 解釋一下：最快模式算法是基於未完成的七層請求數來計算的。請求被發送到一個成員時，LTM將為它遞增一個計數器，當請求被響應后，再對計數器遞減。當LTM收到一個連接請求后，有最少的未完成請求的成員將被選擇。如果VS沒有關聯七層的Profile，LTM是不能追蹤請求和回應的，負載均衡算法將“降級”為最小連接數模式。
Plain Programmer Description: The load balancer looks at the response time of each attached server and chooses the one with the best response time. This is pretty straight-forward, but can lead to congestion because response time right now won’t necessarily be response time in 1 second or two seconds. Since connections are generally going through the load balancer, this algorithm is a lot easier to implement than you might think, as long as the numbers are kept up to date whenever a response comes through.
These next three I use the BIG-IP name for. They are variants of a generalized algorithm sometimes called Long Term Resource Monitoring.
- Least Connections: With this method, the system passes a new connection to the server that has the least number of current connections. Least Connections methods work best in environments where the servers or other equipment you are load balancing have similar capabilities. This is a dynamic load balancing method, distributing connections based on various aspects of real-time server performance analysis, such as the current number of connections per node or the fastest node response time. This Application Delivery Controller method is rarely available in a simple load balancer.
- 最小連接數：客戶端的每一次請求服務在服務器停留的時間可能會有較大的差異，隨着工作時間加長，如果采用簡單的輪循或隨機均衡算法，每一台服務器上的連接進程可能會產生極大的不同，並沒有達到真正的負載均衡。最少連接數均衡算法對內部中需負載的每一台服務器都有一個數據記錄，記錄當前該服務器正在處理的連接數量，當有新的服務連接請求時，將把當前請求分配給連接數最少的服務器，使均衡更加符合實際情況，負載更加均衡。此種均衡算法適合長時處理的請求服務，如FTP。
- 但是，像Fastest一樣，當連接時間不同時也可能導致擁塞——比如一個服務器正在處理簡單的HTML頁面，而另一個正在運行處理一堆數據庫查詢的JSP腳本，連接數就不太適合這種情況了。
Plain Programmer Description: This algorithm just keeps track of the number of connections attached to each server, and selects the one with the smallest number to receive the connection. Like fastest, this can cause congestion when the connections are all of different durations – like if one is loading a plain HTML page and another is running a JSP with a ton of database lookups. Connection counting just doesn’t account for that scenario very well.
- Observed: The Observed method uses a combination of the logic used in the Least Connections and Fastest algorithms to load balance connections to servers being load-balanced. With this method, servers are ranked based on a combination of the number of current connections and the response time. Servers that have a better balance of fewest connections and fastest response time receive a greater proportion of the connections. This Application Delivery Controller method is rarely available in a simple load balancer.
- 觀察模式：以連接數和響應時間這兩項的最佳平衡為依據來為新的請求選擇服務器。
Plain Programmer Description: This algorithm tries to merge Fastest and Least Connections, which does make it more appealing than either one of the above than alone. In this case, an array is built with the information indicated (how weighting is done will vary, and I don’t know even for F5, let alone our competitors), and the element with the highest value is chosen to receive the connection. This somewhat counters the weaknesses of both of the original algorithms, but does not account for when a server is about to be overloaded – like when three requests to that query-heavy JSP have just been submitted, but not yet hit the heavy work.
- Predictive: The Predictive method uses the ranking method used by the Observed method, however, with the Predictive method, the system analyzes the trend of the ranking over time, determining whether a servers performance is currently improving or declining. The servers in the specified pool with better performance rankings that are currently improving, rather than declining, receive a higher proportion of the connections. The Predictive methods work well in any environment. This Application Delivery Controller method is rarely available in a simple load balancer.
- 預測模式：預測模式使用和觀察模式一樣的評選方法，只不過BIGIP會利用收集到的服務器當前的性能指標（連接數和響應時間），進行預測分析，選擇一台服務器在下一個時間片內，其性能將達到最佳的服務器來響應用戶的請求。預測模式試圖修復在觀察模式中的一個問題，如果服務器的響應時間已經開始下滑，那么它是不太可能接受下一個請求的。
Plain Programmer Description: This method attempts to fix the one problem with Observed by watching what is happening with the server. If its response time has started going down, it is less likely to receive the packet. Again, no idea what the weightings are, but an array is built and the most desirable is chosen.
You can see with some of these algorithms that persistent connections would cause problems. Like Round Robin, if the connections persist to a server for as long as the user session is working, some servers will build a backlog of persistent connections that slow their response time. The Long Term Resource Monitoring algorithms are the best choice if you have a significant number of persistent connections. Fastest works okay in this scenario also if you don’t have access to any of the dynamic solutions.
你可以看到，有些算法遇到長連接可能會導致問題。像是輪詢，如果長連接保持用戶會話那么久，當連接數積壓到一定值時會導致服務器響應時間變慢。如果你有大量的長連接，LTRM（ Long Term Resource Monitoring ）算法是最好的選擇。如果沒有動態的解決方案，Fastest算法也比較適合這種場景。