面試官：說(shuō)說(shuō)看Nginx是如何處理請(qǐng)求的？

當(dāng)客戶(hù)端發(fā)起一個(gè)請(qǐng)求時(shí)，Nginx的工作進(jìn)程會(huì)監(jiān)聽(tīng)網(wǎng)絡(luò)端口，接收客戶(hù)端的連接請(qǐng)求。以下是Nginx處理請(qǐng)求的具體流程：

(1) 接收連接請(qǐng)求：Nginx接收到客戶(hù)端的連接請(qǐng)求后，會(huì)為該連接分配一個(gè)連接對(duì)象（ngx_connection_t）。連接對(duì)象包含連接的狀態(tài)信息、讀寫(xiě)事件處理器等。

(2) 讀取請(qǐng)求頭信息：Nginx從客戶(hù)端讀取請(qǐng)求頭信息。請(qǐng)求頭包含HTTP方法（如GET、POST）、URL、HTTP版本以及各種請(qǐng)求頭字段（如Host、User-Agent、Content-Length等）。

(3) 解析請(qǐng)求頭信息：Nginx解析請(qǐng)求頭信息，提取必要的參數(shù)，如請(qǐng)求方法、URI、Host等。解析后的請(qǐng)求頭信息存儲(chǔ)在ngx_http_request_t結(jié)構(gòu)體中。

(4) 查找匹配的虛擬主機(jī)和location塊：

• Nginx根據(jù)請(qǐng)求頭中的Host字段查找匹配的虛擬主機(jī)（server塊）。每個(gè)虛擬主機(jī)可以配置不同的域名和監(jiān)聽(tīng)端口。
• 在找到匹配的虛擬主機(jī)后，Nginx繼續(xù)查找與請(qǐng)求URI匹配的location塊。location塊定義了如何處理特定路徑的請(qǐng)求。

(5) 執(zhí)行處理階段：Nginx的請(qǐng)求處理分為多個(gè)階段，每個(gè)階段可以由多個(gè)模塊處理。這些階段包括：

• rewrite phase：執(zhí)行重寫(xiě)規(guī)則，如URL重寫(xiě)。
• post rewrite phase：處理重寫(xiě)后的請(qǐng)求。
• preaccess phase：執(zhí)行訪(fǎng)問(wèn)控制前的檢查，如IP地址過(guò)濾。
• access phase：執(zhí)行訪(fǎng)問(wèn)控制，如身份驗(yàn)證。
• postaccess phase：訪(fǎng)問(wèn)權(quán)限控制后的處理。
• try-files：嘗試訪(fǎng)問(wèn)文件或目錄。
• content phase：生成響應(yīng)內(nèi)容，如靜態(tài)文件服務(wù)、反向代理、FastCGI等。在這個(gè)階段，Nginx根據(jù)配置生成響應(yīng)內(nèi)容，這可能涉及讀取靜態(tài)文件、調(diào)用后端服務(wù)（如反向代理、FastCGI、uWSGI等）、生成動(dòng)態(tài)內(nèi)容等。

(6) 生成并發(fā)送響應(yīng)：

• Nginx將生成的響應(yīng)頭發(fā)送回客戶(hù)端。響應(yīng)頭包含HTTP狀態(tài)碼、響應(yīng)頭字段（如Content-Type、Content-Length等）。
• Nginx將生成的響應(yīng)體發(fā)送回客戶(hù)端。響應(yīng)體可以是靜態(tài)文件內(nèi)容、后端服務(wù)返回的數(shù)據(jù)等。

(7) 關(guān)閉連接：一旦響應(yīng)發(fā)送完畢，Nginx會(huì)關(guān)閉連接。如果啟用了keep-alive連接，則連接可以保持打開(kāi)狀態(tài)，用于后續(xù)請(qǐng)求。

面試官：說(shuō)說(shuō)看Nginx的進(jìn)程架構(gòu)是怎樣的？為什么Nginx不使用多線(xiàn)程模型？

1. 進(jìn)程模型

Nginx采用Master-Worker多進(jìn)程架構(gòu)，這種架構(gòu)的設(shè)計(jì)可以確保責(zé)任分離，以便更好地管理系統(tǒng)資源、并發(fā)請(qǐng)求處理與故障恢復(fù)。

