NGINX 应用性能优化指南（第四部分）：负载均衡

【编者的话】本文是“NGINX 应用性能优化指南”系列文章的第四篇，主要介绍了如何从负载均衡方面实现 NGINX 应用性能优化。

注：本文最初发布于 MaxCDN 博客，InfoQ 中文站在获得作者授权的基础上对文章进行了翻译。

正文

NGINX 允许使用upstream指令配置后台。最值得注意的是会话持久化和负载均衡策略。

在会话持久化方面，有三个有用的变量需要考虑：

1. 往返时间；
2. 用于会话持久化的代理 TCP CWND；
3. 持久化会话数。

性能考量

RTT 非常低则可以在代理和应用服务器之间快速建立连接，并快速提高代理的吞吐量。因此，对于（传统的）集中配置后台，热连接确实可以减少处理未缓存请求的工作。

不过，如果你已经部署了反向代理，将未缓存请求引向 _ 远程 _ 源服务器（例如海岸到海岸 80 毫秒），保持连接可以节省大量的连接建立时间——尤其是当你必须提供加密吞吐量的时候。（回想一下，新建一个 TLS 隧道需要消耗 3 个 RTT 进行协商。）

对于远端后台，你可能也会想用tcp_slow_start_after_idle（在 sys.net.ipv4 中）。这决定了 CWND 的大小是否会在连接空闲（一个 RTO）后恢复到初始值。通常，在正常情况下，那个行为是启用的，而且是期望的行为。但是，如果你在使用一个专用的点对点连接，那么你会希望禁用它，因为那不太可能遇到拥塞。BDP 也不大可能变化。

现在，我知道你在想什么：_ 我没有一个专用连接，但让我贪心一次，无论如何都试一试！_ 但下注时要考虑风险和回报。

在比较当前拥塞窗口大小和你对未来 BDP（比如平均吞吐率乘以平均 RTT）的 _ 推测 _ 时，分析真就派上用场了。还有一点值得考虑：对带宽成本的影响，假设数据不全在远端。

另外，如果你的 BDP 与初始拥塞窗口相比非常大，那么就要重新配置初始 CWND。此外，对于在快速 LAN（像 AWS EC2）上集中部署的后台，可能就不需要检查其中任何一项了。

持久化后台连接

指令keepalive（会话持久化）设置每个工作进程同上游服务器保持的最大 _ 空闲连接 _ 数。换句话说，当一个工作进程的连接超出了keepalive设置的数量，它会开始关闭最近最少使用的空闲连接，直到达到那个数值。可以将它想象成每个工作进程的连接池。

支持后台keepalive需要 HTTP/1.1，因为，我们需要设置proxy_http_version指令，并清除Connection头。对于 NGINX：

upstream backend {
    keepalive 100;
    server 192.168.100.250 weight=1 max_fails=2 fail_timeout=10;
    server 192.168.100.251 weight=1 max_fails=2 fail_timeout=10;
    server 192.168.100.252 weight=1 max_fails=2 fail_timeout=10;
}
server {
    location /http {
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_pass http://backend;
    }
}
 

在设置keepalive的值时要记住以下几点：

• 那个连接数会从代理和应用服务器的连接上限（参见worker_connections）中分配；
• 那个值是针对每个工作进程的设置；
• 你可以已经使用keepalive指令配置了多个upstream块。

除非你已经配置了轮询负载均衡，否则很难预测每个应用服务器上的连接分配。更准确地说，那取决于你的负载均衡策略、每个请求的处置以及请求时间。

当每个工作进程都与同一个后台服务器建立其所有的连接时，（不大可能发生的）最坏场景就会出现。不过，那充分表明负载均衡策略需要重新考虑了。

注意：如果你在应用程序服务器上运行着一个默认NGINX 配置，其 worker_connections上限会被设置为 512.

相关教程：增加 CentOS 7 上 NGINX 打开文件的上限

负载均衡策略

NGINX 提供了如下负载均衡策略：

1. 加权轮询；
2. ip_hash：基于客户端 IPv4 或 IPv6 地址的哈希；
3. hash：基于用户定义键的哈希；
4. least_conn：最少活动连接数；
5. least_time： NGINX Plus 提供了最少平均响应时间策略。

在性能方面，least_time可能是首选，但是如果你的后台由相同的高性能应用服务器组成，那么这种策略跟你关系就不大了。此外，hash和ip_hash提供了有用的选项。例如，如果应用服务器需要一段时间加载用户资料，将同一个用户发送给相同的后台服务器可能会受益于缓存命中。

客户端的 IP 地址由$remote_addr变量提供。但是留心客户端 IP 哈希，因为一个 IP 地址可能表示来自同一个 NAT 的多个用户（比如公司办公室或学校）。

查看英文原文： NGINX Application Performance Optimization：Load Balancing

感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。