周末，跟阿里的一個(gè)朋友（去年晉升為P9了）聊了很久，聊的內(nèi)容幾乎全是技術(shù)，當(dāng)然了，兩個(gè)技術(shù)男聊得最多的話題當(dāng)然就是技術(shù)了。從基礎(chǔ)到架構(gòu)，從算法到AI，無(wú)所不談。中間又穿插著不少天馬行空的想象，雖然現(xiàn)在看起來(lái)不太實(shí)際，但是隨著技術(shù)的進(jìn)步，相信五年、十年之后都會(huì)實(shí)現(xiàn)的。

不知道是誰(shuí)提起了在高并發(fā)環(huán)境下如何構(gòu)建緩存服務(wù)，結(jié)果一路停不下來(lái)了?。?/p>

緩存特征

（1）命中率：命中數(shù)/(命中數(shù)+沒(méi)有命中數(shù))

（2）最大元素（空間）：代表緩存中可以存放的最大元素的數(shù)量，一旦緩存中元素的數(shù)量超過(guò)這個(gè)值，或者緩存數(shù)據(jù)所占的空間超過(guò)了最大支持的空間，將會(huì)觸發(fā)緩存清空策略。根據(jù)不同的場(chǎng)景，合理設(shè)置最大元素（空間）的值，在一定程度上可以提高緩存的命中率，從而更有效的使用緩存。

（3）清空策略：FINO（先進(jìn)先出）、LFU（最少使用）、LRU（最近最少使用）、過(guò)期時(shí)間、隨機(jī)等。

• FINO（先進(jìn)先出）：最先進(jìn)入緩存的數(shù)據(jù)，在緩存空間不夠或超出最大元素限制的情況下，會(huì)優(yōu)先被清除掉，以騰出新的空間來(lái)接收新的數(shù)據(jù)。這種策略的算法主要是比較緩存元素的創(chuàng)建時(shí)間，在數(shù)據(jù)實(shí)時(shí)性較高的場(chǎng)景下，可以選擇這種策略，優(yōu)先保證最新策略可用。

• LFU（最少使用）：無(wú)論元素是否過(guò)期，根據(jù)元素的被使用次數(shù)來(lái)判斷，清除使用次數(shù)最少的元素來(lái)釋放空間。算法主要是比較元素的命中次數(shù)，在保證高頻數(shù)據(jù)有效的場(chǎng)景下，可以選擇這種策略。

• LRU（最近最少使用）：無(wú)論元素是否過(guò)期，根據(jù)元素最后一次被使用的時(shí)間戳，清除最遠(yuǎn)使用時(shí)間戳的元素，釋放空間。算法主要是比較元素最近一次被獲取的時(shí)間，在熱點(diǎn)數(shù)據(jù)場(chǎng)景下，可以選擇這種策略。
  過(guò)期時(shí)間：根據(jù)過(guò)期時(shí)間判斷，清理過(guò)期時(shí)間最長(zhǎng)的元素，或者清理最近要過(guò)期的元素。

緩存命中率影響因素

（1）業(yè)務(wù)場(chǎng)景和業(yè)務(wù)需求
緩存往往適合讀多寫(xiě)少的場(chǎng)景。業(yè)務(wù)需求對(duì)實(shí)時(shí)性的要求，直接會(huì)影響到緩存的過(guò)期時(shí)間和更新策略。實(shí)時(shí)性要求越低，就越適合緩存。在相同Key和相同請(qǐng)求數(shù)的情況下，緩存的時(shí)間越長(zhǎng)，命中率就會(huì)越高。

（2）緩存的設(shè)計(jì)（粒度和策略）
通常情況下，緩存的粒度越小，命中率越高。緩存的更新和命中策略也會(huì)影響緩存的命中率，當(dāng)數(shù)據(jù)發(fā)生變化時(shí)，直接更新緩存的值會(huì)比移除緩存或使緩存過(guò)期的命中率更高。