(1) Master-Worker架構(gòu)：

① 主進(jìn)程（Master Process）：

• Nginx的核心組件，負(fù)責(zé)初始化Nginx、加載配置文件、創(chuàng)建Worker進(jìn)程等。
• 監(jiān)聽(tīng)配置文件的變更，并在不重啟的情況下重新加載配置。
• 管理Worker進(jìn)程的生命周期，包括啟動(dòng)、停止和管理Worker進(jìn)程。
• 不直接處理客戶(hù)端的請(qǐng)求，而是用于控制和管理Worker進(jìn)程。

② 工作進(jìn)程（Worker Process）

• Nginx的工作進(jìn)程，負(fù)責(zé)處理客戶(hù)端的請(qǐng)求。
• 每個(gè)Worker進(jìn)程都是一個(gè)完整的Nginx服務(wù)器，多個(gè)Worker進(jìn)程之間是對(duì)等的。
• 每個(gè)Worker進(jìn)程可以處理成千上萬(wàn)的并發(fā)連接，Nginx的事件模型可以根據(jù)系統(tǒng)負(fù)載自動(dòng)選擇合適的事件通知機(jī)制（如epoll）。

(2) 進(jìn)程間協(xié)作：

• Master進(jìn)程和Worker進(jìn)程之間通過(guò)信號(hào)和共享內(nèi)存進(jìn)行通信。Master進(jìn)程會(huì)向Worker進(jìn)程發(fā)送信號(hào)以管理它們的生命周期（如啟動(dòng)、停止、重啟等）。
• Worker進(jìn)程之間通過(guò)共享內(nèi)存和進(jìn)程間通信（IPC）機(jī)制進(jìn)行必要的數(shù)據(jù)共享和同步。

(3) 負(fù)載均衡：

Nginx通過(guò)多進(jìn)程模型實(shí)現(xiàn)了負(fù)載均衡。當(dāng)有新的客戶(hù)端連接請(qǐng)求到達(dá)時(shí)，這些連接會(huì)被平均分配給各個(gè)Worker進(jìn)程，從而實(shí)現(xiàn)負(fù)載均衡。這種設(shè)計(jì)確保了Nginx能夠高效地處理大量并發(fā)連接，避免了單個(gè)進(jìn)程成為瓶頸。

(4) 高可用性：

Nginx的多進(jìn)程模型還提供了高可用性。當(dāng)一個(gè)Worker進(jìn)程出現(xiàn)故障時(shí)，Master進(jìn)程會(huì)自動(dòng)重新啟動(dòng)一個(gè)新的Worker進(jìn)程來(lái)替代原來(lái)的進(jìn)程，從而保證服務(wù)器的高可用性。這種設(shè)計(jì)使得Nginx能夠在高負(fù)載和復(fù)雜環(huán)境下穩(wěn)定運(yùn)行。

2. 為什么Nginx不使用多線(xiàn)程模型？

Nginx選擇不使用多線(xiàn)程模型，而是采用多進(jìn)程加異步非阻塞I/O的事件驅(qū)動(dòng)模型，主要基于以下幾個(gè)原因：

(1) 資源隔離與穩(wěn)定性

• 多進(jìn)程模型下，每個(gè)工作進(jìn)程都是獨(dú)立的，它們之間不會(huì)共享內(nèi)存空間（除了通過(guò)共享內(nèi)存等特定機(jī)制進(jìn)行通信）。這種隔離性使得一個(gè)工作進(jìn)程的崩潰不會(huì)影響到其他進(jìn)程，從而提高了整個(gè)系統(tǒng)的穩(wěn)定性。
• 在多線(xiàn)程模型中，線(xiàn)程之間共享進(jìn)程的內(nèi)存空間，這可能導(dǎo)致線(xiàn)程間的數(shù)據(jù)競(jìng)爭(zhēng)、死鎖等問(wèn)題，增加了系統(tǒng)的復(fù)雜性和調(diào)試難度。

(2) 利用多核CPU

