CloudFront 如何设置缓存策略的优化配置指南
深夜改版上線前，團隊裡的小張突然敲我鍵盤：「客戶的促銷banner在美國刷不出來，後台報錯500！」查了五分鐘才發現，CloudFront把登入態的session_id也給緩存了。這種痛，做過全球加速的同行都懂——緩存策略配錯，輕則用戶體驗翻車，重則資料庫被擊穿。今天這篇實戰筆記，就拆解那些教科書不會寫的CloudFront緩存優化細節。
緩存行為層級才是決勝點。很多人只在分配層掛個預設TTL，這就像把生鮮和罐頭塞同個冰箱。接手某跨境電商時，發現他們商品詳情頁TTL設了24小時，結果價格變動時用戶看到舊資料。後來拆出三條規則：靜態資源（js/css/img）直接套365天，商品API路徑用Lambda@Edge動態判斷max-age，登入相關頁面徹底關閉緩存。重點在於路徑模式用正則精準捕獲，例如把促銷頁面限定在 /campaign/*
緩存鍵的魔鬼藏在參數裡。某客戶的圖片服務器曾因URL帶時間戳參數，導致CloudFront每秒回源數萬次。後來在\”Cache key and origin requests\”裡勾選\”Query strings – Include specified headers\”，只保留v=版本參數。更狠的是開啟自動壓縮參數歸一化，把?v=1.2&t=2024 和 ?t=2024&v=1.2 識別為同個緩存對象，邊緣節點命中率直接飆升40%
動態內容的緩存平衡是門藝術。金融平台客戶的股價API需要秒級更新，但全動態回源扛不住開盤流量。最終解法：後端響應頭帶Cache-Control: public, max-age=10，同時在CloudFront設定最小TTL=5秒。別小看這五秒，配合分區緩存池設計，開盤瞬間的QPS從12萬降到8千。關鍵是後端必須返回Vary: Accept-Encoding頭，避免壓縮版本錯亂
失效操作比你想的更危險。有團隊用控制台手動失效路徑/*，結果全球節點同時回源，源站瞬間被打出503。現在我們都用版本化靜態資源：/static/js/main-v3.js，改版時直接切路徑。動態內容失效必用Lambda@Edge，在Viewer Request階段檢查自定義頭部x-purge-cache，觸發時才回源拿資料，避免雪崩
監控埋點決定生死。曾經有日本節點命中率莫名降到60%，查了CloudWatch才發現是某廣告SDK瘋狂追加隨機參數。後來在實時日誌流裡添加QueryString欄位，用Kinesis Firehose直灌ElasticSearch，參數濫用一目了然。記住開啟\”Enable standard logs\”時，務必勾選Include cookies欄位，這是抓緩存污染的金礦
當你發現新加坡用戶加載延遲突然飆到800ms，別急著調大TTL。上個月我們用CloudFront的連續部署功能，把新策略只發佈到5%邊緣節點，監控三天確認澳洲節點磁盤IO暴增——原來是緩存對象太小但數量巨多，趕緊把默認文件從Memcached遷到SSD儲存層。緩存優化從來不是設定完就結束的事，那些深夜告警教會我的事，比任何文檔都真實
評論: