概念
大量查詢不存在的key，短時間內對db造成巨大的查詢壓力。
解決方案：
1）布隆過濾：將存在的key置於bitmap中，訪問db之前過濾請求；
2）將不存在的key，以空值的形式儲存在cache中，減少對底層db的壓力。
3）資料庫限流
概念：
熱點key過期，在短時間內對db造成的巨大壓力。
解決思路
1）針對熱點資料，臨近過期前，提前載入資料到快取。
2）過期後，加鎖訪問；
3）過期後，佇列緩衝，請求落到db前，再次前置訪問cache
4）資料庫限流
概念
大量key採用相同的過期時間，短時間內key同時過期失效。流量對資料庫造成的巨大壓力。
解決思路
1）降低同時過期的可能，對key做隨機延長expires time;
2）控制db訪問的qps，miss後，佇列緩衝請求db，控制db消費速度；
3）資料庫限流
解決思路
1）寫操作時，限制單個value的大小，大value拆分；
2）value 壓縮
3）限流控制redis集群的qps，避免大流量造成網路阻塞；限流後的流量要麼拒絕訪問，要麼引流到db，但同時也應評估引流到db的流量對資料庫的影響。
4）網路上擴大頻寬。
問題描述
基於hash slot分片之後，某些熱點key的流量非常大。這些熱點流量落到redis的某個節點上，造成單個節點的負載高於集群中其他節點。
解決思路
1）理解問題：熱點key問題，對應到現實世界中的2/8法則，少量的資源吸引佔據了大量的焦點，導致資源在分配時產生「傾斜」。解決這個問題的核心在於解決傾斜的問題。
2）發現熱點：解決發現熱點這個問題，本質是乙個監控的問題。既然是監控，那麼被監控的物件不外乎本文一開始圖中的那幾個角色。
a.從快取本身去監控；
b.從server端的流量出口位置監控
c.從server到快取之間的網路流量監控
以上3中不同的思路，目的在於發現熱點，但這個過程並沒有結束，發現是為了解決問題。
3）平衡熱點：在這一步，已經解決熱點發現的問題，明確熱點資源在**。接下來是資源在分配的過程，這個過程包含兩種情況：
a.資源初始化時，就知道它會變成熱點資源，那麼該如何去分配它？
b.一開始並不知道它是熱點資源，如何遷移去平衡它？
當然a是b的一種特殊情況，可以不為a做特殊處理，直接走遷移的過程。
遷移是乙個具體的執行方案，我們的目標是平衡快取集群的負載。
就像本文開始提到的，這次不寫具體的執行方案和實踐過程了，只是聊一聊思路罷了。Redis快取常見問題
這是決定在使用快取時就該考慮的問題。快取的資料在資料來源發生變更時需要對快取進行更新，資料來源可能是 db，也可能是遠端服務。更新的方式可以是主動更新。資料來源是 db 時，可以在更新完 db 後就直接更新快取。當資料來源不是 db 而是其他遠端服務，可能無法及時主動感知資料變更，這種情況下一般會選...
Redis 之 快取常見問題
使用者查詢乙個資料，快取中沒有，資料庫中也沒有。這樣頻繁的訪問資料庫導致資料庫宕機。解決方法 1.請求加乙個過濾器 布隆過濾器 對所有可能的查詢的引數以hash形式儲存，在控制層先進行校驗，不符合則丟棄。這樣避免資料庫壓力。布隆過濾器 2.快取空物件 查詢為空則在快取中儲存乙個空物件。乙個key訪問...
Redis 常見問題 快取穿透
問題描述 針對 db 中不存在的資料來源，每次請求快取和資料庫都不存在 造成後果 應用伺服器壓力變大 redis 命中率大幅度降低 資料庫壓力鉅增甚至 down 掉 該現象對於 redis 無影響，奔潰的是資料庫 造成原因 頻繁訪問不存在資料 解決方案 1.空值快取 查詢資料庫返回為 null 時也...