基本介紹Nginx是一款輕量級(jí)的 Web服務(wù)器 / 反向代理服務(wù)器 / 電子郵件（IMAP/POP3）代理服務(wù)器，主要的優(yōu)點(diǎn)是：
基礎(chǔ)使用Windows版基本命令 # 啟動(dòng)# 建議使用第一種，第二種會(huì)使窗口一直處于執(zhí)行中，不能進(jìn)行其他命令操作C:\server\nginx-1.19.2> start nginxC:\server\nginx-1.19.2> nginx.exe# 停止# stop是快速停止nginx，可能并不保存相關(guān)信息；quit是完整有序的停止nginx，并保存相關(guān)信息C:\server\nginx-1.19.2> nginx.exe -s stopC:\server\nginx-1.19.2> nginx.exe -s quit# 重載Nginx# 當(dāng)配置信息修改，需要重新載入這些配置時(shí)使用此命令C:\server\nginx-1.19.2> nginx.exe -s reload# 重新打開(kāi)日志文件C:\server\nginx-1.19.2> nginx.exe -s reopen# 查看Nginx版本C:\server\nginx-1.19.2> nginx -v# 查看配置文件是否正確C:\server\nginx-1.19.2> nginx -t簡(jiǎn)單Demo
 效果如圖所示：  Nginx在架構(gòu)體系中的作用
