在我們工作當中，經常需要考慮高可用性的問題。這裡我們稍微介紹一下快取的穿透、擊穿、雪崩。
概念按照正常的業務邏輯，假如說使用者想要查詢乙個東西，redis快取中沒有，他就會去請求資料庫。平常這樣乙個兩個還好，但是當使用者太多了，全都去訪問持久層資料庫了，這時候資料庫就很有可能宕機了。這就叫快取穿透。
解決方案
布隆過濾器
布隆過濾器是一種資料結構，對所有可能查詢的引數以hash形式儲存，在控制層先進行校驗，不符合則丟棄，從而避免了對底層儲存系統的查詢壓力﹔
快取空物件
當儲存層不命中後，即使返回的空物件也將其快取起來，同時會設定乙個過期時間，之後再訪問這個資料將會從快取中獲取，保護了後端資料來源;
但是這種方法不好的地方就很明顯了，如果空的key過多就太消耗記憶體了。
快取擊穿和快取穿透又不太一樣。
快取一般都會有相關的到期時間，當某乙個key的快取已經到期了，同時這個key當前的熱度又特別大（比如說雙十一檢視某一商品庫存），而後台為其建立新的快取又要花費一定的時間（可能有零點幾秒的樣子），在到期和建立好這段過程中，所有使用者都將直接訪問後台資料庫，很容易導致快取被擊穿。
解決方案：
設定熱點資料永遠不過期。（費記憶體）
加互斥鎖。在擊穿時，只能允許一條資料訪問資料庫，剩下的等快取。
描述：
快取雪崩是快取擊穿的公升級版。指快取中資料大批量到過期時間（雙十一設定商品到期時間為1小時，凌晨一點的時候都過期了），而查詢資料量巨大，引起資料庫壓力過大甚至down機。和快取擊穿不同的是，快取擊穿指併發查同一條資料，快取雪崩是不同資料都過期了，很多資料都查不到從而查資料庫。
解決方案：
快取資料的過期時間設定隨機，防止同一時間大量資料過期現象發生。
如果快取資料庫是分布式部署，將熱點資料均勻分布在不同搞得快取資料庫中。
設定熱點資料永遠不過期。
redis結束咯！完結撒花！
redis基礎及快取策略
我們都知道redis是基於記憶體,單執行緒機制工作，查詢速度快，效率高，一般在專案種常用來做快取，但是具體的快取策略是什麼呢？讀且成功 使用者從redis中讀取資料，如果讀取到了，直接使用 讀且失敗 如果使用者沒有從redis中讀取到資料，則去資料庫 一般是mysql 中讀取資料，然後將資料儲存到r...
快取 redis 快取穿透
哪一些因素 考慮使用redis，畢竟 redis 也要增加成本 1 熱點資料 2 讀的成本非常大 3 讀多寫少 4 對資料一致性要求 沒有那麼嚴格 可以出現資料與資料庫不一致 1 秒殺場景 3 物流查詢軌跡 熱點資料 啟用的資料是被快取到redis 當中 快取key 乙個時間點過期的時候，如果快取資...
關於Redis快取
業務場景 實時性要求不高的查詢 如果用redis做mysql的快取,key value中的值為乙個屬性 屬性值組成的hashmap，鍵的定義是個難點。鍵應該盡可能與mysql查詢的條件相關，請求呼叫的方法 controller裡分發 對應的查詢引數就可以唯一的確定查詢條件，如如 listusers....