前言

Cache 是很常聽到的效能優化方式。

簡單來說，就是把常用的結果先存起來，下次需要時不用重新計算或重新查詢。

聽起來很美好，但 Cache 不是免費的。它可以讓系統變快，也可能讓資料變得難以理解。

Cache 解決的是重複成本

假設某個 API 每次都要查很多資料、做很多計算，但結果短時間內不太會變。

這時候就可以考慮 Cache。

第一次請求：

1
查資料庫 -> 計算 -> 回傳結果 -> 存入 Cache

下一次請求：

1
從 Cache 取結果 -> 回傳

如果資料真的不常變，這樣可以省下很多成本。

最大問題是資料何時失效

Cache 最麻煩的地方通常不是怎麼存，而是什麼時候要讓它失效。

例如商品資料被修改了，但 Cache 裡還留著舊資料。

使用者看到的就可能是：

1
2
資料庫：新價格
頁面：舊價格

這種問題常常比查詢慢更難排查。

所以加入 Cache 前，要先想清楚：

  • 資料可以舊多久？
  • 什麼情況要清掉 Cache？
  • Cache 清不掉時會造成多大影響？
  • 使用者是否能接受短暫不一致？

TTL 是常見做法

TTL 是 Time To Live，也就是 Cache 存活時間。

例如：

1
快取 5 分鐘

代表資料放進 Cache 後，5 分鐘內都可以直接使用。超過時間就失效，下一次再重新查資料。

TTL 的好處是簡單。

缺點是資料在 TTL 期間內可能不是最新的。

所以 TTL 適合用在可以接受短暫延遲更新的資料，例如排行榜、統計數字、首頁列表等等。

不要什麼都 Cache

不是所有資料都適合 Cache。

比較適合的情境：

  • 查詢頻率高。
  • 計算成本高。
  • 資料短時間內不常變。
  • 短暫不一致可以接受。

比較不適合的情境：

  • 高度即時資料。
  • 權限判斷敏感。
  • 金流或庫存等不能出錯的資料。
  • 資料變動頻率很高。

Cache 是工具，不是看到效能問題就直接上的萬用解。

結語

Cache 的核心問題其實是取捨。

你用資料一致性，換取速度和成本。

我會先問：

  • 這段查詢真的慢嗎？
  • 慢的原因是重複成本嗎？
  • 使用者能接受資料延遲嗎？
  • Cache 失效策略是什麼？

想清楚這些，再加 Cache，會比看到慢就先快取安全很多。