[toc] ### 1-緩存穿透 緩存穿透說簡單點就是大量請求的 key 根本不存在于緩存中，導致請求直接到了數據庫上，根本沒有經過緩存這一層。舉個例子：某個黑客故意制造我們緩存中不存在的 key 發起大量請求，導致大量請求落到數據庫。 #### 如何避免緩存穿透？ 1. 最基本的就是首先做好參數校驗，一些不合法的參數請求直接拋出異常信息返回給客戶端。比如查詢的數據庫 id 不能小于 0、傳入的郵箱格式不對的時候直接返回錯誤消息給客戶端等等。 2. 緩存無效 key。 3. 布隆過濾器。把所有可能存在的請求的值都存放在布隆過濾器中，當用戶請求過來，先判斷用戶發來的請求的值是否存在于布隆過濾器中。不存在的話，直接返回請求參數錯誤信息給客戶端，存在的話才會走下面的流程。  ### 2-緩存雪崩 #### **1-什么是緩存雪崩?** 簡介:緩存同一時間大面積的失效，所以，后面的請求都會落到數據庫上，造成數據庫短時間內承受大量請求而崩掉。 #### **2-有哪些解決辦法?** **針對 Redis 服務不可用的情況：** 1. 采用 Redis 集群，避免單機出現問題整個緩存服務都沒辦法使用。 2. 限流，避免同時處理大量的請求。 **針對熱點緩存失效的情況：** 1. 設置不同的失效時間比如隨機設置緩存的失效時間。 2. 緩存永不失效。 ### 3-如何保證緩存和數據庫數據的一致性？ 緩存與數據庫一致性問題Cache Aside Pattern 中遇到寫請求是這樣的：更新 DB，然后直接刪除 cache 。 如果更新數據庫成功，而刪除緩存這一步失敗的情況的話，簡單說兩個解決方案： 1. **緩存失效時間變短（不推薦，治標不治本）**：我們讓緩存數據的過期時間變短，這樣的話緩存就會從數據庫中加載數據。另外，這種解決辦法對于先操作緩存后操作數據庫的場景不適用。 2. **增加 cache 更新重試機制（常用）**： 如果 cache 服務當前不可用導致緩存刪除失敗的話，我們就隔一段時間進行重試，重試次數可以自己定。如果多次重試還是失敗的話，我們可以把當前更新失敗的 key 存入隊列中，等緩存服務可用之后，再將 緩存中對應的 key 刪除即可。 ### 4-Redis 內存淘汰機制了解么? > 相關問題：MySQL 里有 2000w 數據，Redis 中只存 20w 的數據，如何保證 Redis 中的數據都是熱點數據? Redis 提供 6 種數據淘汰策略： 1. **volatile-lru（least recently used）**：從已設置過期時間的數據集（server.db\[i\].expires）中挑選最近最少使用的數據淘汰 2. **volatile-ttl**：從已設置過期時間的數據集（server.db\[i\].expires）中挑選將要過期的數據淘汰 3. **volatile-random**：從已設置過期時間的數據集（server.db\[i\].expires）中任意選擇數據淘汰 4. **allkeys-lru（least recently used）**：當內存不足以容納新寫入數據時，在鍵空間中，移除最近最少使用的 key（這個是最常用的） 5. **allkeys-random**：從數據集（server.db\[i\].dict）中任意選擇數據淘汰 6. **no-eviction**：禁止驅逐數據，也就是說當內存不足以容納新寫入數據時，新寫入操作會報錯。這個應該沒人使用吧！ 4.0 版本后增加以下兩種： 7. **volatile-lfu（least frequently used）**：從已設置過期時間的數據集(server.db\[i\].expires)中挑選最不經常使用的數據淘汰 8. **allkeys-lfu（least frequently used）**：當內存不足以容納新寫入數據時，在鍵空間中，移除最不經常使用的 key