Spring Boot 3.2專案中使用快取Cache的正確姿勢！！!

你是否曾想過為什麼在 Spring Boot 應用中快取是如此重要？答案在於它透過減少資料檢索時間來提高效能。在本文中，我們將深入探討快取對微服務模式的影響，並探討根據操作易用性、速度、可用性和可觀測性等因素選擇正確快取的重要性。我們還將探討如何最大程度地提高快取效能和可用性。

1 快取實現

1.1 快取對微服務模式的影響

考慮這樣的情景，其中一個 Edge API 開放給網際網路，觸發對服務 A 和 B 的額外請求，這兩個服務反過來呼叫服務 C 和 D。透過引入客戶端快取，可以顯著提高應用程式效能並打破這種依賴鏈。

1.2 選擇正確的快取

在選擇正確的快取之前，我們必須瞭解我們應用的需求，並根據以下因素選擇快取：

1. 操作易用性 — 是否需要向系統新增新元件？
2. 速度 — 從快取檢索或設定值需要多長時間？
3. 可用性 — 它如何提高系統的整體可用性？
4. 可觀測性 — 系統的狀態推理有多容易？

2 快取型別

有三種不同型別的快取：

2.1. 本地快取

• 僅限於應用程式/節點執行的本地例項
• 由於資料儲存在本地，所以速度更快
• 由於資料與其他快取不共享，缺乏一致性
• 在需要在多個節點之間共享大量資料的情況下效率低
• 用例場景：當資料特定於單個例項且不需要在不同例項之間共享資料時

Local Cache：

2.2. 分散式快取

• 由於快取在多個例項之間共享，快取的資料可由系統中的任何節點訪問（用例：多個例項需要共享一個公共快取）
• 由於網路延遲，從遠端節點訪問資料可能需要一些時間，但並非總是如此
• 由於每個例項將其更改傳播到其他節點，因此一致性
• 可高度擴充套件

Distributed Cache：

2.3. 分層快取

• 每個客戶端副本都保留本地快取和遠端快取，作為回退
• 這類似於 CPU 快取

if local_cache_hit(request):
  return get_from_local_cache(request)
else:
  if remote_cache_hit(request):
    return get_from_remote_cache(request)
  else:
    response = call_a(request)
    set_local_cache_in_background(response)
    set_remote_cache_in_background(response)
    return response

每種快取的目標都是最大程度地增加快取命中，以提高系統的整體效能。那麼在實際設定中，當我們有定期更新的動態資料並且還儲存快取內容以獲得所需輸出時，我們該如何做呢？

可為快取設定生存時間（TTL）。如果我們為我們的快取設定長時間的 TTL，比如近 24 小時，我們可能會讀取陳舊的資料，另一方面，較短的 TTL 將增加新鮮度，但經常呼叫伺服器可能會導致可用性和延遲問題。

我們將討論一些策略，如面向事件驅動架構的主動失效和對於伺服器不發出事件的情況下的後臺重新整理。

1. 主動失效 → 用於事件驅動架構的最常見用法。每當伺服器發出事件時，客戶端都會監聽它並更新快取並清除不必要的快取資料。我們可以設定較長的 TTL，知道過時的條目將被主動失效。
2. 後臺重新整理 → 如果伺服器不發出事件，我們可以在後臺重新整理條目，即使是快取命中。我們的資料可能會變得不那麼陳舊，而延遲將大大降低。

3 結論

實質上，在 Spring Boot 中進行快取是提高效能的關鍵。從打破依賴關係到最佳化命中，它是微服務世界中高效和響應性系統的重要工具。