Nginx知識點

Nginx發展歷史

Nginx 是由俄羅斯程序員 Igor Sysoev 開發的高性能開源 Web 服務器、反向代理服務器和負載均衡器，其歷史如下：

起源與早期開發（2002 - 2004 年）

2002 年，當時 Igor Sysoev 在為俄羅斯門戶網站 Rambler 工作，他注意到 Apache Web 服務器難以處理大量連接，而當時互聯網處于爆炸式增長階段，很多系統都面臨 C10K 問題（單服務器處理 10,000 個并發連接）。Igor 起初嘗試通過改進 Apache 模塊（如 mod_proxy ）來提升性能，后意識到需創建新模塊，于 2001 年創建 mod_accel，過程中還改進了其他幾個 Apache 模塊。之后 Igor 繼續評估 C10K 問題，嘗試不同操作系統效率機制，于 2002 年開始開發 Nginx。他使用 C 語言編碼，為 Unix 啟用的事件創建異步事件循環來處理 HTTP 請求，以提高可移植性，并在一些本地項目安裝預生產版本，展現出比 Apache 更高性能。

2003 年下半年，Nginx 首個工作原型誕生，架構設計和主要功能模塊基本完成，開始在支持網站試點部署。

2004 年 10 月 4 日，Nginx 首次公開發布，發布后靠工程師和系統管理員口口相傳，在高負載系統上實現大幅性能提升。

發展與功能完善（2005 - 2010 年）

2005 - 2006 年，Nginx 的 HTTP 和應用級代理、負載均衡、腳本、配置及事件處理等功能得到改進，社區也初具雛形，互聯網中繼聊天（IRC）上的 #nginx 成為用戶和開發人員的社區支持渠道。

2007 年，Nginx 被普遍認為適合生產使用，Igor 及其他貢獻者增添緩存、改進 DNS 支持等重要功能，被部署到眾多美國初創公司，如 bak、dropbox、facebook 等。

2009 - 2010 年，Nginx 在開源社區日益受追捧。

公司成立與商業化（2011 - 2013 年）

2011 年 4 月 12 日，Nginx 1.0.0 正式發布，Igor 成立 Nginx 公司，明確軟件開發結構，在莫斯科開設第一家辦事處，后擴展到美國舊金山。公司初期專注 Nginx 持續開發，為大型互聯網公司提供專業服務和支持。同年 10 月，Nginx 公司獲 A 輪融資，Netflix 成為首個使用其服務的客戶。

2013 年，Nginx 發布首款商用產品 Nginx Plus，提供負載均衡增強、動態配置和監控等功能。開源內核開發團隊讓社區和第三方開發人員參與編寫 Nginx 和 Nginx Plus 動態加載模塊，同時保障免費版 Nginx 性能不受影響。

持續擴展與功能增強（2014 - 至今）

2014 年，Nginx 獲 B 輪融資，擴大舊金山總部和區域辦事處，銷售、營銷和工程團隊不斷發展，工作重點轉向建立多產品公司。

2015 年 9 月 22 日，支持 HTTP/2，能顯著改善網頁加載情況；9 月 28 日，推出 Nginx JavaScript（NJS），為配置提供可編程性，滿足企業將標準配置擴展為動態設置的需求；11 月 17 日，推出 Nginx Amplify，創建基于 SaaS 的監控解決方案，提供內置配置建議。

2016 年 3 月 9 日，發布 Nginx Ingress Controller，成為在 Kubernetes 集群中配置應用交付的首選方法。

2017 年 9 月 6 日，推出 Nginx Unit，這是全新動態配置 Web 和應用服務器，最初支持 php、python 和 go 語言運行應用，后擴展到更多應用語言和框架。

2019 年，Nginx Inc. 被 F5 Networks 以 6.7 億美元收購，繼續推動 Nginx 發展。

2020 年，推出 Nginx Unit，支持多種編程語言的應用服務器。

2021 年及以后，Nginx 持續更新，不斷增強安全性、性能和擴展性。如今，Nginx 在 Web 服務器領域占據重要地位，以高并發處理能力、低資源消耗聞名，被大量網站使用，常作為負載均衡器。

Lua 簡介（銜接redis）

基礎知識

Lua 是一種輕量級、高效的腳本語言，它以其簡單的語法、小巧的體積和出色的可嵌入性而聞名。Lua 經常被用作嵌入式腳本語言，可集成到各種應用程序中，為應用增添腳本化的靈活性。

在.NET 中使用 Lua，通常會借助第三方庫，像 NLua 。NLua 是一個用于.NET 平臺的 Lua 綁定庫，它能讓你在.NET 應用里調用 Lua 腳本，還能在 Lua 腳本里調用.NET 代碼。

可以通過 NuGet 包管理器來安裝 NLua。在 Visual Studio 中，打開 “工具” -> “NuGet 包管理器” -> “管理解決方案的 NuGet 程序包”，搜索 “NLua” 并安裝。

示例代碼及解析

以下是一個簡單的示例，展示了如何在.NET 中使用 NLua 執行 Lua 腳本。

