2019-10-09 15:53:47 馮insist 閱讀數 2552 文章標籤: nginx學習,看這一篇就夠了:下載、安裝。使用:正向代理、反向代理、 更多php
分類專欄: nginxhtml
版權聲明:本文爲博主原創文章,遵循 CC 4.0 BY-SA 版權協議,轉載請附上原文出處連接和本聲明。java
本文連接:http://www.javashuo.com/article/p-fyfutqey-x.htmllinux
Nginx 是高性能的 HTTP 和反向代理的web服務器,處理高併發能力是十分強大的,能經受高負 載的考驗,有報告代表能支持高達 50,000 個併發鏈接數。nginx
其特色是佔有內存少,併發能力強,事實上nginx的併發能力確實在同類型的網頁服務器中表現較好,中國大陸使用nginx網站用戶有:百度、京東、新浪、網易、騰訊、淘寶等。web
Nginx 不只能夠作反向代理,實現負載均衡。還能用做正向代理來進行上網等功能。 正向代理:若是把局域網外的 Internet 想象成一個巨大的資源庫,則局域網中的客戶端要訪 問 Internet,則須要經過代理服務器來訪問,這種代理服務就稱爲正向代理。正則表達式
增長服務器的數量,而後將請求分發到各個服務器上,將原先請求集中到單個服務器上的 狀況改成將請求分發到多個服務器上,將負載分發到不一樣的服務器,也就是咱們所說的負 載均衡redis
客戶端發送多個請求到服務器,服務器處理請求,有一些可能要與數據庫進行交互,服 務器處理完畢後,再將結果返回給客戶端。shell
這種架構模式對於早期的系統相對單一,併發請求相對較少的狀況下是比較適合的,成 本也低。可是隨着信息數量的不斷增加,訪問量和數據量的飛速增加,以及系統業務的複雜 度增長,這種架構會形成服務器相應客戶端的請求日益緩慢,併發量特別大的時候,還容易 形成服務器直接崩潰。很明顯這是因爲服務器性能的瓶頸形成的問題,那麼如何解決這種情 況呢?數據庫
咱們首先想到的多是升級服務器的配置,好比提升 CPU 執行頻率,加大內存等提升機 器的物理性能來解決此問題,可是咱們知道摩爾定律的日益失效,硬件的性能提高已經不能 知足日益提高的需求了。最明顯的一個例子,天貓雙十一當天,某個熱銷商品的瞬時訪問量 是極其龐大的,那麼相似上面的系統架構,將機器都增長到現有的頂級物理配置,都是不能 夠知足需求的。那麼怎麼辦呢?上面的分析咱們去掉了增長服務器物理配置來解決問題的辦法,也就是說縱向解決問題 的辦法行不通了,那麼橫向增長服務器的數量呢?這時候集羣的概念產生了,單個服務器解 決不了,咱們增長服務器的數量,而後將請求分發到各個服務器上,將原先請求集中到單個服務器上的狀況改成將請求分發到多個服務器上,將負載分發到不一樣的服務器,也就是咱們 所說的負載均衡
爲了加快網站的解析速度,能夠把動態頁面和靜態頁面由不一樣的服務器來解析,加快解析速 度。下降原來單個服務器的壓力。
nginx安裝時,用到的包,我都準備好啦,方便使用:
https://download.csdn.net/download/qq_40036754/11891855
原本想放百度雲的,可是麻煩,因此我就直接上傳到個人資源啦,你們也能夠直接聯繫我,我直接給你們的。
cd /usr/local/nginx
目錄內容以下:
在 windows 系統中訪問 linux 中 nginx,默認不能訪問的,由於防火牆問題 (1)關閉防火牆 (2)開放訪問的端口號,80 端口
查看開放的端口號
firewall-cmd --list-all
設置開放的端口號
firewall-cmd --add-service=http –permanent firewall-cmd --add-port=80/tcp --permanent
重啓防火牆
firewall-cmd –reload
使用nginx操做命令前提:必須進入到nginx的自動生成目錄的下/sbin文件夾下。
nginx有兩個目錄:
第一個:安裝目錄,我放在:
/usr/feng/
第二個:自動生成目錄:
/usr/local/nginx/
./nginx -v
./nginx
./nginx -s stop
在目錄:/usr/local/nginx/sbin 下執行命令,不須要重啓服務器,自動編譯。
./nginx -s reload
/usr/local/nginx/conf/nginx.conf
配置文件中有不少#, 開頭的表示註釋內容,咱們去掉全部以 # 開頭的段落,精簡以後的 內容以下:
worker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 80; server_name localhost; location / { root html; index index.html index.htm; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } } }
從配置文件開始到 events 塊之間的內容,主要會設置一些影響nginx 服務器總體運行的配置指令,主要包括配 置運行 Nginx 服務器的用戶(組)、容許生成的 worker process 數,進程 PID 存放路徑、日誌存放路徑和類型以 及配置文件的引入等。
好比上面第一行配置的:
worker_processes 1;
這是 Nginx 服務器併發處理服務的關鍵配置,worker_processes 值越大,能夠支持的併發處理量也越多,可是 會受到硬件、軟件等設備的制約。
好比上面的配置:
events { worker_connections 1024; }
events 塊涉及的指令**主要影響 Nginx 服務器與用戶的網絡鏈接,經常使用的設置包括是否開啓對多 work process 下的網絡鏈接進行序列化,是否 容許同時接收多個網絡鏈接,選取哪一種事件驅動模型來處理鏈接請求,每一個 word process 能夠同時支持的最大鏈接數等。**
上述例子就表示每一個 work process 支持的最大鏈接數爲 1024.
這部分的配置對 Nginx 的性能影響較大,在實際中應該靈活配置。
http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 80; server_name localhost; location / { root html; index index.html index.htm; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } } }
這算是 Nginx 服務器配置中最頻繁的部分,代理、緩存和日誌定義等絕大多數功能和第三方模塊的配置都在這裏。
須要注意的是:http 塊也能夠包括 http全局塊、server 塊。
(1)在 liunx 系統安裝 tomcat,使用默認端口 8080,我這裏8080被其餘應用佔用,因此我已修改端口爲8081。在conf目錄下的server.xml配置文件中,以下,將port改成 8081,其實下面也有相似的Connector 標籤,可是要看protocol協議爲HTTP/1.1的標籤修改便可。
<Connector port="8081" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
(2)對外開放訪問的端口 (我這裏不須要)
(3)在 windows 系統中經過瀏覽器訪問 tomcat 服務器
別忘了開啓tomcat,在bin目錄下,使用 命令:
./startup.sh
添加內容在 host 文件中
如上配置,咱們監聽 80 端口,訪問域名爲 www.123.com,不加端口號時默認爲 80 端口,故 訪問該域名時會跳轉到 127.0.0.1:8081 路徑上。在瀏覽器端輸入 www.123.com 結果以下:
實現效果:使用 nginx 反向代理,根據訪問的路徑跳轉到不一樣端口的服務中
nginx 監聽端口爲 9001,
訪問 http://127.0.0.1:9001/edu/ 直接跳轉到 127.0.0.1:8081
訪問 http://127.0.0.1:9001/vod/ 直接跳轉到 127.0.0.1:8082
tomcat8081 解壓包,而後進入到 /bin 下 ,使用命令 ./startup 啓動
tomcat8082
使用命令 編輯 文件 :/conf/server.xml 文件
vim server.xml
修改後以下:
一、修改server 的默認端口,由默認8005->8091
二、修改http協議的默認端口,由默認的8080->8082
三、修改默認ajp協議的默認端口,由默認的8009->9001
<h1>fengfanchen-nginx-8081!!!</h1>
tomcat8082的tomcat,放到目錄 /webapp/edu 下,內容:
<h1>fengfanchen-nginx-8082!!!</h1>
修改 nginx 的配置文件 在 http 塊中添加 server{}
修改其中註釋的就行。
修改爲功後
該指令用於匹配 URL。
語法以下:
一、= :用於不含正則表達式的 uri 前,要求請求字符串與 uri 嚴格匹配,若是匹配 成功,就中止繼續向下搜索並當即處理該請求。
二、~:用於表示 uri 包含正則表達式,而且區分大小寫。
三、~*:用於表示 uri 包含正則表達式,而且不區分大小寫。
四、^~:用於不含正則表達式的 uri 前,要求 Nginx 服務器找到標識 uri 和請求字 符串匹配度最高的 location 後,當即使用此 location 處理請求,而再也不使用 location 塊中的正則 uri 和請求字符串作匹配。
注意:若是 uri 包含正則表達式,則必需要有 ~ 或者 ~*標識。
瀏覽器地址欄輸入地址 http://208.208.128.122/edu/a.html,負載均衡效果,平均 8081 和 8082 端口中
cp a.html ../edu/
便可完成,
查看命令
cd ../edu/ # 進入到 edu 目錄下 cat a.html #查看內容
測試URL
http://208.208.128.122:8081/edu/a.html
http://208.208.128.122:8082/edu/a.html
修改了第一個示例的 配置
upstream myserver { server 208.208.128.122:8081; server 208.208.128.122:8082; } server { listen 80; server_name 208.208.128.122; #charset koi8-r; #access_log logs/host.access.log main; location / { root html; proxy_pass http://myserver; #proxy_pass http://127.0.0.1:8081; index index.html index.htm; }
測試url
http://208.208.128.122/edu/a.html
隨着互聯網信息的爆炸性增加,負載均衡(load balance)已經再也不是一個很陌生的話題, 顧名思義,負載均衡便是將負載分攤到不一樣的服務單元,既保證服務的可用性,又保證響應 足夠快,給用戶很好的體驗。快速增加的訪問量和數據流量催生了各式各樣的負載均衡產品, 不少專業的負載均衡硬件提供了很好的功能,但卻價格不菲,這使得負載均衡軟件大受歡迎, nginx 就是其中的一個,在 linux 下有 Nginx、LVS、Haproxy 等等服務能夠提供負載均衡服 務,並且 Nginx 提供了幾種分配方式(策略):
每一個請求按時間順序逐一分配到不一樣的後端服務器,若是後端服務器 down 掉,能自動剔除。
配置方式:
weight 表明權重, 默認爲 1,權重越高被分配的客戶端越多
upstream myserver { server 208.208.128.122:8081 weight=10; # 在這兒 server 208.208.128.122:8082 weight=10; } server { listen 80; server_name 208.208.128.122; location / { root html; proxy_pass http://myserver; index index.html index.htm; }
ip_hash 每一個請求按訪問 ip 的 hash 結果分配,這樣每一個訪客固定訪問一個後端服務器
upstream myserver { ip_hash; // 在這兒 server 208.208.128.122:8081 ; server 208.208.128.122:8082 ; } server { listen 80; server_name 208.208.128.122; location / { root html; proxy_pass http://myserver; index index.html index.htm; }
fair(第三方),按後端服務器的響應時間來分配請求,響應時間短的優先分配。
upstream myserver { server 208.208.128.122:8081 ; server 208.208.128.122:8082 ; fair; # 在這兒 } server { listen 80; server_name 208.208.128.122; location / { root html; proxy_pass http://myserver; index index.html index.htm; }
Nginx 動靜分離簡單來講就是把動態跟靜態請求分開,不能理解成只是單純的把動態頁面和 靜態頁面物理分離。嚴格意義上說應該是動態請求跟靜態請求分開,能夠理解成使用 Nginx 處理靜態頁面,Tomcat 處理動態頁面。動靜分離從目前實現角度來說大體分爲兩種:
一種是純粹把靜態文件獨立成單獨的域名,放在獨立的服務器上,也是目前主流推崇的方案;
另一種方法就是動態跟靜態文件混合在一塊兒發佈,經過 nginx 來分開。
經過 location 指定不一樣的後綴名實現不一樣的請求轉發。經過 expires 參數設置,可使 瀏覽器緩存過時時間,減小與服務器以前的請求和流量。具體 Expires 定義:是給一個資 源設定一個過時時間,也就是說無需去服務端驗證,直接經過瀏覽器自身確認是否過時便可, 因此不會產生額外的流量。此種方法很是適合不常常變更的資源。(若是常常更新的文件, 不建議使用 Expires 來緩存),我這裏設置 3d,表示在這 3 天以內訪問這個 URL,發送 一個請求,比對服務器該文件最後更新時間沒有變化,則不會從服務器抓取,返回狀態碼 304,若是有修改,則直接從服務器從新下載,返回狀態碼 200。
<h1>fengfanchen-test-html</h1>
http://208.208.128.122/image/ http://208.208.128.122/image/01.jpg
http://208.208.128.122/www/a.html
配置示例流程:
第一種方式:命令安裝
yum install keepalived -y # 查看版本: rpm -q -a keepalived
第二種方式:安裝包方式(這裏我使用這個)
將壓縮包上傳至:/usr/feng/
命令以下:
cd /usr/feng/ tar -zxvf keepalived-2.0.18.tar.gz cd keepalived-2.0.18 ./configure make && make install
安裝以後,在 etc 裏面生成目錄 keepalived,有文件 keepalived.conf 。
這個就是主配置文件。
主從模式主要在這個文件裏配置。
修改/etc/keepalived/keepalivec.conf 配置文件
global_defs { notification_email { acassen@firewall.loc failover@firewall.loc sysadmin@firewall.loc } notification_email_from Alexandre.Cassen@firewall.loc smtp_server 208.208.128.122 smtp_connect_timeout 30 router_id LVS_DEVEL } vrrp_script chk_http_port { script "/usr/local/src/nginx_check.sh" interval 2 #(檢測腳本執行的間隔) weight 2 } vrrp_instance VI_1 { state MASTER # 備份服務器上將 MASTER 改成 BACKUP interface ens192 //網卡 virtual_router_id 51 # 主、備機的 virtual_router_id 必須相同 priority 100 # 主、備機取不一樣的優先級,主機值較大,備份機值較小 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 208.208.128.50 // VRRP H 虛擬地址 } }
在/usr/local/src 添加檢測腳本
#!/bin/bash A=`ps -C nginx –no-header |wc -l` if [ $A -eq 0 ];then /usr/local/nginx/sbin/nginx sleep 2 if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then killall keepalived fi fi
把兩臺服務器上 nginx 和 keepalived 啓動 :
啓動 nginx:./nginx
啓動 keepalived:systemctl start keepalived.service
85服務同樣。
nginx 啓動後,是由兩個進程組成的。master(管理者)和worker(工做者)。
一個nginx 只有一個master。但能夠有多個worker
,過來的請求由master管理,worker進行爭搶式的方式去獲取請求。
Nginx 同 redis 相似都採用了 io 多路複用機制,每一個 worker 都是一個獨立的進程,但每一個進 程裏只有一個主線程,經過異步非阻塞的方式來處理請求, 即便是千上萬個請求也不在話 下。每一個 worker 的線程能夠把一個 cpu 的性能發揮到極致。因此 worker 數和服務器的 cpu 數相等是最爲適宜的。設少了會浪費 cpu,設多了會形成 cpu 頻繁切換上下文帶來的損耗。
第一個:發送請求,佔用了 woker 的幾個鏈接數?
第二個:nginx 有一個 master,有四個 woker,每一個 woker 支持最大的鏈接數 1024,支持的 最大併發數是多少?
這個值是表示每一個 worker 進程所能創建鏈接的最大值,因此,一個 nginx 能創建的最大鏈接 數,應該是 worker_connections * worker_processes。固然,這裏說的是最大鏈接數,對於 HTTP 請 求 本 地 資 源 來 說 , 能 夠 支 持 的 最 大 並 發 數 量 是 worker_connections * worker_processes,若是是支持 http1.1 的瀏覽器每次訪問要佔兩個鏈接,因此普通的靜態訪 問最大併發數是: worker_connections * worker_processes /2,而若是是 HTTP 做 爲反向代 理來講,最大併發數量應該是 worker_connections * worker_processes/4。由於做爲反向代理服務器,每一個併發會創建與客戶端的鏈接和與後端服 務的鏈接,會佔用兩個鏈接。