問題:
快取穿透的概念很簡單，使用者想要查詢乙個資料，發現redis記憶體資料庫沒有，也就是快取沒有命中，於是向 持久層資料庫查詢。發現也沒有，於是本次查詢失敗。當使用者很多的時候，快取都沒有命中，於是都去請求了 持久層資料庫。這會給持久層資料庫造成很大的壓力，這時候就相當於出現了快取穿透。 這裡需要注意和快取擊穿的區別，快取擊穿，是指乙個key非常熱點，在不停的扛著大併發，大併發集中對這 乙個點進行訪問，當這個key在失效的瞬間，持續的大併發就穿破快取，直接請求資料庫，就像在乙個屏障上 鑿開了乙個洞。 為了避免快取穿透其實有很多種解決方案。下面介紹幾種。
### 1.1白名單策略
(1)將id放在bitmaps中，id作為bitmaps的offset (2)布隆過濾器 首先也是對所有可能查詢的引數以hash形式儲存，當使用者想要查詢時，使用布隆過濾器，發現不在集合中，就直接丟棄，不再對持久層進行查詢。 **思考:這種方式是否會存在redis和永續性資料庫資料不一致的情況。** ### 1.2快取空物件
當儲存層不民眾後，即使返回空物件也將其快取起來，同時設定乙個過期時間，之後訪問這個資料會直接從快取中獲取，保護了後端資料來源；但是需要注意設定過期時間
但是這種方法會存在乙個問題:即使對空值設定了過期時間，還是會在快取層和儲存層的資料會有一段時間視窗可能不一致，這對於需要保持一致性的業務會有一定得影響
###1.3實施監控
監控命中率(業務正常範圍時候,通過會有乙個波動值),根據不同的情況設定黑名單
## 2.快取雪崩
redis高可用
這個思想含義是，既然redis可能掛掉，那麼增設幾台redis，這樣一台掛掉之後其他的還可以繼續工作，也就是搭建集群。
(2)限流降級 這個解決方案的思想是，在快取失效後通過加鎖或者佇列來控制讀資料庫寫快取的執行緒數量。比如對於某個key只允許乙個執行緒查詢資料和寫快取。其他執行緒在這個過程等待。
(3)資料預熱 在即將發生大併發訪問前手動觸發載入快取不同的key，設定不同的過期時間，讓快取失效的時間點盡量均勻。
快取擊穿是在高併發的條件下讀取快取資料，多使用者同時請求乙個快取資料，如果快取中沒有這條資料，那麼這些使用者又同時去資料庫中查詢這條資料，浪費了系統資源，有悖於快取資料的初衷，嚴重的話可能會造成伺服器宕機的風險
(1)使用同步鎖，修飾在獲取快取的方法裡面，保證在多使用者同時請求的條件下，只有第乙個進入的執行緒去判斷是否要查詢資料庫並存入快取，其他執行緒只需要在第乙個執行緒結束後，從快取中讀取資料即可，無需再去訪問永續性資料庫。
上面是對快取穿透的再次優化，加入執行緒同步鎖以及雙重鎖檢查。
雙重鎖檢查:
1.避免當快取資料沒有失效時，其他執行緒排隊等待。
2.當第乙個執行緒從資料庫中獲取到資料並存入快取中時，其他執行緒直接從快取中獲取資料即可
(2)不再設定快取時間，由後台建立定時任務去維護這部分快取資料。這種方法請求時直接從快取中獲取資料，無需再判斷是否從資料庫中獲取，定時任務也可在請求較少的時間段分批更新快取資料。 當然**量，**複雜度增大，分批更新代表需要多個定時任務去維護快取資料，同時更新有可能會造成快取雪崩的情況。 ##4.資料預熱 快取預熱: 提前將相關快取資料直接載入到快取系統，避免使用者在請求的時候，先查詢資料庫，然後再將資料快取的問題
問題:
1.主從之間資料吞吐量大
2.資料同步操作頻度高
解決方案 1.統計訪問頻度較高的熱點資料，比如直接寫個快取重新整理頁面，上線時手動操作 2.資料量不大，可以再專案啟動時自動進行載入 3.定期重新整理快取
Redis快取擊穿，傳統，雪崩
redis的三種常見的使用問題 快取穿透 快取的資料db中不存在，快取中也不存在。但是高頻次的無結果查詢全部落在db上，從而影響db效能 快取擊穿 當熱點資料發生過期時。高頻次的訪問全部落在db上，從而影響db效能 快取雪崩 和快取穿透相似。很多的熱點資料同一時間過期。1.快取空值 針對空結果查詢進...
Redis穿透 擊穿和雪崩
概念 key對應的資料在資料來源並不存在，每次針對此key的請求從快取獲取不到，請求都會到資料來源，從而可能壓垮資料來源。比如用乙個不存在的使用者id獲取使用者資訊，不論快取還是資料庫都沒有，若黑客利用此漏洞進行攻擊可能壓垮資料庫。解決方案 乙個一定不存在快取及查詢不到的資料，由於快取是不命中時被動...
Redis的擊穿和雪崩
有時候被問到redis 擊穿和雪崩，啥？瞬間一臉懵逼。今天看到一篇講解的很透徹 細緻的博文，看了受益良多，特此也分享給各位碼農盆友。主要講的問題 在乙個面臨高併發系統中，快取幾乎成了每個架構師應對高流量的首衝解決方案，但是，乙個好的快取系統，除了和資料庫一致性問題之外，還存在著其他問題，給整體的系統...