前面我們提到分布式多級緩存架構的全貌，但總感覺少了些什么東西。在這樣大的場景下面，如果遇到緩存使用問題那可咋辦？但自古英雄出少年，相信此刻你已踏馬西去，正走在尋找答案上得夕陽西下。每每面談Redis大家肯定不陌生，反正就是各種被社會得毒打。上來就緩存問題（擊穿、穿透、雪崩）三板斧，直接就是開門紅，險些讓我們招架不住。在這里我又日思夜想：

1. 它們之間是如何造成的？
2. 項目業(yè)務開發(fā)中應該注意些什么才能防范它們？

前言

說時遲那時快，對面依然不存在。正在低頭玩手機的我，頓時感覺臉旁一陣涼風襲來，不由自主得抬起頭來。只見一位光頭大叔坐我對面，椅子頓時咯吱咯吱作響，順手還摸了一把那锃亮锃亮的頭。這雷厲風行、英姿颯爽的身段，外加上處處逼人的寒冷氣息，猶如那劍指鋒芒，讓人背后感到針針發(fā)涼。

這難道是把傳說中的敏捷開發(fā)修煉到高層時，所散發(fā)出的內力嗎？猶如走出那六親不認的步伐，走路帶風

緩存業(yè)務的高效

面試官： 看你簡歷上寫了很多緩存的內容，那先談談你對緩存的理解？為啥用它？

吒吒輝： 面試官您好，說到緩存，那你算是找對人了，我能給你干到天亮，目前幾乎所有網站都會用它，我也是略知一二得。

其一

緩存一般指nosql，即非關系型數據庫，它存儲的數據并不像數據庫那樣有很強的邏輯關系，類似干拿錢-->辦事-->走人的感覺，以K--->V形式來操作。
因無邏輯關系，所以操作數據時就能避免很多費時的邏輯數據計算操作，從而快速的獲取到數據。

但Redis的K-V其實隱含了兩層意思，不清楚你知道否？

因為K-V本身具備Hash的特征，所以就分別為外Hash和內Hash。

• 外Hash，指Redis的操作形式，即這種K-V的結果。從表現形式來的
• 內Hash，為Redis的hash數據類型，從存儲的結構來看。Redis的hash的結構底層采用類似JAVA的HashMap。

面試官： 我記得那個Hash不是還有一個HashTable嗎？Redis咋不用它?

首先，它們底層都基于 Hashtable 來實現的，區(qū)別就在于Hashtable是線程安全的，而Hashmap則相反。

因為Redis本身就是單線程，故它的模式就 決定它為線程安全。所以采用 Hashtable 這種支持多線程的線程安全機制就有點浪費。好比如你一個人是想咋玩就咋玩。

Redis-Hash采用數組+鏈表的形式共同組成HASH。

Redis真的的單線程嗎?后面發(fā)文分析

其二

緩存多以內存為存儲介質，遠不是MySQL走磁盤能比擬的。 我直接給你拿京東的金士頓來做個比較，你老人家就明白了。
磁盤性能：

內存性能：

內存性能：2666MHz * 64bit（單通道，雙通道則128bit） / 8（位到字節(jié)單位轉換） = 21.328GB/s。這只是理論，實際發(fā)揮還要看內存控制器，實際上2666單條跑出來的數據在18～20GB/s差不多了。

差距：21328Mb/500Mb（SSD）=40.656。那你機械硬盤就會有上百倍的差距。一般部署服務器的磁盤不可能都是固態(tài)。而是固+機，簡稱：古（固）巨基（機）。也是出于成本的考慮，

面試官： 那固態(tài)和機械為啥差距這么大呢？

機械磁盤的讀寫是需要根據磁頭臂的移動+磁頭讀寫數據才能完成，它是由外到內的寫入每一個扇區(qū)。

而固態(tài)硬盤會有多個閃存。每個閃存可能有4、8、16個閃存顆粒構成。讀寫時，可以同時多個閃存采用電信號去到存儲位置中來進行讀寫，相當于并行的方式，所以比你磁盤轉動得要快得多。

