均衡方式是负载均衡向 后端服务器 分配流量的算法，根据不同的均衡方式可以达到不同的均衡效果。 加权轮询算法
加权轮询算法（Weighted Round-Robin Scheduling）是以轮叫的方式、依次请求调度不同的服务器。加权轮询调度算法可以解决服务器间性能不一的情况，它用相应的权值表示服务器的处理性能，按权值的高低和轮询方式分配请求到各服务器。加权轮询算法根据新建连接数来调度，权值高的服务器先收到连接，权重值越高被轮询到的次数（概率）也越高，相同权值的服务器处理相同数目的连接数。
优势：简洁实用，无需记录当前所有连接的状态，是一种无状态调度。
劣势：相对简单，在请求服务时间变化较大或每个请求消耗时间不一致的情况下，容易导致服务器间的负载不平衡。
适用场景：当每个请求所占用的后端时间基本相同时，负载情况最好。常用于短连接服务，例如 HTTP 等。
用户推荐：已知每个请求所占用后端时间基本相同、后端服务器处理的请求类型相同或者相似时，推荐您选择加权轮询的方式。请求时间相差较小时，也推荐您使用加权轮询的方式，因为该实现方式消耗小，无需遍历，效率较高。
加权最小连接数算法
在实际情况中，客户端的请求服务在服务器停留的时间会有较大的差异。随着工作时间的延伸，采用简单的轮询或随机均衡算法，每台服务器上的连接进程数目可能会有极大的不同，导致没有达到真正的负载均衡。
最小连接调度是一种动态调度算法，与轮询调度算法相反，它通过服务器当前所活跃的连接数来估计服务器的负载情况。调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器时，其连接数加一；当连接中止或超时，其连接数减一。
加权最小连接数算法（Weighted Least-Connection Scheduling）是在最小连接数调度算法的基础上，根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求，是在最小连接数调度算法的基础上的改进。
说明：
假设各台后端服务器的权值依次为 wi，当前连接数依次为 ci，依次计算 ci/wi,值最小的后端服务器实例作为下一个分配的实例。如果存在 ci/wi 相同的后端服务器实例，再使用加权轮询的方式调度。
优势：此算法适合长时处理的请求服务，如 FTP 等应用。
劣势：由于接口限制，目前最小连接数和会话保持功能不能同时开启。
适用场景：每个请求所占用的后端时间相差较大的场景。常用于长连接服务。
用户推荐：如果用户需要处理不同的请求，且请求所占用后端时间相差较大，如3ms和3s等数量级差距，推荐使用加权最小连接数算法，实现负载均衡。
源地址散列调度算法
源地址散列调度算法（ip_hash）根据请求的源 IP 地址，使用散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器为可用且未超载状态，则请求发送到该服务器，反之则返回空。
优势：可以使某一客户端的请求通过哈希表一直映射在同一台后端服务器上，在不支持会话保持的场景中，可以使用 ip_hash 实现简单的会话保持。
用户推荐：将请求的源地址进行哈希运算，并结合您所设置的后端服务器权重，派发请求至某匹配的服务器，使得同一客户端 IP 的请求始终被派发至某特定的服务器。该方式适合无 Cookie 功能的协议。
均衡算法选取及权重配置
为了让用户在不同场景下实现后端服务器集群稳定地承接业务，下文将给出负载均衡选择与权重配置的场景示例，供您参考。
场景1：
1.1 假设有3台配置相同（CPU/内存）的后端服务器，由于性能一致，可以将后端服务器权重都设置为10。
1.2 现在每台后端服务器与客户端建立了100个 TCP 连接，并新增1台后端服务器。
1.3 在此场景下，推荐使用最小连接数均衡方式，能快速实现第4台后端服务器的负载提升，降低另外3台后端服务器的压力。
场景2：
1.1 假设您首次接触云服务，且建站时间不长，网站负载较低，建议购买相同配置的后端服务器，此时后端服务器都是无差别的接入层服务器。
1.2 在此场景下，可以将后端服务器权重都设为默认值10，采用加权轮询的均衡方式进行流量分发。
场景3：
1.1 假设您有5台服务器，用于承载简单的静态网站访问，且5台服务器的计算能力的比例为 9：3：3：3：1（按 CPU、内存换算）。
1.2 在此场景下，可以依次将后端服务器权重比例设置为90、30、30、30、和10。静态网站访问大多数是短连接请求，因此，可以采用加权轮询的均衡方式，让负载均衡实例按后端服务器的性能比例分配请求。
场景4：
1.1 假设您有10台后端服务器，用于承担海量的 Web 访问请求，且不希望多购置后端服务器增加支出，但某台后端服务器经常会因为负载过高，导致服务器重启。
1.2 在此场景下，建议根据后端服务器的性能进行相应的权重设置，为负载过高的后端服务器设置较小的权值。此外，可以采用最小连接数的负载均衡方式，将请求分配到活跃连接数较少的后端服务器上，从而解决某台后端服务器负载过高的问题。
场景5：
1.1 假设您有3台后端服务器，用于处理若干长连接请求，且这3台服务器的计算能力比例为 3：1：1（按 CPU、内存换算）。
1.2 此时性能最好的服务器处理请求较多，您不希望过载此服务器，欲将新的请求分配到空闲服务器上。
1.3 在此场景下，可以采用最小连接数的均衡方式，并适当降低繁忙服务器的权重，便于负载均衡将请求分配到活跃数较少的后端服务器上，实现负载均衡。
场景6：
1.1 假设您希望后续客户端的请求可以分配到同一服务器上。此时，采用加权轮询或加权最小连接数的方式，不能保证相同客户端的请求被分到固定服务器上。
1.2 为了配合特定应用程序服务器的需求，保证客户端的会话具有“粘性”或“持续性”。在此场景下，可以采用 ip_hash 的均衡方式进行流量分发，可以确保来自同一客户端的请求总被定向分发到同一后端服务器上（服务器数量变化或该服务器不可用时除外）。