（3）緩存容量和基礎(chǔ)設(shè)施
緩存的容量有限，則容易引起緩存失效和被淘汰（目前多數(shù)的緩存框架或中間件都采用了LRU算法）。同時(shí)，緩存的技術(shù)選型也是至關(guān)重要的，比如采用應(yīng)用內(nèi)置的本地緩存就比較容易出現(xiàn)單機(jī)瓶頸，而采用分布式緩存則畢竟容易擴(kuò)展。所以需要做好系統(tǒng)容量規(guī)劃，并考慮是否可擴(kuò)展。此外，不同的緩存框架或中間件，其效率和穩(wěn)定性也是存在差異的。

（4）其他因素
當(dāng)緩存節(jié)點(diǎn)發(fā)生故障時(shí)，需要避免緩存失效并最大程度降低影響，這種特殊情況也是架構(gòu)師需要考慮的。業(yè)內(nèi)比較典型的做法就是通過(guò)一致性Hash算法，或者通過(guò)節(jié)點(diǎn)冗余的方式。

有些朋友可能會(huì)有這樣的理解誤區(qū)：既然業(yè)務(wù)需求對(duì)數(shù)據(jù)時(shí)效性要求很高，而緩存時(shí)間又會(huì)影響到緩存命中率，那么系統(tǒng)就別使用緩存了。其實(shí)這忽略了一個(gè)重要因素--并發(fā)。通常來(lái)講，在相同緩存時(shí)間和key的情況下，并發(fā)越高，緩存的收益會(huì)越高，即便緩存時(shí)間很短。

提高緩存命中率的方法

從架構(gòu)師的角度，需要應(yīng)用盡可能的通過(guò)緩存直接獲取數(shù)據(jù)，并避免緩存失效。這也是比較考驗(yàn)架構(gòu)師能力的，需要在業(yè)務(wù)需求，緩存粒度，緩存策略，技術(shù)選型等各個(gè)方面去通盤(pán)考慮并做權(quán)衡。盡可能的聚焦在高頻訪問(wèn)且時(shí)效性要求不高的熱點(diǎn)業(yè)務(wù)上，通過(guò)緩存預(yù)加載（預(yù)熱）、增加存儲(chǔ)容量、調(diào)整緩存粒度、更新緩存等手段來(lái)提高命中率。

對(duì)于時(shí)效性很高（或緩存空間有限），內(nèi)容跨度很大（或訪問(wèn)很隨機(jī)），并且訪問(wèn)量不高的應(yīng)用來(lái)說(shuō)緩存命中率可能長(zhǎng)期很低，可能預(yù)熱后的緩存還沒(méi)來(lái)得被訪問(wèn)就已經(jīng)過(guò)期了。

緩存的分類(lèi)和應(yīng)用場(chǎng)景

（1）本地緩存：編程實(shí)現(xiàn)（成員變量、局部變量、靜態(tài)變量）、Guava Cache
（2）分布式緩存：Memcached、Redis

高并發(fā)場(chǎng)景下緩存常見(jiàn)問(wèn)題

（1）緩存的一致性
更新數(shù)據(jù)庫(kù)成功——更新緩存失敗
更新緩存成功——更新數(shù)據(jù)庫(kù)失敗
更新數(shù)據(jù)庫(kù)成功——淘汰緩存失敗
淘汰緩存成功——更新數(shù)據(jù)庫(kù)失敗

（2）緩存并發(fā)
并發(fā)時(shí)請(qǐng)求緩存時(shí)已過(guò)期或者沒(méi)有命中或者更新的情況下有大量的請(qǐng)求訪問(wèn)數(shù)據(jù)庫(kù)。

解決辦法：在緩存更新或者過(guò)期的情況下,先嘗試獲取到lock,當(dāng)更新完成后,嘗試釋放鎖,其他的請(qǐng)求只需要犧牲一定的等待時(shí)間

（3）緩存穿透
在高并發(fā)的場(chǎng)景下,如果某一個(gè)key被高并發(fā)的訪問(wèn)沒(méi)有被命中,出于對(duì)容錯(cuò)性的考慮會(huì)嘗試從后端的數(shù)據(jù)庫(kù)獲取，從而導(dǎo)致大量的請(qǐng)求訪問(wèn)了數(shù)據(jù)庫(kù),主要是當(dāng)key對(duì)應(yīng)的數(shù)據(jù)為空或者為null的情況下，這就導(dǎo)致數(shù)據(jù)庫(kù)中并發(fā)的執(zhí)行了很多不必要的查詢操作。從而導(dǎo)致了巨大的沖擊和壓力。