• Nginx的多進(jìn)程模型可以很好地利用現(xiàn)代操作系統(tǒng)提供的進(jìn)程調(diào)度機(jī)制，將工作進(jìn)程分配到不同的CPU核心上運(yùn)行，從而實(shí)現(xiàn)并行處理。
• 雖然多線(xiàn)程模型也可以利用多核CPU，但線(xiàn)程的創(chuàng)建、切換和同步開(kāi)銷(xiāo)通常比進(jìn)程更高，尤其是在高并發(fā)場(chǎng)景下。

(3) 避免線(xiàn)程競(jìng)爭(zhēng)和死鎖

• 在多線(xiàn)程模型中，多個(gè)線(xiàn)程可能同時(shí)訪(fǎng)問(wèn)共享資源（如內(nèi)存、文件等），這需要使用鎖機(jī)制來(lái)確保數(shù)據(jù)的一致性和安全性。然而，鎖的使用往往會(huì)導(dǎo)致線(xiàn)程競(jìng)爭(zhēng)和死鎖問(wèn)題，降低系統(tǒng)的性能。
• Nginx通過(guò)采用異步非阻塞I/O和事件驅(qū)動(dòng)模型，避免了鎖的使用，從而減少了線(xiàn)程競(jìng)爭(zhēng)和死鎖的風(fēng)險(xiǎn)。

(4) 簡(jiǎn)化編程模型

• Nginx的多進(jìn)程加異步非阻塞I/O模型相對(duì)簡(jiǎn)單明了，開(kāi)發(fā)者可以更容易地理解和維護(hù)代碼。
• 多線(xiàn)程編程往往涉及復(fù)雜的線(xiàn)程同步和通信機(jī)制，增加了編程的復(fù)雜性和出錯(cuò)的可能性。

(5) 設(shè)計(jì)初衷

• Nginx的設(shè)計(jì)初衷就是為了提供一個(gè)高性能、低資源消耗的Web服務(wù)器和反向代理服務(wù)器。在設(shè)計(jì)之初，Nginx的開(kāi)發(fā)者就選擇了多進(jìn)程加異步非阻塞I/O的模型，并一直沿用至今。
• Nginx的社區(qū)和開(kāi)發(fā)者群體也傾向于保持這種設(shè)計(jì)哲學(xué)，以確保Nginx的穩(wěn)定性和性能優(yōu)勢(shì)。

面試官：什么是正向代理和反向代理？Nginx如何實(shí)現(xiàn)正向代理和反向代理功能？

反向代理功能是指代理服務(wù)器接受互聯(lián)網(wǎng)上的連接請(qǐng)求，然后將這些請(qǐng)求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器，并將從內(nèi)部服務(wù)器上得到的響應(yīng)返回給互聯(lián)網(wǎng)上請(qǐng)求連接的客戶(hù)端。在這個(gè)過(guò)程中，代理服務(wù)器在外部世界中顯示為服務(wù)器。

一般來(lái)說(shuō)反向代理中代理服務(wù)器和后臺(tái)服務(wù)是一伙兒的，綁定在一起?？蛻?hù)端不知道自己實(shí)際請(qǐng)求的到底是誰(shuí)。

現(xiàn)實(shí)中的反向代理例子有：負(fù)載均衡服務(wù)器、網(wǎng)絡(luò)安全防護(hù)(防DDoS攻擊) 和內(nèi)容分發(fā)網(wǎng)絡(luò) CDN等。

Nginx實(shí)現(xiàn)反向代理功能主要通過(guò)配置Nginx服務(wù)器，使其成為客戶(hù)端和目標(biāo)服務(wù)器之間的中介。以下是Nginx實(shí)現(xiàn)反向代理功能的具體步驟和要點(diǎn)：

(1) 配置Nginx：

Nginx的反向代理配置主要在nginx.conf文件中進(jìn)行，或者在包含的子配置文件中進(jìn)行。

• 監(jiān)聽(tīng)端口：設(shè)置Nginx監(jiān)聽(tīng)的端口，默認(rèn)為80端口，用于接收HTTP請(qǐng)求。
• 服務(wù)器名稱(chēng)：定義Nginx服務(wù)器響應(yīng)的域名。
• location塊：根據(jù)請(qǐng)求的URI進(jìn)行匹配，并定義相應(yīng)的操作，如反向代理。
• 反向代理指令（proxy_pass）：指定請(qǐng)求應(yīng)被轉(zhuǎn)發(fā)到的后端服務(wù)器的URL。