csharp

using NLua;

class Program{

????static void Main()

????{

????????// 創建一個Lua虛擬機實例

????????using (Lua lua = new Lua())

????????{

????????????// 定義一個簡單的Lua腳本

????????????string luaScript = @"

????????????????-- 定義一個Lua函數

????????????????function add(a, b)

????????????????????return a + b

????????????????end

????????????";

????????????// 執行Lua腳本

????????????lua.DoString(luaScript);

????????????// 獲取Lua函數

????????????LuaFunction addFunction = lua["add"] as LuaFunction;

????????????if (addFunction != null)

????????????{

????????????????// 調用Lua函數

????????????????object[] result = addFunction.Call(3, 5);

????????????????// 輸出結果

????????????????if (result.Length > 0)

????????????????{

????????????????????int sum = (int)result[0];

????????????????????Console.WriteLine("3 + 5 = " + sum);

????????????????}

????????????}

????????}

????}}

代碼解析

創建 Lua 虛擬機實例：using (Lua lua = new Lua())?創建了一個新的 Lua 虛擬機實例。借助這個實例，你可以執行 Lua 腳本并與 Lua 環境進行交互。

定義 Lua 腳本：string luaScript?定義了一個簡單的 Lua 腳本，其中包含一個名為?add?的函數，此函數用于計算兩個數的和。

執行 Lua 腳本：lua.DoString(luaScript)?執行定義好的 Lua 腳本，把腳本加載到 Lua 虛擬機中。

獲取 Lua 函數：lua["add"]?從 Lua 虛擬機里獲取名為?add?的函數，并將其轉換為?LuaFunction?類型。

調用 Lua 函數：addFunction.Call(3, 5)?調用 Lua 函數?add，傳入參數?3?和?5，并返回計算結果。

輸出結果：將計算結果轉換為整數類型并輸出。

通過這個示例，你能夠看到在.NET 中使用 Lua 腳本是多么簡單，并且可以在.NET 代碼和 Lua 腳本之間進行交互。

Lua 常被用于銜接 Nginx 和 Redis，在實際應用中起到重要作用：

實現原理與方式

嵌入 Nginx 擴展功能：Nginx 本身主要用于處理網絡請求、反向代理等基礎功能，通過集成 Lua 模塊（如 ngx_lua ），可在 Nginx 中嵌入 Lua 腳本。Lua 腳本能在 Nginx 處理請求的過程中，靈活地實現各種自定義邏輯，比如在請求到達 Nginx 后，通過 Lua 腳本對請求進行分析、修改請求參數等。
連接 Redis 進行數據交互：借助 Lua 豐富的 Redis 客戶端庫（如 lua - resty - redis ），Lua 腳本可直接與 Redis 建立連接。當 Nginx 接收到請求時，Lua 腳本能夠根據需求從 Redis 中讀取緩存數據（如圖片、CSS 文件、數據庫查詢結果等），若數據不存在則再請求后端服務器獲取，然后將數據存入 Redis 緩存，以此減少后端服務器壓力和響應時間。

實際應用場景舉例

1.緩存管理：在高并發的 Web 應用中，可利用 Lua 腳本操作 Redis 緩存。當有請求到達 Nginx 時，Lua 腳本先檢查 Redis 中是否有對應資源緩存，有則直接返回，無則從后端獲取并緩存到 Redis ，提升響應速度，減輕后端負載。例如電商網站商品詳情頁，頻繁被訪問的商品信息可通過這種方式緩存。

2.動態路由：根據不同條件（如請求來源、用戶身份等），使用 Lua 腳本在 Nginx 中實現動態路由。比如 API 網關場景下，Lua 腳本讀取 Redis 中存儲的路由配置信息，決定將請求轉發到哪個后端服務器。

3.會話管理：將用戶會話數據存儲在 Redis 中，由 Lua 腳本在 Nginx 中進行管理。如用戶登錄后，會話信息存于 Redis ，后續請求到 Nginx 時，Lua 腳本從 Redis 讀取會話數據驗證用戶狀態，實現會話的快速可靠處理，便于應用擴展。

不過，Lua 并非銜接 Nginx 和 Redis 的唯一方式，還可通過其他語言編寫的模塊或工具實現類似功能，但 Lua 憑借輕量級、高效執行、易于嵌入和調試等優勢，成為常用選擇。

應用方式

Lua 腳本不一定直接寫在 Nginx 上，有以下兩種常見使用方式：

直接嵌入到 Nginx 配置文件

可將 Lua 腳本代碼直接寫在 Nginx 配置文件中。例如，在配置文件合適位置使用lua_code?指令直接編寫 Lua 代碼片段，像location /test { lua_code_cache on; lua_code 'ngx.say("Hello, Lua!");'; }?，這樣當 Nginx 處理/test?路徑請求時，會執行其中的 Lua 代碼，輸出Hello, Lua!?。這種方式適合簡單、少量代碼且不需要復用的場景，方便快捷，能快速實現一些簡單功能測試或臨時邏輯處理。

以外部文件形式引用

