前言
- 昨天有讀者朋友留言,想要陳某寫一篇防止快取穿透的文章,今天特意寫了一篇。
- 文章目錄如下:
-
什麼是快取穿透?
- 快取穿透其實是指從快取中沒有查到資料,而不得不從後端系統(比如資料庫)中查詢的情況。
- 快取畢竟是在記憶體中,不可能所有的資料都儲存在 Redis 中,因此少量的快取穿透是不可避免的,也是系統能夠承受的,但是一旦在瞬間發生大量的快取穿透,資料庫的壓力會瞬間增大,後果可想而知。
- 在開發中使用快取的方案如下圖,在查詢資料庫之前會先查詢 Redis:
- 快取穿透的整個過程分為如下幾個步驟:
- 應用查詢快取,快取不命中
- DB 層查詢不命中,不將空結果快取
- 返回空結果
- 下一個請求繼續重複1,2,3步。
解決方案
- 萬事萬物都是相生相剋,既然出現了快取穿透,就一定有避免的方案。
- 下面介紹兩種快取的方案,分別是
快取空值
、布隆過濾器
。
快取空值
- 回顧快取穿透的定義知道,大量空值沒有快取導致重複的訪問 DB 層,由此解決方案也是很明顯了,直接將返回的空值也快取即可。此時的執行步驟如下圖:
-
- 如上圖所示,如果快取不命中,查詢 DB 層之後,直接將空值快取在 Redis 中。虛擬碼如下:
Object nullValue = new Object();
try {
Object valueFromDB = getFromDB(uid); //從資料庫中查詢資料
if (valueFromDB == null) {
cache.set(uid, nullValue, 10); //如果從資料庫中查詢到空值,就把空值寫入快取,設定較短的超時時間
} else {
cache.set(uid, valueFromDB, 1000);
}
} catch(Exception e) {
// 出現異常也要寫入快取
cache.set(uid, nullValue, 10);
}
- 通過虛擬碼可以很清楚的瞭解了快取空值的流程,但是需要注意以下問題:
- 快取一定要設定過期時間:因為空值並不是準確的業務資料,並且會佔用快取空間,所以要給空值加上一個過期時間,使得能夠在短期之內被淘汰。但是隨之而來的一個問題就是在一定的時間視窗內快取的資料和實際資料不一致,比如設定 10 秒鐘過期時間,但是在這 10 秒之內業務又寫入了資料,那麼返回就不應該為空值了,所以還要考慮資料一致的問題,解決方法很簡單,利用訊息系統或者主動更新的方式清除掉快取中的資料即可。
布隆過濾器
- 1970 年布隆提出了一種布隆過濾器的演算法,用來判斷一個元素是否在一個集合中。這種演算法由一個二進位制陣列和一個 Hash 演算法組成。
- 具體的演算法思想這裡不再詳細解釋了,如有不瞭解的可以看陳某上一篇文章大白話布隆過濾器,又能和麵試官扯皮了~。
- 解決快取穿透的大致思想:在訪問快取層和儲存層之前,可以通過定時任務或者系統任務來初始化布隆過濾器,將存在的 key 用布隆過濾器提前儲存起來,做第一層的攔截。例如:一個推薦系統有 4 億個使用者 id, 每個小時演算法工程師會根據每個使用者之前歷史行為計算出推薦資料放到儲存層中, 但是最新的使用者由於沒有歷史行為, 就會發生快取穿透的行為, 為此可以將所有推薦資料的使用者做成布隆過濾器。 如果布隆過濾器認為該使用者 id 不存在, 那麼就不會訪問儲存層, 在一定程度保護了儲存層。此時的結構如下圖:
-
- 當然布隆過濾器的假陽性的存在導致了誤判率,但是我們可以儘量的降低誤判率,一個解決方案就是:使用多個 Hash 演算法為元素計算出多個 Hash 值,只有所有 Hash 值對應的陣列中的值都為 1 時,才會認為這個元素在集合中。
- 這種方法適用於
資料命中不高
、 資料相對固定
、 實時性低
(通常是資料 集較大
)的應用場景,程式碼維護較為複雜,但是快取空間佔用少。為什麼呢?因為布隆過濾器不支援刪除元素,一旦資料變化,並不能及時的更新布隆過濾器。
兩種方案對比
- 兩種方案各有優缺點,具體使用哪種方案還是要根據業務場景和系統體量來定。具體的區別如下表:
方案 | 適用場景 | 維護成本 |
快取物件 |
1. 資料命中不高 2. 資料頻繁變化,實時性高 |
程式碼維護點單、需要過多的快取空間,資料一致性需要自己實現 |
布隆過濾器 |
1. 資料命中不高 2.資料相對固定,實時性低 |
程式碼維護複雜、快取空間佔用少 |
總結