Nginx proxy_cache 實戰：以硬碟緩存換極致性價比，小記憶體撐大流量架構設計

核心觀點：proxy_cache 是性價比之王

架構模式：Nginx (反向代理 + proxy_cache) + 後端動態應用

• 後端：PHP-FPM / Java / Python / Go / Node.js（處理動態邏輯、生成 HTML/JSON）
• 前端 Nginx：proxy_cache 將後端回應緩存到硬碟，後續請求直接由 Nginx 以靜態文件方式服務。
• 結果：動態應用變「靜態站點」，Nginx 發揮極致靜態服務能力，小記憶體（1-2GB）撐起百萬級 PV/日。

為什麼不用 Varnish？

結論：除非你是「大記憶體富豪」且追求極致微秒級延遲，Nginx proxy_cache + SSD + OS Page Cache 是 99% 場景的最優解。

核心配置模板

# http 上下文：定義緩存區
proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=app_cache:100m inactive=7d max_size=50g use_temp_path=off;

# 可選：獨立 temp_path（必須同檔案系統，否則 rename 跨裝置失敗）
# proxy_temp_path /data/nginx/tmp;

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass https://backend_upstream;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # ===== 緩存核心指令 =====
        proxy_cache app_cache;
        proxy_cache_key "$scheme$request_method$host$request_uri$args"; # 含查詢字串
        proxy_cache_valid 200 302 10m;   # 正常回應緩存 10 分鐘
        proxy_cache_valid 404 1m;        # 404 緩存 1 分鐘（防穿透）
        proxy_cache_valid any 1m;        # 其他狀態碼 1 分鐘
        proxy_cache_min_uses 1;          # 首次請求即緩存
        proxy_cache_methods GET HEAD;    # 僅緩存 GET/HEAD

        # 可選：忽略後端不緩存頭（謹慎使用）
        # proxy_ignore_headers Cache-Control Expires Set-Cookie;
        # proxy_hide_header Set-Cookie;    # 不向客戶端透傳 Cookie

        # 可選：緩存狀態標頭（前端除錯用）
        add_header X-Cache-Status $upstream_cache_status;
    }

    # ===== 互動頁面：登入用戶/帶 Cookie 不緩存 =====
    location /user/ {
        # 方案 A：完全不緩存
        proxy_cache off;
        proxy_pass https://backend_upstream;
        ...
    }

    location /comment/ {
        # 方案 B：短緩存（5-15 分鐘），平衡互動性與效能
        proxy_cache app_cache;
        proxy_cache_valid 200 302 5m;
        proxy_cache_key "$scheme$request_method$host$request_uri$args$cookie_userid";
        ...
    }

    # ===== 手動清除緩存（需 ngx_cache_purge 模組）=====
    location ~ /purge(/.*) {
        allow 10.0.0.0/8;
        allow 127.0.0.1;
        deny all;
        proxy_cache_purge app_cache "$scheme$request_method$host$1$is_args$args";
    }
}

關鍵指令深度解析

互動性業務的緩存策略：三種模式對比

進階：fastcgi_cache 替代方案（純 PHP-FPM 架構）

若架構為 Nginx + PHP-FPM（無獨立應用伺服器），可直接用 fastcgi_cache 緩存 FastCGI 回應：

fastcgi_cache_path /data/nginx/fcgi_cache levels=1:2 keys_zone=fcgi_cache:50m inactive=1d max_size=20g;

location ~ \.php$ {
    fastcgi_pass unix:/run/php/php-fpm.sock;
    fastcgi_cache fcgi_cache;
    fastcgi_cache_key "$scheme$request_method$host$request_uri$args";
    fastcgi_cache_valid 200 10m;
    fastcgi_cache_bypass $cookie_nocache $arg_nocache;
    fastcgi_no_cache $cookie_sessionid;
    add_header X-FastCGI-Cache $upstream_cache_status;
    include fastcgi_params;
}

實測對比：同樣硬體，proxy_cache (Nginx + 獨立應用) 負載穩定在 0.4 以下；fastcgi_cache (LNMP) 負載 0.3-0.8 波動較大。原因在於 PHP-FPM 進程模型與 Nginx Worker 爭搶 CPU/上下文切換。

生產級調優清單

1. SSD + noatime 掛載：/dev/nvme0n1p1 /data/nginx/cache ext4 defaults,noatime,discard 0 0
2. OS Page Cache 充分利用：預留 50%+ 記憶體給 OS，熱緩存自動駐留記憶體。
3. 避免緩存雪崩：proxy_cache_lock on; proxy_cache_lock_timeout 5s; proxy_cache_lock_age 5s; 同一鍵並發僅一請求回源。
4. 緩存預熱：上線前腳本批量 curl -s -o /dev/null 熱門 URL。
5. 監控指標：$upstream_cache_status (HIT/MISS/BYPASS/EXPIRED/STALE/UPDATING) 統計命中率，目標 > 90%。
6. 日誌分析：log_format cache '$upstream_cache_status $request_uri $upstream_response_time';

總結

Nginx proxy_cache 以硬碟為緩存介質、OS Page Cache 為加速層、共享記憶體區為索引的三層架構，實現了極低成本、極高容量、接近記憶體速度的緩存能力。配合業務感知的緩存鍵設計、差異化 TTL、主動失效機制，可將動態應用轉化為高性能靜態服務，是中小型架構「以小博大」的核心利器。