參考文章：
作者丨我一定會有貓的 https://juejin.im/post/5b604b9ef265da0f62639001
作者丨Java技術棧 https://mp.weixin.qq.com/s/9n3LJrFbVGouWYqKeoVSxw

緩存三大問題及解決方案

1. 緩存來由

隨著互聯網系統發展的逐步完善，提高系統的qps，目前的絕大部分系統都增加了緩存機制從而避免請求過多的直接與數據庫操作從而造成系統瓶頸，極大的提升了用戶體驗和系統穩定性。

2. 緩存問題

雖然使用緩存給系統帶來了一定的質的提升，但同時也帶來了一些需要注意的問題。

2.1 緩存穿透

緩存穿透是指查詢一個一定不存在的數據，因為緩存中也無該數據的信息，則會直接去數據庫層進行查詢，從系統層面來看像是穿透了緩存層直接達到db，從而稱為緩存穿透，沒有了緩存層的保護，這種查詢一定不存在的數據對系統來說可能是一種危險，如果有人惡意用這種一定不存在的數據來頻繁請求系統，不，準確的說是攻擊系統，請求都會到達數據庫層導致db癱瘓從而引起系統故障。

2.1.1 解決方案

緩存穿透業內的解決方案已經比較成熟，主要常用的有以下幾種：

• bloomfilter：類似于哈希表的一種算法，用所有可能的查詢條件生成一個bitmap，在進行數據庫查詢之前會使用這個bitmap進行過濾，如果不在其中則直接過濾，從而減輕數據庫層面的壓力。

• 空值緩存：一種比較簡單的解決辦法，在第一次查詢完不存在的數據后，將該key與對應的空值也放入緩存中，只不過設定為較短的失效時間，例如幾分鐘，這樣則可以應對短時間的大量的該key攻擊，設置為較短的失效時間是因為該值可能業務無關，存在意義不大，且該次的查詢也未必是攻擊者發起，無過久存儲的必要，故可以早點失效。

2.2 緩存雪崩

在普通的緩存系統中一般例如redis、memcache等中，我們會給緩存設置一個失效時間，但是如果所有的緩存的失效時間相同，那么在同一時間失效時，所有系統的請求都會發送到數據庫層，db可能無法承受如此大的壓力導致系統崩潰。這就是緩存雪崩：Redis掛掉了，請求全部走數據庫。緩存雪崩如果發生了，很可能就把我們的數據庫搞垮，導致整個服務癱瘓！

2.2.1 解決方案

• 線程互斥：只讓一個線程構建緩存，其他線程等待構建緩存的線程執行完，重新從緩存獲取數據才可以，每個時刻只有一個線程在執行請求，減輕了db的壓力，但缺點也很明顯，降低了系統的qps。
• 交錯失效時間：這種方法時間比較簡單粗暴，既然在同一時間失效會造成請求過多雪崩，那我們錯開不同的失效時間即可從一定長度上避免這種問題，在緩存進行失效時間設置的時候，從某個適當的值域中隨機一個時間作為失效時間即可。在緩存的時候給過期時間加上一個隨機值，這樣就會大幅度的減少緩存在同一時間過期。

對于“Redis掛掉了，請求全部走數據庫”這種情況，我們可以有以下的思路：

事發前：實現Redis的高可用(主從架構+Sentinel 或者Redis Cluster)，盡量避免Redis掛掉這種情況發生。

事發中：萬一Redis真的掛了，我們可以設置本地緩存(ehcache)+限流(hystrix)，盡量避免我們的數據庫被干掉(起碼能保證我們的服務還是能正常工作的)

事發后：redis持久化，重啟后自動從磁盤上加載數據，快速恢復緩存數據

2.3 緩存擊穿

緩存擊穿實際上是緩存雪崩的一個特例，大家使用過微博的應該都知道，微博有一個熱門話題的功能，用戶對于熱門話題的搜索量往往在一些時刻會大大的高于其他話題，這種我們成為系統的“熱點“，由于系統中對這些熱點的數據緩存也存在失效時間，在熱點的緩存到達失效時間時，此時可能依然會有大量的請求到達系統，沒有了緩存層的保護，這些請求同樣的會到達db從而可能引起故障。擊穿與雪崩的區別即在于擊穿是對于特定的熱點數據來說，而雪崩是全部數據。

2.3.1 解決方案

