一、緩存雪崩：
1、緩存失效時間相同導致大量緩存同時失效
緩存時間加隨機因子，不同商品設置不同失效時間
2、緩存系統故障
事前：增加緩存系統高可用方案設計，避免出現系統性故障（主從、集羣）
事故中：
增加多級緩存，在單一緩存故障時，仍有其他緩存系統可用，如之前項目中使用的三級緩存方案：內存級緩存->Memcached->Redis這樣的方案；
啓用熔斷限流機制，只允許可承受流量，避免全部流量壓垮系統（hystrix）
事後：緩存數據持久化，在故障後快速恢復緩存系統
二、緩存穿透
1、訪問不存在數據從而繞過緩存，直接讀取數據庫
數據不存在時，在緩存系統設置空值
布隆過濾器bloomfilter
三、緩存一致性
1、常規流程是：讀操作：命中緩存則返回，無緩存則讀數據庫並寫緩存；寫操作：先刪除緩存，再更新數據庫。會出現的問題是當寫操作先刪除緩存尚未更新數據庫時，讀操作未命中緩存所以讀數據庫並寫緩存，然後寫操作更新數據庫，導致緩存中數據和數據庫不一致
bug版 - 加事務解決更新緩存失敗問題：在事務中處理，先更新數據庫再刪除緩存，同時成功後才提交事務。這種方式還是保證不了一致性，當更新數據並刪除緩存後事務準備提交時，有別的請求過來查詢舊數據到緩存中仍然造成不一致。
升級bug版 - 加事務並在事務結束後再次刪緩存：那第二次刪除緩存失敗了咋整？此法還是不行
最終一致性方案：事實上很多大公司的代碼規範中都規定不要在事務中調用遠程服務，因爲在處理速度上來說，cpu > 操作系統緩存 > 內存 > 磁盤 > 網絡，網絡調用會花費大量時間，大事務會造成數據庫吞吐量降低，因此摒棄事務這種方法。既然保證不了強一致性，就保證最終一致性：先更新數據庫，成功後再刪除緩存，若刪除失敗則將失敗消息發送到MQ，MQ不斷重試讓緩存失效，使用MQ來保證緩存和數據庫的最終一致性。實際上這種方法還是有問題，當刪除緩存失敗了要向MQ發消息時，服務器宕機或重啓了導致消息沒有發送到MQ，怎麼辦？具體更深入的研究請參考以下鏈接。
參考：http://fivezh.github.io/2019/02/11/cache-things/?utm_source=tuicool&utm_medium=referral
https://blog.csdn.net/liubenlong007/article/details/79744417
實現緩存最終一致性的兩種方案
————————————————
轉自：https://blog.csdn.net/taotao12312/article/details/95449481?utm_medium=distribute.pc_relevant.none-task-blog-baidujs-2