一篇文章讀懂Nginx的負載均衡，緩存和跨域

1.OSI網絡模型

網絡模型就是 OSI（Open System Interconnect），意思爲開放網絡互聯，是由國際標準化組織(ISO)和國際電報電話諮詢委員會(CCITT)共同出版的，他是一種網絡互聯模型，也是一種規範。

網絡模型分爲七層，也就是當用戶發起請求到服務器接收，會歷經七道工序，或者說用戶利用互聯網發送消息給另一個用戶，也會歷經七道工序。這七層可以分爲如下：

層級	名稱	說明
第七層	應用層	與用戶行爲交互
第六層	表示層	定義數據格式以及數據加密
第五層	會話層	創建、管理以及銷燬會話
第四層	傳輸層	創建、管理請求端到響應端（端到端）的連接
第三層	網絡層	請求端的IP地址
第二層	數據鏈路層	提供介質訪問與鏈路管理
第一層	物理層	傳輸介質，物理媒介

以上七層每層可以與上下相鄰層進行通信。每一層都是非常複雜的，我們不在這裏深究，我們以舉例的形式來闡述每一層是幹嘛的。

應用層：這是面向用戶的，最靠近用戶，爲了讓用戶和計算機交互，在計算機裏會有很多軟件，比如eclipse，idea，qq，nginx等，這些都是應用軟件，用戶可以通過這些應用軟件和計算機交互，交互的過程其實就是接口的調用，應用層爲用戶提供了交互的接口，以此爲用戶提供交互服務。那麼在這一層最常見的協議有：HTTP,HTTPS,FTP,SMTP,POP3等。Nginx在本層，爲七層負載均衡。
```
  舉例：我要寄一封信給遠在天邊的老外LiLei，我會打開快遞軟件下單，這個時候我是用戶，快遞軟件就是應用服務，是建立在計算機上的，提供給用戶交互的一種服務或稱之爲手段。
```

表示層：該層提供數據格式編碼以及加密功能，確保請求端的數據能被響應端的應用層識別。

  舉例：我寫中文給LiLei，他看不懂，這個時候我就會使用翻譯軟件把中文翻譯成英文，隨後信中涉及到一些比較隱私的信息我會加密一下，這個時候翻譯軟件和加密器就充當了表示層的作用，他用於顯示用戶能夠識別的內容。

會話層：會話可以理解爲session，請求發送到接受響應的這個過程之間存在會話，會話層就充當了這一過程的管理者，從創建會話到維護會話最後銷燬會話。

  舉例：我每次寫信給LiLei都會記錄在一個小本本上，寄信時間日期，收信時間日期，這本小本本上存有每次通信記錄，這個小本本就相當於是一個會話的管理者。又或者說，我們平時在打電話，首先需要撥打電話，這是建立會話，對方接聽電話，此時正在通話（維持並管理會話），通話結束後會話銷燬，那麼這也是一次會話的生命週期。

傳輸層：該層建立端到端的連接，他提供了數據傳輸服務，在傳輸層通信會涉及到端口號，本層常見的協議爲TCP、UDP，LVS就是在傳輸層，也就是四層負載均衡。
```
  舉例：我和LiLei通信過程中會藉助快遞公司，快遞公司會分配快遞員取件和寄件，那麼這個快遞員則充當傳輸層的作用。
```
網絡層：網絡通信的時候必須要有本機IP和對方的IP，請求端和響應端都會有自己的IP的，IP就相當於你家地址門牌號，在網絡上雲服務器有固定的公網IP，普通計算機也有，只不過是動態IP，運營商每天會分配不同的IP給你的計算機。所以網絡層也能稱之爲IP層，IP是互聯網的基礎根本。能提供IP分配的設備則爲路由器或交換機。
```
  舉：對於擁有固定IP的雲服務來說，他們都是由騰訊雲、阿里雲等這樣的供應商提供的，他們爲雲服務器提供固定ip；電信、移動、聯調等運營商爲你的計算機動態分配ip，每天都不同；則這些供應商和運營商都是網絡層。同理，快遞員由物流公司分配和管理，那麼物流公司就是網絡層咯。
```

數據鏈路層：這一層會提供計算機MAC地址，通信的時候會攜帶，爲了確保請求投遞正確，所以他會驗證檢測MAC地址，以確保請求響應的可靠性。

  舉例：快遞員在投遞派送的時候，他（或客服）會預先提前打電話給你，確認你家地址對不對、有沒有人、貨到付款有沒有準備好錢等等，這個時候快遞員（或客服）就充當了數據鏈路層的職責。

物理層：端到端請求響應過程中的媒介，物理介質，比如網線、中繼器等等設備，都是你在端到端交互過程中不可缺少的基礎設備。

  舉例：快遞員在投遞的過程中，你寫的信會歷經一些交通運輸工具，比如首先通過飛機運輸到國外，在海關統一拿到信以後會通過汽車運輸到LiLei所在城市的物流集散地，最後快遞員通過三輪電頻車寄到LiLei家裏，這個時候，飛機、汽車、三輪電瓶車都是物理層的媒介。

