NGINX应用性能优化指南（第四部分）：负载均衡
BryAbigail
8年前
<p>【编者的话】本文是“NGINX应用性能优化指南”系列文章的第四篇，主要介绍了如何从负载均衡方面实现NGINX应用性能优化。</p> <p> </p> <h2>正文</h2> <p>NGINX允许使用<code>upstream</code>指令配置后台。最值得注意的是会话持久化和负载均衡策略。</p> <p><img src="https://simg.open-open.com/show/b2b9131b664372f382794a9a963680eb.png" alt="NGINX应用性能优化指南（第四部分）：负载均衡" width="680" height="299"></p> <p>在会话持久化方面，有三个有用的变量需要考虑：</p> <ol> <li>往返时间；</li> <li>用于会话持久化的代理TCP CWND；</li> <li>持久化会话数。</li> </ol> <h2>性能考量</h2> <p>RTT非常低则可以在代理和应用服务器之间快速建立连接，并快速提高代理的吞吐量。因此，对于（传统的）集中配置后台，热连接确实可以减少处理未缓存请求的工作。</p> <p>不过，如果你已经部署了反向代理，将未缓存请求引向<em>远程</em>源服务器（例如海岸到海岸80毫秒），保持连接可以节省大量的连接建立时间——尤其是当你必须提供加密吞吐量的时候。（回想一下，新建一个TLS隧道需要消耗3个RTT进行协商。）</p> <p>对于远端后台，你可能也会想用<code>tcp_slow_start_after_idle</code>（在sys.net.ipv4中）。这决定了CWND的大小是否会在连接空闲（一个RTO）后恢复到初始值。通常，在正常情况下，那个行为是启用的，而且是期望的行为。但是，如果你在使用一个专用的点对点连接，那么你会希望禁用它，因为那不太可能遇到拥塞。BDP也不大可能变化。</p> <p>现在，我知道你在想什么：<em>我没有一个专用连接，但让我贪心一次，无论如何都试一试！</em>但下注时要考虑风险和回报。</p> <p>在比较当前拥塞窗口大小和你对未来BDP（比如平均吞吐率乘以平均RTT）的<em>推测</em>时，分析真就派上用场了。还有一点值得考虑：对带宽成本的影响，假设数据不全在远端。</p> <p>另外，如果你的BDP与初始拥塞窗口相比非常大，那么就要重新配置初始CWND。此外，对于在快速LAN（像AWS EC2）上集中部署的后台，可能就不需要检查其中任何一项了。</p> <p><strong>持久化后台连接</strong></p> <p>指令<code>keepalive</code>（会话持久化）设置每个工作进程同上游服务器保持的最大<em>空闲连接</em>数。换句话说，当一个工作进程的连接超出了<code>keepalive</code>设置的数量，它会开始关闭最近最少使用的空闲连接，直到达到那个数值。可以将它想象成每个工作进程的连接池。</p> <p>支持后台<code>keepalive</code>需要HTTP/1.1，因为，我们需要设置<code>proxy_http_version</code>指令，并清除<code>Connection</code>头。对于NGINX：</p> <pre> <code>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; } } </code></pre> <p>在设置<code>keepalive</code>的值时要记住以下几点：</p> <ul> <li>那个连接数会从代理和应用服务器的连接上限（参见<code>worker_connections</code>）中分配；</li> <li>那个值是针对每个工作进程的设置；</li> <li>你可以已经使用<code>keepalive</code>指令配置了多个<code>upstream</code>块。</li> </ul> <p><img src="https://simg.open-open.com/show/3049e10b2bd48e2de4ba6c4a4273798e.jpg" alt="NGINX应用性能优化指南（第四部分）：负载均衡" width="680" height="129"></p> <p> </p> <p>除非你已经配置了<a href="/misc/goto?guid=4959672366226081995">轮询负载均衡</a>，否则很难预测每个应用服务器上的连接分配。更准确地说，那取决于你的负载均衡策略、每个请求的处置以及请求时间。</p> <p>当每个工作进程都与同一个后台服务器建立其所有的连接时，（不大可能发生的）最坏场景就会出现。不过，那充分表明负载均衡策略需要重新考虑了。</p> <p><strong>注意</strong>：如果你在应用程序服务器上运行着一个默认NGINX配置，其<code>worker_connections</code>上限会被设置为512.</p> <blockquote> <p>相关教程：<a href="http://www.supertcp.com/boosting-nginx-open-files-limit-on-centos-7/?utm_source=maxcdn&utm_medium=nginx_post">增加CentOS 7上NGINX打开文件的上限</a></p> </blockquote> <h2>负载均衡策略</h2> <p>NGINX提供了如下负载均衡策略：</p> <ol> <li>加权轮询；</li> <li><code>ip_hash</code>：基于客户端IPv4或IPv6地址的哈希；</li> <li><code>hash</code>：基于用户定义键的哈希；</li> <li><code>least_conn</code>：最少活动连接数；</li> <li><code>least_time</code>：<a href="/misc/goto?guid=4959672366399125303">NGINX Plus</a>提供了最少平均响应时间策略。</li> </ol> <p>在性能方面，<code>least_time</code>可能是首选，但是如果你的后台由相同的高性能应用服务器组成，那么这种策略跟你关系就不大了。此外，<code>hash</code>和<code>ip_hash</code>提供了有用的选项。例如，如果应用服务器需要一段时间加载用户资料，将同一个用户发送给相同的后台服务器可能会受益于缓存命中。</p> <p>客户端的IP地址由<code>$remote_addr</code>变量提供。但是留心客户端IP哈希，因为一个IP地址可能表示来自同一个NAT的多个用户（比如公司办公室或学校）。</p> <p>来源：<a href="http://www.infoq.com/cn/articles/nginx-application-performance-part04?utm_campaign=rightbar_v2&utm_source=infoq&utm_medium=articles_link&utm_content=link_text">InfoQ</a></p>