随机：此负载均衡算法在可用的服务器间随机分发请求，通过生成随机数随机挑选一台服务器，并将当前连接发给它。系统对需要进行负载均衡的服务器建立一个数组（array），使用随机数生成器来决定谁将获得下一个连接。
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.
轮询：将请求依次顺序循环地分发给服务器，从1到N然后重新开始。此种均衡算法适合于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。
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.
权重：根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。例如：服务器A的权值被设计成1，B的权值是3，C的权值是6，则服务器A、B、C将分别接受到10%、30％、60％的服务请求。此种均衡算法能确保高性能的服务器得到更多的使用率，避免低性能的服务器负载过重。
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.
动态比率：类似于权重，不过权重值是随着对服务器持续的监控而变化的。这是一个动态的负载均衡算法，基于对服务器性能的实时分析，如连接数或响应时间。
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.
最快模式：传递连接给那些响应速度最快的服务器。这种算法可能对于服务器处于不同的逻辑网络中的情况特别有用。均衡器记录着每个服务器的响应时间并选择最快的那一个。这非常直接了当，但是可能会导致拥塞，因为当前的响应时间并不一定真的还是1s或是2s了。
解释一下：最快模式算法是基于未完成的七层请求数来计算的。请求被发送到一个成员时，LTM将为它递增一个计数器，当请求被响应后，再对计数器递减。当LTM收到一个连接请求后，有最少的未完成请求的成员将被选择。如果VS没有关联七层的Profile，LTM是不能追踪请求和回应的，负载均衡算法将“降级”为最小连接数模式。
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.
最小连接数：客户端的每一次请求服务在服务器停留的时间可能会有较大的差异，随着工作时间加长，如果采用简单的轮循或随机均衡算法，每一台服务器上的连接进程可能会产生极大的不同，并没有达到真正的负载均衡。最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录，记录当前该服务器正在处理的连接数量，当有新的服务连接请求时，将把当前请求分配给连接数最少的服务器，使均衡更加符合实际情况，负载更加均衡。此种均衡算法适合长时处理的请求服务，如FTP。
但是，像Fastest一样，当连接时间不同时也可能导致拥塞——比如一个服务器正在处理简单的HTML页面，而另一个正在运行处理一堆数据库查询的JSP脚本，连接数就不太适合这种情况了。
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.
观察模式：以连接数和响应时间这两项的最佳平衡为依据来为新的请求选择服务器。
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.
预测模式：预测模式使用和观察模式一样的评选方法，只不过BIGIP会利用收集到的服务器当前的性能指标（连接数和响应时间），进行预测分析，选择一台服务器在下一个时间片内，其性能将达到最佳的服务器来响应用户的请求。预测模式试图修复在观察模式中的一个问题，如果服务器的响应时间已经开始下滑，那么它是不太可能接受下一个请求的。
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.
你可以看到，有些算法遇到长连接可能会导致问题。像是轮询，如果长连接保持用户会话那么久，当连接数积压到一定值时会导致服务器响应时间变慢。如果你有大量的长连接，LTRM（ Long Term Resource Monitoring ）算法是最好的选择。如果没有动态的解决方案，Fastest算法也比较适合这种场景。
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.