Squid 代理緩存深度優化指南：從業務拆分到參數調優的系統化方法論

前言：優化的誤區與核心哲學

許多運維陷入「調參數迷思」：只調 cache_mem、maximum_object_size 等內核參數，期望榨乾效能。實則 Squid 效能上限由業務架構決定，參數調優僅能在架構允許範圍內榨取 10%~20% 提升。真正的數量級突破（100%~200%+）來自於：

1. 正確的緩存策略（Cache-Control/Expires）
2. 業務流量拆分（動靜分離、大小文件隔離、可緩存/不可緩存隔離）
3. 監控驅動的持續迭代

第零步：建立可觀測性基礎設施

無監控不優化。編譯時 --enable-snmp，部署 MRTG/Cacti/Zabbex/Prometheus+Grafana 監控核心指標：

• Request Hit Ratio (RHR)：請求命中率，目標 > 90%（靜態資源站點應達 95%+）。
• Byte Hit Ratio (BHR)：流量命中率，反映頻寬節省效果。
• Service Time：HIT/MISS 平均響應時間，目標 HIT < 10ms，MISS < 上游響應時間。
• Cache Swap Usage：磁碟緩存使用率，配合 cache_swap_low/high 水位線。
• File Descriptors Usage：FD 使用率，預留 20%+ 餘量。

第一階段：緩存策略落地——讓 Squid「知道」什麼能緩存

A. 動態頁面：應用層輸出 Cache-Control/Expires

Squid 預設不緩存無明確緩存頭的回應。開發人員必須在動態頁面輸出：

# PHP 範例：緩存 300 秒
$expire = 300;
header("Cache-Control: max-age=$expire, public");
header("Expires: " . gmdate("D, d M Y H:i:s", time() + $expire) . " GMT");

# Java Servlet 範例
response.setHeader("Cache-Control", "max-age=300, public");
response.setDateHeader("Expires", System.currentTimeMillis() + 300_000);

關鍵點：

• public 允許代理緩存；private 僅瀏覽器緩存（Squid 不緩存）。
• max-age 優先級高於 Expires，建議同時輸出雙重保險。
• 登入頁、購物車、API 介面嚴禁輸出緩存頭（或輸出 Cache-Control: no-store, private）。

B. 靜態資源：Web Server 層統一加頭（推薦）

Apache mod_expires / Nginx expires 指令按路徑/副檔名批量加頭：

# Nginx 範例
location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2?|svg)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}

# Apache mod_expires 範例

    ExpiresActive On
    ExpiresByType image/jpeg "access plus 30 days"
    ExpiresByType text/css "access plus 7 days"
    ExpiresByType application/javascript "access plus 7 days"

優於 Squid refresh_pattern：符合 HTTP 標準、易除錯、避免前端違協配置導致的詭異問題。

第二階段：業務流量拆分——消除干擾，專注優化

拆分一：可緩存 vs 不可緩存

登入、註冊、支付、即時 API 等不可緩存流量若混入緩存節點：

• 拉低整體 RHR，干擾容量規劃。
• 搶佔 FD/CPU/頻寬，影響靜態資源服務質量。
• 瀏覽器並發連接限制（同域 6 條），拆分域名可突破限制。

方案：api.example.com 直連上游；static.example.com 走 Squid 緩存。

拆分二：大文件 vs 小文件

下載站（GB 級安裝包）與圖片站（KB 級圖標）混跑的災難：

• 大文件佔滿 cache_dir，擠出熱門小文件 → 小文件 MISS 激增。
• 小文件佔滿 inode/目錄項，大文件無法入緩存 → 大文件 MISS 激增。
• 替換算法（LRU/LFU/Heap）無法同時優化兩極分佈的對象大小。

方案：依文件大小分層：

DNS 分流：dl.example.com → cluster-huge，img.example.com → cluster-small。

第三階段：參數精調——在正確架構上榨取極致

記憶體緩存

# 物理記憶體 64GB 機器，預留 8GB 給 OS/FS Cache
cache_mem 32 GB
maximum_object_size_in_memory 256 KB   # 小文件叢集可調 512KB
memory_replacement_policy heap GDSF    # 考慮對象大小與命中頻率的混合策略

磁碟緩存佈局

網路與 FD 優化

日誌與統計

a %Ss/%03>Hs %

第四階段：進階功能與邊界優化

• 緩存清除：編譯 --enable-http-violations 並載入 ngx_cache_purge 模組（或使用 Squid 3.2+ 原生 PURGE 方法），支援 curl -X PURGE https://proxy/object 精準失效。
• 範圍請求支援：range_offset_limit -1 允許緩存大文件分片，配合 quick_abort_min/max 控制客戶端中斷後的預取行為。
• 上游健康檢查：cache_peer ... check-interval=30 timeout=5 自動摘除故障上游。
• HTTPS 終結與緩存：Squid 3.5+ 支援 ssl-bump 解密緩存，但涉及憑證管理與合規，評估風險後謹慎啟用。
• ICP/HTCP 叢集協作：多節點間共享緩存索引，減少重複回源，適合大型 CDN 邊緣節點群。

驗證優化成效：標準化壓測流程

1. 建立基線：wrk -t8 -c2000 -d60s --latency https://squid/ 記錄 RHR、BHR、P99 延遲、吞吐量。
2. 單一變更：每次只調一類參數或架構。
3. 對比基線：關注 業務指標（用戶可感知的頁面載入時間） 而非單純 Squid 內部指標。
4. 長期觀察：上線後持續監控 1~2 週，排除冷啟動、週期性流量干擾。

總結

Squid 優化是系統工程，而非參數遊戲。正確的緩存頭 → 業務流量拆分 → 監控驅動參數調優 → 進階功能補強，四步走策略能將命中率從 50% 推至 95%+，將頻寬成本降低 80%+。切記：沒有業務方配合的緩存頭輸出，再強的 Squid 也只是昂貴的 TCP 連接池。