快取穿透和快取擊穿處理

2021-10-21 02:05:00 字數 4181 閱讀 3060

為了應對越來越大的流量,快取便成為系統服務必不可少的一部分,但使用快取就會出現快取擊穿和快取穿透的威脅。

背景介紹

網際網路應用逐步深入到生活的各個角落,為了滿足越來越多使用者使用網際網路應用的需求,幾乎所有網際網路公司都採用快取的方案來解決瞬時流量超高,或者長期流量過高的問題。但使用快取存在風險——快取穿透和快取擊穿:簡單的講就是如果該資料原本就不存在,那麼就會發生快取穿透;如果快取內容因為各種原因失效,那麼就會發生快取擊穿。

具體一點來說,如果快取中不存在需要查詢的內容,一般情況下需要再深入一層進行查詢,一般為不能承受壓力的關係型資料庫(承壓能力為快取的1%,甚至更低),如果資料庫中不存在,則叫做快取穿透;反之,如果資料庫中存在這個資料,則叫做快取擊穿(如果同一時刻大量的快取失效叫做快取雪崩,本文暫不討論該問題)。這種查詢在流量不高的情況下,不會出現問題,如果查詢資料庫的流量過高,尤其是資料庫中不存在的情況下,嚴重時會導致資料庫不可用,連帶影響使用資料庫的其他業務,本業務也有很大的可能性受到影響。

快取穿透常見的處理方式

1、空值快取

既然該資料本身就不存在,最簡單粗暴的方式就是直接將不存在的值定義為空(視具體業務和快取的方式定義為null或者」」)。具體方式是每次查詢完資料庫,我們可以將key在快取中設定對應的值為空,短期內再次查詢這個key的時候就不用查詢資料庫了。

通常的簡單做法:

這裡需要強調注意:為了系統的最終一致性,這些key必須設定過期時間,或者必須存在更新方式,防止這個key的資料後期真實存在,但改key始終為空,導致資料不一致的情況出現。

這種方式的缺點也十分的明顯:如果key數量巨大且分散無任何規律,就會浪費大量快取空間,並且不能抗住瞬時流量衝擊(尤其是遇到惡意的攻擊的時候,有可能將快取空間打爆,影響範圍更大),需要額外配置降級開關(查詢資料庫的開關或者限流),這時本方案就顯得沒想象的那麼美好。針對不能抗住瞬時流量的情況,常見的處理方式是使用計數器,對不存在的key進行計數,當某個key在一定時間達到一定的量級,就查詢一次資料庫,按照資料庫的返回值對key進行快取。未達指定閾值數量之前,按照商定的空值返回。

故這種解決方案的建議使用場景為:key全集資料資料量級較小,並且完全可**,可以通過提前填充的方式直接將資料快取。

2、布隆過濾器(bloomfilter)

本質上布隆過濾器是一種資料結構,比較巧妙的概率型資料結構(probabilistic data structure),特點是高效地插入和查詢,可以用來告訴你 「某樣東西一定不存在或者可能存在」。相比於傳統的 list、set、map 等資料結構,它更高效、占用空間更少,但是缺點是其返回的結果是概率性的,而不是確切的。實際應用中,google bigtable,apache hbbase 和 apache cassandra 使用布隆過濾器減少對不存在的行和列的查詢。

布隆過濾器的原理如下:

假如「京東」經過hash後佔位為618,加入後,如下所示:

假如大促經過hash後佔位為為678,加入後,如下所示:

假如某寶hash後佔位256,則可以完全判斷該key不存在,直接返回null即可。但某某多hash後佔位167,則不能判斷是否存在,需要進行查庫操作進行判斷。

這裡需要強調注意的是必須使用高效的hash演算法,否則這種方式會嚴重影響系統的效能,建議的演算法包括murmurhash、fnv的穩定高效的演算法。

使用過程中,通常把有資料的key都放到bloomfilter中,每次查詢的時候都先去bloomfilter判斷,如果沒有就直接返回空。由於布隆過濾器不支援刪除操作(具體結合上圖推算刪除乙個就可以得知),對於刪除的key,查詢就會經過bloomfilter然後查詢快取再查詢資料庫,所以bloomfilter建議結合快取空值用,對於刪除的key,可以在快取中快取空。(當然有同學自行實現了可刪除的布隆過濾器——counting bloom filter,原理較為簡單,本文不做具體分析,個人感覺將簡單的問題複雜化了)。

同樣它也不支援擴容操作,這就要求布隆過濾器建立初期必須進行嚴格的推算,確保後期不需要擴容,否則重建布隆過濾器的成本可能會超乎想象。具體的推算公式如下(具體的推算過程非本文重點,請各位自行查詢):