解決方法:
緩存空對(duì)象：對(duì)查詢結(jié)果為空的對(duì)象也進(jìn)行緩存，如果是集合可以緩存一個(gè)空的集合，而不是null,如果是單個(gè)對(duì)象可以通過(guò)字段標(biāo)識(shí)來(lái)區(qū)分,需要保證緩存數(shù)據(jù)的時(shí)效性(實(shí)現(xiàn)相對(duì)簡(jiǎn)單)，適合命中不高但可能會(huì)頻繁更新的數(shù)據(jù)。
單獨(dú)過(guò)濾處理：對(duì)所有可能對(duì)應(yīng)數(shù)據(jù)為空的key進(jìn)行統(tǒng)一的存放,并在請(qǐng)求前做攔截(實(shí)現(xiàn)相對(duì)復(fù)雜)，適合命中不高更新不頻繁的數(shù)據(jù)

（4）緩存顛簸問(wèn)題
緩存的顛簸問(wèn)題，有些地方可能被稱為“緩存抖動(dòng)”，可以看作是一種比“雪崩”更輕微的故障，但是也會(huì)在一段時(shí)間內(nèi)對(duì)系統(tǒng)造成沖擊和性能影響。一般是由于緩存節(jié)點(diǎn)故障導(dǎo)致。業(yè)內(nèi)推薦的做法是通過(guò)一致性Hash算法來(lái)解決。

（5）緩存雪崩現(xiàn)象
緩存雪崩就是指由于緩存的原因，導(dǎo)致大量請(qǐng)求到達(dá)后端數(shù)據(jù)庫(kù)，從而導(dǎo)致數(shù)據(jù)庫(kù)崩潰，整個(gè)系統(tǒng)崩潰，發(fā)生災(zāi)難。導(dǎo)致這種現(xiàn)象的原因有很多種，上面提到的“緩存并發(fā)”，“緩存穿透”，“緩存顛簸”等問(wèn)題，其實(shí)都可能會(huì)導(dǎo)致緩存雪崩現(xiàn)象發(fā)生。這些問(wèn)題也可能會(huì)被惡意攻擊者所利用。還有一種情況，例如某個(gè)時(shí)間點(diǎn)內(nèi)，系統(tǒng)預(yù)加載的緩存周期性集中失效了，也可能會(huì)導(dǎo)致雪崩。為了避免這種周期性失效，可以通過(guò)設(shè)置不同的過(guò)期時(shí)間，來(lái)錯(cuò)開(kāi)緩存過(guò)期，從而避免緩存集中失效。

從應(yīng)用架構(gòu)角度，我們可以通過(guò)限流、降級(jí)、熔斷等手段來(lái)降低影響，也可以通過(guò)多級(jí)緩存來(lái)避免這種災(zāi)難。

此外，從整個(gè)研發(fā)體系流程的角度，應(yīng)該加強(qiáng)壓力測(cè)試，盡量模擬真實(shí)場(chǎng)景，盡早的暴露問(wèn)題從而防范。

（6）緩存無(wú)底洞現(xiàn)象
該問(wèn)題由 facebook 的工作人員提出的， facebook 在 2010 年左右，memcached 節(jié)點(diǎn)就已經(jīng)達(dá)3000 個(gè)，緩存數(shù)千 G 內(nèi)容。他們發(fā)現(xiàn)了一個(gè)問(wèn)題---memcached 連接頻率，效率下降了，于是加 memcached 節(jié)點(diǎn)，添加了后，發(fā)現(xiàn)因?yàn)檫B接頻率導(dǎo)致的問(wèn)題，仍然存在，并沒(méi)有好轉(zhuǎn)，稱之為”無(wú)底洞現(xiàn)象”

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：
長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