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

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

前言

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

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

緩存業(yè)務(wù)的高效

面試官： 看你簡歷上寫了很多緩存的內(nèi)容，那先談?wù)勀銓彺娴睦斫?？為啥用它?/span>

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

其一

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

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

因?yàn)镵-V本身具備Hash的特征，所以就分別為外Hash和內(nèi)Hash。

• 外Hash，指Redis的操作形式，即這種K-V的結(jié)果。從表現(xiàn)形式來的
• 內(nèi)Hash，為Redis的hash數(shù)據(jù)類型，從存儲的結(jié)構(gòu)來看。Redis的hash的結(jié)構(gòu)底層采用類似JAVA的HashMap。

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

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

因?yàn)镽edis本身就是單線程，故它的模式就 決定它為線程安全。所以采用 Hashtable 這種支持多線程的線程安全機(jī)制就有點(diǎn)浪費(fèi)。好比如你一個(gè)人是想咋玩就咋玩。

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

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

其二

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

內(nèi)存性能：

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

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

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

機(jī)械磁盤的讀寫是需要根據(jù)磁頭臂的移動(dòng)+磁頭讀寫數(shù)據(jù)才能完成，它是由外到內(nèi)的寫入每一個(gè)扇區(qū)。

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

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

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

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

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

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

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

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

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

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

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

什么是緩存擊穿呢？

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

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

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

因?yàn)槟阍瓉淼恼埱笞叩氖蔷彺?，現(xiàn)在它沒了。所以數(shù)據(jù)庫就需要多承受幾十、上百倍的數(shù)據(jù)訪問壓力。

假設(shè)當(dāng)時(shí) 10000/s 個(gè)請求，緩存能扛住9000/s 個(gè)請求，緩存一失效。此時(shí)10000 /s個(gè)請求全部落到數(shù)據(jù)庫，那自然是招架不住。

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

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

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

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

一、業(yè)務(wù)層

1.1 加鎖

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

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

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

但這加鎖方案是不是會阻塞請求，影響用戶體驗(yàn)?zāi)兀?/span>
還是一個(gè)遞歸的調(diào)用。沒辦法，你沒搶到鎖的請求只能等待或重試。不然你難道要打人爆力搶鎖呀?。?！

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

1.2. 隊(duì)列

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

這種情況下 都是直接響應(yīng)用戶， 那這樣不是就有很多用戶無法拿到數(shù)據(jù)嗎？

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

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

1.3. 無效時(shí)間

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

二、緩存層

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

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

你老說得確實(shí)是個(gè)問題，對應(yīng)一般高流量的網(wǎng)站都是會采用分布式多機(jī)器的架構(gòu)模式。這時(shí)候也會有并發(fā)的問題產(chǎn)生。

因?yàn)楹唵蔚幕コ怄i，只能滿足單機(jī)器上的擊穿問題。如果在分布式的并發(fā)場景下，就變成同時(shí)有多臺機(jī)器拿到鎖而訪問到后端。

這樣就達(dá)到了并行的訪問形式，數(shù)據(jù)庫也會因?yàn)檎埱罅窟^大而造成并發(fā)訪問。所以說這種情況下還是有很大壓力。那要怎么解決呢？

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

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

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

如果要用戶體驗(yàn)好點(diǎn)的話，就搞隊(duì)列吧，這樣不用一直阻塞等待，在分布式的場景那分布式鎖還是得來獨(dú)自安排。

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

面試官： 那你在談?wù)劸彺娲┩赴桑?/span>

緩存穿透就是當(dāng)你請求訪問緩存Key時(shí)，緩存本身的內(nèi)容就沒有它，數(shù)據(jù)庫更無它的身影。這樣的請求就會穿透緩存直達(dá)數(shù)據(jù)庫。

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

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

原因就在，數(shù)據(jù)庫本身就無這個(gè)key對應(yīng)的數(shù)據(jù)，而緩存又依照數(shù)據(jù)庫生存，那它就更沒得了。

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

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

一、業(yè)務(wù)上：

1.1.訪問限制黑名單

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

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

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

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

1.2.設(shè)置Key為null

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

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

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

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

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

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

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

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

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

1.3.第三方

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

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

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

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

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

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

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

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

二、緩存上

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

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

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

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

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

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

一、業(yè)務(wù)上

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

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

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

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

比如：秒殺、熱榜、首頁的聚合數(shù)據(jù)等。這時(shí)就應(yīng)該把它們的過期時(shí)間給錯(cuò)開掉

二、模式上

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

總結(jié)

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

思考題

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

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