隨著系統訪問量的提高，復雜度的提升，響應性能成為一個重點的關注點。而緩存的使用成為一個重點。redis 作為緩存中間件的一個佼佼者，成為了面試必問項目。本文分享一下Redis幾道常見的面試題：

緩存雪崩

1.1什么是緩存雪崩?

如果我們的緩存掛掉了，這意味著我們的全部請求都跑去數據庫了。

我們都知道Redis不可能把所有的數據都緩存起來(內存昂貴且有限)，所以Redis需要對數據設置過期時間，并采用的是惰性刪除+定期刪除兩種策略對過期鍵刪除。

如果緩存數據設置的過期時間是相同的，并且Redis恰好將這部分數據全部刪光了。這就會導致在這段時間內，這些緩存同時失效，全部請求到數據庫中。

這就是緩存雪崩：Redis掛掉了，請求全部走數據庫。

緩存雪崩如果發生了，很可能就把我們的數據庫搞垮，導致整個服務癱瘓!

1.2如何解決緩存雪崩?

在緩存的時候給過期時間加上一個隨機值，這樣就會大幅度的減少緩存在同一時間過期。

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

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

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

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

緩存穿透

2.1什么是緩存穿透

緩存穿透是指查詢一個一定不存在的數據。由于緩存不***，并且出于容錯考慮，如果從數據庫查不到數據則不寫入緩存，這將導致這個不存在的數據每次請求都要到數據庫去查詢，失去了緩存的意義。

這就是緩存穿透：

請求的數據在緩存大量不***，導致請求走數據庫。

緩存穿透如果發生了，也可能把我們的數據庫搞垮，導致整個服務癱瘓!

2.1如何解決緩存穿透?

解決緩存穿透也有兩種方案：

由于請求的參數是不合法的(每次都請求不存在的參數)，于是我們可以使用布隆過濾器(BloomFilter)或者壓縮filter提前攔截，不合法就不讓這個請求到數據庫層!

當我們從數據庫找不到的時候，我們也將這個空對象設置到緩存里邊去。下次再請求的時候，就可以從緩存里邊獲取了。

這種情況我們一般會將空對象設置一個較短的過期時間。

緩存與數據庫雙寫一致

3.1對于讀操作，流程是這樣的

如果我們的數據在緩存里邊有，那么就直接取緩存的。

如果緩存里沒有我們想要的數據，我們會先去查詢數據庫，然后將數據庫查出來的數據寫到緩存中。***將數據返回給請求。

3.2什么是緩存與數據庫雙寫一致問題?

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

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

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

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

***

本文帶領大家了解了如何解決緩存雪崩、緩存穿透、保證緩存與數據庫雙寫時一致 等問題。除此之外還有很多提問點需要我們關注，推薦閱讀列出一部分。

希望大家看完有所幫助。