(2) 配置示例：

一個(gè)基本的反向代理配置示例如下：

http {
    server {
        listen 80;  # 監(jiān)聽(tīng)80端口
        server_name example.com;  # 服務(wù)器名稱(chēng)
        location / {
            proxy_pass http://backend-server:8080;  # 后端服務(wù)器地址與端口
            proxy_set_header Host $host;  # 保留原始Host頭
            proxy_set_header X-Real-IP $remote_addr;  # 傳遞真實(shí)客戶(hù)端IP
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;  # 傳遞請(qǐng)求協(xié)議(http/https)
            # 其他可選配置，如緩存、超時(shí)、重試等
        }
    }
}

正向代理用于將客戶(hù)端的請(qǐng)求轉(zhuǎn)發(fā)到目標(biāo)服務(wù)器，并將服務(wù)器的響應(yīng)返回給客戶(hù)端。在這種方式下，客戶(hù)端將請(qǐng)求發(fā)送給代理服務(wù)器，由代理服務(wù)器代替客戶(hù)端向目標(biāo)服務(wù)器發(fā)出請(qǐng)求，并將目標(biāo)服務(wù)器的響應(yīng)返回給客戶(hù)端。通過(guò)正向代理，客戶(hù)端可以直接訪(fǎng)問(wèn)外部網(wǎng)絡(luò)，而無(wú)需直接與目標(biāo)服務(wù)器建立連接。

現(xiàn)實(shí)中的正向代理例子有：VPN。

Nginx作為高性能的Web服務(wù)器和反向代理服務(wù)器，也可以實(shí)現(xiàn)正向代理功能。以下是Nginx實(shí)現(xiàn)正向代理的具體步驟和配置方法：

Nginx正向代理的配置方法

由于默認(rèn)的Nginx發(fā)布版本不支持正向代理功能，需要借助ngx_http_proxy_connect_module這個(gè)第三方插件來(lái)完成。在配置文件中添加正向代理的配置，例如：

server {
    listen 3128;  # 監(jiān)聽(tīng)端口
    resolver 114.114.114.114;  # DNS解析器
    proxy_connect;  # 允許CONNECT請(qǐng)求
    proxy_connect_allow 443 563;  # 允許連接的端口
    proxy_connect_connect_timeout 10s;  # 連接超時(shí)時(shí)間
    proxy_connect_data_timeout 10s;  # 數(shù)據(jù)傳輸超時(shí)時(shí)間
    location / {
        proxy_pass http://$host;  # 轉(zhuǎn)發(fā)請(qǐng)求到目標(biāo)服務(wù)器
        proxy_set_header Host $host;  # 設(shè)置請(qǐng)求頭
    }
}

以上配置中，listen指令指定了Nginx監(jiān)聽(tīng)的端口，resolver指令指定了DNS解析器的地址，proxy_connect等指令用于配置CONNECT請(qǐng)求的處理，location指令和proxy_pass指令則用于指定將請(qǐng)求轉(zhuǎn)發(fā)到哪個(gè)目標(biāo)服務(wù)器。

面試官：什么是動(dòng)態(tài)資源、靜態(tài)資源分離？為什么要做動(dòng)、靜分離？Nginx怎么做的動(dòng)靜分離？

動(dòng)態(tài)資源與靜態(tài)資源分離（簡(jiǎn)稱(chēng)動(dòng)、靜分離）是一種常見(jiàn)的Web應(yīng)用架構(gòu)模式。

1. 動(dòng)態(tài)資源與靜態(tài)資源

(1) 靜態(tài)資源

當(dāng)用戶(hù)多次訪(fǎng)問(wèn)某個(gè)資源時(shí)，如果資源的源代碼不會(huì)發(fā)生改變，那么該資源就被稱(chēng)為靜態(tài)資源。常見(jiàn)的靜態(tài)資源包括圖片（img）、樣式表（css）、腳本文件（js）、視頻（mp4）等。這些資源通常可以被瀏覽器和CDN（內(nèi)容分發(fā)網(wǎng)絡(luò)）緩存，以減少對(duì)服務(wù)器的重復(fù)請(qǐng)求。

