跟華仔從0開始學架構-高性能緩存架構-筆記
緩存基本架構
緩存穿透：
緩存穿透指緩存沒有發揮作用，業務系統雖然查緩存，但是緩存中沒有數據，業務系統需要再次去存儲系統查詢數據。通常有以下原因導致：
1、存儲數據不存在
被訪問的數據真實不存在，則在緩存中不會存儲相應的數據。通常情況，這種場景不會太多，一旦出現異常情況，如黑客攻擊，故意大量訪問讀取不存在的數據業務，有可能將存儲系統拖垮
2、緩存數據生成消耗大量時間和資源
這種情況是存儲系統中存在數據，但生成緩存數據需要消耗大量的資源且耗時很長。如果剛好業務在訪問的時候緩存失效了，那麼緩存也沒有發揮作用，壓力落在了存儲系統上
解決方案：
1、設置默認值；
2、通常情況下，讀取頁數據緩存足夠用，需監控爬蟲爬數據的情況；
緩存雪崩：
緩存失效後，引起系統性能的急劇下降。當緩存過期被清楚後，業務系統需要重新生成緩存，因此需要訪問存儲系統，再次進行運算。這個處理步驟耗時幾十毫秒甚至上百毫秒。對於高併發的業務系統來說，幾百毫秒內可能接到幾百上千個請求。由於就的緩存已經被清楚，新的緩存還未生成，並且處理這些請求的線程都不知道其他請求正在生成緩存，所以都回去讀取數據庫，造成存儲系統壓力大。拖垮系統。
雪崩解決方案：
更新數據加鎖機制和後臺更新機制
1、更新鎖
對於緩存更新操作進行加鎖保護，保證只有一個線程可以進行更新緩存，未獲取鎖的線程要麼等待鎖釋放後讀取，要麼返回空或者默認值，根據具體業務場景給定策略；
2、後臺更新（實時更新+定時任務後臺更新+人工觸發更新）
不用業務線程來更新緩存，將緩存有效期設置爲永久，後臺線程定時更新緩存
後臺定時任務更新緩存需要考慮一種場景：：
當緩存系統內存不夠用是，會“踢掉”一些緩存釋放數據；如果業務系統讀取到這些被踢掉的緩存，又不更新緩存，因此從業務系統看到的現象就是數據像丟失了一樣，解決這種現象的方式有以下兩種：
1、後臺頻繁查詢緩存，發現數據丟失則更新緩存。讀取時間間隔不能設置太長，且用戶體驗不好；
2、當業務系統發現數據丟失後，通過消息隊列發送消息通知後臺更新緩存；
後臺更新數據需業務剛上新的時候進行緩存預熱，緩存預熱將緩存數據加載到緩存系統，而非等用戶訪問纔出發加載緩存；
經典評論：
當面試的時候被問到數據庫不是有緩存嗎？爲什麼還用緩存系統
1、mysql第一種緩存叫sql語句結果緩存，條件苛刻，程序員不可控，一般線上都會關閉這個功能；
2、mysql的第二種緩存叫innodb buffer pool，緩存的是磁盤上的分頁數據，不是sql查詢結果，sql的執行過程升不了，而memcached和redis都是緩存sql的結果，兩種緩存方式性能差很遠；
好的緩存方案從以下幾個方面入手設計：
1、什麼數據應該被緩存
2、什麼時候觸發緩存以及觸發緩存的方式是什麼
3、緩存的層次和粒度
4、緩存的命名規則和失效規則
5、緩存的監控指標和故障應對方案
6、可視化緩存數據如redis具體key內容和大小
別人踩過的坑
1、將mysql md5做key查詢結果存入緩存，結果業務系統數據不一致，要清楚緩存簡直是噩夢，最後重啓memcache；
2、緩存非銀彈，既然允許數據緩存，那麼在你是可以接受在一定時間區間內的數據不一致性的。（最終是一致的）；
3、關鍵信息不緩存，如價格、庫存等；
4、業務查詢結果序列化後放redis，下次從redis取出來時保存，原來結果類雖然實現了serializble接口，但是沒有重新serialVersionUID，導致不能返序列化；