好比如傳遞口令的工作。前者是先跑到站點，在寫下通知。然后才能繼續(xù)跑到下一個站點進行通知。而后者則是直接通過電話口頭傳遞指令給多個站點

閃存是什么?
閃存是一種存儲介質，和內存最大的區(qū)別是斷電后數據仍然不會丟失（和硬盤相似），數據刪除不是以單個的字節(jié)為單位而是以固定的區(qū)塊為單位，區(qū)塊大小一般為256KB到20MB。

吒吒輝: 所以你像MySQL這樣的東西在高并發(fā)請求下，那就很有問題，我在給你老人家打個比方

MySQL-3個關聯(lián)表的數據結果，我給它安排到緩存中，在用內存來提提速，這不就是省去了數據在數據庫中組裝、從磁盤中讀取的時間嗎？

所以，用它，將可以大范圍抵御高頻率的用戶訪問請求，避免做重復而又復雜的計算工作。直接將其攔截到數據庫上游，保護后方的機器。讓你請求在高也得給我規(guī)規(guī)矩矩得。

你像拿電商首頁、秒殺系統(tǒng)、熱點推薦等數據，那都要100%考慮緩存得，當然業(yè)務需要提速的話，都是可以用得到的

一眼望去你的簡歷，就 緩存擊穿 我心房

面試官： 嗯，不錯，那使用緩存常會遇到緩存的3大問題，你先給說下緩存擊穿是什么？

吒吒輝： 其實，緩存使用問題主要就集中在數據為臟數據、使用時緩存失效、緩存實例不可用等問題上。

而我們一切的方案都折中于滿足于主要問題。而這“緩存擊穿”就是緩存失效的情景。

什么是緩存擊穿呢？

緩存擊穿就是當你請求訪問緩存Key時，恰巧它失效了。而這時數據還沒更新到緩存中，外加上高頻訪問請求。相當于把緩存都給打穿了。

從而讓這些透穿的請求分分鐘把數據庫給打得懷疑人生，甚至不能自理。猶如下面這感覺，表面風平浪靜，實則早以暗藏殺機

為什么有這么大的殺傷力？

因為你原來的請求走的是緩存，現在它沒了。所以數據庫就需要多承受幾十、上百倍的數據訪問壓力。

假設當時 10000/s 個請求，緩存能扛住9000/s 個請求，緩存一失效。此時10000 /s個請求全部落到數據庫，那自然是招架不住。

這時一般數據庫的CPU會飆到100%，服務器會卡死?？赡蹹BA會直接重啟一波。那不用多說，會直接再次陷入僵局。

當然這種規(guī)模訪問，一般都有監(jiān)控系統(tǒng)，在得出數據庫負載過大的情況時，會發(fā)送報警的消息通知。然后再針對性想辦法。

面試官：那你覺得這種情況要怎么做？

吒吒輝： 解鈴還須系鈴人，既然是在使用過程中遇到突變情況，那么就需要在業(yè)務&緩存上來提前進行搭橋。

一、業(yè)務層

1.1 加鎖

如果緩存失效沒拿到數據，就先拿到互斥鎖然后去數據庫查詢數據，然后在返回結果，并重新設置緩存。

這樣高頻的請求訪問就會被限制為1個請求。數據庫的壓力自然也會變小，后面相同請求繼續(xù)走緩存。

public static getData(string $key)
{ //從緩存讀取數據 $result = $redis->get($key); //緩存中不存在數據 if （$result ==null ） { //獲取swoole互斥鎖 $lock = new Swoole\Lock(SWOOLE_MUTEX); if ($lock->lock()) {
               $result = getDataFormMysql($key); //獲取到數據庫 if ($result != null))   setDataFromRedis($key, $result)); return $lock->unlock();
       }else { //獲取鎖失敗，則重試 usleep(10000);
               $result = getData($key;)
           }
       } return $result;
}

