後端工程師經驗談 — 有時候用 Cache Aside 是個壞主意

今天突然想起一件故事，這個故事是關於 Cache 機制沒設計好導致系統不穩的故事。

後端工程師很常會透過在 API 埋 cache 的手法，增加回應速度，並且減輕後端資料庫的負擔，這個手法的模式如下所示：

def api(...):
    ...
    cache = get_cache(key)
    if cache:
       return response.ok(cache)
    data = query_database()
    set_cache(key, data, ttl)
    return response.ok(data)

上述程式碼會先查詢 cache server 有沒有相關的快取，如果有的話，就拿出來直接回應給使用者；如果沒有快取，就對資料庫進行查詢，再將查詢結果放到 cache server, 如此一來，下次再有相同的 request 的話，就能夠使用快取。

這種快取手法稱為 Cache Aside, 也是後端工程師最常用使用的快取方式。

Cache Aside 雖然簡單好用，但它有個缺點。

故事是這樣的⋯⋯。

當時我做了 1 個所有使用者都會呼叫的 API, 該 API 負責回應過去某段時間內的各大分類的熱銷商品，因為所有使用者看到的熱銷商品都一樣，所以這個 API 只需要做 1 份 cache, 我就在 API 裡使用上述提到的 Cache Aside 手法，在 cache 失效時自動重算過去某段時間的各大分類的熱銷商品，再放回去 Cache server 供下次使用。

然後，上線當天的尖峰時刻就出事了，系統每隔一段時間就收到多筆 Timeout Error ⋯⋯。

後來一路查下去就是我寫的 API 所造成的，而造成錯誤的根本原因是：

一旦 cache 失效或者正在更新時，因為所有使用者都會用到這個 API, 所以同時會有很多個 query requests 湧進後端資料庫，它們都要求查詢各大分類熱門商品的資料，而恰好這個查詢剛好是對資料庫負擔較重的 aggregation 運算，所需的運算時間相對久（是 slow query），因此導致資料庫疲於運算，最終超過 API 所設定的 Timeout 限制⋯⋯，然後，大家就加班囉～

這個故事給我的啟示是 Cache Aside 有時候是個壞點子，一旦 cache 失效/更新期間會造成大量 query 湧進資料庫，造成資料庫負擔驟升的情況，就最好不要使用 Cache Aside, 建議使用 Refresh-Ahead 手法，在 cache 失效之前就先更新好，例如可以寫個 script 用 Crontab 定期更新。

以上一點經驗分享，希望有人下次要加 Cache 時不會再犯跟我一樣的錯誤。