分散式快取系統是三高架構中不可或缺的部分,大大提高了整個專案的並發量、回應速度,但它也帶來了新的需要解決的問題,分別是: 快取穿透、快取擊穿、快取雪崩和快取一致性問題。
第一個比較大的問題就是快取穿透。這個概念比較好理解,和命中率有關。如果命中率很低,那麼壓力就會集中在資料庫持久層。
假如能找到相關數據,我們就可以把它緩存起來。但問題是,本次請求,在快取和持久層都沒有命中,這種情況就叫做快取的穿透。
舉個例子,如上圖,在一個登入系統中,有外部攻擊,一直嘗試使用不存在的使用者進行登錄,這些使用者都是虛擬的,不能有效地被快取起來,每次都會到資料庫中查詢一次,最後就會造成服務的效能故障。
解決這個問題有多種方案,我們來簡單介紹一下。
第一種就是把空物件快取起來。不是持久層查不到資料嗎?那我們就可以把本次請求的結果設為 null,然後再放入快取中。透過設定合理的過期時間,就可以確保後端資料庫的安全。
快取空物件會佔用額外的快取空間,還會有資料不一致的時間窗口,所以第二種方法就是針對大數據量的、有規律的鍵值,使用布隆過濾器進行處理。
一筆記錄存在與不存在,是 Bool 值,只需要使用 1 位元就可儲存。布隆過濾器就可以把這種是、否操作,壓縮到一個資料結構。例如手機號,用戶性別這種數據,就非常適合使用布隆過濾器。
快取擊穿,指的也是使用者請求落在資料庫上的情況,大多數情況,是由於快取時間批次過期引起的。
我們通常會對快取中的數據,設定一個過期時間。如果在某個時刻從資料庫獲取了大量數據,並設定了相同的過期時間,它們將會在同一時刻失效,造成和快取的擊穿。
對於比較熱點的數據,我們就可以設定它不過期;或者在訪問的時候,更新它的過期時間;批量入庫的緩存項,也盡量分配一個比較平均的過期時間,避免同一時間失效。
雪崩這個字看著可怕,實際情況也確實比較嚴重。快取是用來對系統加速的,後端的資料庫只是資料的備份,而不是作為高可用的替代方案。
當快取系統故障,流量會瞬間轉移到後端的資料庫。過不了多久,資料庫將會被大流量壓垮掛掉,這種級聯式的服務故障,可以形象化地稱為雪崩。
快取的高可用建設是非常重要的。 Redis 提供了主從和 Cluster 的模式,其中 Cluster 模式使用簡單,每個分片也能單獨做主從,可以保證極高的可用性。
另外,我們對資料庫的效能瓶頸有一個大體的評估。如果快取系統當掉,那麼流向資料庫的請求,就可以使用限流元件,將請求攔截在外面。
引入快取元件後,另外一個老大難的問題,就是快取的一致性。
我們先來看問題是怎麼發生的。對於一個快取項目來說,常用的操作有四個:寫入、更新、讀取、刪除。
寫入:快取和資料庫是兩個不同的元件,只要涉及雙寫,就存在只有一個寫成功的可能性,造成資料不一致。
更新:更新的情況類似,需要更新兩個不同的元件。
讀取:讀取要保證從快取中讀到的資訊是最新的,是和資料庫中的是一致的。
刪除:當刪除資料庫記錄的時候,如何把快取中的資料也刪掉?
由於業務邏輯大多數情況下,是比較複雜的。其中的更新操作,就非常昂貴,例如一個使用者的餘額,就是透過計算一系列的資產算出來的一個數。如果這些關聯的資產,每個地方改動的時候,都去刷新緩存,那程式碼結構就會非常混亂,以至於無法維護。
我推薦使用觸發式的快取一致性方式,使用懶載入的方式,可以讓快取的同步變得非常簡單:
當讀取快取的時候,如果快取裡沒有相關數據,執行相關的業務邏輯,建構快取資料存入到快取系統;
當與快取項目相關的資源有變動,則先刪除對應的快取項,然後在資料庫中更新資源,最後再刪除對應的快取項目。
這種操作,除了程式設計模型簡單,有一個明顯的好處。我只有在用到這個快取的時候,才把它載入到快取系統中。如果每次修改 都建立、更新資源,那麼快取系統中就會存在非常多的冷資料。這實際上是實現了邊緣快取模式(Cache-Aside Pattern),即按需將資料從資料儲存載入到快取中,最大的作用就是提高效能減少不必要的查詢。
但這樣還是有問題。接下來介紹的場景,也是面試中常提及的問題。
我們上面提到的資料庫的更新動作,和快取刪除動作,明顯是不在一個事務裡的。可能造成資料庫的內容和快取裡的內容在更新的過程有不一致。
在面試中,只要你把這個問題給點出來,面試官都會蹺大拇指。
可以使用分散式鎖定來解決這個問題,將資料庫操作和快取操作,與其他的快取讀取操作,使用鎖定進行資源隔離即可。一般來說,讀取操作是不需要加鎖的,它會在遇到鎖的時候,重試等待,直到超時。
以上是Java分散式快取系統需要解決哪四大問題?的詳細內容。更多資訊請關注PHP中文網其他相關文章!