NGINX 均衡

这里只说均衡, 没有说负载

为了调优那个 Throttle , 我绞尽了脑汁, 各种状况层出不穷. 最典型的一个问题: 运行一段时间后, Throttle 的计数增加的慢了, 但是服务器 CPU 都是空闲的, Redis 毫无压力. 用性能计数器查看站点的连接数, 发现所有的请求都打到了一个站点上去了.

对NGINX 的了解基本等于空白, 配置就是照抄已有的项目...

upstream xxx{
    server 10.89.70.22:8001;
    server 10.89.70.22:8002;
    server 10.89.70.22:8003;
    server 10.89.70.22:8004;
    server 10.89.70.22:8005;
    server 10.89.70.22:8016;
    server 10.89.70.22:8017;
}

可以看到这里只是配置了"负载", 并没有指定如何使它"均衡".

今天特意翻翻了 NG的文档, 找到了怎么配置"均衡":
HTTP Load Balancing

NG 有6种均衡方案:

Round Robin

请求在服务器之间平均分配，同时考虑了服务器权重。 默认情况下使用此方法（没有启用它的指令）, 我上面的配置就是属于这个...

Least Connections

跟据权重, 把请求发到连接数最少的那个上去. 指令是 least_conn;

upstream backend {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
}

IP Hash

就是跟据请求的IP来定向. 指令 ip_hash;

Generic Hash

这个应该是自定义 HASH ,

upstream backend {
    hash $request_uri consistent;
    server backend1.example.com;
    server backend2.example.com;
}

上面的例子应该是取 url 中的 consistent 参数来计算 hash. 不了解, 不置喙。

Least Time

仅适用于NGINX Plus
对于每个请求，NGINX Plus选择具有最低平均延迟和最少活动连接数的服务器, 指令： least_time xxx;
xxx 有如下3个选项：

• header 从服务器接收第一个字节的时间
• last_byte 从服务器接收完整响应的时间
• last_byte inflight 接收来自服务器的完整响应的时间，其中考虑了不完整的请求

Random

每个请求将被传递到随机选择的服务器。 如果指定了 two 参数，NGINX会参考服务器权重， 随机选择两个服务器，然后通过指定的方式选择其中之一，指令： random two xxx;
xxx 有3个选项：

• least_conn – 选择连接数最少的那个
• least_time=header (NGINX Plus) – 从服务器接收第一个字节的时间
• least_time=last_byte (NGINX Plus) – 从服务器接收完整响应的时间

---

由于我们是内部系统， 要最大化的利用服务器资源， 所以选择了 least_conn

效果对比
应用之后， 效果明显示， 左边半部分是默认的 Round Robin 运行一段时间后， 所有的请求都打到了同一个站点上去了。
右边半部分是应用了 least_conn 的效果。