(2) 動(dòng)態(tài)資源當(dāng)

用戶(hù)多次訪(fǎng)問(wèn)某個(gè)資源時(shí)，如果資源的源代碼可能會(huì)發(fā)生變化，那么該資源就被稱(chēng)為動(dòng)態(tài)資源。常見(jiàn)的動(dòng)態(tài)資源包括JSP、FTL等服務(wù)器端腳本或模板文件。這些資源通常需要根據(jù)用戶(hù)的請(qǐng)求動(dòng)態(tài)生成響應(yīng)內(nèi)容。

2. 動(dòng)、靜分離的原因

(1) 性能優(yōu)化

動(dòng)態(tài)內(nèi)容和靜態(tài)內(nèi)容在處理和分發(fā)上存在差異。將它們分離可以分別進(jìn)行優(yōu)化，從而提高整體性能。例如，靜態(tài)資源可以由專(zhuān)門(mén)的靜態(tài)資源服務(wù)器（如Nginx）直接處理和提供，而動(dòng)態(tài)資源則由應(yīng)用服務(wù)器處理。這樣可以顯著減少對(duì)動(dòng)態(tài)資源服務(wù)器的請(qǐng)求量，降低其負(fù)載。

(2) 緩存管理

靜態(tài)資源易于被緩存，而動(dòng)態(tài)資源通常不適宜緩存或需要更精細(xì)的緩存控制。通過(guò)動(dòng)、靜分離，可以更好地管理緩存策略，提高緩存命中率，減少服務(wù)器響應(yīng)時(shí)間和帶寬消耗。

(3) 負(fù)載均衡

分離后，可以根據(jù)內(nèi)容類(lèi)型對(duì)資源進(jìn)行優(yōu)化分配，實(shí)現(xiàn)更有效的負(fù)載均衡。例如，可以根據(jù)動(dòng)態(tài)資源的訪(fǎng)問(wèn)量和特點(diǎn)，針對(duì)性地增加動(dòng)態(tài)資源服務(wù)器的數(shù)量和規(guī)模，以應(yīng)對(duì)高并發(fā)的訪(fǎng)問(wèn)需求。

(4) 安全性增強(qiáng)

靜態(tài)內(nèi)容服務(wù)器通常不需要執(zhí)行復(fù)雜的程序代碼，因此攻擊面較小，可以降低安全風(fēng)險(xiǎn)。將其與執(zhí)行動(dòng)態(tài)代碼的服務(wù)器分離可以降低潛在的安全威脅。

以下是Nginx動(dòng)靜分離的具體實(shí)現(xiàn)方式：

3. 配置方法

在Nginx中，可以通過(guò)location指令來(lái)實(shí)現(xiàn)動(dòng)靜分離。location指令用于匹配請(qǐng)求的URI，并根據(jù)不同的路徑將請(qǐng)求分發(fā)給不同的處理模塊。

(1) 靜態(tài)資源處理

在上述配置中，location /static/和location /images/分別匹配以/static/和/images/開(kāi)頭的請(qǐng)求，Nginx將在指定的root目錄下查找對(duì)應(yīng)的文件。如果文件存在，Nginx會(huì)直接將文件返回給客戶(hù)端。location ~* \.(jpg|jpeg|png|gif|ico|css|js)$使用正則表達(dá)式匹配所有以這些擴(kuò)展名結(jié)尾的請(qǐng)求，并設(shè)置緩存過(guò)期時(shí)間和Cache-Control頭部。

靜態(tài)資源通常直接由Nginx處理，因此可以在location塊中指定靜態(tài)資源的目錄。

使用正則表達(dá)式匹配靜態(tài)資源的文件擴(kuò)展名，如.jpg、.jpeg、.png、.gif、.ico、.css、.js等。

配置示例：

server {
	listen 80;
	server_name www.example.com;
	
	# 靜態(tài)資源處理
	location /static/ {
		root /var/www/example;
	}
	location /images/ {
		root /var/www/example;
	}
	location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
		root /var/www/example;
		expires 30d;  # 設(shè)置靜態(tài)資源的緩存過(guò)期時(shí)間
		add_header Cache-Control "public";  # 添加Cache-Control頭部，強(qiáng)化瀏覽器緩存行為
	}
}

