背景
緩存數據查詢流程：simple_flow_A：Get+Cahce
- 查詢緩存是否有數據；若有直接返回；
- 如無則查詢數據庫是否有數據；如無直接返回；
- 若有則將查庫數據更新至緩存；
- 返回最新數據；
問題來源
- 高併發；
- 要保證緩存機制能在高併發的情況下照常執行；
- 異常請求對緩存機制的影響；
- 異常：業務範圍之外的請求參數；
- 需要過濾或處理異常請求，防止跳過緩存，使緩存機制失效；
問題場景
執行上述流程時：simple_flow_A
- 緩存無數據（緩存數據過期or緩存數據初始化）
- 數據庫無數據
核心問題點
-
緩存穿透
- case_A：利用緩存中實際不存在的key惡意大量請求，將請求壓力直接附加到數據庫層；
- 核心：問題的根本是不存在的key是不會存在放緩存中的，所以緩存機制針在此場景下並不生效，需要規避此場景；
- solution_A：思路：1：解決value爲空時不存放緩存的機制；2：在工具層匹配是否爲指定返回結果，不影響調用方or調用方法；
- solution_A：細節：1：將值不存在的key也通過指定value存在放緩存中；2：獲取時判斷值是否數據指定value，如果是，判定爲空；
- solution_A：影響：1：一定要保證存指定value（邏輯空值）的key在有實際真正value時能順利更新緩存；
2：並且此類過期時間應小於正常緩存；否則大量惡意請求每個Key都不同，則會產生大量的無效性緩存存儲量； - solution_B：思路：API算法過濾參數，快速失敗返回；TODO；
-
緩存擊穿（又稱：緩存併發）
- case_A：高併發場景下，執行simple_flow_A時：當緩存失效或者不存在時（常規情況下存在的需要請求數據庫的環節），會有大量請求並行請求數據庫；
- case_B：假如在緩存初始化的階段（第一次訪問數據時），如果是高併發，如果按照simple_flow_A；這其中涉及操作原子性的問題，
因爲涉及了兩個環節：查庫&set緩存；兩個並行的現成如果出現了A+C：Update+BBA的情況（並行的時序性無法保證並且不同線程直接出現了數據變更，
導致set緩存的時候出現了兩個數據源，並且線程間執行先後順序無法保證），即會數據覆蓋，最終數據不一致（髒數據）的情況； - 核心：需要互斥性&原子性
- solution_A：思路：code的方式將查庫&set緩存包裝成爲原子操作；
- solution_A：細節：引入分佈式事務鎖來實現互斥功能，實現原子操作；鎖的內外針對緩存的值進行DoubleCheck，實現原子操作的前提下也保證不會有冗餘操作影響緩存機制；
特殊的：引入鎖是爲了保證同一時間節點上併發操作的問題，不應該影響不在同一時間節點上的請求處理，上述細節中有個漏洞，就是如果進入鎖查庫的結果是
空的時候我們需要採用解決“緩存穿透”的基本方案設置指定value進緩存，否則後續請求也會在緩存和數據庫之間反覆查詢，並且中間還有鎖的介入； - solution_A：影響：高併發情況下當鎖定鎖之後後續現成會出現短暫的等待；
-
緩存雪崩
- case：與緩存穿透和緩存擊穿不同的原因是單點數據緩存問題導致的不同，緩存雪崩是因爲站點內大量不同類型數據的緩存同時到期，導致數據庫總符合陡增產生的影響；
- 核心：努力讓過期時間段均勻分佈；
- solution_A：加鎖排隊；即上述“緩存擊穿”的solution_A，即使出現大量不同數據類型導致的廣義的擊穿，單每種類型數據的數據庫壓力是可控唯一的；
- solution_B：隨機過期時間；如果不影響功能，可以將過期時間在指定範圍內做隨機設置；
- solution_C：永不過期處理（物理or邏輯上永不過期處理）；
- solution_D：特殊情況可以考慮長短期緩存並行使用；
-
熱點數據
- case：如果存在類似需要緩存的數據類型，同類型下不同數據訪問的頻率是不同的，並且訪問規律存在一定的變化性；
- solution_A：設置緩存定長列表，並且通過熱點規則進行排序，定期清理尾部元素實現自更新；
結論
- 對於緩存穿透，緩存併發，緩存雪崩三種緩存常見問題場景，我們需要做到的基本工作：
- 存放空值&加鎖排隊，滿足緩存穿透和緩存併發的需求，並且這兩種方案組合一定程度上能處理雪崩的情況；
- 雪崩問題如果優先級較高，還可以並行使用永不過期（物理or邏輯）策略；