哪一些因素 考慮使用redis，畢竟 redis 也要增加成本
1 熱點資料
2 讀的成本非常大
3 讀多寫少
4 對資料一致性要求 沒有那麼嚴格（可以出現資料與資料庫不一致）
1 秒殺場景
3 物流查詢軌跡（熱點資料 啟用的資料是被快取到redis 當中）
快取key 乙個時間點過期的時候，如果快取資料為熱點資料，那麼在過期時間點超高併發訪問這個 key，壓力就會傳導至資料庫掛掉
解決方法 使用互斥鎖， 思路是這樣，大併發過來，搶到鎖 去請求資料庫，請求成功，設定到 redis 中，其他沒有搶到的 sleep 一秒，這個時候，快取中已經有資料，這樣 其他查詢 都會獲取快取中的資料，問題解決
static lock reenlock = new reentrantlock();
public listgetdata04() throws interruptedexception finally
} else }}
return result;
}快取擊穿，是某乙個key在某乙個時間點失效，有大量併發請求過來
快取穿透，是利用自己偽造的key，這個key它在快取裡面一定不存在
最後 都去查詢資料庫
最簡單的方法，所有的key 存到 set 或者 list集合 ，存在 合法請求，不存在 非法請求
布隆過濾器 解決過濾器 問題
Redis快取穿透 快取雪崩
把redis作為快取使用已經是司空見慣，但是使用redis後也可能會碰到一系列的問題，尤其是資料量很大的時候，經典的幾個問題如下 一 快取和資料庫間資料一致性問題 分布式環境下 單機就不用說了 非常容易出現快取和資料庫間的資料一致性問題，針對這一點的話，只能說，如果你的專案對快取的要求是強一致性的，...
Redis 快取穿透 快取雪崩
目錄 1.快取穿透 如何避免？如何選擇？2 快取擊穿 如何解決 3.快取雪崩 如何解決？快取穿透 一般的快取系統，都是按照key去快取查詢，如果不存在對應的value，就應該去後端系統查詢 比如db 一些惡意的請求會故意查詢不存在的key，請求量很大，就會對後端系統造成很大的壓力，或導致資料庫異常。...
redis快取穿透 快取雪崩
什麼是快取雪崩 在同一時間內大量的快取資料失效，大量的請求都會去資料庫查詢，造成快取雪崩。解決方法 這個沒有完美的解決方法，但是可以分析使用者行為，盡量讓失效時間點均勻分布，還有就是在快取失效後，通過加鎖或者佇列來控制讀資料庫寫快取的執行緒數量，比如對某國key只允許乙個執行緒查詢資料庫和快取，其他...