後端工程師經驗談 — 有時候用 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 時不會再犯跟我一樣的錯誤。

Facebook Threads X

對抗久坐職業傷害

研究指出每天增加 2 小時坐著的時間,會增加大腸癌、心臟疾病、肺癌的風險,也造成肩頸、腰背疼痛等常見問題。

然而對抗這些問題,卻只需要工作時定期休息跟伸展身體即可!

你想輕鬆改變現狀嗎?試試看我們的 PomodoRoll 番茄鐘吧! PomodoRoll 番茄鐘會根據你所設定的專注時間,定期建議你 1 項辦公族適用的伸展運動,幫助你打敗久坐所帶來的傷害!

贊助我們的創作

看完這篇文章了嗎? 休息一下,喝杯咖啡吧!

如果你覺得 MyApollo 有讓你獲得實用的資訊,希望能看到更多的技術分享,邀請你贊助我們一杯咖啡,讓我們有更多的動力與精力繼續提供高品質的文章,感謝你的支持!