Nginx實用整理

1. nginx 簡述

    1.1Nginx是輕量級高併發HTTP服務器和反向代理服務器；同時也是一個IMAP、POP三、SMTP代理服務器；Nginx能夠做爲一個HTTP服務器進行網站的發佈處理，另外Nginx能夠做爲反向代理進行負載均衡的實現，優勢： 

• Nginx使用基於事件驅動架構，使得其能夠支持數以百萬級別的TCP鏈接
• 豐富的第三方模塊
• 跨平臺

    1.2Nginx 架構

     Nginx採用異步非阻塞【http://www.javashuo.com/article/p-tzbgifhh-bz.html】，好處有：

• 不須要建立線程，每一個請求只佔用少許的內存
• 沒有上下文切換，事件處理很是輕量

       nginx在啓動後，在unix系統中會以daemon的方式在後臺運行，後臺進程包含一個master進程和多個worker進程。固然nginx也是支持多線程的方式的，只是咱們主流的方式仍是多進程的方式，也是nginx的默認方式。

　　master進程主要用來管理worker進程，包含：接收來自外界的信號，向各worker進程發送信號，監控worker進程的運行狀態，當worker進程退出後(異常狀況下)，會自動從新啓動新的worker進程。

　　worker進程則是處理基本的網絡事件。多個worker進程之間是對等的，他們同等競爭來自客戶端的請求，各進程互相之間是獨立的。一個請求，只可能在一個worker進程中處理，一個worker進程，不可能處理其它進程的請求。

　　worker進程的個數是能夠設置的，通常咱們會設置與機器cpu核數一致。更多的worker數，只會致使進程來競爭cpu資源了，從而帶來沒必要要的上下文切換。並且，nginx爲了更好的利用多核特性，具備cpu綁定選項，咱們能夠將某一個進程綁定在某一個核上，這樣就不會由於進程的切換帶來cache的失效。

　　【驚羣現象】每一個worker進程都是從master進程fork過來。在master進程裏面，先創建好須要listen的socket以後，而後再fork出多個worker進程，這樣每一個worker進程均可以去accept這個socket(固然不是同一個socket，只是每一個進程的這個socket會監控在同一個ip地址與端口，這個在網絡協議裏面是容許的)。通常來講，當一個鏈接進來後，全部在accept在這個socket上面的進程，都會收到通知，而只有一個進程能夠accept這個鏈接，其它的則accept失敗。

2. nginx 正向代理與反向代理

　　正向代理：替客戶客戶端訪問明確已知的服務端地址（客戶端很是明確要訪問的服務器地址，而服務器端只知道請求來自哪一個代理服務器），正向代理模式屏蔽或者隱藏了真實客戶端信息。

       正向代理的用途：
             （1）訪問原來沒法訪問的資源，如Google
             （2） 能夠作緩存，加速訪問資源
             （3）對客戶端訪問受權，上網進行認證
             （4）代理能夠記錄用戶訪問記錄（上網行爲管理），對外隱藏用戶信息

       反向代理："它代理的是服務端，代服務端接收請求"，主要用於服務器集羣分佈式部署的狀況下，反向代理隱藏了服務器的信息

       反向代理的做用：
              （1）保證內網的安全，一般將反向代理做爲公網訪問地址，Web服務器是內網
              （2）負載均衡，經過反向代理服務器來優化網站的負載

3. nginx 負載均衡

　　3.1 算法（若是被分發的服務器存在異常，他能夠將請求從新轉發給另一臺服務器，而後自動去除異常服務器）

1. weight輪詢(默認，經常使用)：接收到的請求按照權重分配到不一樣的後端服務器，即便在使用過程當中，某一臺後端服務器宕機，Nginx會自動將該服務器剔除出隊列，請求受理狀況不會受到任何影響。 這種方式下，能夠給不一樣的後端服務器設置一個權重值(weight)，用於調整不一樣的服務器上請求的分配率；權重數據越大，被分配到請求的概率越大；該權重值，主要是針對實際工做環境中不一樣的後端服務器硬件配置進行調整的。
2. ip_hash（經常使用）：每一個請求按照發起客戶端的ip的hash結果進行匹配，這樣的算法下一個固定ip地址的客戶端總會訪問到同一個後端服務器，這也在必定程度上解決了集羣部署環境下session共享的問題。
3. fair：智能調整調度算法，動態的根據後端服務器的請求處理到響應的時間進行均衡分配，響應時間短處理效率高的服務器分配到請求的機率高，響應時間長處理效率低的服務器分配到的請求少；結合了前二者的優勢的一種調度算法。可是須要注意的是Nginx默認不支持fair算法，若是要使用這種調度算法，請安裝upstream_fair模塊。
4. url_hash：按照訪問的url的hash結果分配請求，每一個請求的url會指向後端固定的某個服務器，能夠在Nginx做爲靜態服務器的狀況下提升緩存效率。一樣要注意Nginx默認不支持這種調度算法，要使用的話須要安裝Nginx的hash軟件包。

