一、緩存穿透

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

那這種問題有什么好辦法解決呢？

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

二、緩存并發(fā)

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

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

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

三、緩存失效

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

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

四、緩存雪崩

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

解決思路：

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

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

3，如果是因為某臺緩存服務(wù)器宕機，可以考慮做主備，比如：redis主備，但是雙緩存涉及到更新事務(wù)的問題，update可能讀到臟數(shù)據(jù)，需要好好解決。

五、緩存預(yù)熱

單機web系統(tǒng)情況下比較簡單。

解決思路：

1，直接寫個緩存刷新頁面，上線時手工操作下。

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

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

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

解決思路：

1，寫個程序去跑。

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

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

六、緩存算法

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

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

總結(jié)：

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

參考：

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

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