點選上面藍字進行關注的都是靚仔和仙女由

我們在用快取的時候，不管是Redis或者Memcached，基本上會通用遇到以下三個問題：

• 快取穿透

• 快取併發

• 快取失效

  快取穿透

上面三個圖會有什麼問題呢？

我們在專案中使用快取通常都是先檢查快取中是否存在，如果存在直接返回快取內容，如果不存在就直接查詢資料庫然後再快取查詢結果返回。這個時候如果我們查詢的某一個數據在快取中一直不存在，就會造成每一次請求都查詢DB，這樣快取就失去了意義，在流量大時，可能DB就掛掉了。

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

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

有時候如果網站併發訪問高，一個快取如果失效，可能出現多個程序同時查詢DB，同時設定快取的情況，如果併發確實很大，這也可能造成DB壓力過大，還有快取頻繁更新的問題。

我現在的想法是對快取查詢加鎖，如果KEY不存在，就加鎖，然後查DB入快取，然後解鎖；其他程序如果發現有鎖就等待，然後等解鎖後返回資料或者進入DB查詢。

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

引起這個問題的主要原因還是高併發的時候，平時我們設定一個快取的過期時間時，可能有一些會設定1分鐘啊，5分鐘這些，併發很高時可能會出在某一個時間同時生成了很多的快取，並且過期時間都一樣，這個時候就可能引發一當過期時間到後，這些快取同時失效，請求全部轉發到DB，DB可能會壓力過重。

那如何解決這些問題呢？

其中的一個簡單方案就時講快取失效時間分散開，比如我們可以在原有的失效時間基礎上增加一個隨機值，比如1-5分鐘隨機，這樣每一個快取的過期時間的重複率就會降低，就很難引發集體失效的事件。

我們討論的第二個問題時針對同一個快取，第三個問題時針對很多快取。

1、快取穿透：查詢一個必然不存在的資料。比如文章表，查詢一個不存在的id，每次都會訪問DB，如果有人惡意破壞，很可能直接對DB造成影響。

2、快取失效：如果快取集中在一段時間內失效，DB的壓力凸顯。這個沒有完美解決辦法，但可以分析使用者行為，儘量讓失效時間點均勻分佈。當發生大量的快取穿透，例如對某個失效的快取的大併發訪問就造成了快取雪崩。

如何解決DB和快取一致性問題？

答：當修改了資料庫後，有沒有及時修改快取。這種問題，以前有過實踐，修改資料庫成功，而修改快取失敗的情況，最主要就是快取伺服器掛了。而因為網路問題引起的沒有及時更新，可以通過重試機制來解決。而快取伺服器掛了，請求首先自然也就無法到達，從而直接訪問到資料庫。那麼我們在修改資料庫後，無法修改快取，這時候可以將這條資料放到資料庫中，同時啟動一個非同步任務定時去檢測快取伺服器是否連線成功，一旦連線成功則從資料庫中按順序取出修改資料，依次進行快取最新值的修改。

多級快取是什麼概念呢？

答：多級快取就是將ehcache與redis做二級快取，就像我之前寫的文章也提到過。但同樣會存在一致性問題，如果我們需要強一致性的話，快取與資料庫同步是會存在時間差的，所以我們在具體開發的過程中，一定要根據場景來具體分析，二級快取更多的解決是，快取穿透與程式的健壯性，當集中式快取出現問題的時候，我們的應用能夠繼續執行。

想更加詳細，更加深入的瞭解快取擊穿嗎？

在這裡部落告訴大家一個小祕密

今晚8：30

動腦學院  Lison大神

將在騰訊課堂  動腦學院  免費Java公開課中

給大家詳細講解

《 redis你不得不知道的故事 分散式鎖三大注意事項 》

你只需要在今晚8：30的時候

點選文章最末 閱讀原文

即可進行觀看

推薦閱讀  

▼

推薦程式設計師必備微訊號 

▼