您現在的位置是:首頁 > 音樂首頁音樂

詳解快取:快取中存在的挑戰及策略

由 讀芯術 發表于 音樂2021-08-05
簡介· “驚群效應”問題下游服務不可用時,如果為了從下游服務獲取未快取的資料而發出多個請求,則可能會引發多次重試,進而導致服務掉線

什麼是緩衝

全文共2906字,預計學習時長8分鐘

詳解快取:快取中存在的挑戰及策略

圖源:unsplash

在計算機世界中,快取(caching)就是將資料子集儲存到一個具備高度可訪問性的高速執行層的過程,這一層被稱作高速緩衝儲存器(cache)。

此過程旨在快速讀取使用率較高的資料,避免在存取之前的資料時產生額外的計算負擔。快取只能儲存資料一小段時間,這是權衡容量後的選擇,以此換取更高的執行速度。

像隨機存取儲存器(RAM)和記憶體儲存引擎這類在快取層下的硬體能夠實現快速存取,它們通常和軟體層一起被用於訪問資料。快取基本上分為兩種:本地快取和遠端快取。本地快取依靠JVW(Java虛擬機器)堆進行儲存,而遠端(或叢集)快取使用記憶體儲存器,如Redis和Memcached。

· 什麼是堆內本地快取?

堆內快取指把資料儲存於Java堆中,在這裡資料由垃圾收集器(GC)自動管理。

· 什麼是堆外本地快取?

堆外快取指把資料儲存在堆外。垃圾收集器不會自動處理這些資料,因為資料被儲存在Java堆外,所以它們以位元組陣列儲存,因此也存在把資料序列化和反序列化的額外執行負擔。

· 什麼是遠端快取?

遠端快取是將資料儲存在雲端的緩衝區。因為可以在雲端檢索資料,所以這有助於構建一個更堅固且效能更強的持久層。Redis和Memcached是當下兩款大受歡迎的記憶體快取產品。

詳解快取:快取中存在的挑戰及策略

圖源:unsplash

堆內快取的優點:

· GC會自動分配和釋放物件

· 訪問資料的速度更快

堆內快取的不足:

· GC停頓多發

· 因為資料被儲存於JVM儲存器之中,如果JVM崩潰了,資料就會丟失。因此無法長期快取。

堆外快取的優點:

· 允許大量資料的快取且無須擔心GC停頓

· JVM崩潰後支援在儲存器中新增持久層以恢復資料

· JVM之間可共享快取資料

堆外快取的不足:

· 資料的序列化和反序列化是使用堆外快取時最大的不便之處。這會為下層程式帶來計算負擔。因為沒有共同的資料結構,把序列化的資料轉換成單獨物件將付出額外的成本。

· 短期資料更適合堆內快取,因為它允許GC自動執行。因而,識別哪些資料可以被歸於堆內快取會帶來額外的計算。

· 手動儲存器管理(像儲存器分段之類的問題!)

總之,因為堆外快取能夠長期儲存大量資料,所以它是儲存資料的一種更好方式。再加上大磁碟子系統,就能提高每秒讀寫次數(IOPS)。

遠端快取的優勢:

· 遠端快取叢集可以根據需求進行擴充套件

· 遠端快取不僅僅侷限於單一資料結構,並且它支援多語言程式設計,因而操作簡單。

· 與磁碟的低速存取相比,效能有所增強(因為資料儲存在儲存器中,存取資料速度更快)

如何確定系統/服務需要快取

· 快取命中率:如果服務所提供的資料不需要經常重新整理且屬於經常檢索型資料,應當考慮快取它們。

· 最終一致性的容限:仔細考慮源資料的變化率,以及快取的重新整理頻率。還應該考慮服務物件是否重視最近資料的讀取。

快取策略型別和相應挑戰

詳解快取:快取中存在的挑戰及策略

圖源:unsplash

本地快取:

· 透過在服務(比如說雜湊表)內使用某種儲存方式將使本地快取的執行更加容易,但也會導致快取一致性問題。意思就是,不同伺服器中的本地快取不同,這將導致資料不一致。

