目錄
🎫 前言
🎉 開篇福利
🎁 開篇福利 x2 ?Double happiness
# 介紹
# 地址
# 下載
💻 命令及解析
# 整個文件系統中搜索名為nginx.conf的文件
# 編輯nginx.conf文件
# 重新加載配置文件
#?快速查找nginx.conf文件并使用vim編輯器打開它
# 默認80端口代理配置
#?設置一個簡單的代理服務器
# 反向代理
#?負載均衡
## RR策略
## 權重?
##?ip_hash
##?fair(第三方)
##?url_hash(第三方)?
##?rewrite
# 壓縮和解壓縮
🎫 前言
1. nginx官網地址:nginx news
2. 實踐以下代碼功能,需要服務器
? ? ? ? 方案a. 虛擬機 : 參閱?http://t.csdnimg.cn/Y7QYA
? ? ? ? 方案b. 云服務器:參閱?http://t.csdnimg.cn/iRkv3
3. 阿里云 云服務器 ECS 購買直達:云小站_專享特惠_云產品推薦-阿里云
🎉 開篇福利
vscode可安裝? nginx-formatter? 插件
創建一個??nginx.conf ?文件
在linux系統中,使用FinalShell工具SSH鏈接服務器,查看 nginx.conf 文件內容
sudo cat /etc/nginx/nginx.conf
復制到本地 nginx.conf 文件中,對其代碼右鍵,選擇??使用...格式化文檔??
選擇? nginx-formatter??
這樣看起來就舒服多了,也可以在本地編輯好之后寫入到服務中。
🎁 開篇福利 x2 ?Double happiness
# 介紹
NGINX 配置配置高性能、安全、穩定的NGINX服務器的最簡單方法。
# 地址
NGINXConfig | DigitalOcean
# 下載
下載 生成的配置: ? nginxconfig.io-example.com.tar.gz
然后 上傳 到你的服務器的?/etc/nginx 目錄.
或, 復制壓縮配置的base64字符串,將其粘貼到服務器的命令行并執行。
a.進入你的 NGINX服務器上的配置目錄:
cd /etc/nginx
b.創建當前NGINX配置的備份:
tar -czvf nginx_$(date +'%F_%H-%M-%S').tar.gz nginx.conf sites-available/ sites-enabled/ nginxconfig.io/
c.使用tar解壓新的壓縮配置
tar -xzvf nginxconfig.io-example.com.tar.gz | xargs chmod 0644
💻 命令及解析
# 整個文件系統中搜索名為nginx.conf的文件
sudo find / -name "nginx.conf"
# 編輯nginx.conf文件
vim /etc/nginx/nginx.conf
# 重新加載配置文件
nginx -s reload# windows
nginx.exe -s reload
#?快速查找nginx.conf文件并使用vim編輯器打開它
find /etc/nginx -name "nginx.conf" -exec vim {} \;
# 默認80端口代理配置
# 訪問 https://www.example.com/,nginx指向服務端的/www/wwwroot目錄,并尋找index.html文件。
# 訪問 https://www.example.com/images/example.jpg,nginx指向服務端的/www/images目錄,并尋找example.jpg文件。http {server {location / {root /www/wwwroot;}location /images/ {root /www;}}
}
#?設置一個簡單的代理服務器
# 新服務(服務處理)
server {listen 8080;root /www/wwwroot;location / {}
}# 代理配置,數據轉發
server {location / {proxy_pass http://localhost:8080;}location ~ \.(gif|jpg|png)$ {root /www/images;}
}
# 反向代理
server { listen 80; server_name localhost; client_max_body_size 1024M;location / {proxy_pass http://localhost:8080;proxy_set_header Host $host:$server_port;}
}
#?負載均衡
## RR策略
upstream vinca {server localhost:8080;server localhost:8081;
}
server {listen 81;server_name localhost;client_max_body_size 1024M;location / {proxy_pass http://vinca;proxy_set_header Host $host:$server_port;}
}
## 權重?
upstream vinca {server localhost:8080 weight=9;server localhost:8081 weight=1;
}
- 在Nginx的upstream塊中,weight參數用于指定服務器的權重。權重越高,服務器在負載均衡時被選中的概率就越大。
- 示例中,upstream塊定義了名為"vinca"的后端服務器組,其中包含了2個服務器。第一個服務器的配置:server localhost:8000 weight=9;
- 這里的weight=9表示該服務器的權重是9。而另外一個服務器沒有顯式的指定權重,因此它們的默認權重為1。
- 在請求分發時,Nginx會根據服務器的權重比例來選擇哪個服務器處理請求。由于第一個服務器的權重是9,而其他服務器的權重是默認的1,所以第一個服務器被選中的概率要高于另外一個服務器。
- 通過調整服務器的權重,可以在負載均衡時實現更為精細的控制,將請求按照一定比例分配給不同的服務器。
##?ip_hash
upstream vinca {ip_hash;server localhost:8080;server localhost:8081;
}
- 在上述示例中,ip_hash是Nginx的負載均衡算法之一。它的作用是基于客戶端IP地址來實現會話粘性(Session Affinity),也稱為IP哈希負載均衡。
- 當使用ip_hash時,Nginx通過計算客戶端IP地址的哈希值,將每個請求分配給一臺服務器。一旦確定了一個客戶端請求應該被分派到的特定服務器,后續該客戶端的所有請求都將被發送到同一臺服務器上,從而實現會話的保持。
- 這在某些情況下非常有用,例如當你的應用程序需要確保用戶的會話狀態始終保持在同一臺后端服務器上時。通過使用ip_hash,可以確保同一IP地址的客戶端請求都被分發到相同的后端服務器,從而避免了會話狀態的丟失。
- 需要注意的是,ip_hash算法可能會導致負載不均衡的問題,因為某些IP地址可能會產生更多的請求。如果你的后端服務器能夠處理不同IP地址之間的請求不平衡,并且你需要確保會話粘性,那么ip_hash是一個可行的負載均衡選擇。
##?fair(第三方)
upstream backend {fair;server localhost:8080;server localhost:8081;
}
- 在這段代碼中,upstream塊定義了一個名為"backend"的后端服務器組。同時使用了fair參數,這表明Nginx將使用fair模塊來進行負載均衡。
- fair模塊是Nginx的第三方擴展模塊,它提供了一種稱為"fair load balancing"的負載均衡算法。fair load balancing算法旨在更加公平地分配請求到后端服務器,而不是簡單地根據權重或者輪詢來進行分發。
- fair模塊會考慮每個后端服務器的當前連接數和響應時間等因素,以便更合理地分配負載。具體來說,fair模塊會根據服務器的響應時間和連接數動態地調整請求的分發,以確保每臺服務器都能獲得相對公平的負載。
- 通過使用fair,你可以讓Nginx在進行負載均衡時更加智能地考慮每臺服務器的負載情況,從而提高系統的性能和穩定性。
- 需要注意的是,fair模塊并非Nginx自帶的標準模塊,它是一個可選的第三方模塊,因此在使用前需要確保該模塊已經被正確編譯并加載到Nginx中。
##?url_hash(第三方)?
upstream backend {hash $request_uri;hash_method crc32;server localhost:8080;server localhost:8081;
}
這段Nginx配置代碼定義了一個名為"backend"的后端服務器組。它使用了hash指令來進行負載均衡,并指定了哈希算法和哈希鍵。
具體解釋如下:
- hash $request_uri;:這行代碼指定了使用$request_uri作為哈希鍵。每個請求的URI將被計算哈希值,以決定將請求發送到哪臺后端服務器。
- hash_method crc32;:這行代碼指定了使用CRC32算法作為哈希算法。CRC32是一種快速的哈希算法,用于計算請求URI的哈希值。
- server localhost:8080;和server localhost:8081;:這兩行代碼定義了兩臺后端服務器的地址和端口。
通過使用哈希負載均衡,可以根據請求的URI將請求分發到后端服務器。相同URI的請求將始終被分發到相同的后端服務器,這有助于在緩存中提高命中率,并實現會話粘性。
注意事項:
- 使用哈希負載均衡時,必須小心選擇哈希鍵。選擇不合適的哈希鍵可能導致負載不均衡,因為某些URI可能會更頻繁地訪問。
- 如果后端服務器的數量發生變化(增加或減少),哈希負載均衡可能會導致請求分布不均勻。在這種情況下,需要考慮重新平衡或調整哈希鍵的選擇。
- 哈希負載均衡可能會導致請求集中于少數后端服務器,而其他服務器的負載較輕。這可能會對系統的性能和可擴展性產生影響,因此需要根據實際情況進行評估和調整。
- 請確保CRC32哈希算法已經編譯到你的Nginx版本中,否則可能需要重新編譯或選擇其他可用的哈希算法。
總結:哈希負載均衡是一種根據請求URI進行分發的方法,可以在特定情況下提供更好的性能和會話粘性。但在使用時需謹慎選擇哈希鍵,并根據實際情況進行評估和調整。
##?rewrite
當需要為不同設備(如PC端和移動端)定制不同的頁面重定向時,可以使用Nginx的rewrite模塊來實現。以下是一個簡單易懂的PC端和移動端重寫方案:
server {listen 80;server_name example.com;# PC端重定向規則location / {if ($http_user_agent ~* (android|iphone|ipad)) {# 移動端訪問,重定向到移動端頁面rewrite ^(.*)$ /mobile$1 last;}# PC端訪問,保持原樣}# 移動端重定向規則location /mobile {# 處理移動端頁面請求}
}
1.?listen 80;:監聽80端口,接收HTTP請求。
2.?server_name example.com;:配置服務器名,替換成實際的域名。
3.?PC端重定向規則:
- location /:匹配所有請求。
- if ($http_user_agent ~* (android|iphone|ipad)):使用$http_user_agent變量檢查用戶代理,判斷是否為移動設備。
- rewrite ^(.*)$ /mobile$1 last;:如果是移動設備訪問,則重寫URL,在請求路徑前加上"/mobile",并使用last標志表示終止當前location的處理。
4.移動端重定向規則:
- location /mobile:匹配以/mobile開頭的請求,用于處理移動端頁面請求。
代碼配置中,當用戶通過移動設備訪問網站時,Nginx會根據用戶代理信息判斷其為移動設備,然后重寫URL以將請求路由到/mobile路徑下,從而展示移動端頁面。對于PC端訪問,則保持原樣,不做任何重定向處理。
需要注意的是,使用rewrite時要謹慎考慮正則表達式的匹配和重寫規則,避免出現意外的行為。此外,對于移動端重定向,也可以使用Nginx的map模塊結合變量來實現更靈活的設備識別和重定向規則。
# 壓縮和解壓縮
http {gzip on; # 開啟gzip壓縮功能gzip_min_length 1000; # 設置最小壓縮文件大小gzip_types text/plain text/css application/javascript; # 設置需要進行gzip壓縮的文件類型gzip_proxied any; # 啟用所有可能的gzip壓縮代理server {listen 80;server_name example.com;location / {# 處理請求}location /compressed {gunzip on; # 允許對請求進行解壓縮# 處理解壓縮后的請求}}
}
- gzip on;:開啟gzip壓縮功能。啟用后,Nginx會自動對符合條件的響應內容進行gzip壓縮。
- gzip_min_length 1000;:設置最小壓縮文件大小。僅當響應內容長度大于或等于1000字節時,才會進行壓縮。
- gzip_types text/plain text/css application/javascript;:設置需要進行gzip壓縮的文件類型。這里配置了常見的文本文件和JavaScript文件類型。
- gzip_proxied any;:啟用所有可能的gzip壓縮代理。這樣可以確保在與反向代理或負載均衡等情況下仍能正確壓縮響應內容。
- location /compressed:匹配以/compressed開頭的請求路徑。
- gunzip on;:允許對請求進行解壓縮。在該location中,Nginx會自動解壓請求內容。
在代碼中,當收到客戶端發起的請求時,Nginx會判斷響應內容是否符合gzip壓縮條件,并進行相應處理。如果響應內容長度達到設定的最小壓縮文件大小,并且內容類型匹配gzip_types指定的文件類型,Nginx會對響應內容進行gzip壓縮。對于帶有/compressed路徑的請求,Nginx會自動解壓請求內容。
需要注意的是,gzip壓縮會消耗一定的CPU資源,而解壓縮也會增加服務器的負擔。因此,在配置gzip時需要權衡壓縮和解壓縮的效益與資源消耗,并根據實際情況進行調整。
?以上就是個人整理的nginx實戰經驗,歡迎評論留言。