(2) 動(dòng)態(tài)請(qǐng)求處理

對(duì)于動(dòng)態(tài)請(qǐng)求，可以將請(qǐng)求轉(zhuǎn)發(fā)給后端應(yīng)用服務(wù)器（如PHP-FPM、Django、Node.js等）處理。

配置示例：

server {
	listen 80;
	server_name www.example.com;
	
	# 動(dòng)態(tài)請(qǐng)求處理
	location ~ \.php$ {
		root /var/www/example;
		fastcgi_pass 127.0.0.1:9000;  # 指定將這些請(qǐng)求轉(zhuǎn)發(fā)給PHP-FPM服務(wù)器處理
		fastcgi_index index.php;
		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
		include fastcgi_params;
	}
}

在上述配置中，location ~ \.php$使用正則表達(dá)式匹配所有以.php結(jié)尾的請(qǐng)求，并將這些請(qǐng)求視為動(dòng)態(tài)請(qǐng)求。fastcgi_pass指定將這些請(qǐng)求轉(zhuǎn)發(fā)給PHP-FPM服務(wù)器處理，127.0.0.1:9000是PHP-FPM的監(jiān)聽(tīng)地址。其他參數(shù)用于設(shè)置FastCGI參數(shù)和請(qǐng)求的文件路徑。

4. 注意事項(xiàng)

(1) Nginx的location匹配優(yōu)先級(jí)

Nginx的location匹配遵循特定的優(yōu)先級(jí)規(guī)則，包括精確匹配（使用=符號(hào)）、正則表達(dá)式匹配（使用~或~*）、前綴匹配（普通location）。在配置多個(gè)location塊時(shí)，需要謹(jǐn)慎考慮它們之間的優(yōu)先級(jí)關(guān)系，以確保正確的請(qǐng)求路由。

(2) 緩存策略

通過(guò)合理配置緩存，可以顯著提高網(wǎng)站性能。Nginx提供了強(qiáng)大而靈活的緩存功能，可以通過(guò)proxy_cache_path和proxy_cache指令來(lái)實(shí)現(xiàn)。對(duì)于靜態(tài)資源，可以設(shè)置較長(zhǎng)的緩存過(guò)期時(shí)間，以減少對(duì)服務(wù)器的重復(fù)請(qǐng)求。

(3) 安全性

通過(guò)動(dòng)靜分離，可以將靜態(tài)內(nèi)容服務(wù)器與執(zhí)行動(dòng)態(tài)代碼的服務(wù)器分離，從而降低安全風(fēng)險(xiǎn)。靜態(tài)內(nèi)容服務(wù)器通常不需要執(zhí)行復(fù)雜的程序代碼，因此攻擊面較小。

面試官：Nginx負(fù)載均衡的算法策略有哪些？

1. 輪詢(xún)（Round Robin）

原理：輪詢(xún)算法按照服務(wù)器列表的順序依次分發(fā)請(qǐng)求。當(dāng)一個(gè)新的請(qǐng)求到達(dá)時(shí)，Nginx會(huì)將其分配給列表中的下一個(gè)服務(wù)器，如果到達(dá)列表末尾，則重新開(kāi)始循環(huán)。

特點(diǎn)：

• 簡(jiǎn)單易用，無(wú)需額外配置。
• 適用于后端服務(wù)器性能相近的情況，因?yàn)槊總€(gè)服務(wù)器都會(huì)輪流接收到請(qǐng)求。

http {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
    }
    server {
        location / {
            proxy_pass http://backend;
        }
    }
}

2. 加權(quán)輪詢(xún)（Weighted Round Robin）

原理：在輪詢(xún)的基礎(chǔ)上，為每個(gè)服務(wù)器分配一個(gè)權(quán)重值。權(quán)重值越高的服務(wù)器，接收到的請(qǐng)求越多。Nginx會(huì)根據(jù)權(quán)重值來(lái)計(jì)算每個(gè)服務(wù)器接收請(qǐng)求的比例。

特點(diǎn)：

• 考慮了服務(wù)器性能的差異，可以靈活分配請(qǐng)求。
• 需要手動(dòng)配置權(quán)重值，以反映服務(wù)器的實(shí)際性能。
• 適用于后端服務(wù)器性能不均衡的情況，可以更好地利用服務(wù)器資源。

