【編者的話】本文是“NGINX應(yīng)用性能優(yōu)化指南”系列文章的第四篇，主要介紹了如何從負(fù)載均衡方面實(shí)現(xiàn)NGINX應(yīng)用性能優(yōu)化。

注：本文最初發(fā)布于MaxCDN博客，InfoQ中文站在獲得作者授權(quán)的基礎(chǔ)上對文章進(jìn)行了翻譯。

正文

NGINX允許使用upstream指令配置后臺(tái)。最值得注意的是會(huì)話持久化和負(fù)載均衡策略。

在會(huì)話持久化方面，有三個(gè)有用的變量需要考慮：

1. 往返時(shí)間；
2. 用于會(huì)話持久化的代理TCP CWND；
3. 持久化會(huì)話數(shù)。

性能考量

RTT非常低則可以在代理和應(yīng)用服務(wù)器之間快速建立連接，并快速提高代理的吞吐量。因此，對于（傳統(tǒng)的）集中配置后臺(tái)，熱連接確實(shí)可以減少處理未緩存請求的工作。

不過，如果你已經(jīng)部署了反向代理，將未緩存請求引向遠(yuǎn)程源服務(wù)器（例如海岸到海岸80毫秒），保持連接可以節(jié)省大量的連接建立時(shí)間——尤其是當(dāng)你必須提供加密吞吐量的時(shí)候。（回想一下，新建一個(gè)TLS隧道需要消耗3個(gè)RTT進(jìn)行協(xié)商。）

對于遠(yuǎn)端后臺(tái)，你可能也會(huì)想用tcp_slow_start_after_idle（在sys.net.ipv4中）。這決定了CWND的大小是否會(huì)在連接空閑（一個(gè)RTO）后恢復(fù)到初始值。通常，在正常情況下，那個(gè)行為是啟用的，而且是期望的行為。但是，如果你在使用一個(gè)專用的點(diǎn)對點(diǎn)連接，那么你會(huì)希望禁用它，因?yàn)槟遣惶赡苡龅綋砣DP也不大可能變化。

現(xiàn)在，我知道你在想什么：我沒有一個(gè)專用連接，但讓我貪心一次，無論如何都試一試！但下注時(shí)要考慮風(fēng)險(xiǎn)和回報(bào)。

在比較當(dāng)前擁塞窗口大小和你對未來BDP（比如平均吞吐率乘以平均RTT）的推測時(shí)，分析真就派上用場了。還有一點(diǎn)值得考慮：對帶寬成本的影響，假設(shè)數(shù)據(jù)不全在遠(yuǎn)端。

另外，如果你的BDP與初始擁塞窗口相比非常大，那么就要重新配置初始CWND。此外，對于在快速LAN（像AWS EC2）上集中部署的后臺(tái)，可能就不需要檢查其中任何一項(xiàng)了。

持久化后臺(tái)連接

指令keepalive（會(huì)話持久化）設(shè)置每個(gè)工作進(jìn)程同上游服務(wù)器保持的最大空閑連接數(shù)。換句話說，當(dāng)一個(gè)工作進(jìn)程的連接超出了keepalive設(shè)置的數(shù)量，它會(huì)開始關(guān)閉最近最少使用的空閑連接，直到達(dá)到那個(gè)數(shù)值。可以將它想象成每個(gè)工作進(jìn)程的連接池。

支持后臺(tái)keepalive需要HTTP/1.1，因?yàn)椋覀冃枰O(shè)置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;    }}

在設(shè)置keepalive的值時(shí)要記住以下幾點(diǎn)：

• 那個(gè)連接數(shù)會(huì)從代理和應(yīng)用服務(wù)器的連接上限（參見worker_connections）中分配；
• 那個(gè)值是針對每個(gè)工作進(jìn)程的設(shè)置；
• 你可以已經(jīng)使用keepalive指令配置了多個(gè)upstream塊。

除非你已經(jīng)配置了輪詢負(fù)載均衡，否則很難預(yù)測每個(gè)應(yīng)用服務(wù)器上的連接分配。更準(zhǔn)確地說，那取決于你的負(fù)載均衡策略、每個(gè)請求的處置以及請求時(shí)間。

當(dāng)每個(gè)工作進(jìn)程都與同一個(gè)后臺(tái)服務(wù)器建立其所有的連接時(shí)，（不大可能發(fā)生的）最壞場景就會(huì)出現(xiàn)。不過，那充分表明負(fù)載均衡策略需要重新考慮了。

注意：如果你在應(yīng)用程序服務(wù)器上運(yùn)行著一個(gè)默認(rèn)NGINX配置，其worker_connections上限會(huì)被設(shè)置為512.

相關(guān)教程：增加CentOS 7上NGINX打開文件的上限

負(fù)載均衡策略

NGINX提供了如下負(fù)載均衡策略：

1. 加權(quán)輪詢；
2. ip_hash：基于客戶端IPv4或IPv6地址的哈希；
3. hash：基于用戶定義鍵的哈希；
4. least_conn：最少活動(dòng)連接數(shù)；
5. least_time：NGINX Plus提供了最少平均響應(yīng)時(shí)間策略。

在性能方面，least_time可能是首選，但是如果你的后臺(tái)由相同的高性能應(yīng)用服務(wù)器組成，那么這種策略跟你關(guān)系就不大了。此外，hash和ip_hash提供了有用的選項(xiàng)。例如，如果應(yīng)用服務(wù)器需要一段時(shí)間加載用戶資料，將同一個(gè)用戶發(fā)送給相同的后臺(tái)服務(wù)器可能會(huì)受益于緩存命中。

客戶端的IP地址由$remote_addr變量提供。但是留心客戶端IP哈希，因?yàn)橐粋€(gè)IP地址可能表示來自同一個(gè)NAT的多個(gè)用戶（比如公司辦公室或?qū)W校）。

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

感謝郭蕾對本文的審校。

給InfoQ中文站投稿或者參與內(nèi)容翻譯工作，請郵件至editors@cn.infoq.com。也歡迎大家通過新浪微博（@InfoQ，@丁曉昀），微信（微信號(hào)：InfoQChina）關(guān)注我們。