分散式快取
- 2021 年 11 月 2 日
- 筆記
- Java-Interview-Advanced
分散式快取
快取雪崩
快取雪崩我們可以簡單理解為:由於原有快取失效,新快取未到期間所有原本應該訪問快取的請求都去查詢資料庫了,而對資料庫CPU和記憶體造成巨大壓力,嚴重的會造成資料庫宕機。 從而形成一系列連鎖反應,造成整個系統崩潰。一般三種處理辦法:
- 一般並發量不是特別多的時候,使用最多的解決方案是加鎖排隊。
- 給每一個快取數據增加相應的快取標記,記錄快取是否失效,如果快取標記失敗,則更新數據快取。
- 為key設置不同的快取失效時間。
快取穿透
快取穿透是指用戶查詢數據,在資料庫沒有,自然在快取中也不會有。這樣就導致用戶查詢的時候,在快取中找不到,每次都要去資料庫查一遍,然後返回空(相當於進行了兩次無用查詢)。這樣請求就繞過快取直接查詢資料庫,這也是經常提的快取命中率問題。
有很多種方法可以有效地解決快取穿透問題,最常見的則是採用布隆過濾器 ,將所有可能存在的數據哈希到一個足夠大的bitmap中,一個一定不存在的數據會被這個bitmap攔截掉,從而避免了對底層存儲系統的查詢壓力。另外也有一個更為簡單粗暴的方法,如果一個查詢返回的數據為空(不管是數據不存在,還是系統故障),我們仍然把這個空結果進行快取,但它的過期時間會很短,最長不超過五分鐘。通過這個直接設置的默認值存到快取,這樣第二次到快取中獲取就有值了,而不會繼續訪問資料庫。
快取預熱
快取預熱就是系統上線後,將相關快取數據直接載入到快取系統。這樣就可以避免在用戶請求的時候,先查詢資料庫,然後再將數據快取問題.用戶直接查詢事先被預熱的快取數據!
快取更新
快取更新除了快取伺服器自帶的快取失效策略之外(Redis默認的有6種策略可拱選擇),我們還可以根據具體的業務需求進行自定義的快取淘汰,常見的策略有兩種:
- 定時去清理過期的快取
- 當有用戶請求過來時,再判斷這個請求所用到的快取是否過期,過期的話就去底層系統得到新數據並更新快取
快取降級
當訪問量劇增、服務出現問題(如響應時間慢或不響應)或非核心服務影響到核心流程性能時,仍然需要保證服務是可用的,即使是有損服務。系統可以根據一些關鍵數據進行自動降級,也可以配置開關實現人工降級。降級的最終目的是保證核心服務可用,即使是有損的。而且有些服務是無法降級的(如加入購物車,支付)