轮询方式

轮询方式是指负载均衡向后端服务器分配流量的算法，根据不同的轮询方式及后端服务器的权重设置，可以达到不同的效果。

加权轮询算法（Weighted Round-Robin Scheduling）

加权轮询算法就是以轮叫的方式依次将请求调度不同的服务器。加权轮询调度算法可以解决服务器间性能不一的情况，它用相应的权值表示服务器的处理性能，按权值的高低和轮询方式分配请求到各服务器。权值高的服务器先收到连接，权值高的服务器比权值低的服务器处理更多的连接，相同权值的服务器处理相同数目的连接数。

• 优势

  算法的优点是其简洁性和实用性。它无需记录当前所有连接的状态，所以它是一种无状态调度。

• 劣势

  加权轮询调度算法相对简单，但不适用于请求服务时间变化比较大，或者每个请求所消耗的时间不一致的情况，此时轮询调度算法容易导致服务器间的负载不平衡。

• 适用场景

  每个请求所占用的后端时间基本相同，负载情况最好。常用于短连接服务，例如 HTTP 等服务。

• 用户推荐

  用户可知每个请求所占用后端时间基本相同时，如已知后端服务器处理的都是同类型或者相似类型的请求时，推荐选择加权轮询的方式。当请求时间相差较小时也推荐使用加权轮询的方式，因为该实现方式消耗小，无需遍历，效率较高。

加权最小连接数算法（Weighted Least-Connection Scheduling）

在实际情况中，客户端的每一次请求服务在服务器停留的时间可能会有较大的差异，随着工作时间的延伸，如果采用简单的轮询或随机均衡算法，每一台服务器上的连接进程数目可能会产生极大的不同，这样实际上并没有达到真正的负载均衡。

最小连接调度是一种动态调度算法，它通过服务器当前所活跃的连接数来估计服务器的负载情况。与轮询调度算法相反，最小连接调度是一种动态调度算法，它通过服务器当前所活跃的连接数来估计服务器的负载情况。调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加一; 当连接中止或超时，其连接数减一。

权重最小连接数调度算法是在最小连接数调度算法的基础上，根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求，是在最小连接数调度算法的基础上的改进。

1) 假设各台后端服务器的权值依次为 wi，当前连接数依次为 ci,依次计算 ci/wi,值最小的后端服务器实例作为下一个分配的实例。

2) 如果存在 ci/wi 相同的后端服务器实例，再使用加权轮训的方式调度。

• 优势

  此种均衡算法适合长时处理的请求服务，如 FTP 等应用。

• 劣势

  由于接口限制，目前最小连接数和会话保持功能不能同时开启。

• 适用场景

  每个请求所占用的后端时间相差较大的场景。常用于长连接服务。

• 用户推荐

  如果用户需要处理不同的请求，且请求所占用后端时间相差较大，如 3 ms 和 3s 这种数量级的差距时，推荐使用加权最小连接数算法实现负载均衡。

源地址散列调度算法（ip_hash）

根据请求的源 IP 地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

• 优势

  可以使某一客户端的请求通过哈希表一直映射在同一台后端服务器上。因此在不支持会话保持的场景可以使用 ip_hash 进行简单的会话保持实现。

• 用户推荐

  将请求的源地址进行哈希运算，并结合后端的服务器的权重派发请求至某匹配的服务器，这可以使得同一个客户端 IP 的请求始终被派发至某特定的服务器。该方式适合无 cookie 功能的 TCP 协议。

均衡算法选取及权重配置

为了让用户在不同场景下能够让后端服务器集群稳定地承接业务，我们给出几个负载均衡选择与权重配置的实例供用户进行参考。

• 场景1

  设有3台配置相同（CPU / 内存）的后端服务器，由于性能一致，用户可以将后端服务器权重都设置为10。现在每台后端服务器与客户端端建立了 100 个 TCP 链接，此时新增 1 台后端服务器。在此场景下，推荐用户使用最小连接数的均衡方式，这种配置能快速的让第四台后端服务器的负载提升，降低另外 3 台后端服务器的压力。 　　

• 场景2

  设用户首次接触云服务，且建站时间不长，网站负载较低，则建议购买相同配置的后端服务器，因此后端服务器都是无差别的接入层服务器。在此场景下，用户可以将后端服务器权重都设为默认值 10，采用加权轮询的均衡方式进行流量分发。

• 场景3

  用户有 5 台服务器，用于承载简单的静态网站访问，且 5 台服务器的计算能力的比例为 9：3：3：3：1（按CPU、内存换算）。在此场景下，用户可以依次将后端服务器权重比例设置为 90、30、30、30、和 10，由于静态网站访问大多数是短连接请求，因此可以采用加权轮询的均衡方式，让负载均衡实例按后端服务器的性能比例分配请求。

• 场景4

  某用户有 10 台后端服务器用于承担海量的 Web 访问请求，且不希望多购置后端服务器增加支出。某台后端服务器经常会因为负载过高，导致服务器重启。在此场景下，建议用户根据后端服务器的性能进行相应的权重设置，给负载过高的后端服务器设置较小的权值。除此之外，可以采用最小连接数的负载均衡方式，将请求分配到活跃连接数较少的后端服务器上，从而解决某台后端服务器负载过高的问题。 　　

• 场景5

  某用户有 3 台后端服务器用于处理若干长连接请求，且这 3 台服务器的计算能力比例为 3：1：1（按CPU、内存换算）。此时性能最好的服务器处理请求较多，用户不希望过载此服务器，希望能够将新的请求分配到空闲服务器上。在此场景下，可以采用最小连接数的均衡方式，并适当降低繁忙服务器的权重，便于负载均衡将请求分配到活跃数较少的后端服务器上，实现负载均衡。

• 场景6

  某用户希望后续客户端的请求可以分配到同一服务器上。而采用 加权轮询 或 加权最小连接数 的方式，不能保证相同客户端的请求被分到固定某台服务器上去。为了配合客户特定应用程序服务器的需求，保证客户端的会话具有“粘性”或是“持续性”，在此场景下，我们可以采用 ip_hash 的均衡方式进行流量分发。此方法可以确保来自同一客户端的请求总被定向分发到同一后端服务器上去。（服务器数量变化或是该服务器不可用时除外）