但這加鎖方案是不是會阻塞請求，影響用戶體驗呢？
還是一個遞歸的調用。沒辦法，你沒搶到鎖的請求只能等待或重試。不然你難道要打人爆力搶鎖呀?。?！

有什么方式可以改進?
用隊列。
其實上面的鎖還可改為最大重試的次數，不然如果遇到網絡波動而導致請求阻塞，這樣不斷的進行重試獲取鎖，就會把機器給拖垮。當然網站請求量少，基本上沒啥問題。但萬事還得小心。

1.2. 隊列

請求沒拿到緩存，那么把請求放入到一個去重的隊列中，相同查詢請求保留一個即可。這時就可以返回客戶端“您稍安勿躁，請等一下”，然后異步執(zhí)行隊列去獲取數據庫中的數據并更新到緩存中。后面來的請求就可讀緩存中的數據。

這種情況下 都是直接響應用戶， 那這樣不是就有很多用戶無法拿到數據嗎？

如果你覺得這樣不好，可以來個折中的辦法，第一次的請求入隊列，讓它去讀取數據并更新緩存。第二次乃至后面的請求在入隊列時進行判斷。如果發(fā)現會重復，那么就等0.1s，然后在去緩存里面拿數據返回。

這樣就可以，不會一直等待數據。但等待是需要的。如果0.1s還不行，就返回提示內容給客戶端，不讓其持續(xù)等待。還能夠省去爭取鎖的消耗。bingo

1.3. 無效時間

讓緩存無失效時間。但最好設置一個計劃任務，不然緩存可能有臟數據的問題，但更新不頻繁或數據不怎么發(fā)生變化的業(yè)務沒事

二、緩存層

緩存層面就是自主實現更新數據到緩存中，當然這個肯定是需要結合后臺任務。比如緩存時間為10S。我反手一個定時任務就安排在9S，把數據更新到緩存中?；蛘呖紤]發(fā)布訂閱模式，監(jiān)聽到頻道來進行數據更新。

面試官：前面你提到加鎖，那如果是分布式多實例的場景你要咋辦？

你老說得確實是個問題，對應一般高流量的網站都是會采用分布式多機器的架構模式。這時候也會有并發(fā)的問題產生。

因為簡單的互斥鎖，只能滿足單機器上的擊穿問題。如果在分布式的并發(fā)場景下，就變成同時有多臺機器拿到鎖而訪問到后端。

這樣就達到了并行的訪問形式，數據庫也會因為請求量過大而造成并發(fā)訪問。所以說這種情況下還是有很大壓力。那要怎么解決呢？

咱們直接給他換成分布式鎖就可以達到效果，比如用：Redis、memcache、zookeeper等來做。

面試官：說了這么多，你更傾向于那個呢？

吒吒輝：
我覺得還是要看業(yè)務場景，簡單的肯定是鎖和設置不過期的數據，對于后者可以通過訂閱頻道或定時任務來更新數據，防止有臟數據。

如果要用戶體驗好點的話，就搞隊列吧，這樣不用一直阻塞等待，在分布式的場景那分布式鎖還是得來獨自安排。

二眼回眸你的簡歷，那 緩存穿透 我心臟

面試官： 那你在談談緩存穿透吧？

緩存穿透就是當你請求訪問緩存Key時，緩存本身的內容就沒有它，數據庫更無它的身影。這樣的請求就會穿透緩存直達數據庫。

如果這是一個高頻請求，數據庫就可能被惡意的打垮。就比如一種大網，請求就通過中間的縫隙穿透過去。好像漏網之魚

為什么說被惡意的打垮呢？

原因就在，數據庫本身就無這個key對應的數據，而緩存又依照數據庫生存，那它就更沒得了。

比如 拿商品id=-1的條件來查詢；你說這不是惡意是啥？明明就沒有，結果還是要來查詢。明擺著給你穿小鞋。欲加之罪，何患無辭。

面試官： 那你面對這種情況會怎么來解決？咳咳，這個還需要大致分析下才有出路。

一、業(yè)務上：

1.1.訪問限制黑名單