例如,伺服器S1用資料D1響應了請求R1,並把它儲存到本地快取中。如果在資料庫中的資料被更新成D2版本,之後R1再次發出相同的請求,則有可能返回資料D1或D2,這取決於請求抵達了哪個伺服器。

· 冷啟動也是記憶體快取的一個重要問題。因為每一個伺服器都是在沒有快取的情況下啟動的,隨著新伺服器的增加,甚至在部署期間,對下游依賴發出的請求數量也會隨之變多。這個問題可以透過請求合併解決。

外部快取:

· 能夠解決以上問題,因為外部快取是分開儲存的,例如Redis和Memcached。

· 提供更多儲存空間並減少因容量而導致的快取淘汰。

· 挑戰包括提高整體系統的複雜性和增加更多負載以維護額外的快取伺服器。

· 始終在服務中新增程式碼來解決快取可能不可用的情況。

· 可以在此期間呼叫下游服務。但如果快取中斷時間過長,可能導致下游服務的負載增加。

· 或者,外部儲存器和內部儲存器一起使用可以避免完全回落到下游依賴。

· 也可以考慮採取減載技術,透過限制服務的請求數量來避免下游服務負載過重。

· 應對快取擴充套件和彈性問題:

如果快取達到最大容量,那麼需要透過向其新增更多節點來擴充套件。深入瞭解系統及其在達到最大容量時的反應(例如,快取達到最大容量時每個容器的記憶體利用率上升)有助於設定準確的警報。

這些警報可用於擴充套件快取服務。在擴充套件服務時,需要記住兩件事:快取叢集是否支援在沒有宕機的情況下新增節點,或者是否支援一致性雜湊演算法來平衡流量分配。始終確保透過模擬故障來測試擴充套件策略。

· 控制資料的魯棒性

快取資料應能夠讀取更新後的程式碼格式,而更新後的程式碼應能夠處理快取所提供的舊版本資料。

快取實現要點

詳解快取:快取中存在的挑戰及策略

圖源:unsplash

· 快取大小:根據服務中透過的資料型別可以確定快取大小,以便提高快取命中率。

· 快取淘汰:這指的是當快取達到最大容量時,把資料從快取中移除。快取淘汰最常見的模式是LRU(最近最少使用)。

· 快取逾期:這是一種確定資料在快取中的保留時間的策略,具體取決於資料重新整理頻率或客戶處理過時資料的能力。

· 下游服務不可用

如果下游服務因為某些原因不可用,快取服務不應該用更新資料的請求攻擊下游,而是能夠長期保護快取,並等待它恢復。根據與客戶之間的權衡協調,要麼報告快取中的過時資料,避免請求令下游服務掉線,要麼使用一種機制來儲存下游服務的錯誤響應,並對其進行相應的解釋說明。

· 安全性

正在快取的敏感資料或客戶資料的安全性是人們對快取叢集的擔憂之一。敏感資料應在儲存前加密,並在輸入和輸出快取資料的過程中確保其安全性。此外,由於快取資料的返回速度比從資料庫獲取的呼叫速度快,攻擊者可以根據響應時間識別服務發出的請求型別,這被稱為側通道時序攻擊。

· “驚群效應”問題

下游服務不可用時,如果為了從下游服務獲取未快取的資料而發出多個請求,則可能會引發多次重試,進而導致服務掉線。可以結合多個策略來緩解這個情況,例如按客戶或請求來進行節流、請求合併(即對相同的未快取資料只發送一個請求)等。

快取可以提供更快的資料訪問速度和提高下游服務可用性,但它的代價是快取節點的處理會更加複雜。透過巧妙地理解下游服務的需求,可以得出一個快取解決方案。在不同的情景中(如流量峰值、快取不可用、下游服務掉線等)都應當對此解決方案的表現進行仔細監控以調整引數。

希望本文能夠幫你理解那些在為服務部署快取解決方案時要牢記於心的要點。

詳解快取:快取中存在的挑戰及策略

留言點贊關注

我們一起分享AI學習與發展的乾貨

如轉載,請後臺留言,遵守轉載規範