　　3.2 配置

            在http節點裏添加:

            #定義負載均衡設備的 Ip及設備狀態 

            upstream myServer {   

                 server 127.0.0.1:9090 down; 
                 server 127.0.0.1:8080 weight=2; 
                 server 127.0.0.1:6060; 
                 server 127.0.0.1:7070 backup; 
           }

          在須要使用負載的Server節點下添加

          proxy_pass http://myServer;

          upstream 每一個設備的狀態:

          down 表示單前的server暫時不參與負載 
          weight  默認爲1.weight越大，負載的權重就越大。 
          max_fails ：容許請求失敗的次數默認爲1.當超過最大次數時，返回proxy_next_upstream 模塊定義的錯誤 
          fail_timeout:max_fails 次失敗後，暫停的時間。 
          backup： 其它全部的非backup機器down或者忙的時候，請求backup機器。因此這臺機器壓力會最輕。

4. nginx 經常使用配置規則

     server {
        listen       80;
        server_name  localhost;
        charset utf-8;
        client_max_body_size 100M; 
        client_body_buffer_size 1024M; 
        fastcgi_intercept_errors on;
        location / {
                        proxy_pass https://127.0.0.1/elastic/;
                        proxy_set_header Host $host;
                        proxy_http_version 1.1;
                        proxy_set_header Upgrade $http_upgrade;
                        proxy_set_header Connection "upgrade";
                        proxy_set_header X-real-ip $remote_addr;
                        proxy_set_header X-Forwarded-For $remote_addr;
        }
     }

　nginx location 配置規則：

　　待完善...

5. nginx 進階（openResty）【https://blog.csdn.net/y4x5M0nivSrJaY3X92c/article/details/81517950】

    OpenResty® 是一個基於 Nginx 與 Lua 的高性能 Web 平臺。咱們知道開發 Nginx 的模塊須要用 C 語言，同時還要熟悉它的源碼，成本和門檻比較高。國人章亦春把 LuaJIT VM 嵌入到了 Nginx 中，使得能夠直接經過 Lua 腳本在 Nginx 上進行編程，同時還提供了大量的類庫（如：lua-resty-mysql lua-resty-redis 等），直接把一個 Nginx 這個 Web Server 擴展成了一個 Web 框架，藉助於 Nginx 的高性能，可以快速地構造出一個足以勝任 10K 乃至 1000K 以上單機併發鏈接的高性能 Web 應用系統。

Nginx 採用的是 master-worker 模型，一個 master 進程管理多個 worker 進程，worker 真正負責對客戶端的請求處理，master 僅負責一些全局初始化，以及對 worker 進行管理。在 OpenResty 中，每一個 worker 中有一個 Lua VM，當一個請求被分配到 worker 時，worker 中的 Lua VM 裏建立一個 coroutine(協程) 來負責處理。協程之間的數據隔離，每一個協程具備獨立的全局變量 _G。

 

   1. OpenResty 請求處理流程，因爲 Nginx 把一個請求分紅了不少階段，第三方模塊就能夠根據本身的行爲，掛載到不一樣階段處理達到目的。OpenResty 也應用了一樣的特性。不一樣的階段，有不一樣的處理行爲，這是 OpenResty 的一大特點。OpenResty 處理一個請求的流程參考下圖（從 Request start 開始）

   2. OpenResty 變量

   2.1 全局變量　

      在 OpenResty 中，只有在 init_by_lua* 和 init_worker_by_lua* 階段才能定義真正的全局變量。由於在其餘階段，OpenResty 會設置一個隔離的全局變量表，以避免在處理過程當中污染了其餘請求。即便在上述兩個階段能夠定義全局變量，也儘可能避免這麼作。全局變量能解決的問題，用模塊變量也能解決，並且會更清晰，乾淨。

   2.2 模塊變量

    定義在 Lua 模塊中的變量稱爲模塊變量。Lua VM 會將 require 進來的模塊換成到 package.loaded table 裏，模塊裏的變量都會被緩存起來，在同一個 Lua VM下，模塊中的變量在每一個請求中是共享的，這樣就能夠避免使用全局變量來實現共享了。

  2.3 本地變量

   跟全局變量，模塊變量相對，咱們這裏姑且把 *_by_lua* 裏定義的變量稱爲本地變量。本地變量僅在當前階段有效，若是須要跨階段使用，須要藉助 ngx.ctx 或者附加到模塊變量裏

5.1 jwt + openResty 【https://www.jianshu.com/p/66d5163b9e99】