爽吗你个小浪货叫大声点,男倌被各种玉势开菊男男,老公每晚吃咪咪乳房会变大吗

大家好，我是前端dog君，一名95后前端小兵。2019年畢業于北京化工大學，天津人，不知道有校友和老鄉嘛？對前端的熱愛，讓我們在此相聚，希望這篇文章，能幫助到您，也同時希望能交到志同道合的小伙伴，共同發展，一起進步。我的微信號dm120225，備注簡書，期待您的光臨。

上一篇我們聊了聊docker的基本操作，鏈接：寫給前端的docker簡明教程。那么這一篇，我們就用docker安裝nginx，聊一聊nginx的基本操作。

我們將會從以下幾部分展開：nginx介紹、nginx原理、nginx安裝、nginx配置、nginx應用，一步步的和大家一起學習nginx。

nginx介紹

定義

我們先來看下nginx的基本定義吧：

nginx是一個高性能的http和反向代理的web服務器，同時也提供了IMAP POP3 SMTP服務。

不過我們一般不使用nginx作為郵件服務器，最多的用途，是利用nginx高性能的http部署應用和反向代理做轉發。說到這，我們看一下兩個基本概念，正向代理和反向代理有什么區別。

正向代理和反向打理

實踐中客戶端無法直接跟服務端發起請求的時候，我們就需要代理服務。代理可以實現客戶端與服務端之間的通信,我們的Nginx也可以實現相應的代理服務。

正向代理

客戶端 <一> 代理一>服務端

我們簡單地打個租房的比方:

A(客戶端)想租C(服務端)的房子,但是A(客戶端)并不認識C(服務端)租不到。
B(代理)認識C(服務端)能租這個房子所以你找了B(代理)幫忙租到了這個房子。

這個過程中C(服務端)不認識A(客戶端)只認識B(代理)
C(服務端)并不知道A(客戶端)租了房子，只知道房子租給了B(代理)。

反向代理

客戶端一>代理 <一> 服務端

我們也用一個租房的例子:

A(客戶端)想租一個房子,B(代理)就把這個房子租給了他。
這時候實際上C(服務端)才是房東。
B(代理)是中介把這個房子租給了A(客戶端)。

這個過程中A(客戶端)并不知道這個房子到底誰才是房東
他都有可能認為這個房子就是B(代理)的

由上的例子和圖我們可以知道，正向代理和反向代理的區別在于代理的對象不一樣,正向代理的代理對象是客戶端,反向代理的代理對象是服務端。

優缺點

了解了正向代理和反向代理的區別后，我們來看下nginx的優缺點。

優點

高并發量

nginx采用了異步非阻塞的方式來處理請求，能夠支持高達5w個并發連接數的響應。

內存消耗小

nginx采用的事件處理方式，與多線程相比，不需要創建線程，每個請求占用的內存很少，也沒有上下文切換，事件處理非常輕量級。

簡單穩定

配置簡單（在conf文件中配置）性能穩定（nginx采用了分階段資源分配技術，使cpu內存占有率非常低，具有很高的穩定性）。

模塊化程度高

nginx是高度模塊化設計。

低成本

nginx是開源免費的。

內置的健康檢查功能

如果 nginx代理后端的某臺web服務宕機了，不會影響前端訪問
節省帶寬，會直接剔除掉。

支持熱部署

啟動特別容易，并且幾乎可以做到724小時不間斷運行*，即使運行數月也不需要重新啟動。還能夠在不間斷服務的情況下，對軟件版本進行升級。

缺點

適用范圍小

nginx僅能支持http，https和Email協議，這樣就在適用范圍上面小些。

nginx不支持url來檢測

對后端服務的健康檢查，只支持通過端口來檢測，不支持通過url來檢測。

不支持session的直接保持

可通過ip_hash來解決。

nginx原理

現在我們對nginx已經有了一些初步認識了。下面我們一起來看下nginx的原理。