更多時候，會把 Lua 腳本編寫成獨立的.lua?文件，然后在 Nginx 配置文件中通過lua_code_file?指令引用。例如location /lua { default_type text/html; lua_code_cache on; lua_code_file /path/to/your_script.lua; }?，這里指定了 Nginx 處理/lua?路徑請求時，去執行/path/to/your_script.lua?文件中的 Lua 腳本。這種方式便于代碼管理和復用，大型項目或復雜邏輯中，將不同功能邏輯拆分到多個.lua?文件，利于團隊協作開發與代碼維護。

要在 Nginx 中使用 Lua 腳本，還需先確保 Nginx 集成了相關模塊（如原生 Nginx 需編譯安裝 ngx_http_lua_module 模塊，或直接使用集成大量模塊的 OpenResty ）。

應用流程

在 Nginx 中可以通過 Lua 模塊（ngx_lua）來直接訪問 Redis，這樣能實現高效的緩存和數據處理。下面為你詳細介紹如何配置 Nginx 以支持 Lua 訪問 Redis，并給出示例代碼。

環境準備

需安裝 Nginx 并啟用ngx_lua模塊。可以從源碼編譯安裝 Nginx 時添加--with-http_lua_module選項來啟用。
要安裝 Redis 并保證其正常運行。

配置 Nginx

在 Nginx 配置文件里添加以下內容，從而啟用 Lua 模塊并配置 Lua 路徑：

nginx

http?{

????# 加載lua模塊

????lua_package_path?"/path/to/lua/?.lua;;";

????server?{

????????listen?80;

????????server_name?example.com;

????????location?/redis?{

????????????# 執行lua腳本

????????????content_by_lua_file?/path/to/your/lua/script.lua;

????????}

????}}

在上述配置中：

lua_package_path?指明 Lua 模塊的搜索路徑。
content_by_lua_file?指定處理請求的 Lua 腳本文件路徑。

Lua 腳本示例

以下是一個簡單的 Lua 腳本示例，用于連接 Redis 并獲取一個鍵的值：

nginx-lua-redisNginx Lua 訪問 Redis 腳本

生成 redis_access.lua

代碼解釋

加載 Redis 模塊：local redis = require "resty.redis"?加載了?resty.redis?模塊，此模塊提供了與 Redis 交互的功能。
創建 Redis 連接對象：local red = redis:new()?創建了一個新的 Redis 連接對象。
設置超時時間：red:set_timeout(1000)?設置連接和操作的超時時間為 1 秒。
連接到 Redis 服務器：red:connect("127.0.0.1", 6379)?嘗試連接到本地的 Redis 服務器。
獲取鍵的值：red:get("mykey")?從 Redis 中獲取鍵?"mykey"?的值。
處理結果：依據返回結果，輸出相應的信息。
關閉連接：red:close()?關閉與 Redis 的連接。

部署和測試

把上述 Lua 腳本保存到指定路徑（如?/path/to/your/lua/script.lua）。
重新加載 Nginx 配置：nginx -s reload。
訪問?http://example.com/redis?即可測試腳本是否正常工作。

通過以上步驟，你就能在 Nginx 中使用 Lua 直接訪問 Redis 了。

Nginx與AOP

可以說 Nginx 在一定程度上體現了面向切面編程（AOP）的思想，下面為你詳細解釋：

什么是 AOP

面向切面編程（AOP）是一種編程范式，它將程序中的橫切關注點（如日志記錄、事務管理、權限驗證等）從核心業務邏輯中分離出來，形成獨立的模塊（即切面），然后在特定的切入點（如方法調用前后、異常拋出時等）將這些切面織入到主程序中。這樣做的好處是提高了代碼的可維護性、可復用性和可擴展性。

Nginx 體現 AOP 思想的方面

1. 模塊化和功能分離

Nginx 采用模塊化設計，各個模塊可以獨立開發、配置和部署。例如，Nginx 有 HTTP 模塊、郵件模塊、流模塊等，每個模塊負責不同的功能。這些模塊就類似于 AOP 中的切面，它們可以獨立于核心的請求處理邏輯進行開發和管理。比如，Nginx 的訪問日志模塊可以記錄每個請求的詳細信息，它與處理請求的核心邏輯是分離的，就像 AOP 中把日志記錄這個橫切關注點從業務邏輯中分離出來一樣。

2. 攔截和處理請求

Nginx 可以在請求處理的不同階段插入自定義的處理邏輯。例如，在請求進入 Nginx 后，它可以進行一系列的預處理操作，如請求過濾、權限驗證、限流等；在請求處理完成后，還可以進行后處理操作，如添加響應頭、緩存處理等。這些操作可以在不修改核心業務邏輯的情況下，通過配置 Nginx 的模塊來實現，類似于 AOP 在方法調用前后插入額外的邏輯。

3. 配置靈活

Nginx 通過配置文件來管理各個模塊的行為，用戶可以根據需要靈活地啟用或禁用某些模塊，以及調整模塊的參數。這就好比 AOP 中可以根據不同的需求，靈活地選擇在哪些切入點織入哪些切面。例如，在開發環境中可以禁用某些性能監控模塊，而在生產環境中啟用它們。

