描述：在某些特定環境下，無論是先更新redis還是更新資料庫，兩者的資料都有可能不一致。
解決方案1 雙寫模式
解決方案2 失效模式
最終解決方案
無論是雙寫模式還是失效模式，都會導致快取的不一致問題。即多個例項同時更新會出事，怎麼辦？
如果是使用者緯度資料（訂單資料、使用者資料），這種併發機率非常小，不用考慮這個問題，快取資料加上過期時間，每隔一段時間觸發讀的主動更新即可
如果是選單，商品介紹等基礎資料，也可以去使用canal訂閱binlog的方式
快取資料+過期時間也足夠解決大部分業務對於快取的要求
通過加鎖保證併發讀寫，寫寫的時候按順序排好隊。讀讀無所謂。所以適合使用讀寫鎖。（業務不關心臟資料，允許臨時髒資料可忽略）；
總結：
canal - binlog的增量訂閱和消費元件（了解）
描述：指查詢乙個一定不存在的資料，由於快取是不命中，將去查詢資料庫，但是資料庫也無此記錄，我們沒有將這次查詢的null寫入快取，這將導致這個不存在的資料每次請求都要到儲存層去查詢，失去了快取的意義。
風險：利用不存在的資料進行攻擊，資料庫瞬時壓力增大，最終導致崩潰。
解決方案：
介面層增加校驗，如使用者鑑權校驗，或者對id做基礎校驗，id<=0的直接攔截；
從快取取不到的資料，在資料庫中也沒有取到，這時也可以將value存為null，快取有效時間可以設定短點，如30秒（設定太長會導致正常情況也沒法使用），這樣可以防止攻擊使用者反覆用同乙個id暴力攻擊。
描述：
解決方案：
設定熱點資料永遠不過期。
加分布式鎖，讓未獲取到分布式鎖的執行緒自旋操作，緩解資料庫的壓力。分布式鎖的實現方案參考：
描述：
快取雪崩是指在我們設定快取時key採用了相同的過期時間，導致快取在某一時刻同時失效，請求全部**到db，db瞬時壓力過重雪崩。
解決方案：
快取資料的過期時間設定隨機，防止同一時間大量資料過期現象發生
如果快取資料庫是分布式部署，將熱點資料均勻分布在不同搞得快取資料庫中
設定熱點資料永遠不過期
springboot下redis高併發下的快取穿透
public responsebody string getclassesbyid pathvariable id integer id return redistemplate.opsforvalue get classes 從redis中拿 這樣看單機條件下沒有問題但是高併發下還是會存在多個使用...
Redis在高併發下常見的錯誤場景
第一種，看看自己是否已經入坑了。判斷redis快取是否有資料 if jedis.exists testlocklistv 1 else system.out.println jedis.get testlocklistv 1 快取有資料直接返回快取資料 很多同學都是判斷是否存在相同的key，如果不存...
高併發下快取失效問題
快取穿透 指查詢乙個一定不存在的資料，由於快取是不命中，將去查詢資料庫，但是資料庫也無此記錄，我們沒有將這次查詢的null寫入快取，這將導致這個不存在的資料每次請求都要到儲存層去查詢，失去了快取的意義 風險 利用不存在的資料進行攻擊，資料庫瞬時壓力增大，最終導致崩潰 解決 null結果快取，並加入短...