網(wǎng)關(guān)網(wǎng)關(guān)：可以簡(jiǎn)單的理解為用戶(hù)請(qǐng)求和服務(wù)器響應(yīng)的關(guān)口，即面向用戶(hù)的總?cè)肟?/p> 網(wǎng)關(guān)可以攔截客戶(hù)端所有請(qǐng)求，對(duì)該請(qǐng)求進(jìn)行權(quán)限控制、負(fù)載均衡、日志管理、接口調(diào)用監(jiān)控等，因此無(wú)論使用什么架構(gòu)體系，都可以使用Nginx作為最外層的網(wǎng)關(guān) 虛擬主機(jī)虛擬主機(jī)的定義：虛擬主機(jī)是一種特殊的軟硬件技術(shù)，它可以將網(wǎng)絡(luò)上的每一臺(tái)計(jì)算機(jī)分成多個(gè)虛擬主機(jī)，每個(gè)虛擬主機(jī)可以獨(dú)立對(duì)外提供 www 服務(wù)，這樣就可以實(shí)現(xiàn)一臺(tái)主機(jī)對(duì)外提供多個(gè) web 服務(wù)，每個(gè)虛擬主機(jī)之間是獨(dú)立的，互不影響的。 通過(guò) Nginx 可以實(shí)現(xiàn)虛擬主機(jī)的配置，Nginx 支持三種類(lèi)型的虛擬主機(jī)配置
表現(xiàn)形式其實(shí)大家多見(jiàn)過(guò)，即： # 每個(gè) server 就是一個(gè)虛擬主機(jī)http { # ... server{ # ... } # ... server{ # ... }}路由在Nginx的配置文件中，我們經(jīng)常可以看到這樣的配置： location / { #....}location在此處就起到了路由的作用，比如我們?cè)谕粋€(gè)虛擬主機(jī)內(nèi)定義兩個(gè)不同的路由，如下： location / { proxy_pass https://www.baidu.com/;}location /api { proxy_pass https://apinew./user_api/v1/user/get?aid=2608&user_id=1275089220013336?_self=1; }效果如下： 
因?yàn)槁酚傻拇嬖?，為我們后續(xù)解決跨域問(wèn)題提供了一定的思路，同時(shí)配置內(nèi)容和API接口等更加方便 PS：路由的功能非常強(qiáng)大，支持正則匹配 正向與反向代理此處額外解釋一下proxy_pass的含義 在Nginx中配置proxy_pass代理轉(zhuǎn)發(fā)時(shí)，如果在proxy_pass后面的url加 /，表示絕對(duì)根路徑； 如果沒(méi)有/，表示相對(duì)路徑 正向代理
反向代理
共同點(diǎn)
區(qū)別
靜態(tài)服務(wù)器靜態(tài)服務(wù)器是Nginx的強(qiáng)項(xiàng)，使用非常容易，在默認(rèn)配置下本身就是指向了靜態(tài)的HTML界面，如： location / { root html; index index.html index.htm;}所以前端同學(xué)們，如果構(gòu)建好了界面，可以進(jìn)行相應(yīng)的配置，把界面指向目標(biāo)文件夾中即可，root指的是html文件夾 負(fù)載均衡負(fù)載均衡功能是Nginx另一大殺手锏，一共有5種方式，著重介紹一下。 輪詢(xún)每個(gè)請(qǐng)求按時(shí)間順序逐一分配到不同的后端服務(wù)器，如果后端服務(wù)器down掉，能自動(dòng)剔除，配置如下： upstream tomcatserver { server 192.168.0.1; server 192.168.0.2;}輪詢(xún)策略是默認(rèn)的負(fù)載均衡策略 指定權(quán)重即在輪詢(xún)的基礎(chǔ)之上，增加權(quán)重的概念，weight和訪問(wèn)比率成正比，用于后端服務(wù)器性能不均的情況，配置如下： upstream tomcatserver { server 192.168.0.1 weight=1; server 192.168.0.2 weight=10;}IP Hash每個(gè)請(qǐng)求按訪問(wèn)ip的hash結(jié)果分配，這樣每個(gè)訪客固定訪問(wèn)一個(gè)后端服務(wù)器，可以解決session的問(wèn)題，配置如下： upstream tomcatserver { ip_hash; server 192.168.0.14:88; server 192.168.0.15:80;}fair第三方提供的負(fù)載均衡策略，按后端服務(wù)器的響應(yīng)時(shí)間來(lái)分配請(qǐng)求，響應(yīng)時(shí)間短的優(yōu)先分配，生產(chǎn)環(huán)境中有各種情況可能導(dǎo)致響應(yīng)時(shí)間波動(dòng)，需要慎用 upstream tomcatserver { server server1; server server2; fair;}url_hash第三方提供的負(fù)載均衡策略，按訪問(wèn)url的hash結(jié)果來(lái)分配請(qǐng)求，使每個(gè)url定向到同一個(gè)后端服務(wù)器 upstream tomcatserver { server squid1:3128; server squid2:3128; hash $request_uri; hash_method crc32;}Nginx的模塊化設(shè)計(jì)先來(lái)看看Nginx模塊架構(gòu)圖：  這5個(gè)模塊由上到下重要性一次遞減。 （1）核心模塊； 核心模塊是Nginx服務(wù)器正常運(yùn)行必不可少的模塊，如同操作系統(tǒng)的內(nèi)核。它提供了Nginx最基本的核心服務(wù)。像進(jìn)程管理、權(quán)限控制、錯(cuò)誤日志記錄等； （2）標(biāo)準(zhǔn)HTTP模塊； 標(biāo)準(zhǔn)HTTP模塊支持標(biāo)準(zhǔn)的HTTP的功能，如：端口配置，網(wǎng)頁(yè)編碼設(shè)置，HTTP響應(yīng)頭設(shè)置等； （3）可選HTTP模塊； 可選HTTP模塊主要用于擴(kuò)展標(biāo)準(zhǔn)的HTTP功能，讓Nginx能處理一些特殊的服務(wù)，如：解析GeoIP請(qǐng)求，SSL支持等； （4）郵件服務(wù)模塊； 郵件服務(wù)模塊主要用于支持Nginx的郵件服務(wù)； （5）第三方模塊； 第三方模塊是為了擴(kuò)展Nginx服務(wù)器應(yīng)用，完成開(kāi)發(fā)者想要的功能，如：Lua支持，JSON支持等；
Nginx的請(qǐng)求處理流程基于上文中的Nginx模塊化結(jié)構(gòu)，我們很容易想到，在請(qǐng)求的處理階段也會(huì)經(jīng)歷諸多的過(guò)程，Nginx 將各功能模塊組織成一條鏈，當(dāng)有請(qǐng)求到達(dá)的時(shí)候，請(qǐng)求依次經(jīng)過(guò)這條鏈上的部分或者全部模塊，進(jìn)行處理，每個(gè)模塊實(shí)現(xiàn)特定的功能。 一個(gè) HTTP Request 的處理過(guò)程：
 Nginx的多進(jìn)程模型Nginx 在啟動(dòng)后，會(huì)有一個(gè) master 進(jìn)程和多個(gè) worker 進(jìn)程。 master 進(jìn)程主要用來(lái)管理worker 進(jìn)程，包括接收來(lái)自外界的信號(hào)，向各 worker 進(jìn)程發(fā)送信號(hào)，監(jiān)控 worker 進(jìn)程的運(yùn)行狀態(tài)以及啟動(dòng) worker 進(jìn)程。 worker 進(jìn)程是用來(lái)處理來(lái)自客戶(hù)端的請(qǐng)求事件。多個(gè) worker 進(jìn)程之間是對(duì)等的，它們同等競(jìng)爭(zhēng)來(lái)自客戶(hù)端的請(qǐng)求，各進(jìn)程互相獨(dú)立，一個(gè)請(qǐng)求只能在一個(gè) worker 進(jìn)程中處理。worker 進(jìn)程的個(gè)數(shù)是可以設(shè)置的，一般會(huì)設(shè)置與機(jī)器 CPU 核數(shù)一致，這里面的原因與事件處理模型有關(guān) Nginx 的進(jìn)程模型，可由下圖來(lái)表示：  這種設(shè)計(jì)帶來(lái)以下優(yōu)點(diǎn)： 1） 利用多核系統(tǒng)的并發(fā)處理能力 現(xiàn)代操作系統(tǒng)已經(jīng)支持多核 CPU 架構(gòu)，這使得多個(gè)進(jìn)程可以分別占用不同的 CPU 核心來(lái)工作。Nginx 中所有的 worker 工作進(jìn)程都是完全平等的。這提高了網(wǎng)絡(luò)性能、降低了請(qǐng)求的時(shí)延。 2） 負(fù)載均衡 多個(gè) worker 工作進(jìn)程通過(guò)進(jìn)程間通信來(lái)實(shí)現(xiàn)負(fù)載均衡，即一個(gè)請(qǐng)求到來(lái)時(shí)更容易被分配到負(fù)載較輕的 worker 工作進(jìn)程中處理。這也在一定程度上提高了網(wǎng)絡(luò)性能、降低了請(qǐng)求的時(shí)延。 3） 管理進(jìn)程會(huì)負(fù)責(zé)監(jiān)控工作進(jìn)程的狀態(tài)，并負(fù)責(zé)管理其行為 管理進(jìn)程不會(huì)占用多少系統(tǒng)資源，它只是用來(lái)啟動(dòng)、停止、監(jiān)控或使用其他行為來(lái)控制工作進(jìn)程。首先，這提高了系統(tǒng)的可靠性，當(dāng) worker 進(jìn)程出現(xiàn)問(wèn)題時(shí)，管理進(jìn)程可以啟動(dòng)新的工作進(jìn)程來(lái)避免系統(tǒng)性能的下降。其次，管理進(jìn)程支持 Nginx 服務(wù)運(yùn)行中的程序升級(jí)、配置項(xiàng)修改等操作，這種設(shè)計(jì)使得動(dòng)態(tài)可擴(kuò)展性、動(dòng)態(tài)定制性較容易實(shí)現(xiàn)。 Nginx如何解決驚群現(xiàn)象什么是驚群現(xiàn)象？ 驚群效應(yīng)（thundering herd）是指多進(jìn)程（多線(xiàn)程）在同時(shí)阻塞等待同一個(gè)事件的時(shí)候（休眠狀態(tài)），如果等待的這個(gè)事件發(fā)生，那么他就會(huì)喚醒等待的所有進(jìn)程（或者線(xiàn)程），但是最終卻只能有一個(gè)進(jìn)程（線(xiàn)程）獲得這個(gè)時(shí)間的“控制權(quán)”，對(duì)該事件進(jìn)行處理，而其他進(jìn)程（線(xiàn)程）獲取“控制權(quán)”失敗，只能重新進(jìn)入休眠狀態(tài)，這種現(xiàn)象和性能浪費(fèi)就叫做驚群效應(yīng)。 上文中介紹了Nginx的多進(jìn)程模型，而典型的多進(jìn)程模型正如文中所說(shuō)，多個(gè)worker進(jìn)程之間是對(duì)等的，因此當(dāng)一個(gè)請(qǐng)求到來(lái)的時(shí)候，所有進(jìn)程會(huì)同時(shí)開(kāi)始競(jìng)爭(zhēng)，最終執(zhí)行的又只有一個(gè)，這樣勢(shì)必會(huì)造成資源的浪費(fèi)。 Nginx解決該問(wèn)題的思路是：不讓多個(gè)進(jìn)程在同一時(shí)間監(jiān)聽(tīng)接受連接的socket，而是讓每個(gè)進(jìn)程輪流監(jiān)聽(tīng)，這樣當(dāng)有連接過(guò)來(lái)的時(shí)候，就只有一個(gè)進(jìn)程在監(jiān)聽(tīng)那肯定就沒(méi)有驚群的問(wèn)題。 具體做法是：利用一把進(jìn)程間鎖，每個(gè)進(jìn)程中都嘗試獲得這把鎖，如果獲取成功將監(jiān)聽(tīng)socket加入wait集合中，并設(shè)置超時(shí)等待連接到來(lái)，沒(méi)有獲得鎖的進(jìn)程則將監(jiān)聽(tīng)socket從wait集合去除。 事件驅(qū)動(dòng)模型和異步非阻塞IO承接上文，我們知道了Nginx的多進(jìn)程模型后了解到，其工作進(jìn)程實(shí)際上只有幾個(gè)，但為什么依然能獲得如此高的并發(fā)性能，當(dāng)然與其采用的事件驅(qū)動(dòng)模型和異步非阻塞IO的方式來(lái)處理請(qǐng)求有關(guān)。 Nginx服務(wù)器響應(yīng)和處理Web請(qǐng)求的過(guò)程，是基于事件驅(qū)動(dòng)模型的，它包含事件收集器、事件發(fā)送器和事件處理器等三部分基本單元，著重關(guān)注事件處理器，而一般情況下事件處理器有這么幾種辦法：
