經歷幾年開發經驗之後，再去面試，緩存問題是不可避免的，現在最常見的緩存就應該是Redis了，下面是在面試中最常見的Redis的8個問題。
一、爲什麼要使用 Redis ？
主要可以從兩個方面來考慮：性能和併發
1、性能：如果我們在項目中碰到需要執行耗時特別久，且結果不頻繁變動的SQL，就特別合適將查詢結果放入到緩存中，以便下次查詢的時候能夠快速的相應；
2、併發：在大併發的情況下，所有的請求直接訪問數據庫，數據庫就會出現連接異常，這個時候就需要 Redis 做一個緩衝，每次請求過來的時候，首先訪問 Redis ，而不是直接訪問數據庫，極大的降低了數據庫的壓力。
二、使用 Redis 有什麼優缺點？
要知道任何事物都是有利有弊的，Redis 也不例外：
-
緩存和數據庫雙寫一致性問題
-
緩存雪崩問題
-
緩存擊穿問題
-
緩存的併發競爭問題
三、單線程的 Redis 爲什麼這麼快？
此問題主要考察 redis 的內部機制，主要從一下三點回答：
- 純內存操作
- 單線程操作，避免了頻繁的上下文切換
- 採用了非阻塞 I/O 多路複用機制
四、Redis 的數據類型，以及每種數據類型的使用場景？
這個就比較簡單了，一共五種：String、hash、list、set、zset 。 具體的使用場景可查看另一篇博文Redis基本數據類型及使用場景
五、Redis 的過期策略以及內存淘汰機制
Redis 採用的是定期刪除+惰性刪除策略：定期刪除、redis默認每隔100ms 檢查內存中是否有過期的 key ，有過期的 key 則刪除。而 redis 不是每100ms 將所有的 key 檢查一次（如果所有的都檢查，豈不會卡死），而是隨機抽取檢查。如果只採用定期刪除，將會導致很多 key 到期沒有刪除。於是惰性刪除就上場了、也就是說在你獲取某個 key 的時候，redis 會檢查一下，這個 key 如果過期了就刪除。在 redis.conf 中配置 maxmemory-policy volatile-lru
- noeviction : 內存不足時寫入數據，寫入數據報錯
- allkeys-lru : 內存不足時寫入數據，鍵空間中移除最近最少使用的 key（推薦使用）
- allkeys-random : 內存不足時寫入數據，隨機刪除某個 key
- volatile-lru : 內存不足時寫入數據，在設置過期時間的鍵空間中，移除最近最少使用的key
- volatile-random : 內存不足時寫入數據，在設置過期時間的鍵空間中，隨機移除某個 key
- volatile-ttl : 內存不足時寫入數據，更早過期的 key ，優先移除
六、Redis 和數據庫雙寫一致性問題
一致性問題是分佈式常見的問題，可以分爲最終一致性和強一致性。強一致性要求的數據，不能放緩存。首先。採取正確的更新策略，先更新數據庫，在刪除緩存。其次，因爲可能存在刪除緩存失敗的問題，提供做一個補償措施即可，比如利用消息隊列。
七、如何應對緩存穿透和緩存雪崩的問題
緩存穿透：黑客故意去請求緩存中不存在的數據，導致所有的請求都懟到數據庫上，從而數據庫連接異常。
解決方案：
1、利用互斥鎖，緩存失效的時候，先去獲取鎖，得到鎖再去請求數據庫，沒得到鎖則休眠一段時間再重試。
2、採用異步更新策略，無論 key 是否取到值，都直接返回。value 中維護一個緩存失效時間，緩存如果過期，異步起一個線程去讀數據庫，更新緩存。要做緩存預熱（項目啓動時加載緩存）
3、提供一個能迅速判斷請求是否有效的攔截機制，比如，利用布隆過濾器，內部維護一系列合法有效的 key 。迅速判斷請求所帶的 key 的合法性。不合法則直接返回。
緩存雪崩：緩存同一時刻大面積失效，此時又來一大波請求懟到數據庫……
解決方案：
1、給緩存加上一個隨機值，避免集體失效
2、使用互斥鎖，但是該方案吞吐量明顯下降。
3、雙緩存，緩存A 和 緩存B ，緩存A 有失效時間，緩存B 沒有失效時間，當A沒有數據時，讀取B，並異步讀取數據庫中的數據 更新 緩存A 與緩存B中的數據。
八、如何解決 Redis 的併發競爭 key 的問題
這個問題就是同時有多個子系統去 set 一個 key 。
解決方案：
1、如果不要求順序：設置分佈式鎖，搶到鎖就去 設置 key 的值。
2、有順序要求：分佈式鎖，寫入數據的時候保存一個時間戳，如果設置的時間戳大於緩存中的時間戳 就進行寫入操作，如果 寫入數據的時間戳小於緩存中的時間戳，則不進行寫入操作。