工作過程：
nginx在啟動后，會有一個master進程和多個worker進程，master進程主要用來管理worker進程，包含：接收來自外界的信號，向各worker進程發送信號，監控worker進程的運行狀態，當worker進程退出后（異常情況下），會自動重新啟動新的worker進程。而基本的網絡事件，則是放在了worker進程中來處理。多個worker進程之間是對等的，他們同等競爭來自客戶端的請求，各進程互相之間是獨立的。一個請求，只可能在一個worker進程中處理，一個worker進程，不可能處理其他進程的請求。worker進程的個數是可以設置的，一般我們會設置與機器的cpu核數一致（這里面的原因與nginx的進程模型以及事件處理模型分不開的）

nginx安裝

我們了解完nginx是什么，有什么特點，基本原理后，下面就一起來使用docker來安裝nginx，體驗一下nginx。

我們編寫的docker-compose.yml文件內容如下:

# docker-compose.yml

version: '3.1'
services:
  nginx:
    restart: always
    image: daocloud.io/library/nginx:1.7.8
    container_name: nginx
    ports:
      - 80:80
    volumes:
      - volumes:/etc/nginx
volumes:
  volumes: {}

我們在服務器上新建一個nginx目錄將docker-compose.yml放進去。這里要給大家解釋下數據卷為什么這么寫。docker-compose根據這個配置文件去執行，執行到volumes時，會自動根據映射一個數據卷，數據卷名稱為當前目錄名+volumes，如下：

可以看到，我們在nginx目錄下使用docker-compose啟動nginx，自動創建了一個叫nginx_volumes的數據卷。默認nginx的安裝目錄在/etc/nginx，我們來看下nginx數據卷nginx_volumes都有什么內容。

可以看到nginx數據卷中有如上的文件。說明我們的數據卷也映射成功，接下來我們訪問下nginx。

出現了如上界面，說明我們的nginx安裝并啟動成功。

nginx配置

安裝好了nginx后，我們來看下nginx都可能會有什么配置。nginx的配置文件是nginx.conf，我們已經在數據卷中映射出來了，我們來看下都有什么內容。

我們可以看到，這里在最后又 include 了 /etc/nginx/conf.d目錄下所有以conf結尾的文件，我們來看下都有什么內容。

我們打開default.conf

這里我們截取了部分內容。關于nginx的使用，核心可以說是去修改這個配置文件。我們來整理一下，針對這些配置文件做些介紹，來看下都是干什么用的。

整體介紹

nginx共分為三塊：main（全局塊）、events（塊）、http塊

main（全局塊）

從配置文件開始到events塊之間的內容，主要控制nginx子進程所屬的用戶和用戶組，派生子進程數，錯誤日志位置和級別，pid位置等。

events塊

events塊主要影響nginx服務器與用戶的網絡連接，常用的設置包括是否開啟對多work_process下的網絡連接進行序列化，是否允許同時接收多個網絡連接，選取哪種事件驅動模型來處理連接請求，每個work_process可以同時支持的最大連接數等。

http塊

http塊包括http-全局塊、http-server塊、upstream 塊。可以嵌套多個server，配置代理，緩存，日志定義等絕大多數功能和第三方模塊的配置。這是我們最重要的配置，以后我們的大部分配置工作是在http塊下完成的。

http-server塊

nginx中主機的配置塊，可用于配置多個虛擬主機，每個server塊就相當于一個虛擬主機。

upstream 塊

配置負載均衡。

http-server-location 塊

一個server塊可以配置多個location塊，這塊的主要作用是基于nginx服務器接收到的請求路徑，對虛擬主機名稱之外的字符串進行匹配，對待定的請求進行處理。

配置詳解

