redis相關問題

redis理解

A.執行流程

緩存雪崩

A. 觸發緩存雪崩的兩種狀況

1. redis掛了，請求全走數據庫
2. 對緩存數據設置了相同的過時時間，致使某段時間，緩存所有同時失效，請求全走數據庫

B. 解決方案

1. 緩存的過時時間加上一個隨機值，就能夠減小緩存在同一時間過時。
2. 假如redis真的掛啦，能夠設置本地緩存+限流，避免redis掛了。假如掛了，redis持久化，重啓後自動從磁盤上加載數據，快速恢復緩存數據。

緩存穿透

A. 觸發緩存穿透狀況

1. 請求的數據在緩存大量不命中【負數】，致使請求走數據庫。

B. 解決方案

1. 由於請求參數是不合法，咱們能夠用過濾器進行攔截，不合法就不讓這個請求到數據庫層！
2. 當數據庫找不到，咱們能夠將空對象設置到緩存裏面，下次請求從緩存中獲取。【這個緩存時間能夠設短一點】

緩存擊穿

A. 觸發緩存擊穿狀況

1. 緩存在某個時間點過時的時候，剛好在這個時間點對這個Key有大量的併發請求過來，這些請求發現緩存過時通常都會從後端DB加載數據並回設到緩存，這個時候大併發的請求可能會瞬間把後端DB壓垮。

B. 解決方案

1. 使用互斥鎖。在根據key得到的value值爲空時，先鎖上，再從數據庫加載，加載完畢，釋放鎖。若其餘線程發現獲取鎖失敗，則睡眠50ms後重試。【容易形成死鎖問題】
2. 布隆過濾器，迅速判斷一個元素是否在一個集合中。【將已存在的緩存放到布隆過濾器中，當黑客訪問不存在的緩存時迅速返回避免緩存及DB掛掉。】

什麼是緩存與數據庫雙寫一致問題？

A.觸發讀寫不一致的緣由

• 數據更新時，各類狀況就會形成數據庫和緩存的數據不一致了

B.解決方案

• 先刪除緩存，在更新數據庫
  • 在高併發下表現不如意，在原子性被破壞時表現優異
• 先更新數據庫，再刪除緩存(Cache Aside Pattern設計模式)
  • 在高併發下表現優異，在原子性被破壞時表現不如意

未完待續

參考掘金大佬博客