NGINX 快取叢集架構與高效能實踐

NGINX 作為熱門的反向代理和負載平衡伺服器，其快取機制對於提升網站效能至關重要。本文不僅介紹了 NGINX 快取的基礎設定，更探討瞭如何在多台 NGINX 伺服器上構建快取叢集，以應對高流量和高用性的需求。透過組態主備伺服器和採用一致性雜湊演算法，可以有效地分散流量壓力，並在單點故障時確保服務的連續性。此外，文章也探討瞭如何結合負載平衡和快取層，以及如何透過 NGINX Plus 的擴充套件功能來監控和管理快取系統，提供更全面的效能最佳化策略。

高效能快取技術：NGINX 與 NGINX Plus 的內部運作機制與叢集架構

前言

高效能快取技術是現代網路架構中的關鍵組成部分，而 NGINX 與 NGINX Plus 提供了強大的快取解決方案。本文將探討 NGINX 快取的內部運作機制、清除快取的機制，以及如何在多台 NGINX 伺服器之間實作快取分享，以達到高容量與高用性的快取架構。

NGINX 快取的內部運作機制

NGINX 的快取機制是根據磁碟的，這意味著快取內容被儲存在伺服器的檔案系統中。當客戶端請求資源時，NGINX 首先檢查該資源是否已經被快取。如果資源存在於快取中，NGINX 將直接傳回快取內容，而無需向原始伺服器發起請求，從而顯著提高回應速度並減少對原始伺服器的負載。

# 設定 NGINX 快取範例
http {
    proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=my_cache:10m max_size=10g;
    
    server {
        listen 80;
        location / {
            proxy_pass http://localhost:8001;
            proxy_cache my_cache;
            proxy_cache_valid 200 301 302 10m;
            proxy_cache_min_uses 1;
            proxy_cache_methods GET HEAD;
        }
    }
}

內容解密：

上述設定建立了一個 NGINX 快取區，路徑為 /data/nginx/cache，並定義了一個名為 my_cache 的快取區域，大小為 10MB。levels 引數定義了快取目錄的層級結構，有助於提高檔案系統的效能。proxy_cache_valid 指令設定了不同 HTTP 狀態碼的快取有效時間，而 proxy_cache_min_uses 則定義了在快取資源之前，資源至少被請求的次數。

清除快取機制

NGINX Plus 提供了強大的快取清除功能，可以根據 URI 清除指定的快取內容。這個功能可以透過特殊的處理程式實作，該處理程式會檢查 URI 並刪除與之匹配的快取檔案。可以使用星號作為萬用字元來清除符合特定模式的多個檔案。

# 設定 NGINX Plus 快取清除範例
http {
    server {
        listen 80;
        location / {
            proxy_pass http://localhost:8001;
            proxy_cache my_cache;
        }
        
        location ~ /purge(/.*) {
            proxy_cache_purge my_cache "$scheme$request_method$host$1";
        }
    }
}

內容解密：

上述設定允許透過特定的 URI 模式來清除快取。例如，存取 /purge/some/path 將清除與 /some/path 匹配的快取內容。proxy_cache_purge 指令用於指定清除快取的條件。

NGINX 快取叢集架構

NGINX 不支援在多台伺服器之間直接分享磁碟上的快取內容，這是出於對效能和可靠性的考慮。然而，可以透過快取分片（sharding）和快取叢集（clustering）來實作高效能和高用性的快取架構。

快取分片（Cache Sharding）

快取分片是將快取內容分散儲存在多台 NGINX 伺服器上的技術。每台伺服器負責儲存一部分快取內容，這樣可以提高整體快取容量並減少對單一伺服器的依賴。

# 設定 NGINX 快取分片範例
http {
    upstream cache_servers {
        hash $scheme$proxy_host$request_uri consistent;
        server red.cache.example.com;
        server green.cache.example.com;
        server blue.cache.example.com;
    }
    
    server {
        listen 80;
        location / {
            proxy_pass http://cache_servers;
            proxy_cache my_cache;
        }
    }
}

內容解密：

上述設定使用了一致性雜湊演算法來將請求分配到不同的快取伺服器。每個請求根據其 URI 被對應到一台特定的快取伺服器上，從而實作了快取的分片儲存。

快取叢集（Cache Clustering）

快取叢集旨在實作高用性的快取架構，即使在部分伺服器故障的情況下，也能保持快取服務的可用性。這可以透過結合負載平衡和快取技術來實作。

結合負載平衡和快取層

在這種架構中，每台 NGINX 例項同時作為負載平衡器和快取伺服器。這樣可以最大化快取容量並提高系統的整體效能。

  graph LR
    A[客戶端] -->|請求|> B[負載平衡層]
    B -->|分發請求|> C[NGINX 例項1]
    B -->|分發請求|> D[NGINX 例項2]
    B -->|分發請求|> E[NGINX 例項3]
    C -->|快取/回源|> F[原始伺服器]
    D -->|快取/回源|> F
    E -->|快取/回源|> F