Nginx 與典型 AOP 的區別

雖然 Nginx 體現了一些 AOP 的思想，但它和典型的 AOP 編程框架（如 Spring AOP）還是有區別的：

應用層面不同：Nginx 主要應用于服務器層面，處理網絡請求和響應；而 AOP 框架通常應用于程序開發層面，用于處理代碼中的橫切關注點。
實現方式不同：Nginx 通過模塊和配置文件來實現功能的分離和插入；而 AOP 框架通常通過代理、字節碼增強等技術來實現切面的織入。

綜上所述，Nginx 在設計和使用上體現了部分 AOP 的思想，通過模塊化和靈活的配置，實現了功能的分離和在請求處理流程中的插入，但它和典型的 AOP 編程框架在應用場景和實現方式上有所不同。

nginx的負載均衡策略

Nginx 的負載均衡策略用于將客戶端的請求合理地分配到多個后端服務器上，以實現服務器資源的有效利用和系統的高可用性。以下是 Nginx 常見的幾種負載均衡策略：

1.輪詢（Round Robin）

1. 原理：按順序依次將請求分配到后端服務器上，均等分配請求。
2. 示例配置：

nginx

upstream?backend_pool?{

????server?backend1.example.com;

????server?backend2.example.com;

????server?backend3.example.com;}server?{

????listen???????80;

????server_name??example.com;

????location?/?{

????????proxy_pass?http://backend_pool;

????}}

適用場景：適用于后端服務器性能相近的情況，能簡單有效地平均分配負載。

2.加權輪詢（Weighted Round Robin）

- 原理：根據服務器的性能差異，為不同服務器設置不同的權重，權重越高，被分配到請求的概率越大。
- 示例配置：

nginx

upstream?backend_pool?{

????server?backend1.example.com weight=3;

????server?backend2.example.com weight=2;

????server?backend3.example.com weight=1;}server?{

????listen???????80;

????server_name??example.com;

????location?/?{

????????proxy_pass?http://backend_pool;

????}}

適用場景：適用于后端服務器性能不同的場景，可根據服務器的硬件配置或處理能力來分配權重，使性能強的服務器承擔更多的請求。

3.IP 哈希（IP Hash）

- 原理：根據客戶端的 IP 地址計算哈希值，通過該哈希值將請求始終路由到同一臺后端服務器，保證來自同一 IP 的請求被分配到相同的服務器上。
- 示例配置：

nginx

upstream?backend_pool?{

????ip_hash;

????server?backend1.example.com;

????server?backend2.example.com;

????server?backend3.example.com;}server?{

????listen???????80;

????server_name??example.com;

????location?/?{

????????proxy_pass?http://backend_pool;

????}}

適用場景：當需要實現會話粘滯（Session Sticky），即讓同一個客戶端的請求始終由同一臺服務器處理時，IP 哈希策略非常有用，比如在有狀態服務或需要保持用戶會話一致性的場景中。

4.最少連接（Least Connections）

- 原理：將請求分配給當前連接數最少的后端服務器，動態地根據服務器的負載情況分配請求。
- 示例配置：

nginx

upstream?backend_pool?{

????least_conn;

????server?backend1.example.com;

????server?backend2.example.com;

????server?backend3.example.com;}server?{

????listen???????80;

????server_name??example.com;

????location?/?{

????????proxy_pass?http://backend_pool;

????}}

適用場景：適用于后端服務器處理請求的時間差異較大，或者請求負載不均衡的情況，能更合理地分配負載，避免服務器過載。

5.加權最少連接（Weighted Least Connections）

原理：結合了加權輪詢和最少連接的特點，根據服務器的權重和當前連接數來分配請求。權重越高且連接數相對較少的服務器，被分配到請求的概率越大。
- 示例配置：

nginx

upstream?backend_pool?{

????least_conn;

????server?backend1.example.com weight=3;

????server?backend2.example.com weight=2;

????server?backend3.example.com weight=1;}server?{

????listen???????80;

????server_name??example.com;

????location?/?{

????????proxy_pass?http://backend_pool;

????}}

適用場景：在服務器性能不同且請求負載不均衡的場景中表現較好，能綜合考慮服務器的處理能力和當前負載狀態來分配請求。

6.通用哈希（Generic Hash）

- 原理：通過對用戶自定義的鍵（如請求的 URL、請求頭中的某個字段等）進行哈希計算，根據哈希值將請求分配到后端服務器。
- 示例配置：

nginx

upstream?backend_pool?{

????hash?$request_uri consistent;

????server?backend1.example.com;

????server?backend2.example.com;

????server?backend3.example.com;}server?{

????listen???????80;

????server_name??example.com;

????location?/?{

????????proxy_pass?http://backend_pool;

????}}

適用場景：當需要根據特定的請求特征來實現負載均衡，并且希望具有一定的穩定性和可預測性時，通用哈希策略比較適用。例如，根據不同的 URL 路徑將請求分配到不同的服務器上，以實現基于業務邏輯的負載均衡。