以上就是七層網絡模型，大家理解其意義即可。需要注意的是Nginx存在於第七層，屬於七層負載均衡；而第四層會有LVS，屬於四層負載均衡。

2.Nginx的集羣負載均衡解析

負載均衡：當有大量的併發請求來到服務器的時候，把這些請求分配到多臺計算機節點上，讓更多的節點來處理請求和響應，來大大的減少用戶的等待時間

2.1 負載均衡分類

四層負載均衡：ip+端口形式進行負載均衡，通過轉發到後臺的服務器，通過轉發並且會記錄是由哪個服務器處理的，當下一次請求進來時還是讓同一臺服務器來處理請求，相當於長連接，一旦打開就會一直處於連接狀態，是傳輸層基於TCP和UDP
七層負載均衡：基於URL或ip的負載均衡，是應用層的，基於HTTP協議的負載均衡

2.2 Nginx配置集羣

# 配置上游服務器模塊
upstream tomcats{
    server 192.168.1.173:8080;
    server 192.168.1.174:8080;
    server 192.168.1.175:8080;
}
server {
    listen 80;
    server_name ww.tomcats.com;
    location /{
        #引用上游服務器塊
        proxy_pass http://tomcats;
    }
}

2.3 Nginx 負載均衡策略

方式名	分配方式
輪詢（默認方式）	平均分配
權重	按照比重分配
ip_hash	依據ip分配
least_conn	最少連接方式
fair	響應時間
url_hash	依據URL分配方式

權重配置方式

upstream tomcats{
    server 192.168.1.173:8080 weight=1;
    server 192.168.1.174:8080 weight=2;
    server 192.168.1.175:8080 weight=3;
}

ip_hash配置方式

upstream tomcats{

    ip_hash
    server 192.168.1.173:8080; 
    server 192.168.1.174:8080;
    server 192.168.1.175:8080;
}

least_conn配置方式

upstream tomcats{

    least_conn;
    server 192.168.1.173:8080;
    server 192.168.1.174:8080;
    server 192.168.1.175:8080;
}

fair配置方式

upstream tomcats{

    fair
    server 192.168.1.173:8080;
    server 192.168.1.174:8080;
    server 192.168.1.175:8080;
}

url配置方式

upstream tomcats{

    hash $request_uri;
    server 192.168.1.173:8080;
    server 192.168.1.174:8080;
    server 192.168.1.175:8080;
}

2.4 upstream指令參數

max_conns：限制每臺server的連接數，用於保護避免過載，可起到限流作用。
測試參考配置如下：

# worker進程設置1個，便於測試觀察成功的連接數
worker_processes  1;

upstream tomcats {
        server 192.168.1.173:8080 max_conns=2;
        server 192.168.1.174:8080 max_conns=2;
        server 192.168.1.175:8080 max_conns=2;
}

slow_start:使某一臺服務器慢慢的加入到集羣當中
注：商業版，需要付費
配置參考如下：

upstream tomcats {
        server 192.168.1.173:8080 weight=6 slow_start=60s;
#       server 192.168.1.190:8080;
        server 192.168.1.174:8080 weight=2;
        server 192.168.1.175:8080 weight=2;
}

注意：該參數不能使用在hash和random load balancing中。如果在 upstream 中只有一臺 server，則該參數失效。

down:用於標記服務節點不可用
配置參考如下：

upstream tomcats {
        server 192.168.1.173:8080 down;
        server 192.168.1.174:8080 weight=1;
        server 192.168.1.175:8080 weight=1;
}

backup:表示當前服務器節點是備用機，只有在其他的服務器都宕機以後，自己纔會加入到集羣中，被用戶訪問到：
配置參考如下：

upstream tomcats {
        server 192.168.1.173:8080 backup;
        server 192.168.1.174:8080 weight=1;
        server 192.168.1.175:8080 weight=1;
}

max_fails：表示失敗幾次，則標記server已宕機，剔出上游服務。
fail_timeout：表示失敗的重試時間。

假設目前設置如下：
max_fails=2 fail_timeout=15s
則代表在15秒內請求某一server失敗達到2次後，則認爲該server已經掛了或者宕機了，隨後再過15秒，這15秒內不會有新的請求到達剛剛掛掉的節點上，而是會請求到正常運作的server，15秒後會再有新請求嘗試連接掛掉的server，如果還是失敗，重複上一過程，直到恢復。

Keepalived 提高吞吐量
keepalived：設置長連接處理的數量
proxy_http_version：設置長連接http版本爲1.1
proxy_set_header：清除connection header 信息

upstream tomcats {
#       server 192.168.1.173:8080 max_fails=2 fail_timeout=1s;
#       server 192.168.1.174:8080 weight=1;
#       server 192.168.1.175:8080 weight=1;
        keepalive 32;
}

server {
        listen       80;
        server_name  www.tomcats.com;

        location / {
            proxy_pass  http://tomcats;
            proxy_http_version 1.1;
            proxy_set_header Connection "";
        }
    }

3.ip_hash算法與一致性hash算法