圖表翻譯： 此圖示展示了一個結合負載平衡和快取層的架構。客戶端的請求首先被負載平衡層分發到不同的 NGINX 例項，每個例項負責處理請求並根據需要進行快取或回源操作。

高效能快取：NGINX 與 NGINX Plus 快取叢集詳解

在現代網路架構中，快取機制對於提升網站效能和減少伺服器負載至關重要。NGINX 和 NGINX Plus 提供了一套強大的快取解決方案，能夠有效地處理大量請求並減少對原始伺服器的負擔。本文將探討如何使用 NGINX 和 NGINX Plus 構建高效能的快取叢集。

組態第一層「熱」快取

為了進一步提升效能，可以在前端負載平衡層組態第一層快取，用於儲存極為熱門的內容，並將大型共用快取作為第二層快取。這種架構能夠改善效能，並在第二層快取層失效時減少對原始伺服器的影響，因為內容只需在第一層快取內容逐漸過期時才需要重新整理。

快取層架構圖示

  graph LR
    A[客戶端請求] -->|DNS, keepalived, etc.| B[負載平衡器]
    B -->|輪詢排程| C[第一層快取伺服器1]
    B -->|輪詢排程| D[第一層快取伺服器2]
    C -->|一致性雜湊| E[第二層快取伺服器1]
    C -->|一致性雜湊| F[第二層快取伺服器2]
    D -->|一致性雜湊| E
    D -->|一致性雜湊| F
    E -->|請求內容| G[原始伺服器]
    F -->|請求內容| G

圖表翻譯： 此圖示展示了客戶端請求如何透過負載平衡器分配到第一層快取伺服器，再由第一層快取伺服器根據一致性雜湊演算法將請求轉發至第二層快取伺服器，最終由第二層快取伺服器向原始伺服器請求內容的流程。

如果快取叢集需要處理非常大量的熱門內容，可能會發現第一層快取的更新率非常高。也就是說，對有限快取空間的需求如此之高，以至於內容在能夠滿足甚至一次後續請求之前就被從快取中清除。

判斷這種情況的一個指標是 NGINX Plus 狀態模組擴充套件統計中提供的兩個指標：已服務內容和已寫入內容的比例較低。這兩個指標出現在內建的實時活動監控儀錶板的快取標籤頁中的 Served 和 Written 欄位。

程式碼範例：組態 NGINX 快取

proxy_cache_path /tmp/mycache keys_zone=mycache:10m;
server {
    listen 80;
    proxy_cache mycache;
    proxy_cache_valid 200 15s;
    location / {
        proxy_pass http://backend;
    }
}
upstream backend {
    server 192.168.56.11;  # 後端伺服器1
    server 192.168.56.12;  # 後端伺服器2
}

內容解密：

proxy_cache_path 定義了快取的路徑和共用記憶體區域的大小。
proxy_cache 啟用了針對指定位置的快取。
proxy_cache_valid 設定了對特定 HTTP 狀態碼的快取有效時間。
proxy_pass 將請求轉發給後端伺服器。
upstream 模組定義了後端伺服器的列表。

方法1：快取分片

將快取分散到多個 NGINX 或 NGINX Plus 網路快取伺服器上是一種建立高容量、可擴充套件快取的有效方法。一致性雜湊提供了一定程度的高用性，確保如果一個快取伺服器失敗，只有其所快取的內容會被宣告無效。

方法2：建立高用性快取叢集

上一節描述了一種建立大型分片快取叢集的模式。本文將介紹如何使用兩個或更多 NGINX 或 NGINX Plus 快取伺服器來建立高用性快取叢集。

組態主快取伺服器

proxy_cache_path /tmp/mycache keys_zone=mycache:10m;
server {
    status_zone mycache;  # 用於 NGINX Plus 擴充套件狀態
    listen 80;
    proxy_cache mycache;
    proxy_cache_valid 200 15s;
    location / {
        proxy_pass http://secondary;
    }
}
upstream secondary {
    zone secondary 128k;  # 用於 NGINX Plus 擴充套件狀態
    server 192.168.56.11;  # 次要快取伺服器
    server 192.168.56.12 backup;  # 原始伺服器（備份）
}

內容解密：

主快取伺服器將所有請求轉發給次要快取伺服器，並快取來自次要伺服器的回應。
當次要伺服器失敗時，主伺服器直接將請求轉發給原始伺服器。

組態次要快取伺服器

proxy_cache_path /tmp/mycache keys_zone=mycache:10m;
server {
    status_zone mycache;  # 用於 NGINX Plus 擴充套件狀態
    listen 80;
    proxy_cache mycache;
    proxy_cache_valid 200 15s;
    location / {
        proxy_pass http://origin;
    }
}
upstream origin {
    zone origin 128k;  # 用於 NGINX Plus 擴充套件狀態
    server 192.168.56.12;  # 原始伺服器
}

內容解密：

次要快取伺服器將請求轉發給原始伺服器，並快取回應。
主伺服器同樣快取來自次要伺服器的回應。

組態高用性

為了確保在主伺服器失敗時次要伺服器能夠接管流量，需要組態高用性（HA）解決方案。這裡使用了 NGINX Plus 的主動-被動 HA 解決方案。