k 為雜湊函式的個數,m 為布隆過濾器的長度,n 為插入元素的個數(需要處理的資料個數),p 為誤報率。

布隆過濾器的使用場景受key的狀態限制,如果key是動態無規律的,不建議使用該方式。作者使用布隆過濾器作為使用者是否參與活動的過濾,布隆過濾器在活動期間最大值為目前的會員數量,完全可控。

考慮真實情況下,快取的儲存空間及效能問題,在真實使用中,為了避免熱key和大key的問題,首先對使用者標識進行了hash,首先對hash按照布隆過濾器的數量進行取餘,確定使用哪個布隆過濾器,然後使用布隆過濾器。具體情況如下:

快取擊穿常見的處理方式

1、互斥鎖(mutex key)

這是比較常見的做法,是在快取失效的時候,不是立即去查詢資料庫,先搶互斥鎖(比如redis的setnx乙個mutex key),當操作返回成功時(即獲取到互斥鎖),再進行查詢資料庫的操作並回設快取;否則,就重試整個獲取快取的方法或者直接返回空。setnx,官方的解釋是只在鍵 key 不存在的情況下,將鍵 key 的值設定為 value 。若鍵 key 已經存在,則 setnx 命令不做任何動作。setnx 是『set if not exists』(如果不存在,則set)的簡寫。

但這種方式顯然存在問題,redis的setnx命令是當key不存在時設定key,但setnx不能同時完成expire設定失效時長,不能保證setnx和expire的原子性。這會導致setnx成功但expire失敗時,鎖永遠不會釋放,下面提供了一種可行的**,供大家討論:

try 

return flag;

}} catch (exception e)

return false;

redis還是善解人意的,從 2.6.12 起,我們可以使用set命令完成setnx和expire的操作,並且這種操作是原子操作,可以完全替代上述的**了。

這種簡單粗暴的方式有著嚴格是使用場景(換句話說就是有著嚴重的缺陷),如果快取大量失效(快取雪崩),那麼對於資料庫是一場災難;如果資料庫查詢緩慢,不僅對資料是一場災難,對於使用該快取的介面會造成執行緒阻塞,介面效能又開啟了另外一場災難!一般情況下,這種方式適用於永久快取的key,或者key偶爾丟失的情況下,其他情況請各位讀者慎重考慮或增加其他機制保護資料庫和介面(如使用hystrix限流&降級等)。

2、非同步構建快取

當快取失效時,不是立刻去查詢資料庫,而是先建立快取更新的非同步任務,然後直接返回空值。這種做法不會阻塞當前執行緒,並且對於資料庫的壓力基本可控,但犧牲了整體資料的一致性。從實際的使用看,這種方法對於效能非常友好,唯一不足的就是構建快取時候,所有查詢返回的內容均為空值,但是對於一致性要求不高的網際網路功能來說這個還是可以忍受。

總結

綜上所述,針對常見的快取穿透和快取擊穿的問題,各自的優缺點如下:

實戰過程中,快取穿透和快取擊穿是必須考慮的問題,如果基礎建設不夠穩固(redis集群),或者快取時間設定的存在問題,那就必須考慮快取雪崩(大批量key失效或者集群不可用)的問題,解決的思路大同小異。筆者工作過程中,不同的場景下,會混合使用上面的幾種方式,確保系統的穩定和安全。

條條大路通羅馬,希望讀者能從本文得到一點點啟發,開發出符合自己業務的解決方案。

redis 快取穿透和快取擊穿處理

為了應對越來越大的流量,快取便成為系統服務必不可少的一部分,但使用快取就會出現快取擊穿和快取穿透的威脅。背景介紹 網際網路應用逐步深入到生活的各個角落,為了滿足越來越多使用者使用網際網路應用的需求,幾乎所有網際網路公司都採用快取的方案來解決瞬時流量超高,或者長期流量過高的問題。但使用快取存在風險 快...

快取穿透,快取雪崩和快取擊穿

q 快取穿透,是指查詢乙個資料庫一定不存在的資料。正常的使用快取流程大致是,資料查詢先進行快取查詢,如果key不存在或者key已經過期,再對資料庫進行查詢,並把查詢到的物件,放進快取。如果資料庫查詢物件為空,則不放進快取。a 1.布隆過濾器,將所有可能存在的資料雜湊到乙個足夠大的bitmap中,乙個...

快取擊穿 快取穿透和快取雪崩

快取擊穿 定義 快取中的key一般設有過期時間,如果某個key過期了,恰在這個時候,有大量的併發請求訪問這個key,則這些請求都會到達db,導致db瞬間壓力過大,壓垮db。解決方案 1.設定互斥鎖,mutex。當快取失效時不時立即去訪問資料庫,而是使用快取工具的操作成功帶返回值的操作,比如redis...