在redis的生產環境中，大量客戶端連線請求某乙個key，但都需要從db中獲取資料，來回寫資料庫，如下圖：
造成的問題：
大量的執行緒請求資料庫，造成資料庫壓力，還有就是請求會變慢。
解決辦法：
在快取層面做乙個互斥鎖，達到只有單個執行緒來更新資料的目的，但是響應還是很慢，只是db壓力減輕
還可能因為操作不當而造成執行緒死鎖問題。
（2）key永不過期策略：
熱點key不設定過期時間，但是存在乙個邏輯過期時間，邏輯過期時間儲存在key相應 的value中
若發現邏輯過期時間到期，則返回老值，非同步更新value值，存在的缺點會導致資料的短暫不一致。
——本文摘自csdn
熱點key重建優化
開發人員使用 快取 過期時間 的策略既可以加速資料讀寫，又保證資料的定期更新，這種模式基本能夠滿足絕大部分需求。但是有兩個問題如果同時出現，可能就會對應用造成致命的危害 在快取失效的瞬間，有大量執行緒來重建快取，造成後端負載過大，甚至可能會讓應用崩潰。互斥鎖 mutex key 此方法只允許乙個執行...
Redis熱點大Key的優化過程
對於電商 中，我們經常可以會遇到熱門商品的搶購或者秒殺場景以及事先經過廣告投放等措施進行定向引流，這樣就會導致某個熱賣商品在短時間內湧入大量流量。比如，雙十一期間某些熱門商品的降價 當這其中的某一件商品被數萬次點選瀏覽或者購買時，會形成乙個較大的需求量，這種情況下就會造成熱點問題。熱點key產生問題...
Redis雪崩 穿透 熱點key等優化
請求cache拿不到資料,就會去儲存層拿，會一直請求資料。導致後端打崩。1.快取層快取空值，增加過期時間 2.布隆過濾器 快取雪崩就是指快取由於某些原因,整體crash掉了，導致大量請求到達後端資料庫，從而導致資料庫崩潰。如 1.某個時間點內，系統預載入的快取週期性集中失效了 設定快取n 隨機數過期...