如果不想業(yè)務上加入太多不可控因子。那么可以在服務端加入訪問限定黑名單機制。咋個意思？

用戶請求發(fā)送到服務端時，服務端調用Redis-client先拿 EXISTS 判斷緩存數據是否存在，如果發(fā)現沒得值，就把當前key記錄到訪問限制黑名單列表，訪問次數+1，并設置合適的過期時間。然后再去數據庫讀取數據。

如果訪問的key是我們緩存中的內容，那么自然可以去數據庫拿到數據，如果同一個key或幾個key都一二再再而三拿不到數據，那么就肯定有問題。對應黑名單限制列表的訪問次數自然也就上去了。

這樣后面請求獲取key時，就先去訪問控制列表看看有沒得它（key）這個刺兒頭，有，我直接頭都不回的給你拒絕掉，還順手給你一大嘴巴子（給黑名單里面的key重置過期時間），這樣后面惡意請求在過來，可以保證這個黑名單還有key的名字。直接讓它面壁思過，給我唱征服。

1.2.設置Key為null

如果訪問key的在數據庫中也沒有，就直接給給該key設置為NULL，并設置過期時間，畢竟null也需要占據空間的，還是得讓它自己刪除。這樣后面請惡意請求直接讓它與null談話

面試官： 如果現在惡意請求兵分三路，分多波攻擊，每次key都不一樣。會怎么樣呢？

如果惡意請求要打持久戰(zhàn)，那流量肯定大，每次訪問的都是不一樣。

那首先肯定會有限流方案來限制這種級別的流量，以減少后端服務的沖擊。所以到后端服務的流量整體規(guī)模就會變小，但總量可能還是會大于數據庫承受壓力。

如果請求key隨機性和流量規(guī)模很大，相當于一個key訪問一次就不來了，這樣存儲黑名單的列表就會很大。后面做查詢時也就比較慢了。

例如用Redis-zset存儲，流量規(guī)模一旦過大，它就需要很多的存儲空間， 所以咱們可采用bitmap來減少存儲空間和把Key分散開來。

如果請求key的隨機性不是很大，流量規(guī)模大。但是這種類型請求很多，這時候還得看業(yè)務情況。

如果是個性業(yè)務，比如用戶訪問個人信息，這時得把key放到黑名單限制列表中，限制一下它那120邁的速度。

如果是共性業(yè)務，比如直接瀏覽的商品，那肯定得用隊列來降降速。不然數據庫真受不住。

1.3.第三方

那有沒有更簡單的方案，感覺上面很是繁瑣？ 其實，也有，你選擇“布隆過濾器”這家伙就可以。
它是第Redis里面的第三方模塊，使用時你自己需要做編譯安裝才可使用，不像Redis自帶的常用數據類型。

每次訪問緩存時，直接用布隆過濾器里面進行判斷是否存在key，如果有，就去Redis里面讀取，無，就拒絕請求。

相當于過濾請求的作用，而且布隆過濾器存儲數據的單位是位（bit），所以整體占據的存儲容量也不是很大，重要的是可以做到攔截請求操作。

但布隆過濾器自身具備不高誤判率，隨著存儲的數量增多也會加大。所以布隆過濾器如何說找到了緩存那么是可能沒有，如果找不到這個緩存那么就是一定沒有緩存。
但這對廣大的請求來說，幾乎影響不大。

你這里是說請求訪問key時就用布隆過濾器來判斷，那剛開始沒存儲數據咋辦，干看著它？
**不，不，不，你得這么來看 **

啟動系統(tǒng)時，直接做緩存預熱。就提前把熱點數據或當前業(yè)務需要的緩存數據給載入到緩存中。這樣后面請求來了，我發(fā)現你不是我自家兄弟的Key，直接妥妥拒絕沒得商量。
可這熱點數據、業(yè)務需要的數據要怎么發(fā)現呢？網站上線一開始肯定沒運行啊，讓布隆過濾器喝西北風？
。。。。。。我這個。

