楠木軒

圖解 | 什麼是快取系統“三座大山”?

由 申屠仲舒 釋出於 科技

無處不在的快取

快取在計算機系統是無處不在,在CPU層面有L1-L3的Cache,在Linux中有TLB加速虛擬地址和物理地址的轉換,在瀏覽器有本地快取、手機有本地快取等。

可見,快取在計算機系統中有非常重要的地位,其主要作用是提高響應速度、減少磁碟訪問等,本文主要討論在高併發系統中的快取系統。

一句話概括快取系統在高併發系統中的地位的話:如果高併發系統是烤羊肉串,那麼快取系統就是那一撮孜然。

高併發系統中的快取


2.1 快取系統的作用

快取系統在高併發系統的作用很大,在某種程度上可以說沒有快取系統很難支撐高併發場景。

基於機械磁碟或SSD的資料庫系統,一般來說讀寫的速度遠慢於記憶體,因此單純磁碟介質的資料庫無法支撐很高的併發,可以簡單認為快取是保護磁碟資料庫的重要屏障。

對於一些基於LSM的儲存引擎資料庫來說,隨機寫改為順序寫速度提升很大,但是隨機讀仍然是個問題,所以快取系統是很有必要的。

2.2 快取系統訪問流程

實際場景也是讀多寫少,看看請求是如何得到響應的,簡單看下互動流程:

  • 請求到達之後,業務執行緒首先訪問快取,如果快取命中則返回
  • 如果未命中則繼續請求磁碟資料庫系統,獲取資料返回
  • 從磁盤獲取資料後將結果回寫到快取系統且增加老化時間,為下次請求做準備

以上是高併發系統中快取和磁碟資料庫系統、客戶端請求之間的互動過程,後續的問題分析,也是基於此過程展開的。

快取系統的三大問題

網路上對於快取三大問題的文章很多,提到的三個問題主要是:

  • 快取雪崩 Cache Avalanche
  • 快取穿透 Cache Penetration
  • 快取擊穿 Hotspot Invalid

對於上面的三個名詞我一直分不清楚,腦海中並沒有清晰的區別。

於是想到去谷歌看看歪果仁是怎麼說的,然而英文表述就是上面的英文,基本上和漢語翻譯是一樣的,所以只能強記,太難了。

3.1 快取雪崩問題

所謂雪崩就是原來有所支撐的冰雪,某一瞬間失去依託,瞬間湧下來。

這個場景讓我想起了2011年上映的柯南劇場版《沉默的十五分鐘》,柯南在北澤村水庫為了拯救村莊製造的雪崩:

可見雪崩確實很可怕,回到高併發系統,如果快取系統故障,大量的請求無法從快取完成資料請求,就全量洶湧衝向磁碟資料庫系統,導致資料庫被打死,整個系統徹底崩潰。

3.2 快取雪崩解決方案

造成快取雪崩的主要原因是快取系統不夠高可用,因此提高快取系統的穩定性和可用性十分必要,比如對於使用Redis作為快取的系統而言可以使用哨兵機制、叢集化、持久化等來提高快取系統的HA。

除了保證快取系統的HA之外,服務本身也需要支援降級,可以藉助比如Hystrix來實現服務的熔斷、降級、限流來降低出現雪崩時的故障程度。

說白了就是別讓服務徹底死掉就行,就像大雪封高速肯定不能通行了,堵車慢一些至少可以走。

3.3 快取穿透問題

穿透形象一點就是:請求過來了 轉了一圈 一無所獲 就像穿過透明地帶一樣。

在高併發系統中快取穿透,如果一個req需要請求的資料在快取中沒有,這時業務執行緒就會訪問磁碟資料庫系統,然而磁碟資料庫也沒有這個資料,無奈業務執行緒只能白白處理一圈。

如果某時段有大量惡意的不存在的key的集中請求,那麼服務將一直處理這些根本不存在的請求,導致正常請求無法被處理,從而出現問題。

舉個栗子:

拉麵館的服務員和廚師不允許拒絕已經進來的消費者,但是拉麵館的經營範圍有限。此時惡意消費者點了一隻5斤的澳洲龍蝦,經過服務員和廚師都無法響應這個需求,此時輪流來了1000個這樣的惡意消費者,拉麵館基本要歇菜了。

3.4 快取穿透解決方案

有效甄別是否存在這個key再決定是否讀取很重要,常見的做法有:

  • 把不存在的key寫一下,這樣再來就相當於命中了,其實這種方法侷限性很大,今天是5斤龍蝦,明天改成6斤的螃蟹,快取系統和資料庫中儲存大量無用key本身是無意義的,所以一般不建議
  • 另外一種思路,轉換為查詢問題,類似於在海量資料中查詢某個key是否存在,考慮空間複雜度和時間複雜度,一般選用布隆過濾器來實現。

布隆過濾器是個好東西,有非常多的用途,包括:垃圾郵件識別、搜尋蜘蛛爬蟲url去重等,主要藉助K個雜湊函式和一個超大的bit陣列來降低雜湊衝突本身帶來的誤判,從而提高識別準確性。

布隆過濾器也存在一定的誤判,假如判斷存在可能不一定存在,但是假如判斷不存在就一定不存在,因此剛好用在解決快取穿透的key查詢場景,事實上很多系統都是基於布隆過濾器來解決快取穿透問題的。

3.5 快取擊穿問題

快取擊穿是這樣一種情況:

由於快取系統中的熱點資料都有過期時間,如果沒有過期時間就造成了主存和快取的資料不一致,因此過期時間一般都不會太長。

設想某時刻一批熱點資料同時在快取系統中過期失效,那麼這部分資料就都將請求磁碟資料庫系統。

從描述上來看有點像微小規模的雪崩,但是對資料庫的壓力就很小了,只不過會影響併發效能,然而在多執行緒場景中快取擊穿卻是經常發生的,相反快取穿透和雪崩頻率不如快取擊穿,因此研究擊穿的現實意義更大一些。

3.6 快取擊穿解決方案

可以採用的方案大概有幾種:

  • 在設定熱點資料過期時間時儘量分散,比如設定100ms的基礎值,在此基礎上正負浮動10ms,從而降低相同時刻出現CacheMiss的key的數量。
  • 另外一種做法是多執行緒加鎖,其中第一個執行緒發現CacheMiss之後進行加鎖,再從資料庫獲取內容之後寫到快取中,其他執行緒獲取鎖失敗則阻塞數ms之後再進行快取讀取,這樣可以降低訪問資料資料庫的執行緒數,需要注意在單機和叢集需要使用不同的鎖,叢集環境使用分散式鎖來實現,但是由於鎖的存在也會影響併發效率。
  • 一種方法是在業務層對使用的熱點資料檢視是否即將過期,如果即將過期則去資料庫獲取最新資料進行更新並延長該熱點key在快取系統中的時間,從而避免後面的過期CacheMiss,相當於把事情提前解決了。

快取擊穿的解決方法都有一定的權衡,實際中根據自己的需求來解決。

快取擊穿的影響一般來說並不會太大,或許在你的服務跑了很久之後你才意識到會有快取擊穿問題。