session的應用

在計算機領域，特別是在 Web 應用程序中，Session（會話）是一種用于跟蹤用戶與服務器之間交互狀態的機制。以下是其詳細介紹：

定義

Session 是指在一段時間內，一個用戶與服務器之間進行的一系列交互操作。從用戶打開瀏覽器訪問網站開始，到關閉瀏覽器離開網站為止，這個過程可以被視為一個 Session。在這個過程中，服務器需要識別不同的用戶，并為每個用戶維護其相關的狀態信息。

作用

保持用戶狀態：在用戶瀏覽網站的過程中，Session 可以記錄用戶的登錄狀態、瀏覽歷史、購物車信息等。例如，用戶登錄到一個電商網站后，添加商品到購物車，Session 會記錄這些操作，使得用戶在不同頁面之間跳轉時，購物車中的商品信息不會丟失，并且服務器能夠識別該用戶已經登錄，為其提供相應的個性化服務。
實現跨頁面交互：當用戶在一個網站的多個頁面之間進行操作時，Session 可以在這些頁面之間傳遞數據。比如，用戶在填寫一個多步驟的表單時，Session 可以保存用戶在前面步驟中輸入的數據，以便在后續步驟中使用，確保整個表單提交過程的連貫性。
安全驗證：Session 可以用于存儲用戶的身份驗證信息。服務器通過驗證 Session 中的相關數據，來確定用戶是否具有訪問特定資源的權限。例如，用戶登錄后，服務器會在 Session 中記錄用戶的角色和權限信息，當用戶訪問需要特定權限的頁面或執行某些操作時，服務器會檢查 Session 中的權限數據，以決定是否允許用戶進行相應操作，從而增強系統的安全性。
個性化設置：根據用戶在 Session 中記錄的偏好和設置，為用戶提供個性化的界面和服務。例如，用戶可以在網站上設置自己喜歡的語言、字體大小、界面主題等，這些信息會存儲在 Session 中，服務器根據這些信息為用戶定制個性化的頁面展示。

ip hash作用

IP 哈希的作用主要是實現請求的定向分配和會話保持，具體如下：

實現會話保持：在一些 Web 應用或服務中，需要確保同一個客戶端的所有請求都由同一臺后端服務器處理，以維持會話的一致性。通過 IP 哈希算法，根據客戶端的 IP 地址計算哈希值，并將請求始終路由到同一臺后端服務器上，從而實現會話保持。這樣，服務器可以在處理請求時依賴之前存儲在該客戶端會話中的信息，如用戶登錄狀態、購物車內容、用戶偏好設置等，避免因請求被分配到不同服務器而導致的會話數據不一致問題。
提高緩存效率：當后端服務器存在緩存機制時，IP 哈希可以使來自同一 IP 地址的請求總是到達同一臺服務器，這樣服務器上的緩存對于該客戶端的后續請求就具有更高的命中率。因為同一客戶端的相關數據更有可能被緩存在同一臺服務器上，減少了緩存未命中的情況，從而提高了系統的整體性能和響應速度。
負載均衡與穩定性：IP 哈希在一定程度上也能起到負載均衡的作用，它將來自不同 IP 地址的請求均勻地分配到后端服務器池中。同時，由于基于 IP 地址進行哈希計算，只要客戶端的 IP 地址不發生變化，請求的分配就具有穩定性。這對于一些對請求分配有嚴格要求的系統非常重要，例如某些數據庫集群環境，需要確保特定客戶端的所有請求都由同一臺數據庫服務器處理，以保證數據的一致性和事務處理的正確性。

SQLSERVER的選型與服務器的核心數（附屬）

SQL Server 的選型與服務器核心數密切相關，主要體現在以下方面：

性能層面

并發處理能力：核心數越多，并行處理能力越強，能同時處理更多請求。如高并發場景下（超 1000 個并發用戶），8 核以上更能滿足需求；低并發（少于 100 個并發用戶）2 - 4 核可能就夠。例如電商大促時，大量用戶同時下單，需較多核心數保障響應速度。
復雜運算支持：面對復雜查詢（多表聯合查詢、大數據量處理），多核心可并行處理任務，提升效率。簡單查詢 4 核基本能應對，復雜場景建議 8 核以上。

授權層面

核心數授權模式：SQL Server 有基于核心的授權模式，需按物理服務器核心數支付許可費用，至少購買 4 個核心許可證。若使用虛擬機，為虛擬核心買許可。選擇時要考慮核心數對應的授權成本。

選型建議

小型應用：像開發測試環境、小型網站等，數據量和并發低，2 - 4 核即可。
中型應用：中等規模企業應用、有一定并發量的電商網站，4 - 8 核較合適。
大型及超大型應用：高并發的企業級應用、大數據分析等，8 核以上，超大型的 16 核以上。

?Nginx 配置文件的結構

這張圖展示了 Nginx 配置文件的結構層次，各部分含義如下：

main 塊