熱點數據肯定是網站跑起來經過運行一段時間才能確定的，一般Redis不是會做持久化嘛，不然Redis-（RDB、AOF）吃干飯呀。直接根據持久化的數據恢復業(yè)務中需要的熱點數據，一并更新到布隆過濾器。

雖然新系統(tǒng)、新業(yè)務沒有遺留的歷史數據，那我們可設置些規(guī)則，例如：最新、點擊量高的數據給篩它一波。然后把滿足這些規(guī)則的數據給設置到緩存和布隆過濾器中。

二、緩存上

這個比較直接，就是根據緩存的命中率來進行分析，如果我發(fā)現Redis內部某個key一直是未命中，而且訪問次數還跳躍的很。那就直接上報給key的黑名單。

這樣后面如果請求訪問的key只要為它就直接干掉,相當于做一個黑key的發(fā)現，然后再來對它來做攔截

三眼再看你的簡歷，那 緩存雪崩 讓我徹底淪陷

面試官： 那緩存雪崩要怎么解決？
吒吒輝： 緩存雪崩其實和緩存擊穿有點類似，都是緩存失效。只不過它們各自針對緩存失效的情況不一樣。

緩存雪崩是緩存同時大面積失效而導致請求像雪崩式的一擁而下，直搗黃龍（數據庫）。而緩存擊穿針對的是單個key訪問恰巧失效的問題。

由此可見緩存雪崩的破壞力更大。關鍵要點在于同時會有大面積的key失效。那怎么解決呢？

一、業(yè)務上

設置緩存時，采用隨機時間來把每個key的過期時刻都打亂，這樣就不會統(tǒng)一集中失效，造成緩存雪崩。
是不是只要緩存大面積失效就會對后方造成問題？

這倒還不一定，如果你當前的子系統(tǒng)，不是什么流量大的業(yè)務，你會有問題嗎？

比如：個人中心的基本資料，誰沒事天天看，又不是不認識自己。

所以這問題還是得看業(yè)務特點，如果本身流量就比較高的業(yè)務在設計緩存時，就不要把緩存設置的那么集中。

比如：秒殺、熱榜、首頁的聚合數據等。這時就應該把它們的過期時間給錯開掉

二、模式上

大流量的業(yè)務下，自然要緩存的數據也會很多。所以在設置緩存時，也可采用緩存數據分片來把緩存分配到不同的實例上來進行緩存，這樣每個緩存實例的壓力也會小很多。這樣子就算失效了一部分它敢給我集體罷工嘛？
如果要保證多個緩存實例宕機后，整個系統(tǒng)還想繼續(xù)麻溜的跑起來，那集群的方案自然是少不了的，有它才可以通過備節(jié)點快速補充上來。從而恢復業(yè)務的正常運行，抵御那些過高的網絡請求。

總結

1. 緩存高效于模式上的提速，內外HASH你可知道？
2. 緩存穿透是請求訪問數據庫本不該出現的key，算惡意請求
1. 業(yè)務上的規(guī)則檢查防護
2. 布隆過濾器
3. 緩存設null
3. 緩存擊穿是請求訪問key時恰巧失效，而打到數據庫。
1. 互斥鎖、隊列、分布式鎖
2. 緩存無失效
4. 緩存雪崩是緩存出現大面積失效，而導致流量洪峰流到數據庫
1. 隨機失效
2. 集群處理
3. 數據分片拆分

思考題

1. 緩存三大問題的本質是什么造成的？
2. 設計的方案很多，具體實踐拿捏看什么？
3. 你網站的熱點數據發(fā)現規(guī)則會怎么考慮呢？要不要單獨出業(yè)務？

如有感悟，歡迎關注。
點贊、分享、留言都可走一走。本來文章還是可以寫很多東西，不過我感覺像微服務、優(yōu)化、分布式等場景在這里不大合適，就準備單獨出技術知識分享專題來做，不然大家就不好理解了。
也可以后面來一個高級版的緩存問題防御。這樣大家可能很好理解。具體怎么安排大家可留言告知。除此之外以下相關的內容幫助大家提升