负载均衡 均衡算法选择与权重配置实例 - 最佳实践

负载均衡算法比较分析

加权轮询算法 Weighted Round-Robin Scheduling

• 原理
  轮叫调度算法就是以轮叫的方式依次将请求调度不同的服务器，即每次调度执行 i = (i + 1) mod n，选出第 i 台服务器。加权轮叫调度算法可以解决服务器间性能不一的情况，它用相应的权值表示服务器的处理性能，按权值的高低和轮叫方式分配请求到各服务器。权值高的服务器先收到的连接，权值高的服务器比权值低的服务器处理更多的连接，相同权值的服务器处理相同数目的连接数。
• 优势
  算法的优点是其简洁性，和实用性。它无需记录当前所有连接的状态，所以它是一种无状态调度。
• 劣势
  加权轮叫调度算法相对简单，但不适用于请求服务时间变化比较大，或者每个请求所消耗的时间不一致的情况，此时轮叫调度算法容易导致服务器间的负载不平衡。
• 适用场景
  每个请求所占用的后端时间基本相同，负载情况最好。常用于短连接服务，例如 HTTP 等服务。
• 用户推荐
  用户可知每个请求所占用后端时间基本相同时，如已知rs处理的都是同类型或者相似类型的请求时，推荐选择加权轮询的方式。当请求时间相差较小时也推荐使用加权轮询的方式，因为该实现方式消耗小，无需遍历，效率较高。

加权最小连接数 Weighted Least-Connection Scheduling

• 原理
  在实际情况中，客户端的每一次请求服务在服务器停留的时间可能会有较大的差异，随着工作时间的延伸，如果采用简单的轮询或随机均衡算法，每一台服务器上的连接进程数目可能会产生极大的不同，这样实际上并没有达到真正的负载均衡。最小连接调度是一种动态调度算法，它通过服务器当前所活跃的连接数来评估服务器的负载情况。与轮询调度算法相反。调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1；当连接中止或超时，其连接数减一。权重最少连接数调度算法是在最少连接数调度算法的基础上，根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求，是在最少连接数调度算法的基础上的改进。
  1. 假设各台 rs 的权值依次为 wi,当前连接数依次为 ci，依次计算 ci/wi，值最小的 rs 作为下一个分配的 rs。
  2. 如果存在 ci/wi 相同的 rs，这些 rs 再使用加权轮询的方式调度
• 优势
  此种均衡算法适合长时处理的请求服务，如FTP等应用。
• 劣势
  由于接口限制，目前最小连接数和会话保持功能不能同时开启。
• 适用场景
  每个请求所占用的后端时间相差较大的场景。常用于长连接服务。
• 用户推荐
  如果用户需要处理不同的请求，且请求所占用后端时间相差较大，如3ms和3s这种数量级的差距时，推荐使用加权最小连接数算法实现负载均衡。

源地址散列调度算法 ip_hash

• 原理
  根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
• 优势
  ip_hash 可以实现部分会话保持的效果，能够记住源 IP，使某一 client 请求通过 hash 表一直映射在同一台 rs 上。因此在不支持会话保持的场景可以使用 ip_hash 进行调度。
• 用户推荐
  将请求的源地址进行hash运算，并结合后端的服务器的权重派发请求至某匹配的服务器，这可以使得同一个客户端 IP的请求始终被派发至某特定的服务器。该方式适合负载均衡无 cookie 功能的 TCP 协议。

均衡算法选取及权重配置实例

在负载均衡即将发布的新功能中，七层转发将支持最小连接数的均衡方式，为了让用户在不同场景下，能够让 RS 集群稳定的承接业务，因此我们给出几个负载均衡选择与权重配置的实例供用户进行参考。

• 场景1
  设有3台配置相同（CPU / 内存）的 RS，由于性能一致，用户可以将 RS 权重都设置为10。设现在每台 RS 与 client 端建立了100个 TCP 连接，此时新增1台 RS。在此场景下，推荐用户使用最小连接数的均衡方式，这种配置能快速的让第四台 RS 的负载提升，降低另外3台 RS 的压力。
• 场景2
  设用户首次接触云服务，且建站时间不长，网站负载较低，则建议购买相同配置的 RS，因此 RS 都是无差别的接入层服务器。在此场景下，用户可以将 RS 权重都设为10，采用加权轮询的均衡方式进行流量分发。
• 场景3
  用户有5台服务器，用与承载简单的静态网站访问，且5台服务器的计算能力的比例为 9：3：3：3：1（按 CPU、内存换算）。在此场景下，用户可以依次将 RS 权重比例设置为90，30，30，30，10，由于静态网站访问大多数是短连接请求，因此可以采用加权轮询的均衡方式，让 CLB 按 RS 的性能比例分配请求。
• 场景4
  某用户有10台 RS 用于承担海量的 Web 访问请求，且不希望多购置 RS 增加支出。 某台 RS 经常会因为负载过高，导致服务器重启。在此场景下，建议用户根据 RS 的性能进行相应的权重设置，给负载过高的 RS 设置较小的权值。除此之外，可以采用最小连接数的负载均衡方式，将请求分配到活跃连接数较少的 RS 上，从而解决某台 RS 负载过高的问题。
• 场景5
  某用户有3台 RS 用于处理若干长连接请求，且这3台服务器的计算能力比例为3：1：1（按 CPU、内存换算）。 此时性能最好的服务器处理请求较多，用户不希望过载此服务器，希望能够将新的请求分配到空闲服务器上。在此场景下，可以采用最小连接数的均衡方式，并适当降低繁忙服务器的权重，便于 CLB 将请求分配到活跃数较少的 RS 上，实现负载均衡。
• 场景6
  某用户希望后续客户端的请求可以分配到同一服务器上。而采用加权轮询或加权最小连接数的方式，不能保证相同客户端的请求被分到固定某台服务器上去。为了配合客户特定应用程序服务器的需求，保证客户端的会话具有“粘性”或是“持续性”，在此场景下，我们可以采用 ip_hash 的均衡方式进行流量分发。此方法可以确保来自同一客户端的请求总被定向分发到同一 RS 上去。（服务器数量变化或是该服务器不可用时除外）