地位：是 Nginx 配置文件的全局塊，位于最頂層，最先被讀取。
作用：設置影響 Nginx 全局運行的指令，像配置工作進程數（worker_processes?），可指定 Nginx 使用的 CPU 核心數，一般設置為服務器 CPU 核心數或其倍數，以充分利用硬件資源；還可配置錯誤日志路徑等，如?error_log /var/log/nginx/error.log;?，用于記錄 Nginx 運行時的錯誤信息。

events 塊

地位：在 main 塊內，用于配置 Nginx 與客戶端的網絡連接相關參數。
作用：設置事件模型和最大連接數等。例如?worker_connections 1024;?，表示每個工作進程能處理的最大連接數，決定了 Nginx 能同時處理的客戶端連接數量。

HTTP 塊

地位：位于 events 塊之下，是 Nginx 配置的核心部分，用于配置 HTTP 相關功能。
作用：配置 HTTP 服務器的各種屬性，如定義虛擬主機（Server 塊）、設置反向代理、配置緩存等。比如?include /etc/nginx/mime.types;?用于引入文件類型映射，讓 Nginx 能正確識別和處理不同類型文件的請求。

Server 塊

地位：在 HTTP 塊內，用于定義虛擬主機。
作用：可針對不同域名或 IP 地址 + 端口組合，配置不同的響應策略。如指定監聽端口（listen 80;?）、服務器名稱（server_name example.com;?），還能配置該虛擬主機下的日志路徑、訪問控制等。

Location 塊

地位：在 Server 塊內，用于匹配請求的 URI，并對特定 URI 請求進行處理。
作用：可配置對不同路徑請求的處理方式，比如?location /static/ { root /var/www/html; }?，表示當請求以?/static/?開頭時，Nginx 從?/var/www/html?目錄下查找對應的文件并返回。可用于實現靜態文件服務、反向代理轉發等功能。

nginx可以做類似于redis的緩存

Nginx 可以實現類似于 Redis 的緩存功能，但二者在原理、應用場景等方面存在差異：

Nginx 緩存

原理：Nginx 從 0.7.48 版開始提供緩存功能，基于 Proxy Store 實現，把 URL 及相關組合當作 Key，用 MD5 算法對 Key 進行哈希，得到硬盤上對應的哈希目錄路徑，從而將緩存內容保存在該目錄中。它支持任意 URL 連接，也支持 404、301、302 等非 200 狀態碼。
功能：能緩存靜態內容（如 css、javascript、圖像等不常變化的文件）和動態內容（如 php 應用程序生成的 html ）。可通過相關指令靈活配置，比如用proxy_cache_path設置緩存文件存放路徑、緩存區大小等；用proxy_cache_valid對不同返回狀態碼的 URL 設置不同緩存時間。還可使用第三方模塊（如 ngx_cache_purge ）手動清除指定 URL 的緩存。
應用場景：主要用于 Web 服務器場景，減輕后端應用服務器負載，降低網絡延遲，提高用戶訪問響應速度。如用戶訪問網站時，Nginx 先檢查緩存，有對應內容則直接返回，無需再次向應用服務器請求。

Redis 緩存

原理：Redis 是基于內存的鍵值對存儲數據庫，數據存儲在內存中，讀寫速度極快。通過設置鍵值對來存儲和讀取數據，支持豐富的數據結構，如字符串、哈希表、列表、集合等。
功能：除基本緩存功能外，還支持事務、發布訂閱、Lua 腳本、持久化（如 RDB 快照、AOF 日志）等高級功能。可方便地進行數據的增刪改查操作，適用于多種復雜業務邏輯。
應用場景：應用廣泛，不僅用于 Web 應用緩存，還用于分布式系統中的數據共享、消息隊列、實時數據分析等場景。例如在高并發的電商系統中，可緩存商品信息、用戶購物車信息等。

二者對比

Nginx 緩存側重于在 Web 服務器層面，對客戶端請求的響應內容進行緩存，以加速 Web 應用訪問；Redis 緩存功能更豐富、靈活，能滿足各種復雜業務場景下的數據緩存和處理需求。實際應用中，二者也可結合使用，如 Nginx 作為 Web 服務器前置緩存，Redis 作為更通用的應用層緩存。

Nginx的數據預熱

Nginx 的數據預熱是指在服務器啟動或某些特定條件下，提前將一些常用或關鍵的數據加載到緩存中，以便在實際請求到來時能夠更快地響應，減少響應時間，提高系統性能。以下是關于 Nginx 數據預熱的一些常見方法和相關要點：

基于文件系統的預熱

對于 Nginx 緩存靜態文件的場景，可以在服務器啟動后，通過腳本或工具主動訪問一些常用的靜態資源文件，如 HTML 頁面、CSS 樣式表、JavaScript 文件、圖片等。這樣 Nginx 會將這些文件加載到緩存中，后續客戶端請求這些資源時，就可以直接從緩存中獲取，而無需從磁盤讀取，加快響應速度。

利用第三方模塊進行預熱

