明智地緩存：如何防止分佈式系統故障

Laura 更新時間 2025年1月7日

快连VPN:速度和安全性最佳的VPN服务

免费试用了解更多

緩存可以以低成本提供可用性和延遲方面的直接好處。但是，如果忽略我們上面討論的方面，則在緩存發生故障時可能會暴露隱藏的擴展瓶頸，從而可能導致系統故障。定期檢查以確保系統在緩存發生故障時也能正常運行，這對於防止可能影響系統可靠性的災難性中斷至關重要。

當我們考慮改善依賴服務調用的延遲和可用性特性時，緩存通常被用作一種通用解決方案。由於我們避免了對依賴服務進行網絡往返，因此延遲有所改善；由於緩存提供了我們所需的響應，我們無需擔心依賴服務的臨時停機，因此可用性有所改善。需要注意的是，如果我們對依賴服務的請求每次都導致不同的響應，或者客戶端發出的請求類型截然不同且響應之間沒有太多重疊，則緩存無濟於事。如果我們的服務無法容忍陳舊數據，那麼使用緩存還會受到其他限制。

我們不會深入探討緩存類型、技術和適用性，因爲這些內容在互聯網上已經廣泛介紹過了。相反，我們將重點討論緩存中較少被提及的風險，這些風險在系統發展過程中被忽視，而這會使系統面臨大面積中斷的風險。

何時使用緩存

在許多情況下，部署緩存是爲了掩蓋依賴服務的已知擴展瓶頸，或者緩存接管這一角色，以隱藏依賴服務隨着時間的推移可能出現的擴展缺陷。例如，當我們的服務開始減少對依賴服務的調用時，他們開始相信這是穩定狀態流量的常態。如果我們的緩存命中率爲 90%，這意味着對依賴服務的 9/10 次調用都由緩存提供，那麼依賴服務只能看到 10% 的實際流量。如果客戶端緩存由於中斷或錯誤而停止工作，依賴服務的流量將激增 9 倍！在幾乎所有情況下，這種流量激增都會使依賴服務過載，從而導致中斷。如果依賴服務是數據存儲，這將導致依賴該數據存儲的多個其他服務癱瘓。

爲了防止此類中斷，客戶端和服務都應考慮遵循建議來保護他們的系統。

建議

對於客戶端來說，重要的是不要再將緩存視爲“可有可無”的優化，而是將其視爲需要與常規服務一樣對待和審查的關鍵組件。這包括對緩存命中率閾值以及發送到依賴服務的整體流量進行監控和報警。

對緩存業務邏輯的任何更新或更改也需要在開發環境和預生產階段經過同樣嚴格的測試。部署到參與緩存的服務器時，應確保存儲的狀態已轉移到部署後即將啓動的新服務器，或者部署期間緩存命中率的下降對於依賴服務來說是可以容忍的。如果在部署期間關閉大量緩存服務服務器，則可能導致緩存命中率成比例下降，從而給依賴服務帶來壓力。

客戶端還需要實施防護措施來控制流向依賴項服務的整體流量（以每服務事務數 (TPS) 來衡量）。當緩存隊列出現故障時，令牌桶等算法可以幫助限制來自隊列的 TPS。這需要通過關閉緩存實例並查看客戶端如何向依賴項服務發送流量來定期進行測試。客戶端還應考慮實施具有較小生存時間 (TTL) 的負緩存策略。負緩存意味着客戶端將存儲來自依賴項服務的錯誤響應，以確保依賴項服務在長時間中斷時不會受到重試請求的轟炸。

同樣，在服務端，需要實施負載削減機制來防止服務過載。在這種情況下，過載意味着服務無法在客戶端超時內做出響應。請注意，隨着服務負載的增加，通常表現爲延遲增加，因爲服務器資源被過度使用，導致響應速度變慢。我們希望在客戶端請求超時之前做出響應，如果總體延遲開始超過客戶端超時，則開始拒絕請求。

有多種技術可以防止過載；最簡單的技術之一是限制從應用程序負載均衡器 ( ALB ) 到服務主機的連接數。但是，這可能意味着不加區分地丟棄請求，如果不希望這樣，則可以在服務的應用程序層實施優先級技術以丟棄不太重要的請求。負載削減的目標是確保服務在服務的整體負載增加時保護有效吞吐量，即在客戶端超時內提供的請求。服務還需要定期運行負載測試以驗證服務主機處理的最大 TPS，這允許對 ALB 連接限制進行微調。我們介紹了幾種保護服務有效吞吐量的技術，這些技術應該可以廣泛應用，但讀者可以根據自己的服務需求探索更多方法。