我們在用緩存的時候，不管是Redis或者Memcached蘑拯，基本上會通用遇到以下三個問題：
- 緩存穿透
- 緩存并發(fā)
- 緩存失效
一钝满、緩存穿透
注：
上面三個圖會有什么問題呢？
我們在項目中使用緩存通常都是先檢查緩存中是否存在申窘，如果存在直接返回緩存內容弯蚜，如果不存在就直接查詢數(shù)據(jù)庫然后再緩存查詢結果返回。這個時候如果我們查詢的某一個數(shù)據(jù)在緩存中一直不存在剃法，就會造成每一次請求都查詢DB碎捺，這樣緩存就失去了意義，在流量大時贷洲，可能DB就掛掉了收厨。
那這種問題有什么好辦法解決呢？
要是有人利用不存在的key頻繁攻擊我們的應用优构，這就是漏洞诵叁。
有一個比較巧妙的作法是，可以將這個不存在的key預先設定一個值钦椭。
比如拧额，"key" , “&&”。
在返回這個&&值的時候彪腔，我們的應用就可以認為這是不存在的key侥锦，那我們的應用就可以決定是否繼續(xù)等待繼續(xù)訪問，還是放棄掉這次操作德挣。如果繼續(xù)等待訪問捎拯，過一個時間輪詢點后，再次請求這個key，如果取到的值不再是&&署照，則可以認為這時候key有值了，從而避免了透傳到數(shù)據(jù)庫吗浩，從而把大量的類似請求擋在了緩存之中建芙。
二、緩存并發(fā)
有時候如果網(wǎng)站并發(fā)訪問高懂扼，一個緩存如果失效禁荸，可能出現(xiàn)多個進程同時查詢DB，同時設置緩存的情況阀湿，如果并發(fā)確實很大赶熟，這也可能造成DB壓力過大，還有緩存頻繁更新的問題陷嘴。
我現(xiàn)在的想法是對緩存查詢加鎖映砖，如果KEY不存在，就加鎖灾挨，然后查DB入緩存邑退，然后解鎖；其他進程如果發(fā)現(xiàn)有鎖就等待劳澄，然后等解鎖后返回數(shù)據(jù)或者進入DB查詢地技。
這種情況和剛才說的預先設定值問題有些類似，只不過利用鎖的方式秒拔，會造成部分請求等待莫矗。
三、緩存失效
引起這個問題的主要原因還是高并發(fā)的時候砂缩，平時我們設定一個緩存的過期時間時作谚，可能有一些會設置1分鐘啊，5分鐘這些梯轻，并發(fā)很高時可能會出在某一個時間同時生成了很多的緩存食磕，并且過期時間都一樣，這個時候就可能引發(fā)一當過期時間到后喳挑，這些緩存同時失效彬伦，請求全部轉發(fā)到DB，DB可能會壓力過重伊诵。
那如何解決這些問題呢单绑？
其中的一個簡單方案就時講緩存失效時間分散開，比如我們可以在原有的失效時間基礎上增加一個隨機值曹宴，比如1-5分鐘隨機搂橙，這樣每一個緩存的過期時間的重復率就會降低，就很難引發(fā)集體失效的事件笛坦。
我們討論的第二個問題時針對同一個緩存区转，第三個問題時針對很多緩存苔巨。
總結來看：
1、緩存穿透：查詢一個必然不存在的數(shù)據(jù)废离。比如文章表侄泽，查詢一個不存在的id，每次都會訪問DB蜻韭，如果有人惡意破壞悼尾，很可能直接對DB造成影響。
2肖方、緩存失效：如果緩存集中在一段時間內失效闺魏，DB的壓力凸顯。這個沒有完美解決辦法俯画，但可以分析用戶行為析桥，盡量讓失效時間點均勻分布。
當發(fā)生大量的緩存穿透活翩，例如對某個失效的緩存的大并發(fā)訪問就造成了緩存雪崩烹骨。
四、大家提問匯總
1材泄、問題1：
如何解決DB和緩存一致性問題沮焕？
答：當修改了數(shù)據(jù)庫后，有沒有及時修改緩存拉宗。這種問題峦树，以前有過實踐，修改數(shù)據(jù)庫成功旦事，而修改緩存失敗的情況魁巩，最主要就是緩存服務器掛了。而因為網(wǎng)絡問題引起的沒有及時更新姐浮，可以通過重試機制來解決谷遂。而緩存服務器掛了，請求首先自然也就無法到達卖鲤，從而直接訪問到數(shù)據(jù)庫肾扰。那么我們在修改數(shù)據(jù)庫后，無法修改緩存蛋逾，這時候可以將這條數(shù)據(jù)放到數(shù)據(jù)庫中集晚，同時啟動一個異步任務定時去檢測緩存服務器是否連接成功，一旦連接成功則從數(shù)據(jù)庫中按順序取出修改數(shù)據(jù)区匣，依次進行緩存最新值的修改偷拔。
2、問題2：
問下緩存穿透那塊！例如莲绰，一個用戶查詢文章欺旧，通過ID查詢，按照之前說的蛤签，是將緩存的KEY預先設置一個值切端，，如果通過ID插過來顷啼，發(fā)現(xiàn)是預先設定的一個值，比如說是“&&”昌屉，那之后的繼續(xù)等待訪問是什么意思钙蒙，這個ID什么時候會真正被附上用戶所需要的值呢？
答：我剛說的主要是咱們常用的后面配置间驮，前臺獲取的場景躬厌。前臺無法獲取相應的key，則等待竞帽，或者放棄扛施。當在后臺配置界面上配置了相關key和value之后，那么以前的key &&也自然會被替換掉屹篓。你說的那種情況疙渣，自然也應該會有一個進程會在某一個時刻，在緩存中設置這個ID堆巧，再有新的請求到達的時候妄荔，就會獲取到最新的ID和value。
3谍肤、問題3：
其實用redis的話啦租，那天看到一個不錯的例子浑侥，雙key蛔六，有一個當時生成的一個附屬key來標識數(shù)據(jù)修改到期時間阎姥，然后快到的時候去重新加載數(shù)據(jù)瘪弓，如果覺得key多可以把結束時間放到主key中构资，附屬key起到鎖的功能哲嘲。
答：這種方案嫌变，之前我們實踐過碰缔。這種方案會產生雙份數(shù)據(jù)赋除，而且需要同時控制附屬key與key之間的關系阱缓，操作上有一定復雜度。
4举农、問題4：
多級緩存是什么概念呢荆针？
答：多級緩存就像我今天之前給大家發(fā)的文章里面提到了，將ehcache與redis做二級緩存，就像我之前寫的文章 http://www.reibang.com/p/2cd6ad416a5a 提到過的航背。但同樣會存在一致性問題喉悴，如果我們需要強一致性的話，緩存與數(shù)據(jù)庫同步是會存在時間差的玖媚，所以我們在具體開發(fā)的過程中箕肃，一定要根據(jù)場景來具體分析，二級緩存更多的解決是今魔，緩存穿透與程序的健壯性勺像，當集中式緩存出現(xiàn)問題的時候，我們的應用能夠繼續(xù)運行错森。