一些 Nginx 的第三方模塊提供了更靈活的數據預熱功能。例如，ngx_cache_purge模塊除了可以用于清除緩存外，也可以結合一些自定義的腳本，在服務器啟動或定時任務中，通過向 Nginx 發送特定的 HTTP 請求來觸發對指定 URL 的緩存預熱。可以編寫一個腳本，遍歷需要預熱的 URL 列表，然后使用curl等工具向 Nginx 發送請求，強制 Nginx 將這些 URL 對應的內容緩存起來。

與后端應用配合的預熱

如果 Nginx 作為反向代理服務器后端連接著動態應用服務器（如 PHP、Java 等應用），可以在應用服務器啟動完成后，通過一些機制通知 Nginx 進行相關數據的預熱。例如，應用服務器可以向 Nginx 發送一個 HTTP 請求，告知 Nginx 去緩存某些動態生成的頁面或數據。或者在應用服務器中內置一些邏輯，在啟動時主動調用 Nginx 的緩存接口，將一些常用的業務數據緩存到 Nginx 中。

配置參數優化以支持預熱

proxy_cache_path指令用于設置緩存文件的存放路徑、緩存區大小等參數。合理設置這些參數對于數據預熱的效果和緩存的性能至關重要。例如，增加緩存區大小可以容納更多的緩存數據，提高緩存命中率。
proxy_cache_valid指令用于設置不同 HTTP 狀態碼的緩存時間。對于那些在預熱過程中獲取到的正常響應（如狀態碼為 200），可以設置較長的緩存時間，以便在后續一段時間內能夠持續從緩存中獲取數據，減少后端服務器的壓力。

數據預熱需要根據具體的業務場景和系統架構來選擇合適的方法和策略，并且要結合 Nginx 的配置參數進行優化，以達到最佳的性能提升效果。同時，還需要考慮預熱的時機、頻率以及對系統資源的占用等因素，避免對正常的業務運行產生負面影響。

案例

系統架構與流程解析

客戶端請求：客戶端發起對商品詳情頁的請求，首先到達 Nginx 。
Nginx 處理：Nginx 會判斷該商品詳情頁是否已存在。若存在，直接進行相關處理；若不存在，Nginx 將請求轉發給 IIS 。Nginx 還需承擔存儲商品詳情頁的任務，目標是以最少資源提供高并發支持。
IIS 業務邏輯：IIS 接收 Nginx 轉發的請求，處理新增商品、修改商品等接口業務。處理完成后，通過消息總線（bus）發送事件消息。
消息傳遞與模板生成：消息總線傳遞消息觸發 “發個消息” 節點，進而調用 “生成模板接口” 。該接口依據商品 id 獲取靜態頁面，并將生成的 html 文件再次存儲到 Nginx 。
Redis 關聯：IIS 與 Redis 存在交互，但圖中未明確具體交互邏輯，推測可能用于數據緩存、存儲等，輔助 IIS 提升性能。
該圖呈現了一個涉及客戶端、Nginx、IIS、Redis 及相關消息處理組件的系統架構。主要業務流程圍繞商品詳情頁請求展開，通過各組件協同工作，實現商品信息處理、消息傳遞以及靜態頁面生成存儲，旨在優化資源利用，提升系統并發處理能力。

IIS是怎么把靜態頁放到nginx里面

Nginx 在從 IIS 獲取靜態頁后，會將其存儲在本地緩存中，為下次訪問做好準備，具體過程如下：

緩存機制觸發

當客戶端請求一個靜態頁面資源時，Nginx 首先會檢查本地緩存中是否存在該資源。如果緩存中沒有（即緩存未命中），Nginx 會將請求轉發給 IIS。IIS 處理請求并返回對應的靜態頁面數據給 Nginx 。

緩存存儲

Nginx 接收到 IIS 返回的靜態頁面數據后，會根據其緩存配置，將該靜態頁面存儲到本地指定的緩存目錄中。Nginx 的緩存配置主要通過proxy_cache_path指令來指定緩存目錄、緩存區大小等參數。例如：

nginx

