1.讀模式，如何讀取乙個資料，應該遵循先從快取中讀取，
如果快取中沒有，再在資料庫讀取，如果在資料庫查到資料則再放到快取中，並返回
2.寫模式，如何保證快取中的資料和資料庫中的資料是一致的
可以使用雙寫模式或失效模式
指查詢乙個一定不存在的資料，由於快取是不命中的，將會查詢資料庫，但是資料庫也無此記錄，我們沒有將這次查詢的null寫入快取，這將導致這個不存在的資料每次請求要到db中去查詢，失去了快取的意義
風險：利用不存在的資料進行攻擊，資料庫瞬時壓力增大，導致崩潰
解決：null結果寫入快取，並加入短暫的過期時間
快取雪崩是指在我們設定快取時key採用了相同的過期時間，導致快取在某一時間同時失效，請求全部**到db，db瞬時壓力過重雪崩
解決：原有的失效時間基礎上加乙個隨機值，比如1-5分鐘隨機，這樣每乙個快取的過期時間重複率就會降低，就很難引發群體失效的事件
對於一些設定了過期時間的key，如果這些key可能會在某些時間點被超高併發的訪問，是一種非常熱點的資料
如果這些key在大量請求同時進來前正好失效，那麼所有對這個key的資料查詢都落到db，對快取造成擊穿
解決：加速，大量併發只讓乙個去查，其他人等待，查詢以後釋放鎖，其他人獲取到鎖，先查快取，就會有資料，不用去db
setnx佔好了鎖，業務**異常或者程式執行過程中宕機，沒有執行刪除鎖的邏輯，就會造成死鎖
解決：設定鎖的自動過期時間，即使沒有刪除，會自動刪除
setnx設定好，正要去設定過期時間，宕機，又死鎖了
解決：設定過期時間和佔位必須是原子性的，redis支援使用setnx ex命令
刪除鎖直接刪除？如果由於業務時間很長，鎖自己過期了，我們直接刪除，有可能把別人正在持有的鎖刪除了
結果：佔鎖的時候，指定鎖的名稱，每個人只能刪除自己的鎖
如果正好判斷是當前值，這個要刪除鎖的時候，鎖已經過期，別人已經設定了新的值，那麼我們刪除的是別人的鎖
解決：刪除鎖必須保證原子性，使用redis+lua指令碼完成
總結：無論是雙寫模式還是失效模式，都會導致快取的不一致問題
1、快取資料+過期時間足夠解決大部分業務對於快取的要求
2、如果是選單，商品介紹等基礎資料，也可以去使用canal訂閱binlog的方式
3、通過加讀寫鎖，寫寫的時候按順序排好對，讀讀無所謂
我們能放入快取的資料本就不應該是實時性、一致性要求超高的，所以快取資料的時候加上過期時間，保證每天拿到當前最新的資料即可
我們不應該過度設計，增加系統的複雜性
遇到實時性，一致性要求高的資料，就應該查資料庫，即使慢點
redis快取擊穿
1 快取擊穿出現的場景 我們知道redis的資料是儲存在記憶體的，而記憶體是有限的，所以一般會設定過期時間，當某個key過期了，而此時大量的併發來請求這個key，導致都去請求mysql啦，而mysql的併發連線數很低，缺少了redis這層盾牌，mysql自然扛不住，這不是架構的問題，因為之前的架構中...
Redis快取擊穿
什麼是快取擊穿 key對應的資料存在，但是在redis中key過期了，此時如有大量的併發請求過來，這些請求發現快取過期一般都會從後端伺服器載入資料並回設到快取，這個時候大併發請求可能會瞬間把後端db壓垮 如圖 出現快取穿透的特點 1.資料庫訪問壓力瞬間增加 2.redis裡面出現大量key過期 3....
Redis 熱鍵問題，快取擊穿，快取穿透，快取雪崩
1.熱鍵問題 描述 熱鍵被大量客戶端訪問，導致大量網路流量集中在一台redis伺服器上，伺服器宕機。解決方法 將熱鍵分散到不同的redis伺服器上 2.快取擊穿 描述 熱鍵被大量客戶端訪問，熱鍵如果過期，可能導致大量網路流量打到 db 伺服器上，導致資料庫伺服器宕機 解決方法 對於熱鍵，訪問之前如果...