#定義Nginx運行的用戶和用戶組
user www www;
#
#nginx進程數,建議設置為等于CPU總核心數.
worker_processes 8;
#
#全局錯誤日志定義類型,[ debug | info | notice | warn | error | crit ]
error_log /var/log/nginx/error.log info;
#
#進程文件
pid /var/run/nginx.pid;
#
#一個nginx進程打開的最多文件描述符數目,理論值應該是最多打開文件數（系統的值ulimit -n）與nginx進程數相除,但是nginx分配請求并不均勻,所以建議與ulimit -n的值保持一致.
worker_rlimit_nofile 65535;
#
#工作模式與連接數上限
events
{
    #參考事件模型,use [ kqueue | rtsig | epoll | /dev/poll | select | poll ]; epoll模型是Linux 2.6以上版本內核中的高性能網絡I/O模型,如果跑在FreeBSD上面,就用kqueue模型.
    use epoll;
    #單個進程最大連接數（最大連接數=連接數*進程數）
    worker_connections 1024;    #最大連接數，默認為512
}
#
#設定http服務器
http
{
    include mime.types; #文件擴展名與文件類型映射表
    default_type application/octet-stream; #默認文件類型，文件流形式
    #charset utf-8; #默認編碼
    server_names_hash_bucket_size 128; #服務器名字的hash表大小
    client_header_buffer_size 32k; #上傳文件大小限制
    large_client_header_buffers 4 64k; #設定請求緩
    client_max_body_size 8m; #設定請求緩
      keepalive_timeout 65;  #連接超時時間，默認為75s，可以在http，server，location塊。
    # 開啟目錄列表訪問,合適下載服務器,默認關閉.
    autoindex on; # 顯示目錄
    autoindex_exact_size on; # 顯示文件大小 默認為on,顯示出文件的確切大小,單位是bytes 改為off后,顯示出文件的大概大小,單位是kB或者MB或者GB
    autoindex_localtime on; # 顯示文件時間 默認為off,顯示的文件時間為GMT時間 改為on后,顯示的文件時間為文件的服務器時間
    
    sendfile on; # 開啟高效文件傳輸模式,sendfile指令指定nginx是否調用sendfile函數來輸出文件,對于普通應用設為 on,如果用來進行下載等應用磁盤IO重負載應用,可設置為off,以平衡磁盤與網絡I/O處理速度,降低系統的負載.注意：如果圖片顯示不正常把這個改成off.
    tcp_nopush on; # 防止網絡阻塞
    tcp_nodelay on; # 防止網絡阻塞
    
    
    # FastCGI相關參數是為了改善網站的性能：減少資源占用,提高訪問速度.下面參數看字面意思都能理解.
    fastcgi_connect_timeout 300; ## 鏈接
    fastcgi_send_timeout 300;  ##讀取 是指nginx進程向fastcgi進程發送request的整個過程的超時時間
    fastcgi_read_timeout 300;  ##發請求 是指fastcgi進程向nginx進程發送response的整個過程的超時時間
    fastcgi_buffer_size 64k;
    fastcgi_buffers 4 64k;
    fastcgi_busy_buffers_size 128k;
    fastcgi_temp_file_write_size 128k;
    
    # gzip模塊設置
    gzip on; #開啟gzip壓縮輸出
    gzip_min_length 1k; #允許壓縮的頁面的最小字節數,頁面字節數從header偷得content-length中獲取.默認是0,不管頁面多大都進行壓縮.建議設置成大于1k的字節數,小于1k可能會越壓越大
    gzip_buffers 4 16k; #表示申請4個單位為16k的內存作為壓縮結果流緩存,默認值是申請與原始數據大小相同的內存空間來存儲gzip壓縮結果
    gzip_http_version 1.1; #壓縮版本（默認1.1,目前大部分瀏覽器已經支持gzip解壓.前端如果是squid2.5請使用1.0）
    gzip_comp_level 2; #壓縮等級.1壓縮比最小,處理速度快.9壓縮比最大,比較消耗cpu資源,處理速度最慢,但是因為壓縮比最大,所以包最小,傳輸速度快
    gzip_types text/plain application/x-javascript text/css application/xml;
    #壓縮類型,默認就已經包含text/html,所以下面就不用再寫了,寫上去也不會有問題,但是會有一個warn.
    gzip_vary on;#選項可以讓前端的緩存服務器緩存經過gzip壓縮的頁面.例如:用squid緩存經過nginx壓縮的數據
    
    #開啟限制IP連接數的時候需要使用
    #limit_zone crawler $binary_remote_addr 10m;
    
    #虛擬主機的配置
    server
    {
        # 監聽端口
        listen 80;
        # 域名可以有多個,用空格隔開
        server_name 127.0.0.1;
        # HTTP 自動跳轉 HTTPS
        rewrite ^(.*) https://www.baidu.com;
        deny 127.0.0.1;  #拒絕的ip
        allow 172.18.5.54; #允許的ip 
    }
    upstream myserver {   
      server 127.0.0.1:8080;
      server 192.168.24.189:8080 backup;  #熱備
    }
    server
    {
        # 監聽端口 HTTPS
        listen 443 ssl;
        server_name https://www.baidu.com;
        root /data/www/;
        # 配置域名證書
        ssl_certificate      C:\WebServer\Certs\certificate.crt;
        ssl_certificate_key  C:\WebServer\Certs\private.key;
        ssl_session_cache    shared:SSL:1m;
        ssl_session_timeout  5m;
        ssl_protocols SSLv2 SSLv3 TLSv1;
        ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
        ssl_prefer_server_ciphers  on;
    
        index index.html index.htm index.php;
        
        location ~ .*\.(php|php5)?$
        {
            fastcgi_pass 127.0.0.1:9000;
            fastcgi_index index.php;
            include fastcgi.conf;
        }
        
        # 配置地址攔截轉發，解決跨域驗證問題
        location /oauth/{
            proxy_pass https://localhost:13580/oauth/;
            proxy_set_header HOST $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
        
        # 圖片緩存時間設置
        location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ {
            expires 10d;
        }
        
        # JS和CSS緩存時間設置
        location ~ .*\.(js|css)?$ {
            expires 1h;
        }

        # 日志格式設定
        log_format access '$server_name $remote_addr -$remote_user [$time_local] "$request"'
                  '$status $uptream_status $body_bytes_sent "$http_referer"'
                  '"$http_user_agent" "$http_x_forwarded_for" '
                  '$ssl_protocol $ssl_cipher $upstream_addr $request_time $upstream_response_time';
       # 定義本虛擬主機的訪問日志
        access_log /var/log/nginx/access.log access;
        
        # 設定查看Nginx狀態的地址.StubStatus模塊能夠獲取Nginx自上次啟動以來的工作狀態，此模塊非核心模塊，需要在Nginx編譯安裝時手工指定才能使用
        location /NginxStatus {
            stub_status on;
            access_log on;
            auth_basic "NginxStatus";
            auth_basic_user_file conf/htpasswd;
            #htpasswd文件的內容可以用apache提供的htpasswd工具來產生.
        }
    }
}

內置變量

$remote_addr:客戶端的IP地址
$remote_user:客戶端用戶名，用于記錄瀏覽者進行身份驗證時提供的名稱，如果沒有登錄，則為空
$time_local 訪問的時間和時區   如21/Sep/ 2016:12:21:15 + 0800  時間信息最后的+0800表示服務器所處時區位于UTC之后的8小時
$request 請求的URI和HTTP協議  如GET/HTTP/1.1
$status 記錄請求返回的HTTP狀態碼  如 200（成功）
$body_bytes_sent 發送給客戶端的文件主體內容大小 如899
$http_referer   來路URL地址
$http_user_agent   客戶端瀏覽器信息
$http_x_forwarded for   客戶端ip地址列表（包括中間經過的代理）

以上的nginx配置是比較全的了，里面涉及到的像work_process 指令，$remote_addr等內置變量和其他配置，下面附上了大佬們的參考鏈接，大家可以詳細的進行查看。下面我們針對location塊的匹配做一個簡單的介紹。

location匹配

介紹

location指令是http模塊當中最核心的一項配置，根據預先定義的URL匹配規則來接收用戶發送的請求，根據匹配結果，將請求轉發到后臺服務器、非法的請求直接拒絕并返回403、404、500錯誤處理等。

語法

nginx官方文檔給出location語法如下：

location [=|~|~*|^~] uri { … }
其中，方括號中的四種標識符是可選項，用來改變請求字符串和uri的匹配方式。uri是待匹配的請求字符串，可以是不包含正則的字符串，這種模式被稱為“標準的uri"；也可以包含正則，這種模式被稱為"正則uri"，如下：

location ~ .*\.(php|php5)?$ { }

uri匹配模式

location指令分為兩種匹配模式：

普通字符串匹配：以=開頭或開頭無引導字符（～）的規則
正則匹配：以～或～開頭表示正則匹配，~表示正則不區分大小寫

= 精確匹配；用于標準uri前，要求請求字符串和uri嚴格匹配。如果匹配成功，就停止匹配，立即執行該location里面的請求。
~ 正則匹配；用于正則uri前，表示uri里面包含正則，并且區分大小寫。
~* 正則匹配；用于正則uri前，表示uri里面包含正則，不區分大小寫。
^~ 非正則匹配；用于標準uri前，nginx服務器匹配到前綴最多的uri后就結束，該模式匹配成功后，不會使用正則匹配。
無普通匹配（最長字符匹配）；與location順序無關，是按照匹配的長短來取匹配結果。若完全匹配，就停止匹配。

uri 匹配規則

當nginx收到一個請求后，會截取請求的URI部份，去搜索所有location指令中定義的URI匹配模式。在server模塊中可以定義多個location指令來匹配不同的url請求，多個不同location配置的URI匹配模式，總體的匹配原則是：先匹配普通字符串模式（普通匹配，匹配到會暫存，繼續搜索正則匹配），再匹配正則模式(正則模式匹配到，即為最終匹配)。只識別URI部份，例如請求為：/test/abc/user.do?name=xxxx

一個請求過來后，Nginx匹配這個請求的流程如下：

先查找是否有=開頭的精確匹配
如：location = /test/abc/user.do { … }
再查找普通匹配
以 最大前綴 為原則，如有以下兩個location，則會匹配后一項
location /test/ { … } location /test/abc { … }

匹配到一個普通格式后，搜索并未結束，而是暫存當前匹配的結果，并繼續搜索正則匹配模式

所有正則匹配模式location中找到第一個匹配項后，就以此項為最終匹配結果

所以正則匹配項匹配規則，受定義的前后順序影響，但普通匹配模式不會

如果未找到正則匹配項，則以普通匹配中緩存的結果為最終匹配結果

如果一個匹配都沒搜索到，則返回404

綜上所述：location匹配優先級為：

（精確匹配 = ）> (最長字符串匹配，但完全匹配 /xxx/yyy/zzz) >（非正則匹配 ^~）>（正則匹配 ~ ~*）>（最長字符串匹配，不完全匹配 /abc）>（location通配 / /abc）

nginx應用

下面呢，我們一起來看下，nginx在我們工作中都會有什么用途。

web服務器

我們先來看下nginx定義

nginx是一個高性能的http和反向代理的web服務器，同時也提供了IMAP POP3 SMTP服務

nginx是一個web服務器，實際上，當我們啟動了nginx之后，訪問80端口，我們已經可以看到一個界面，這就是nginx作為web服務器的一個應用。下面我們就一起來部署一個web應用。

新增nginx配置文件location模塊，配置如下：

現在我們已經有了web1項目

重啟nginx

瀏覽器訪問 /web1

這就是nginx作為web服務器最簡單的例子?？蛻舳送ㄟ^瀏覽器訪問，nginx截取/web1字符串拿到location中按照匹配原則進行匹配，匹配到了之后返回相應的資源。

反向代理

前面我們已經講過了什么是反向代理。但是我們為什么需要反向代理呢？實際上，在我們的前端，處理跨域請求的時候，通常情況下會直接使用webpack-dev-server為我們提供的proxy，也就是我們常說的CORS去處理跨域請求。實際上，如果我們在自己本機上搭建一臺nginx作為一個代理服務器，幫助我們將請求轉發出去，這也是一種選擇。

反向代理實際上是客戶端訪問應用，nginx作為代理服務器轉發請求到真正的服務器，真正的服務器拿到數據后給到nginx，nginx返回給客戶端。下面我們就使用tomcat作為后端服務器，nginx作為反向代理。一起來看下吧。

準備好tomcat的docker-compose.yml文件

啟動tomcat1 docker-compose up -d
輸入網址，能正常訪問

配置nginx，新增location和upstream如下：

注意：upstream和server塊同級

保存配置，重啟nginx
瀏覽器訪問/tomcat1

反向代理生效。

負載均衡

那么什么是負載均衡？我們為什么需要負載均衡？

傳統的架構是，客戶端直接訪問服務端，服務端直接客戶端返回數據。但是隨著用戶量的增大，訪問量的增大，一臺服務器無法承受原本的壓力，于是擴充了多臺服務器，就是服務器集群。那么我們的用戶訪問，比如說http://www.baidu.com，我們訪問百度，只需要記住一個地址就可以了，而背后可能有成千上萬臺服務器，我們不可能去記住所有服務器的ip地址和端口號，我們只想記住一個域名就可以直接訪問應用。nginx就是來幫助我們解決這個問題的。

用戶發送請求，訪問的是nginx。nginx對用戶發送過來的請求進行轉發，那么按照什么策略進行轉發，能保證服務器的利用比較充分，用戶能夠流暢的進行訪問，并且不會宕機，這就是我們說的nginx負載均衡。nginx為我們提供了多種負載均衡策略，包括但不限于輪詢、權重、ip_hash、fair、least_conn等，這里我們介紹比較常用的前三種。

為了演示負載均衡，首先我們準備兩個tomcat服務，這里我們直接看下效果。

訪問8081端口

訪問8082端口

到此呢，我們的兩個tomcat服務和nginx已經準備好，下面介紹下nginx的負載均衡策略。

輪詢

將客戶端發起的請求，平均的分配給每一臺服務器。

這是nginx默認的負載均衡策略，我們在nginx中配置下

進入nginx的數據卷
對conf.d 的default.conf進行配置

配置結束后重啟nginx

我們可以看到，當客戶端發送請求到/tomcat1時，nginx進行轉發，轉發到兩個服務，8081和8082的tomcat服務，nginx默認采用的是輪詢策略，我們用瀏覽器訪問測試下，可以發現，頁面在tomcat1服務和tomcat2服務中跳來跳去，并且是每個服務交替訪問，這就是nginx負載均衡的輪詢策略。

權重

將客戶端的請求，根據服務器的權重值不同，分配不同的數量。

我們的服務器，在不能保證配置相同的情況下，有的服務器配置相對較低，有的服務器配置相對較高，那么我們就讓配置較高的服務器多處理請求，配置較低的服務器少處理請求，這就用到了權重策略。我們在nginx中配置感受下：

配置權重策略

我們只需要將upstream中的服務后添加weight參數即可。途中配置代表如果來了5個請求，81端口的tomcat服務處理4次，82端口的tomcat服務處理1次。

重啟nginx

我們用瀏覽器訪問測試下，可以看到,連續訪問5次，有4次是被tomcat1服務處理的，有1次是被tomcat2處理的，這就是nginx負載均衡的權重策略。

ip_hash

基于發起請求的客戶端的ip地址不同，始終會將請求發送到指定的服務器上。

上面的兩種方法可能存在一個問題，就是我們如果不在一臺服務器去處理請求的話，用戶第一次訪問tomcat1服務，第二次訪問tomcat2服務，那就造成了session丟失的問題。那么為什么會這樣呢？我們簡單的理解下cookie session鑒權策略
用戶輸入賬號密碼，向服務端發送請求，服務端校驗通過后給服務端種cookie，cookie中存有session_id字段，服務端存儲session作為唯一標識，下次用戶再訪問從cookie中讀取session_id，和服務端存儲的session進行對比，如果能找到，那么給客戶端返回數據。

那么如果我們第一次訪問tomcat1服務，第二次訪問tomcat2服務，假設session存儲在tomcat1服務中，那么自然tomcat2中拿不到用戶的session，這就造成了session丟失的問題。那么怎么解決這個問題呢？

1.我們可以弄一臺session服務器專門存儲session，為多個服務器共享，這樣問題就解決了，但是久而久之，session服務器數據越來越大，或許還需要一個session集群。

2.基于token的鑒權策略。用戶登錄成功后，我們給用戶簽發一個token，用戶每次請求都帶來這個token，服務端進行解析，能正確解析出來數據，給客戶端返回數據。解析的過程是在程序計算出來的，也就是說，這個算法，每臺服務器都存在，可以解決這個問題。

3.基于nginx的ip_hash策略。這就是我們這里來介紹的，nginx負載均衡中的ip_hash策略可以解決問題。用戶來訪問，nginx對其ip進行hash運算，存儲起來，指定一個服務器為用戶處理請求。那么下次用戶再來訪問時，就會一直訪問這臺服務器。

以上是對cookie session token的簡單了解，詳細解讀可以看dog君的另一篇文章：一文讀懂cookie session token

下面我們就對nginx的ip_hash策略進行配置，nginx配置如下：

實際上，我們只需要在upstream塊中添加ip_hash即可，重啟nginx，我們來測試下：可以看到，一直訪問的都是tomcat1服務。那么為什么不是tomcat2服務呢？因為tomcat1服務的權重比較大，第一次訪問的是tomcat1服務，又因為有ip_hash策略，所以后面訪問的一直都是tomcat1服務了。

動靜分離

為了加快網站的解析速度，可以把動態頁面和靜態頁面由不同的服務器解析，加快解析速度，降低原來單個服務器的壓力

比如說，我們的圖片，js文件，css文件，html頁面，都可以放在nginx中，nginx的高性能http來幫助我們處理這些請求。像jsp等動態頁面，可以放在tomcat中來去處理。

這就是nginx的動靜分離，巧妙地運用了nginx可以作為web服務器的特點。

一些計算

nginx能建立的最大連接數 worker_connections * worker_processes
HTTP請求本地資源支持最大并發數量 worker_connections * worker_processes
HTTP作為反向代理支持最大并發數 worker_connections * worker_processes / 2

接上面的動靜分離，這里給出一個nginx并發能力的計算公式：
worker_connections * worker_processes / 4 | 2 = nginx最終的并發能力

動態資源除以4，靜態資源除以2，因為動態資源，nginx是作為反向代理存在的，客戶端發送請求給nginx，nginx發送請求給服務端，服務端返回響應給nginx，nginx返回響應給客戶端，一次請求，建立了4次連接。

那么我們如果動靜分離的話，靜態資源交給nginx來處理，客戶端發送請求給nginx，nginx直接返回給客戶端，那么只建立了兩次請求。所以說，動靜分離，會提高nginx的并發能力。

總結

那么到此為止呢，我們的nginx已經介紹完畢了。對于nginx，以上內容只是皮毛，強大的nginx考慮到了我們多種應用場景，太多的配置供我們選擇，比如說upstream 中的backup，設置備用機，作為代理服務器可以修改請求頭和響應頭等等，備用機可以作為我們進行版本升級發布時進行用戶無感知熱更新，那么作為代理服務器，大家想到他可以做什么呢？這個問題留給大家來思考啦！最后，給大家附上一個彩蛋吧，我們在vue項目中如何使用nginx進行無感知發版，也是某大神的良心之作
vue項目部署的最佳實踐,實現無感知發版

參考鏈接：
16張圖入門nginx
nginx配置文件詳解
 nginx配置中location匹配規則詳解

我是前端dog君，一名95后前端小兵。對前端的熱愛，讓我們在此相聚，希望這篇文章，能幫助到您，也同時希望能交到志同道合的小伙伴，共同發展，一起進步。我的微信號dm120225，備注簡書，期待您的光臨。

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美 国产 综合 欧美 视频

寫給前端的nginx簡明教程

nginx介紹

定義

正向代理和反向打理

正向代理

反向代理

優缺點

優點

高并發量

內存消耗小

簡單穩定

模塊化程度高

低成本

內置的健康檢查功能

支持熱部署

缺點

適用范圍小

nginx不支持url來檢測

不支持session的直接保持

nginx原理

nginx安裝

nginx配置

整體介紹

main（全局塊）

events塊

http塊

http-server塊

upstream 塊

http-server-location 塊

配置詳解

內置變量

location匹配

介紹

語法

uri匹配模式

uri 匹配規則

nginx應用

web服務器

反向代理

負載均衡

輪詢

權重

ip_hash

動靜分離

一些計算

總結

推薦閱讀更多精彩內容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频