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