http {
    upstream backend {
        server backend1.example.com weight=3;
        server backend2.example.com weight=2;
        server backend3.example.com weight=1;
    }
    server {
        location / {
            proxy_pass http://backend;
        }
    }
}

3. IP哈希（IP Hash）

原理：根據(jù)客戶(hù)端IP地址的哈希值來(lái)分配請(qǐng)求。Nginx會(huì)計(jì)算每個(gè)客戶(hù)端IP地址的哈希值，并使用該哈希值來(lái)選擇后端服務(wù)器。由于相同IP地址的哈希值相同，因此來(lái)自同一IP地址的請(qǐng)求總是被分配到同一臺(tái)后端服務(wù)器。

特點(diǎn)：

• 實(shí)現(xiàn)了會(huì)話(huà)粘性（Session Persistence），即同一個(gè)客戶(hù)端的請(qǐng)求總是被分配到同一臺(tái)后端服務(wù)器。
• 適用于需要保持會(huì)話(huà)一致性的場(chǎng)景，如購(gòu)物車(chē)、用戶(hù)會(huì)話(huà)等。
• 但可能導(dǎo)致負(fù)載分布不均衡，因?yàn)槟承㊣P地址范圍內(nèi)的客戶(hù)端可能會(huì)頻繁訪(fǎng)問(wèn)同一臺(tái)服務(wù)器。

http {
    upstream backend {
        ip_hash;
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
    }
    server {
        location / {
            proxy_pass http://backend;
        }
    }
}

4. 最少連接（Least Connections）

原理：將請(qǐng)求分發(fā)到當(dāng)前連接數(shù)最少的服務(wù)器上。Nginx會(huì)監(jiān)控每臺(tái)后端服務(wù)器的當(dāng)前連接數(shù)，并將新請(qǐng)求分配給連接數(shù)最少的服務(wù)器。

特點(diǎn)：

• 考慮了服務(wù)器的當(dāng)前負(fù)載情況，可以更有效地平衡負(fù)載。
• 適用于長(zhǎng)連接場(chǎng)景，如WebSocket、數(shù)據(jù)庫(kù)連接等。
• 但需要Nginx維護(hù)連接狀態(tài)，可能會(huì)增加一些開(kāi)銷(xiāo)。
• Nginx本身不直接支持此策略，通常需要借助第三方模塊或自定義腳本實(shí)現(xiàn)。

http {
    upstream backend {
        least_conn;
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
    }
    server {
        location / {
            proxy_pass http://backend;
        }
    }
}

5. Fair（第三方）

原理：根據(jù)后端服務(wù)器的響應(yīng)時(shí)間來(lái)分配請(qǐng)求。Nginx會(huì)監(jiān)控每臺(tái)后端服務(wù)器的響應(yīng)時(shí)間，并將新請(qǐng)求分配給響應(yīng)時(shí)間最短的服務(wù)器。

特點(diǎn)：

• 實(shí)現(xiàn)了更智能的負(fù)載均衡，可以根據(jù)服務(wù)器的實(shí)際性能來(lái)分配請(qǐng)求。
• 適用于對(duì)響應(yīng)時(shí)間要求較高的場(chǎng)景。
• 但需要安裝第三方模塊（如nginx-module-vts）來(lái)實(shí)現(xiàn)。

6. URL哈希（URL Hash，第三方）

原理：根據(jù)請(qǐng)求URL的哈希值來(lái)分配請(qǐng)求。Nginx會(huì)計(jì)算每個(gè)請(qǐng)求URL的哈希值，并使用該哈希值來(lái)選擇后端服務(wù)器。由于相同URL的哈希值相同，因此相同URL的請(qǐng)求總是被分配到同一臺(tái)后端服務(wù)器。

特點(diǎn)：

• 提高了緩存的命中率，因?yàn)橄嗤琔RL的請(qǐng)求總是被分配到同一臺(tái)后端服務(wù)器。
• 適用于緩存服務(wù)器集群。
• 但同樣可能導(dǎo)致負(fù)載分布不均衡。
• Nginx本身不支持此策略，需要安裝Nginx的hash軟件包來(lái)實(shí)現(xiàn)。