http?{

????proxy_cache_path?/var/cache/nginx levels=1:2 keys_zone=my_cache:10m;

????# ...其他配置}

上述配置中，/var/cache/nginx是緩存目錄，levels=1:2設置了緩存目錄的層級結構，keys_zone=my_cache:10m定義了一個名為my_cache、大小為 10MB 的緩存區。

后續訪問處理

當下次再有客戶端請求相同的靜態頁面資源時，Nginx 會再次檢查本地緩存。如果緩存命中（即緩存中存在且未過期），Nginx 會直接從緩存中讀取數據并返回給客戶端，而無需再次向 IIS 請求，從而加快響應速度，減輕 IIS 服務器的負載。

不過，要實現上述過程，還需在 Nginx 配置文件的server或location塊中啟用緩存功能，使用proxy_cache指令并指定緩存區域名稱。例如：

nginx

server?{

????listen?80;

????server_name?example.com;

????location?/?{

????????proxy_cache?my_cache;

????????proxy_pass?http://iis_server;?# 指向IIS服務器地址

????}}

同時，還可以通過proxy_cache_valid指令設置不同 HTTP 狀態碼的緩存有效期等，進一步靈活控制緩存策略。

關于緩存

這張圖展示了一個簡單的系統架構，描述了客戶端、Nginx 和 Redis 之間的交互關系：

客戶端請求：客戶端發起請求，首先到達 Nginx。
Nginx 處理：Nginx 作為中間層，接收客戶端請求，并通過 Lua 腳本擴展與 Redis 對接。其目的是從 Redis 獲取最新數據。
Redis 作用：Redis 作為數據存儲組件，支持高并發訪問，為 Nginx 提供所需的數據。

總結來說，該架構利用 Nginx 結合 Lua 腳本對接 Redis，借助 Redis 高并發的特性，實現為客戶端請求提供數據支持的功能。

Nginx 使用 Lua 腳本擴展對接 Redis，主要有以下原因：

提升性能

減少網絡開銷：通過 Lua 腳本，原本需多次與 Redis 進行網絡請求的操作，可整合為一次請求。比如要獲取多個相關數據并計算，若逐條命令請求 Redis，會產生多次網絡往返；用 Lua 腳本可在 Redis 服務端一次性完成數據獲取和計算，將結果返回給 Nginx，減少等待響應時間，加快應用處理速度。
利用 Redis 高性能：Redis 基于內存存儲，讀寫速度快，適合處理高并發請求。Nginx 結合 Lua 腳本對接 Redis，能借助 Redis 的高性能緩存和讀取數據，快速響應客戶端請求，提升整體系統的并發處理能力。

實現復雜業務邏輯

原子性操作：Redis 執行 Lua 腳本具備原子性，即腳本作為整體執行，期間不會被其他命令打斷。在電商扣減庫存、記錄訂單等多步操作場景中，能確保操作要么全部成功，要么全部失敗，保證數據一致性，避免出現超賣等問題。
靈活定制操作：單純的 Redis 命令難以滿足復雜業務需求，而 Lua 腳本語法簡單、靈活，可實現如數據聚合、篩選、邏輯判斷等復雜操作。以社交平臺計算用戶動態點贊數、評論數等場景為例，Lua 腳本可根據業務規則靈活處理數據。

代碼復用與便捷性

腳本緩存與復用：Lua 腳本在 Redis 中會被緩存，首次執行后，后續調用可直接通過 SHA1 摘要執行，無需重復傳輸腳本內容，提升執行效率。并且多個客戶端可復用已緩存的腳本，減少代碼重復編寫。
熱更新與便捷擴展：當業務邏輯變更時，無需重啟 Redis 或 Nginx 服務，直接更新 Lua 腳本即可實現功能調整，方便快捷。同時，Lua 腳本可便捷地嵌入到 Nginx 中，為 Nginx 擴展功能，滿足不斷變化的業務需求。

在 Nginx 服務器重啟的場景下，涉及 Lua 腳本對接 Redis 獲取數據，會產生以下影響及應對措施：

連接中斷與重建

連接中斷：Nginx 重啟時會清空現有連接，重新加載配置并初始化工作進程。若 Nginx 與 Redis 通過 Lua 腳本建立了連接，該連接會被中斷。例如正在從 Redis 獲取數據的請求，可能因連接中斷而失敗。尤其在高并發場景下，大量請求同時進行，連接中斷可能導致較多請求失敗，影響服務可用性。
連接重建：重啟后，Nginx 再次處理請求時，Lua 腳本需重新建立與 Redis 的連接。這涉及重新進行網絡握手等操作，會增加請求處理時間，導致延遲增加。若連接過程中出現網絡問題或 Redis 服務未就緒，還可能導致連接失敗，使請求無法獲取數據。

緩存失效與預熱

緩存失效：Nginx 重啟會使之前緩存的 Redis 數據失效。比如之前通過 Lua 腳本從 Redis 獲取并在 Nginx 本地緩存的數據，重啟后不再存在。后續請求需重新從 Redis 獲取，增加 Redis 負載和請求響應時間。
緩存預熱：為恢復性能，需對緩存進行預熱，即主動讓 Nginx 通過 Lua 腳本從 Redis 獲取常用數據并重新緩存。可通過編寫腳本在 Nginx 重啟后自動觸發對關鍵數據的請求，將數據存儲回 Nginx 緩存，為后續請求做好準備。

配置加載與腳本執行

配置加載：Nginx 重啟會重新加載配置文件，包括與 Lua 腳本相關的配置，如 Lua 模塊路徑、Lua 腳本文件位置等。若配置文件修改錯誤或加載失敗，會導致 Lua 腳本無法正常執行，進而無法對接 Redis 獲取數據。
腳本執行：Lua 腳本在 Nginx 重啟后重新執行。若腳本存在語法錯誤、依賴問題或與新版本 Nginx 不兼容，可能執行失敗。比如腳本中使用的 Redis 連接庫版本與當前環境不匹配，就無法正常連接 Redis 獲取數據。需提前做好腳本的兼容性測試和檢查。