第三種方式，在編寫(xiě)程序代碼時(shí)，邏輯比前面兩種都復(fù)雜。大多數(shù)網(wǎng)絡(luò)服務(wù)器采用了第三種方式，逐漸形成了所謂的事件驅(qū)動(dòng)處理庫(kù)。 事件驅(qū)動(dòng)處理庫(kù)又被稱(chēng)為多路IO復(fù)用方法，最常見(jiàn)的包括以下三種：select模型，poll模型和epoll模型。 其中Nginx就默認(rèn)使用的是epoll模型，同時(shí)也支持其他事件模型。 epoll的幫助就在于其提供了一種機(jī)制，可以讓進(jìn)程同時(shí)處理多個(gè)并發(fā)請(qǐng)求，不用關(guān)心IO調(diào)用的具體狀態(tài)。IO調(diào)用完全由事件驅(qū)動(dòng)模型來(lái)管理，這樣一來(lái)，當(dāng)某個(gè)工作進(jìn)程接收到客戶(hù)端的請(qǐng)求以后，調(diào)用IO進(jìn)行處理，如果不能立即得到結(jié)果，就去處理其他的請(qǐng)求；而工作進(jìn)程在此期間也無(wú)需等待響應(yīng)，可以去處理其他事情；當(dāng)IO返回時(shí)，epoll就會(huì)通知此工作進(jìn)程；該進(jìn)程得到通知后，會(huì)來(lái)繼續(xù)處理未完的請(qǐng)求 Nginx配置的最佳實(shí)踐在生產(chǎn)環(huán)境或者開(kāi)發(fā)環(huán)境中Nginx一般會(huì)代理多個(gè)虛擬主機(jī)，如果把所有的配置文件寫(xiě)在默認(rèn)的nginx.conf中，看起來(lái)會(huì)非常臃腫，因此建議將每一個(gè)虛擬文件單獨(dú)放置一個(gè)文件夾，Nginx支持這樣的配置，如下： http { # 省略中間配置 # 引用該目錄下以 .conf 文件結(jié)尾的配置 include /etc/nginx/conf.d/*.conf;}具體文件配置如： # Demoupstream web_pro_testin { server 10.42.46.70:6003 max_fails=3 fail_timeout=20s; ip_hash;}server { listen 80; server_name web.pro.testin.cn; location / { proxy_pass http://web_pro_testin; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location ~ ^/(WEB-INF)/ { deny all; }}Nginx全量配置參數(shù)說(shuō)明# 運(yùn)行用戶(hù)user www-data; # 啟動(dòng)進(jìn)程,通常設(shè)置成和cpu的數(shù)量相等worker_processes 6;# 全局錯(cuò)誤日志定義類(lèi)型，[debug | info | notice | warn | error | crit]error_log logs/error.log;error_log logs/error.log notice;error_log logs/error.log info;# 進(jìn)程pid文件pid /var/run/nginx.pid;# 工作模式及連接數(shù)上限events { # 僅用于linux2.6以上內(nèi)核,可以大大提高nginx的性能 use epoll; # 單個(gè)后臺(tái)worker process進(jìn)程的最大并發(fā)鏈接數(shù) worker_connections 1024; # 客戶(hù)端請(qǐng)求頭部的緩沖區(qū)大小 client_header_buffer_size 4k; # keepalive 超時(shí)時(shí)間 keepalive_timeout 60; # 告訴nginx收到一個(gè)新連接通知后接受盡可能多的連接 # multi_accept on; }#設(shè)定http服務(wù)器，利用它的反向代理功能提供負(fù)載均衡支持http { # 文件擴(kuò)展名與文件類(lèi)型映射表義 include /etc/nginx/mime.types; # 默認(rèn)文件類(lèi)型 default_type application/octet-stream; # 默認(rèn)編碼 charset utf-8; # 服務(wù)器名字的hash表大小 server_names_hash_bucket_size 128; # 客戶(hù)端請(qǐng)求頭部的緩沖區(qū)大小 client_header_buffer_size 32k; # 客戶(hù)請(qǐng)求頭緩沖大小 large_client_header_buffers 4 64k; # 設(shè)定通過(guò)nginx上傳文件的大小 client_max_body_size 8m; # 開(kāi)啟目錄列表訪問(wèn)，合適下載服務(wù)器，默認(rèn)關(guān)閉。 autoindex on; # sendfile 指令指定 nginx 是否調(diào)用 sendfile 函數(shù)（zero copy 方式）來(lái)輸出文件，對(duì)于普通應(yīng)用， # 必須設(shè)為 on,如果用來(lái)進(jìn)行下載等應(yīng)用磁盤(pán)IO重負(fù)載應(yīng)用，可設(shè)置為 off，以平衡磁盤(pán)與網(wǎng)絡(luò)I/O處理速度 sendfile on; # 此選項(xiàng)允許或禁止使用socke的TCP_CORK的選項(xiàng)，此選項(xiàng)僅在使用sendfile的時(shí)候使用 #tcp_nopush on; # 連接超時(shí)時(shí)間（單秒為秒） keepalive_timeout 65; # gzip模塊設(shè)置 gzip on; #開(kāi)啟gzip壓縮輸出 gzip_min_length 1k; #最小壓縮文件大小 gzip_buffers 4 16k; #壓縮緩沖區(qū) gzip_http_version 1.0; #壓縮版本（默認(rèn)1.1，前端如果是squid2.5請(qǐng)使用1.0） gzip_comp_level 2; #壓縮等級(jí) gzip_types text/plain application/x-javascript text/css application/xml; gzip_vary on; # 開(kāi)啟限制IP連接數(shù)的時(shí)候需要使用 #limit_zone crawler $binary_remote_addr 10m; # 指定虛擬主機(jī)的配置文件，方便管理 include /etc/nginx/conf.d/*.conf; # 負(fù)載均衡配置 upstream mysvr { # 請(qǐng)見(jiàn)上文中的五種配置 } # 虛擬主機(jī)的配置 server { # 監(jiān)聽(tīng)端口 listen 80; # 域名可以有多個(gè)，用空格隔開(kāi) server_name www.jd.com jd.com; # 默認(rèn)入口文件名稱(chēng) index index.html index.htm index.php; root /data/www/jd; # 圖片緩存時(shí)間設(shè)置 location ~ .*.(gif|jpg|jpeg|png|bmp|swf)${ expires 10d; } #JS和CSS緩存時(shí)間設(shè)置 location ~ .*.(js|css)?${ expires 1h; } # 日志格式設(shè)定 #$remote_addr與$http_x_forwarded_for用以記錄客戶(hù)端的ip地址； #$remote_user：用來(lái)記錄客戶(hù)端用戶(hù)名稱(chēng)； #$time_local： 用來(lái)記錄訪問(wèn)時(shí)間與時(shí)區(qū)； #$request： 用來(lái)記錄請(qǐng)求的url與http協(xié)議； #$status： 用來(lái)記錄請(qǐng)求狀態(tài)；成功是200， #$body_bytes_sent ：記錄發(fā)送給客戶(hù)端文件主體內(nèi)容大??； #$http_referer：用來(lái)記錄從那個(gè)頁(yè)面鏈接訪問(wèn)過(guò)來(lái)的； log_format access '$remote_addr - $remote_user [$time_local] '$request' ' '$status $body_bytes_sent '$http_referer' ' ''$http_user_agent' $http_x_forwarded_for'; # 定義本虛擬主機(jī)的訪問(wèn)日志 access_log /usr/local/nginx/logs/host.access.log main; access_log /usr/local/nginx/logs/host.access.404.log log404; # 對(duì)具體路由進(jìn)行反向代理 location /connect-controller { proxy_pass http://127.0.0.1:88; proxy_redirect off; proxy_set_header X-Real-IP $remote_addr; # 后端的Web服務(wù)器可以通過(guò)X-Forwarded-For獲取用戶(hù)真實(shí)IP proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host; # 允許客戶(hù)端請(qǐng)求的最大單文件字節(jié)數(shù) client_max_body_size 10m; # 緩沖區(qū)代理緩沖用戶(hù)端請(qǐng)求的最大字節(jié)數(shù)， client_body_buffer_size 128k; # 表示使nginx阻止HTTP應(yīng)答代碼為400或者更高的應(yīng)答。 proxy_intercept_errors on; # nginx跟后端服務(wù)器連接超時(shí)時(shí)間(代理連接超時(shí)) proxy_connect_timeout 90; # 后端服務(wù)器數(shù)據(jù)回傳時(shí)間_就是在規(guī)定時(shí)間之內(nèi)后端服務(wù)器必須傳完所有的數(shù)據(jù) proxy_send_timeout 90; # 連接成功后，后端服務(wù)器響應(yīng)的超時(shí)時(shí)間 proxy_read_timeout 90; # 設(shè)置代理服務(wù)器（nginx）保存用戶(hù)頭信息的緩沖區(qū)大小 proxy_buffer_size 4k; # 設(shè)置用于讀取應(yīng)答的緩沖區(qū)數(shù)目和大小，默認(rèn)情況也為分頁(yè)大小，根據(jù)操作系統(tǒng)的不同可能是4k或者8k proxy_buffers 4 32k; # 高負(fù)荷下緩沖大?。╬roxy_buffers*2） proxy_busy_buffers_size 64k; # 設(shè)置在寫(xiě)入proxy_temp_path時(shí)數(shù)據(jù)的大小，預(yù)防一個(gè)工作進(jìn)程在傳遞文件時(shí)阻塞太長(zhǎng) # 設(shè)定緩存文件夾大小，大于這個(gè)值，將從upstream服務(wù)器傳 proxy_temp_file_write_size 64k; } # 動(dòng)靜分離反向代理配置（多路由指向不同的服務(wù)端或界面） location ~ .(jsp|jspx|do)?$ { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://127.0.0.1:8080; } }}Nginx還能做什么解決CORS跨域問(wèn)題思路有兩個(gè)：
適配 PC 或移動(dòng)設(shè)備根據(jù)用戶(hù)設(shè)備不同返回不同樣式的站點(diǎn)，以前經(jīng)常使用的是純前端的自適應(yīng)布局，但無(wú)論是復(fù)雜性和易用性上面還是不如分開(kāi)編寫(xiě)的好，比如我們常見(jiàn)的淘寶、京東......這些大型網(wǎng)站就都沒(méi)有采用自適應(yīng)，而是用分開(kāi)制作的方式，根據(jù)用戶(hù)請(qǐng)求的 user-agent 來(lái)判斷是返回 PC 還是 H5 站點(diǎn) 請(qǐng)求限流Nginx按請(qǐng)求速率限速模塊使用的是漏桶算法，即能夠強(qiáng)行保證請(qǐng)求的實(shí)時(shí)處理速度不會(huì)超過(guò)設(shè)置的閾值，如： http { limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; server { location /search/ { limit_req zone=one burst=5 nodelay; } }}常見(jiàn)問(wèn)題Q1：Nginx一般用作什么？
Q2：為什么要用Nginx？
Q3：為什么Nginx這么快？如果一個(gè)server采用一個(gè)進(jìn)程負(fù)責(zé)一個(gè)request的方式，那么進(jìn)程數(shù)就是并發(fā)數(shù)。那么顯而易見(jiàn)的，就是會(huì)有很多進(jìn)程在等待中。等什么？最多的應(yīng)該是等待網(wǎng)絡(luò)傳輸。 而nginx 的異步非阻塞工作方式正是利用了這點(diǎn)等待的時(shí)間。在需要等待的時(shí)候，這些進(jìn)程就空閑出來(lái)待命了。因此表現(xiàn)為少數(shù)幾個(gè)進(jìn)程就解決了大量的并發(fā)問(wèn)題。 nginx是如何利用的呢，簡(jiǎn)單來(lái)說(shuō)：同樣的4個(gè)進(jìn)程，如果采用一個(gè)進(jìn)程負(fù)責(zé)一個(gè)request的方式，那么，同時(shí)進(jìn)來(lái)4個(gè)request之后，每個(gè)進(jìn)程就負(fù)責(zé)其中一個(gè)，直至?xí)?huà)關(guān)閉。期間，如果有第5個(gè)request進(jìn)來(lái)了。就無(wú)法及時(shí)反應(yīng)了，因?yàn)?個(gè)進(jìn)程都沒(méi)干完活呢，因此，一般有個(gè)調(diào)度進(jìn)程，每當(dāng)新進(jìn)來(lái)了一個(gè)request，就新開(kāi)個(gè)進(jìn)程來(lái)處理。 nginx不這樣，每進(jìn)來(lái)一個(gè)request，會(huì)有一個(gè)worker進(jìn)程去處理。但不是全程的處理，處理到什么程度呢？處理到可能發(fā)生阻塞的地方，比如向上游（后端）服務(wù)器轉(zhuǎn)發(fā)request，并等待請(qǐng)求返回。那么，這個(gè)處理的worker不會(huì)這么傻等著，他會(huì)在發(fā)送完請(qǐng)求后，注冊(cè)一個(gè)事件：“如果upstream返回了，告訴我一聲，我再接著干”。于是他就休息去了。此時(shí)，如果再有request 進(jìn)來(lái)，他就可以很快再按這種方式處理。而一旦上游服務(wù)器返回了，就會(huì)觸發(fā)這個(gè)事件，worker才會(huì)來(lái)接手，這個(gè)request才會(huì)接著往下走。 由于web server的工作性質(zhì)決定了每個(gè)request的大部份生命都是在網(wǎng)絡(luò)傳輸中，實(shí)際上花費(fèi)在server機(jī)器上的時(shí)間片不多。這是幾個(gè)進(jìn)程就解決高并發(fā)的秘密所在。
Q4：什么是正向代理和反向代理
Q5：Nginx負(fù)載均衡的算法有哪些？
Q6：Nginx如何解決的驚群現(xiàn)象？
Q7：Nginx為什么不用多線(xiàn)程模型？
Q8：Nginx壓縮功能有什么壞處嗎？
Q9：Nginx有幾種進(jìn)程模型?
|
|
|
來(lái)自： wq2g2ds152m668 > 《服務(wù)器》