ip_hash：通過對ip進行hash後按照服務器個數取模，然後分配到不同的服務器中，穩定的情況下可以保證每一個ip每次都請求到同一臺服務器上，但是有一個問題：當增加或移除服務器時會導致所有的用戶ip都要在重新計算分配的服務器。

一致性hash算法：將0到2的32次方減一的數做成一個環，將用戶和節點都放到這個環上，把用戶ip順時針放到離他最近的一臺服務器上，這樣增加和減少服務器之後影響到一部分用戶，而不會影響到所有用戶

4.Nginx的跨域問題

4.1 跨域資源共享（CORS）

跨域資源共享(CORS) 是一種機制，它使用額外的 HTTP 頭來告訴瀏覽器讓運行在一個 origin (domain) 上的Web應用被准許訪問來自不同源服務器上的指定的資源。當一個資源從與該資源本身所在的服務器不同的域、協議或端口請求一個資源時，資源會發起一個跨域 HTTP 請求。
CORS需要瀏覽器和服務器同時支持，纔可以實現跨域請求，目前幾乎所有瀏覽器都支持CORS，IE則不能低於IE10。CORS的整個過程都由瀏覽器自動完成，前端無需做任何設置，跟平時發送ajax請求並無差異。so，實現CORS的關鍵在於服務器，只要服務器實現CORS接口，就可以實現跨域通信。

4.2 如何解決跨域問題

目前基本上主流有三種解決方式：JsonP,SpringBoot，Nginx，我們今天來說說Nginx是如何解決跨域問題的

4.3 Nginx通過配置解決跨域問題

在server模塊中添加下面的信息

server {
            listen       88;
            server_name  localhost;
            
            #允許跨域請求的域，*代表所有 
            add_header 'Access-Control-Allow-Origin' *;
            #允許帶上cookie請求 
            add_header 'Access-Control-Allow-Credentials' 'true';
            #允許請求的方法，比如 GET/POST/PUT/DELETE 
            add_header 'Access-Control-Allow-Methods' *;
            #允許請求的header 
            add_header 'Access-Control-Allow-Headers' *;
            
            location / {
                root   html;
                index  index.html index.htm;
            }
    }

5.緩存

5.1瀏覽器緩存

加速用戶訪問，提升單個用戶（瀏覽器訪問者）體驗，緩存在本地

 location /{
        alias /home/;
    # expires 10s; 緩存10秒
    # expires @22h30m;每日22點30分清除緩存
    # expires -1h;緩存提前過期
    # expires epoch;不設置緩存
    # expires off;nginx關閉緩存，不添加頭信息
    expires max;最大緩存時間
    }

5.2 Nginx反向代理緩存

緩存在nginx端，提升所有訪問到nginx這一端的用戶
提升訪問上游（upstream）服務器的速度
用戶訪問仍然會產生請求流量

# proxy_cache_path 設置緩存目錄
#       keys_zone 設置共享內存以及佔用空間大小
#       max_size 設置緩存大小
#       inactive 超過此時間則被清理
#       use_temp_path 臨時目錄，使用後會影響nginx性能
proxy_cache_path /usr/local/nginx/upstream_cache keys_zone=mycache:5m max_size=1g inactive=1m use_temp_path=off;

location / {
    proxy_pass  http://tomcats;

    # 啓用緩存，和keys_zone一致
    proxy_cache mycache;
    # 針對200和304狀態碼緩存時間爲8小時
    proxy_cache_valid   200 304 8h;
}

6.Nginx的模塊化設計解析

Nginx的主要模塊構成

nginx croe:非常核心的內容，爲底層提供一些通信協議，也爲其他模塊和nginx運行時提供一些條件，可以把他理解成一個jmv
http:核心中的一部分
mail:與郵件相關
event module:事件模塊，在linux下的epllo，操作系統層面的處理機制
phase handler：處理客戶端的一些請求，處理後負責處理一些響應
output filter：是一個過濾器，過濾掉一些響應後在返回給客戶端
upstream：反向代理模塊，會把真正的請求轉發到真實的服務器
load balancer 負載均衡器
extend module 繼承模塊，與第三方有關

一篇文章讀懂Nginx的負載均衡，緩存和跨域

1.OSI網絡模型

2.Nginx的集羣負載均衡解析

2.1 負載均衡分類

2.2 Nginx配置集羣

2.3 Nginx 負載均衡策略

2.4 upstream指令參數

3.ip_hash算法與一致性hash算法

4.Nginx的跨域問題

4.1 跨域資源共享（CORS）

4.2 如何解決跨域問題

4.3 Nginx通過配置解決跨域問題

5.緩存

5.1瀏覽器緩存

5.2 Nginx反向代理緩存

6.Nginx的模塊化設計解析

System.Object未被引用的程序集中定義

Java 信號量（semaphore）搭配CountDownLatch 實現多線程處理循環內邏輯並限制創建線程數

【面試準備】項目經驗——接口自動化項目

站在架構師角度去看MQ

一篇文章帶你瞭解RabbitMQ基礎知識

快速搭建VUE+SpringBoot前後端分離項目

一篇文章教你瞭解和如何使用nginx

一篇文章搞懂FastDfs(全是乾貨，建議收藏）

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結