• 二級緩存：對于熱點數據進行二級緩存，并對于不同級別的緩存設定不同的失效時間，則請求不會直接擊穿緩存層到達數據庫。
• 這里參考了阿里雙11萬億流量的緩存擊穿解決方案，解決此問題的關鍵在于熱點訪問。由于熱點可能隨著時間的變化而變化，針對固定的數據進行特殊緩存是不能起到治本作用的，結合LRU算法能夠較好的幫我們解決這個問題。那么LRU是什么，下面粗略的介紹一下，有興趣的可以點擊上面的鏈接查看。
• LRU（Least recently used，最近最少使用）算法根據數據的歷史訪問記錄來進行淘汰數據，其核心思想是“如果數據最近被訪問過，那么將來被訪問的幾率也更高”。最常見的實現是使用一個鏈表保存緩存數據，如下圖所示
  
  這個鏈表即是我們的緩存結構，緩存處理步驟為

首先將新數據放入鏈表的頭部

在進行數據插入的過程中，如果檢測到鏈表中有數據被再次訪問也就是有請求再次訪問這些數據，那么就其插入的鏈表的頭部，因為它們相對其他數據來說可能是熱點數據，具有保留時間更久的意義

最后當鏈表數據放滿時將底部的數據淘汰，也就是不常訪問的數據

LRU-K算法 ，其實上面的算法也是該算法的特例情況即LRU-1，上面的算法存在較多的不合理性，在實際的應用過程中采用該算法進行了改進，例如偶然的數據影響會造成命中率較低，比如某個數據即將到達底部即將被淘汰，但由于一次的請求又放入了頭部，此后再無該數據的請求，那么該數據的繼續存在其實是不合理的，針對這類情況LRU-K算法擁有更好的解決措施。結構圖如下所示：

LRU-K需要多維護一個隊列或者更多，用于記錄所有緩存數據被訪問的歷史。只有當數據的訪問次數達到K次的時候，才將數據放入緩存。當需要淘汰數據時，LRU-K會淘汰第K次訪問時間距當前時間最大的數據。

第一步添加數據照樣放入第一個隊列的頭部如果數據在該隊列里訪問沒有達到K次（該數值根據具體系統qps來定）則會繼續到達鏈表底部直至淘汰；

如果該數據在隊列中時訪問次數達到了K次，那么它會被加入到接下來的2級(具體需要幾級結構也同樣結合系統分析)鏈表中，按照時間順序在2級鏈表中排列

接下來2級鏈表中的操作與上面算法相同，鏈表中的數據如果再次被訪問則移到頭部，鏈表滿時，底部數據淘汰

相比LRU，LRU-K需要多維護一個隊列，用于記錄所有緩存數據被訪問的歷史，所以需要更多的內存空間來用來構建緩存，但優點也很明顯，較好的降低了數據的污染率提高了緩存的命中率，對于系統來說可以用一定的硬件成本來換取系統性能也不失為一種辦法。當然還有更為復雜的緩存結構算法，點擊LRU算法即可學習，例如Two Queues和Mutil Queues等等，本文不過多贅述，只為讀者提供一種解決思路。

2.4 緩存與數據庫雙寫一致

2.4.1什么是緩存與數據庫雙寫一致問題？

如果僅僅查詢的話，緩存的數據和數據庫的數據是沒問題的。但是，當我們要更新時候呢？各種情況很可能就造成數據庫和緩存的數據不一致了。

這里不一致指的是：數據庫的數據跟緩存的數據不一致

從理論上說，只要我們設置了鍵的過期時間，我們就能保證緩存和數據庫的數據最終是一致的。因為只要緩存數據過期了，就會被刪除。隨后讀的時候，因為緩存里沒有，就可以查數據庫的數據，然后將數據庫查出來的數據寫入到緩存中。

除了設置過期時間，我們還需要做更多的措施來盡量避免數據庫與緩存處于不一致的情況發生。

相關評論問題：
A：針對緩存擊穿里面的空值緩存，如果惡意攻擊者不停的換不存在的key，那你的緩存里面一段時間會有非常多的key，內存的消耗也是非常可觀的。甚至會導致你的緩存進行換出操作，把一些正常的數據換出。

B：那么針對這種情況，要怎樣處理呢。我覺得設置權重，限流都可以加上。

A： redis以前的換出策略是lru，4.0加上了lfu了。lfu這種算法一定程度上可以避免把真正的數據換出。當然限流、限制訪問頻率還是更靠譜一些，還有就是文中也提到了的bloom filter

參考文章：
雙11萬億流量下的分布式緩存 https://yq.aliyun.com/articles/290865
緩存淘汰算法 http://flychao88.iteye.com/blog/1977653

總結

以上是生活随笔為你收集整理的缓存三大问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。