什么是Nginx？
Nginx是一個 輕量級/高性能的反向代理Web服務器，用于 HTTP、HTTPS、SMTP、POP3 和 IMAP 協議。他實現非常高效的反向代理、負載平衡，他可以處理2-3萬并發連接數，官方監測能支持5萬并發，現在中國使用nginx網站用戶有很多，例如：新浪、網易、 騰訊等。
Nginx 有哪些優點？
跨平臺、配置簡單。
非阻塞、高并發連接：處理 2-3 萬并發連接數，官方監測能支持 5 萬并發。
內存消耗?。洪_啟 10 個 Nginx 才占 150M 內存。
成本低廉，且開源。
穩定性高，宕機的概率非常小。
內置的健康檢查功能：如果有一個服務器宕機，會做一個健康檢查，再發送的請求就不會發送到宕機的服務器了。重新將請求提交到其他的節點上
Nginx應用場景？
http服務器。Nginx是一個http服務可以獨立提供http服務?？梢宰鼍W頁靜態服務器。
虛擬主機?？梢詫崿F在一臺服務器虛擬出多個網站，例如個人網站使用的虛擬機。
反向代理，負載均衡。當網站的訪問量達到一定程度后，單臺服務器不能滿足用戶的請求時，需要用多臺服務器集群可以使用nginx做反向代理。并且多臺服務器可以平均分擔負載，不會應為某臺服務器負載高宕機而某臺服務器閑置的情況。
nginz 中也可以配置安全管理、比如可以使用Nginx搭建API接口網關,對每個接口服務進行攔截。
Nginx怎么處理請求的？
server { # 第一個Server區塊開始，表示一個獨立的虛擬主機站點
listen 80； # 提供服務的端口，默認80
server_name localhost; # 提供服務的域名主機名
location / { # 第一個location區塊開始
root html; # 站點的根目錄，相當于Nginx的安裝目錄
index index.html index.html; # 默認的首頁文件，多個用空格分開
}
首先，Nginx 在啟動時，會解析配置文件，得到需要監聽的端口與 IP 地址，然后在 Nginx 的 Master 進程里面先初始化好這個監控的Socket(創建 S ocket，設置 addr、reuse 等選項，綁定到指定的 ip 地址端口，再 listen 監聽)。
然后，再 fork(一個現有進程可以調用 fork 函數創建一個新進程。由 fork 創建的新進程被稱為子進程 )出多個子進程出來。
之后，子進程會競爭 accept 新的連接。此時，客戶端就可以向 nginx 發起連接了。當客戶端與nginx進行三次握手，與 nginx 建立好一個連接后。此時，某一個子進程會 accept 成功，得到這個建立好的連接的 Socket ，然后創建 nginx 對連接的封裝，即 ngx_connection_t 結構體。
接著，設置讀寫事件處理函數，并添加讀寫事件來與客戶端進行數據的交換。
最后，Nginx 或客戶端來主動關掉連接，到此，一個連接就壽終正寢了。
Nginx 是如何實現高并發的？
如果一個 server 采用一個進程(或者線程)負責一個request的方式，那么進程數就是并發數。那么顯而易見的，就是會有很多進程在等待中。等什么？最多的應該是等待網絡傳輸。
而 Nginx 的異步非阻塞工作方式正是利用了這點等待的時間。在需要等待的時候，這些進程就空閑出來待命了。因此表現為少數幾個進程就解決了大量的并發問題。
Nginx是如何利用的呢，簡單來說：同樣的 4 個進程，如果采用一個進程負責一個 request 的方式，那么，同時進來 4 個 request 之后，每個進程就負責其中一個，直至會話關閉。期間，如果有第 5 個request進來了。就無法及時反應了，因為 4 個進程都沒干完活呢，因此，一般有個調度進程，每當新進來了一個 request ，就新開個進程來處理。
回想下，BIO 是不是存在醬紫的問題？
Nginx 不這樣，每進來一個 request ，會有一個 worker 進程去處理。但不是全程的處理，處理到什么程度呢？處理到可能發生阻塞的地方，比如向上游（后端）服務器轉發 request ，并等待請求返回。那么，這個處理的 worker 不會這么傻等著，他會在發送完請求后，注冊一個事件：如果 upstream 返回了，告訴我一聲，我再接著干。于是他就休息去了。此時，如果再有 request 進來，他就可以很快再按這種方式處理。而一旦上游服務器返回了，就會觸發這個事件，worker 才會來接手，這個 request 才會接著往下走。
這就是為什么說，Nginx 基于事件模型。
由于 web server 的工作性質決定了每個 request 的大部份生命都是在網絡傳輸中，實際上花費在 server 機器上的時間片不多。這是幾個進程就解決高并發的秘密所在。即：
webserver 剛好屬于網絡 IO 密集型應用，不算是計算密集型。
異步，非阻塞，使用 epoll ，和大量細節處的優化。也正是 Nginx 之所以然的技術基石。
什么是正向代理？
一個位于客戶端和原始服務器(origin server)之間的服務器，為了從原始服務器取得內容，客戶端向代理發送一個請求并指定目標(原始服務器)，然后代理向原始服務器轉交請求并將獲得的內容返回給客戶端。
客戶端才能使用正向代理。正向代理總結就一句話：代理端代理的是客戶端。例如說：我們使用的OpenVPN 等等。
什么是反向代理？
反向代理（Reverse Proxy）方式，是指以代理服務器來接受 Internet上的連接請求，然后將請求，發給內部網絡上的服務器并將從服務器上得到的結果返回給 Internet 上請求連接的客戶端，此時代理服務器對外就表現為一個反向代理服務器。
反向代理總結就一句話：代理端代理的是服務端。
反向代理服務器的優點是什么?
反向代理服務器可以隱藏源服務器的存在和特征。它充當互聯網云和web服務器之間的中間層。這對于安全方面來說是很好的，特別是當您使用web托管服務時。
Nginx目錄結構有哪些？
[root@localhost ~]# tree /usr/local/nginx
/usr/local/nginx
├── client_body_temp
├── conf # Nginx所有配置文件的目錄
│ ├── fastcgi.conf # fastcgi相關參數的配置文件
│ ├── fastcgi.conf.default # fastcgi.conf的原始備份文件
│ ├── fastcgi_params # fastcgi的參數文件
│ ├── fastcgi_params.default
│ ├── koi-utf
│ ├── koi-win
│ ├── mime.types # 媒體類型
│ ├── mime.types.default
│ ├── nginx.conf # Nginx主配置文件
│ ├── nginx.conf.default
│ ├── scgi_params # scgi相關參數文件
│ ├── scgi_params.default
│ ├── uwsgi_params # uwsgi相關參數文件
│ ├── uwsgi_params.default
│ └── win-utf
├── fastcgi_temp # fastcgi臨時數據目錄
├── html # Nginx默認站點目錄
│ ├── 50x.html # 錯誤頁面優雅替代顯示文件，例如當出現502錯誤時會調用此頁面
│ └── index.html # 默認的首頁文件
├── logs # Nginx日志目錄
│ ├── access.log # 訪問日志文件
│ ├── error.log # 錯誤日志文件
│ └── nginx.pid # pid文件，Nginx進程啟動后，會把所有進程的ID號寫到此文件
├── proxy_temp # 臨時目錄
├── sbin # Nginx命令目錄
│ └── nginx # Nginx的啟動命令
├── scgi_temp # 臨時目錄
└── uwsgi_temp # 臨時目錄
Nginx配置文件nginx.conf有哪些屬性模塊?
worker_processes 1； # worker進程的數量
events { # 事件區塊開始
worker_connections 1024； # 每個worker進程支持的最大連接數
} # 事件區塊結束
http { # HTTP區塊開始
include mime.types； # Nginx支持的媒體類型庫文件
default_type application/octet-stream； # 默認的媒體類型
sendfile on； # 開啟高效傳輸模式
keepalive_timeout 65； # 連接超時
server { # 第一個Server區塊開始，表示一個獨立的虛擬主機站點
listen 80； # 提供服務的端口，默認80
server_name localhost； # 提供服務的域名主機名
location / { # 第一個location區塊開始
root html； # 站點的根目錄，相當于Nginx的安裝目錄
index index.html index.htm； # 默認的首頁文件，多個用空格分開
} # 第一個location區塊結果
error_page 500502503504 /50x.html； # 出現對應的http狀態碼時，使用50x.html回應客戶
location = /50x.html { # location區塊開始，訪問50x.html
root html； # 指定對應的站點目錄為html
}
}
......
cookie和session區別？
共同:
存放用戶信息。存放的形式：key-value格式 變量和變量內容鍵值對。
區別:
cookie
存放在客戶端瀏覽器
每個域名對應一個cookie，不能跨躍域名訪問其他cookie
用戶可以查看或修改cookie
http響應報文里面給你瀏覽器設置
鑰匙（用于打開瀏覽器上鎖頭）
session:
存放在服務器（文件，數據庫，redis）
存放敏感信息
鎖頭
為什么 Nginx 不使用多線程？
Apache: 創建多個進程或線程，而每個進程或線程都會為其分配 cpu 和內存（線程要比進程小的多，所以 worker 支持比 perfork 高的并發），并發過大會榨干服務器資源。
Nginx: 采用單線程來異步非阻塞處理請求（管理員可以配置 Nginx 主進程的工作進程的數量）(epoll)，不會為每個請求分配 cpu 和內存資源，節省了大量資源，同時也減少了大量的 CPU 的上下文切換。所以才使得 Nginx 支持更高的并發。
nginx和apache的區別
輕量級，同樣起web服務，比apache占用更少的內存和資源。
抗并發，nginx處理請求是異步非阻塞的，而apache則是阻塞性的，在高并發下nginx能保持低資源，低消耗高性能。
高度模塊化的設計，編寫模塊相對簡單。
最核心的區別在于apache是同步多進程模型，一個連接對應一個進程，nginx是異步的，多個連接可以對應一個進程。
什么是動態資源、靜態資源分離？
動態資源、靜態資源分離，是讓動態網站里的動態網頁根據一定規則把不變的資源和經常變的資源區分開來，動靜資源做好了拆分以后我們就可以根據靜態資源的特點將其做緩存操作，這就是網站靜態化處理的核心思路。
動態資源、靜態資源分離簡單的概括是：動態文件與靜態文件的分離。
為什么要做動、靜分離？
在我們的軟件開發中，有些請求是需要后臺處理的（如：.jsp,.do 等等），有些請求是不需要經過后臺處理的（如：css、html、jpg、js 等等文件），這些不需要經過后臺處理的文件稱為靜態文件，否則動態文件。
因此我們后臺處理忽略靜態文件。這會有人又說那我后臺忽略靜態文件不就完了嗎？當然這是可以的，但是這樣后臺的請求次數就明顯增多了。在我們對資源的響應速度有要求的時候，我們應該使用這種動靜分離的策略去解決動、靜分離將網站靜態資源（HTML，JavaScript，CSS，img等文件）與后臺應用分開部署，提高用戶訪問靜態代碼的速度，降低對后臺應用訪問
這里我們將靜態資源放到 Nginx 中，動態資源轉發到 Tomcat 服務器中去。
當然，因為現在七牛、阿里云等 CDN 服務已經很成熟，主流的做法，是把靜態資源緩存到 CDN 服務中，從而提升訪問速度。
相比本地的 Nginx 來說，CDN 服務器由于在國內有更多的節點，可以實現用戶的就近訪問。并且，CDN 服務可以提供更大的帶寬，不像我們自己的應用服務，提供的帶寬是有限的。
什么叫 CDN 服務？
CDN ，即內容分發網絡。
其目的是，通過在現有的 Internet中 增加一層新的網絡架構，將網站的內容發布到最接近用戶的網絡邊緣，使用戶可就近取得所需的內容，提高用戶訪問網站的速度。
一般來說，因為現在 CDN 服務比較大眾，所以基本所有公司都會使用 CDN 服務。
Nginx怎么做的動靜分離？
只需要指定路徑對應的目錄。location/可以使用正則表達式匹配。并指定對應的硬盤中的目錄。如下：（操作都是在Linux上）
location /image/ {
root /usr/local/static/;
autoindex on;
}
步驟：
# 創建目錄
mkdir /usr/local/static/image
# 進入目錄
cd /usr/local/static/image
# 上傳照片
photo.jpg
# 重啟nginx
sudo nginx -s reload
打開瀏覽器 輸入 server_name/image/1.jpg 就可以訪問該靜態圖片了
Nginx負載均衡的算法怎么實現的?策略有哪些?
為了避免服務器崩潰，大家會通過負載均衡的方式來分擔服務器壓力。將對臺服務器組成一個集群，當用戶訪問時，先訪問到一個轉發服務器，再由轉發服務器將訪問分發到壓力更小的服務器。
Nginx負載均衡實現的策略有以下五種：
輪詢(默認) 每個請求按時間順序逐一分配到不同的后端服務器，如果后端某個服務器宕機，能自動剔除故障系統。
upstream backserver {
server 1112;
server 1113;
}
權重 weight的值越大，分配到的訪問概率越高，主要用于后端每臺服務器性能不均衡的情況下。其次是為在主從的情況下設置不同的權值，達到合理有效的地利用主機資源。
# 權重越高，在被訪問的概率越大，如上例，分別是20%，80%。
upstream backserver {
server 1112 weight=2;
server 1113 weight=8;
}
-ip_hash( IP綁定) 每個請求按訪問IP的哈希結果分配，使來自同一個IP的訪客固定訪問一臺后端服務器，并且可以有效解決動態網頁存在的session共享問題
upstream backserver {
ip_hash;
server 1112:88;
server 1113:80;
}
fair(第三方插件)
必須安裝upstream_fair模塊。
對比 weight、ip_hash更加智能的負載均衡算法，fair算法可以根據頁面大小和加載時間長短智能地進行負載均衡，響應時間短的優先分配。
哪個服務器的響應速度快，就將請求分配到那個服務器上。
upstream backserver {
server server1;
server server2;
fair;
}
url_hash(第三方插件)
必須安裝Nginx的hash軟件包
按訪問url的hash結果來分配請求，使每個url定向到同一個后端服務器，可以進一步提高后端緩存服務器的效率。
upstream backserver {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}
本文鏈接：http://www.persephonegardens.com/41346.html
網友評論comments