互聯網面試中躲不開的緩存問題

相信大家在互聯網公司面試中一定遇到過關於緩存的相關問題,如果你在面試過程中說沒有用過緩存,那麼恭喜你,你被pass了,緩存是互聯網公司必問的問題,所以想要進入互聯網公司的同學就需要好好準備準備這方面的知識了!

一.為什麼要使用緩存

使用緩存其實就兩個目的提高性能和併發

1.高性能

現在有這樣一個場景,有個請求操作數據庫半天出一個結果耗時800ms,並且這個結果在之後的很長時間時沒有改動的,那怎麼幫你,當然是引入緩存啊,將查詢結果放入緩存裡,下次查詢直接從緩存取結果,耗時4ms,看看引入緩存後性能提高了多少倍!

2.高併發

數據庫本身就不是為了高併發設計的,像MySQL單機支撐超過2000qps就報警了,如果你的系統在高峰是請求查過2000qps,一臺MySQL肯定是不行的,這是就可以將部分數據放到緩存裡,減少對數據庫的訪問

二.引入緩存後會出現什麼問題

你要是沒有考慮過引入緩存會出現什麼問題的話,那麼估計也會被pass掉,因為給面試官的印象就是你只是會傻傻的用,並沒有思考用了之後會遇到什麼問題

常見的緩存問題

1.緩存一致性問題

當數據時效性要求很高時,需要保證緩存與數據庫中的數據一致,同時也需要保證緩存節點和副本中的數據一致。

解決方案:這就需要依賴緩存的過期和更新策略。一般會在數據發生更改的時,主動更新緩存中的數據或者移除對應的緩存

2.緩存雪崩

高併發情況下,緩存更新或者過期導致緩存數據失效,大量請求直接落到DB上,導致數據庫壓力過大直至奔潰。

解決方案:(1)如果是由於大量緩存數據在同一時間過期導致大量請求落到DB上的,那麼我們需要調整緩存過期時間,將緩存數據的過期時間設置的均勻一些,避免大量數據在同一時間內發生過期失效。

(2)儘量避免緩存併發、緩存穿透的問題

3.緩存併發

緩存併發應該存在兩個問題:併發讀和併發寫

併發讀的場景下會遇到如果大量緩存數據失效會導致併發請求落到DB嚴重的話就會導致雪崩問題

併發寫的場景會出現數據不一致的問題

4.緩存穿透

查詢一個必然不存在的數據。比如文章表,查詢一個不存在的id,每次都會訪問DB,如果有人惡意破壞,很可能直接對DB造成影響

解決方案:對所有可能查詢的參數以hash形式存儲,在控制層先進行校驗,不符合則丟棄

緩存的問題就說到這裡,這篇文章只能帶大家簡單的瞭解一下緩存以及使用緩存後會遇到哪些問題,後面會陸續整理緩存優秀框架Redis相關的內容,希望對大家有幫助,我會定期分享技術知識,我是【不愛八阿哥】記得關注我,有問題也可以評論或者私信,我會盡可能的回答!

下期預告:

Redis數據類型,Redis過期策略,Redis線程模型


分享到:


相關文章: