緩存淘汰、緩存穿透、緩存擊穿、緩存雪崩、數據庫緩存雙寫一致性

緩存淘汰

爲何須要緩存淘汰？你須要緩存30G的數據，可是Redis自己只能使用10G的內存，那你就得作個取捨了，畢竟魚與熊掌不可兼得。爲了利益最大化確定要保留最重要的10個G。

Redis自己提供了6中緩存淘汰策略，如下屬性表示容許使用的最大內存

server.maxmemory複製代碼

當使用的內存超過限制內存時，Redis會根據配置的如下6中淘汰策略選擇數據淘汰

• volatile-lru：從已設置過時時間的數據集中挑選最近最少使用的數據淘汰

• volatile-ttl：從已設置過時時間的數據集挑選將要過時的數據淘汰

• volatile-random：從已設置過時時間的數據集中任意選擇數據淘汰

• allkeys-lru：從數據集中挑選最近最少使用的數據淘汰

• allkeys-random：從數據集中任意選擇數據淘汰

• no-enviction：內存不足時添加數據會報錯（沒人用這個吧？）

其餘相關配置：

#指定數據淘汰算法
maxmemory-policy allkeys-lru
#LRU和最小TTL算法的樣本個數
maxmemory-samples 5複製代碼

緩存穿透

大量的請求瞬時涌入系統，而這個數據在Redis中不存在，從而全部的請求都落到了數據庫上從而把數據庫打死。形成這種狀況的緣由以下：

• 系統設計不合理，緩存數據更新不及時

• 爬蟲等惡意攻擊
  

解決方案：

• 若是key在數據庫中也不存在，那麼就寫一個空值到Redis中，並設置一個過時時間，避免一直佔用內存

• 查詢緩存以前使用布隆過濾器攔截

緩存擊穿

緩存擊穿，就是常說的熱點key問題，當一個正有很是巨大的訪問量訪問的key 在失效的瞬間，大量的請求擊穿了緩存，直接落到了數據庫上，而後全部從數據獲取到數據的線程又都併發的想要把數據緩存到redis中。

解決方案：

• 使用互斥鎖，同一時刻只容許一個線程去構建緩存，其餘線程等待構建完畢後去緩存取

• 定時更新，假如緩存過時時間爲60分鐘，則單獨設置一個線程每59分鐘去負責更新緩存
  

緩存雪崩

因爲Redis是基於內存的應用，能夠很容易作到高性能、高併發從而起到保護數據庫的做用。若是緩存意外掛了、全部的請求落到了數據上就造成了緩存雪崩。

解決方案：

• 事前：使用主從複製+哨兵或者Redis集羣。Redis主從複製、Redis的哨兵機制、Redis集羣環境搭建

• 事中：本地緩存結合限流和降級。基於註解的分佈式限流組件

• 過後：開啓持久化配置，實現快速緩存的快速恢復。 Redis 的持久化機制

數據庫緩存雙寫一致性

當一個數據須要更新時由於不可能作到同時更新數據庫和緩存、那麼此時讀取數據的時候就必定會發生數據不一致問題，而數據不一致問題在金融交易領域的系統中是確定不容許的。

解決方案：

• 讀的時候，先讀緩存，緩存沒有的話，就讀數據庫，而後取出數據後放入緩存，同時返回響應。

• 更新的時候，先更新數據庫，而後再刪除緩存。

參考自公衆號：石杉的架構筆記

不得不看

1.SpringCloud系列博客彙總

2.Java多線程面試必備基礎知識彙總

3.Java集合源碼分析彙總

4.Linux經常使用命令彙總