容錯移轉場景

當主快取伺服器失敗時，次要伺服器接管流量；當主伺服器還原時，再次接管流量。這種組態確保了快取叢集的高用性，並且不會增加對原始伺服器的負載。

高效能快取技術：NGINX 與 NGINX Plus 快取叢集詳解

在現代網路架構中，快取技術扮演著至關重要的角色，尤其是在提升網站效能和降低伺服器負載方面。NGINX 和 NGINX Plus 提供了一套強大的快取解決方案，本文將探討如何利用 NGINX 和 NGINX Plus 實作高效能的快取叢集。

NGINX 快取叢集架構

NGINX 快取叢集的設計旨在提供高用性和高效能的內容傳遞。透過建立主備快取伺服器，系統能夠確保在單一節點故障時仍能持續提供服務。

主備快取伺服器組態

在主備架構中，主伺服器負責處理大部分的請求，而備伺服器則在主伺服器故障時接管流量。這種組態確保了系統的高用性。

http {
    upstream backend {
        server localhost:8080;
    }

    proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g;
    
    server {
        listen 80;
        location / {
            proxy_pass http://backend;
            proxy_cache my_cache;
            proxy_cache_valid 200 15s;
        }
    }
}

內容解密：

上述組態定義了一個名為 my_cache 的快取區，並將其儲存在 /path/to/cache 目錄下。levels 引數定義了快取目錄的層級結構，而 keys_zone 則定義了快取索引的名稱和大小。proxy_cache_valid 指令指定了快取的有效期，在此範例中，狀態碼為 200 的回應將被快取 15 秒。

高用性（HA）解決方案

NGINX Plus 提供了內建的高用性解決方案，能夠在主伺服器故障時自動將虛擬 IP 位址轉移至備伺服器，從而確保服務的連續性。

容錯移轉機制

當主伺服器發生故障時，NGINX Plus 的 HA 解決方案會將外部 IP 位址轉移到備伺服器。備伺服器接管流量後，能夠利用其已更新的快取內容繼續提供服務，而不會對原始伺服器造成額外的負載。

測試容錯移轉行為

為了驗證 HA 解決方案的有效性，我們可以組態原始伺服器記錄請求並傳回當前時間。這樣，每秒鐘的請求都會產生不同的回應。

server {
    listen 8080;
    location / {
        return 200 "It's now $time_local\n";
        access_log /var/log/nginx/access.log;
    }
}

內容解密：

此組態使原始伺服器傳回當前時間，並將請求記錄到 /var/log/nginx/access.log。這樣，我們可以觀察到主備伺服器之間的快取更新和容錯移轉行為。

快取更新時機

在穩定的情況下，快取內容通常每 15 到 16 秒更新一次。這是由於快取的有效期設定為 15 秒，並且請求間隔可能導致最多 1 秒的延遲。

縮短快取過期時間

如果需要更頻繁地更新快取內容，可以在備伺服器上組態更短的快取過期時間。

NGINX 快取常見問題

快取是否支援 HTTP/2？

是的，NGINX 快取完全支援 HTTP/2。HTTP/2 是一種高效的傳輸協定，能夠提高網站的載入速度。

如何比較 NGINX 快取與其他內容快取？

NGINX 快取是一種高效的內容快取解決方案，能夠加速 Web 應用程式的效能。CDN（內容傳遞網路）是另一種非常有效的內容快取方案，能夠將內容快取在靠近使用者的位置，從而減少延遲。

NGINX 快取是否可以被檢測和監控？

是的，可以透過 add_header 指令新增 X-Cache-Status 頭部來監控 NGINX 快取的狀態。

add_header X-Cache-Status $upstream_cache_status;

內容解密：

此組態將在客戶端的回應中新增 X-Cache-Status 頭部，其值可能為 MISS、BYPASS、EXPIRED 或 STALE，用於表示快取的命中狀態。

隨著網路技術的不斷發展，對高效能快取解決方案的需求也將持續增長。未來，我們可以期待 NGINX 和 NGINX Plus 在快取技術方面的進一步創新和最佳化，以滿足日益增長的效能需求。

  graph LR
    A[原始伺服器] -->|內容|> B[主快取伺服器]
    A -->|內容|> C[備快取伺服器]
    B -->|容錯移轉|> C
    C -->|提供服務|> D[客戶端]

圖表翻譯： 此圖表展示了 NGINX 快取叢集的架構，包括原始伺服器、主快取伺服器和備快取伺服器之間的關係。在主伺服器故障時，備伺服器接管流量，確保服務的連續性。

參考資料

NGINX 官方檔案：https://nginx.org/en/docs/
NGINX Plus 官方檔案：https://docs.nginx.com/nginx/admin-guide/

透過上述的詳細解析和範例，我們可以看到 NGINX 和 NGINX Plus 在快取技術方面的強大能力和靈活性。無論是在高用性還是在效能最佳化方面，NGINX 都能提供優秀的解決方案。未來，隨著網路技術的持續演進，NGINX 快取技術將繼續發揮其重要作用，為使用者提供更快速、更穩定的網路體驗。

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。