快取

一個**快取（cache）**儲存一個昂貴問題的答案，這樣你就不必再問一遍。如果你的主頁為每一個訪客都運行同一個繁重的查詢，那就把結果在 Redis 裡快取 60 秒，瞬間提供給使用者。

快取是一種效能最佳化，不是事實來源。經典的初學者陷阱是忘記快取失效（cache invalidation）——快取的副本變陳舊了，使用者看到的是舊資料。經驗法則：只有當你測量出一個真實的瓶頸時才快取，並且始終對快取值何時過期或重新整理有一條清晰的規則。

有兩種乾淨的策略，把它們搞混會引發大多數快取 bug。**基於時間的過期（TTL——Time To Live，就像蓋在快取值上的保質期）**說"這個值在 60 秒內有效，之後就扔掉"——簡單，而且在略微陳舊的資料無害時（一個瀏覽計數、一個主頁資訊流）很合適。基於事件的失效說"在底層資料改變的那一刻就刪除快取值"——正確，但你必須在每一條寫入路徑上都記得這麼做，而那恰恰是人們出岔子的地方。拿不準時，優先用短 TTL：一個最多陳舊一分鐘的值，比一個因為你忘了一次失效而永遠陳舊的值，是更小的 bug。