一、緩存穿透

我們?cè)陧?xiàng)目中使用緩存通常都是先檢查緩存中是否存在，如果存在直接返回緩存內(nèi)容，如果不存在就直接查詢數(shù)據(jù)庫(kù)然后再緩存查詢結(jié)果返回。這個(gè)時(shí)候如果我們查詢的某一個(gè)數(shù)據(jù)在緩存中一直不存在，就會(huì)造成每一次請(qǐng)求都查詢DB，這樣緩存就失去了意義，在流量大時(shí)，可能DB就掛掉了。

那這種問(wèn)題有什么好辦法解決呢？

要是有人利用不存在的key頻繁攻擊我們的應(yīng)用，這就是漏洞。
有一個(gè)比較巧妙的作法是，可以將這個(gè)不存在的key預(yù)先設(shè)定一個(gè)值。
比如，”key” , “&&”。
在返回這個(gè)&&值的時(shí)候，我們的應(yīng)用就可以認(rèn)為這是不存在的key，那我們的應(yīng)用就可以決定是否繼續(xù)等待繼續(xù)訪問(wèn)，還是放棄掉這次操作。如果繼續(xù)等待訪問(wèn)，過(guò)一個(gè)時(shí)間輪詢點(diǎn)后，再次請(qǐng)求這個(gè)key，如果取到的值不再是&&，則可以認(rèn)為這時(shí)候key有值了，從而避免了透?jìng)鞯綌?shù)據(jù)庫(kù)，從而把大量的類似請(qǐng)求擋在了緩存之中。

二、緩存并發(fā)

有時(shí)候如果網(wǎng)站并發(fā)訪問(wèn)高，一個(gè)緩存如果失效，可能出現(xiàn)多個(gè)進(jìn)程同時(shí)查詢DB，同時(shí)設(shè)置緩存的情況，如果并發(fā)確實(shí)很大，這也可能造成DB壓力過(guò)大，還有緩存頻繁更新的問(wèn)題。

我現(xiàn)在的想法是對(duì)緩存查詢加鎖，如果KEY不存在，就加鎖，然后查DB入緩存，然后解鎖；其他進(jìn)程如果發(fā)現(xiàn)有鎖就等待，然后等解鎖后返回?cái)?shù)據(jù)或者進(jìn)入DB查詢。

這種情況和剛才說(shuō)的預(yù)先設(shè)定值問(wèn)題有些類似，只不過(guò)利用鎖的方式，會(huì)造成部分請(qǐng)求等待。

三、緩存失效

引起這個(gè)問(wèn)題的主要原因還是高并發(fā)的時(shí)候，平時(shí)我們?cè)O(shè)定一個(gè)緩存的過(guò)期時(shí)間時(shí)，可能有一些會(huì)設(shè)置1分鐘啊，5分鐘這些，并發(fā)很高時(shí)可能會(huì)出在某一個(gè)時(shí)間同時(shí)生成了很多的緩存，并且過(guò)期時(shí)間都一樣，這個(gè)時(shí)候就可能引發(fā)一當(dāng)過(guò)期時(shí)間到后，這些緩存同時(shí)失效，請(qǐng)求全部轉(zhuǎn)發(fā)到DB，DB可能會(huì)壓力過(guò)重。

那如何解決這些問(wèn)題呢？
其中的一個(gè)簡(jiǎn)單方案就時(shí)講緩存失效時(shí)間分散開(kāi)，比如我們可以在原有的失效時(shí)間基礎(chǔ)上增加一個(gè)隨機(jī)值，比如1-5分鐘隨機(jī)，這樣每一個(gè)緩存的過(guò)期時(shí)間的重復(fù)率就會(huì)降低，就很難引發(fā)集體失效的事件。

四、緩存雪崩

緩存雪崩可能是因?yàn)閿?shù)據(jù)未加載到緩存中，或者緩存同一時(shí)間大面積的失效，從而導(dǎo)致所有請(qǐng)求都去查數(shù)據(jù)庫(kù)，導(dǎo)致數(shù)據(jù)庫(kù)CPU和內(nèi)存負(fù)載過(guò)高，甚至宕機(jī)。

解決思路：

1，采用加鎖計(jì)數(shù)，或者使用合理的隊(duì)列數(shù)量來(lái)避免緩存失效時(shí)對(duì)數(shù)據(jù)庫(kù)造成太大的壓力。這種辦法雖然能緩解數(shù)據(jù)庫(kù)的壓力，但是同時(shí)又降低了系統(tǒng)的吞吐量。

2，分析用戶行為，盡量讓失效時(shí)間點(diǎn)均勻分布。避免緩存雪崩的出現(xiàn)。

3，如果是因?yàn)槟撑_(tái)緩存服務(wù)器宕機(jī)，可以考慮做主備，比如：redis主備，但是雙緩存涉及到更新事務(wù)的問(wèn)題，update可能讀到臟數(shù)據(jù)，需要好好解決。

五、緩存預(yù)熱

單機(jī)web系統(tǒng)情況下比較簡(jiǎn)單。

解決思路：

1，直接寫個(gè)緩存刷新頁(yè)面，上線時(shí)手工操作下。

2，數(shù)據(jù)量不大，可以在WEB系統(tǒng)啟動(dòng)的時(shí)候加載。

3，搞個(gè)定時(shí)器定時(shí)刷新緩存，或者由用戶觸發(fā)都行。

分布式緩存系統(tǒng)，如Memcached，Redis，比如緩存系統(tǒng)比較大，由十幾臺(tái)甚至幾十臺(tái)機(jī)器組成，這樣預(yù)熱會(huì)復(fù)雜一些。

解決思路：

1，寫個(gè)程序去跑。

2，單個(gè)緩存預(yù)熱框架。

緩存預(yù)熱的目標(biāo)就是在系統(tǒng)上線前，將數(shù)據(jù)加載到緩存中。

六、緩存算法

FIFO算法：First in First out，先進(jìn)先出。原則：一個(gè)數(shù)據(jù)最先進(jìn)入緩存中，則應(yīng)該最早淘汰掉。也就是說(shuō)，當(dāng)緩存滿的時(shí)候，應(yīng)當(dāng)把最先進(jìn)入緩存的數(shù)據(jù)給淘汰掉。
LFU算法：Least Frequently Used，最不經(jīng)常使用算法。
LRU算法：Least Recently Used，近期最少使用算法。請(qǐng)查看：Memcached之你真正理解LRU嗎(4)

LRU和LFU的區(qū)別。LFU算法是根據(jù)在一段時(shí)間里數(shù)據(jù)項(xiàng)被使用的次數(shù)選擇出最少使用的數(shù)據(jù)項(xiàng)，即根據(jù)使用次數(shù)的差異來(lái)決定。而LRU是根據(jù)使用時(shí)間的差異來(lái)決定的。

總結(jié)：

• 緩存盡量做到低冗余，數(shù)據(jù)性質(zhì)較為單一。
  • 例如，在取訂單數(shù)據(jù)時(shí)，用戶部分的信息從用戶緩存中獲取，而不是一起緩存。
• 在修改數(shù)據(jù)時(shí) 替換緩存而不是刪除緩存
  • 當(dāng)然如果數(shù)據(jù)都是冗余在一起的話，就會(huì)造成數(shù)據(jù)一致性的問(wèn)題。

參考：

原文地址：
https://my.oschina.net/huangcongmin12/blog/692783

緩存穿透、緩存并發(fā)、緩存失效之思路變遷
http://www.itdecent.cn/p/d96906140199