工程 · 2 min read
三個地方都在設定 TTL
一個檔案的 TTL 在三個地方設定：bucket metadata、LB cache 和 CDN 規則。TTL 途中只會被壓低，而 IaC 裡的空白代表預設值。
一個檔案的 TTL 不是一個地方決定的。三層各有設定，TTL 從 storage 一路傳到 client，途中只會被壓低。
我原本以為 TTL 只在 CDN 上設定。追下去才發現，路上有三個地方都在決定它。
每一層的設定
| 層 | 設定 | 我們的值 |
|---|---|---|
| ① Bucket | 物件的 Cache-Control metadata | 上傳時沒設，bucket 回 public, max-age=3600 |
| ② LB cache | cache mode | 快取所有靜態檔案 |
| default TTL / client TTL 上限 / max TTL | 3600 / 3600 / 86400 | |
| stale-while-revalidate 時間 | 86400（Stale-while-revalidate：先回舊檔，背景再刷新） | |
| ③ Akamai | caching 行為 | 遵守 Cache-Control 和 Expires，預設 30 天 |
- 在「快取所有靜態檔案」模式下，client TTL 上限就是 LB cache 往外傳的
max-age上限。 - 所以就算上傳時設了 30 天，經過 proxy 路線到 Akamai 時，最多還是 3600 秒。
- 「只會被壓低」的前提是 Akamai 遵守收到的
max-age。Akamai 改成固定 TTL 時，最靠近 client 的它可以蓋掉後面的值（Cache 的新鮮度：fresh、stale 和 304）。 - LB cache 會改寫這個 header：bucket 回
public, max-age=3600，經過它變成public,max-age=3600。
沒寫設定，不代表沒有設定
我們用 IaC（Infrastructure as Code）管理設定。裡面沒寫 LB cache 的規則，我就以為它沒有規則。但只要 cache 開著，它就一定有一整套預設值。我直接向雲端平台查詢，才讀到真正的值。
IaC 裡的空白不是「沒有」，而是「預設」。
延伸閱讀：Cache 的新鮮度：fresh、stale 和 304、Cache header：誰設定，誰讀取、一個 request 走過的路、Stale-while-revalidate：先回舊檔，背景再刷新、我學到的：cache 不是一個方塊，是一條鏈。或回到系列總覽。