本文原始碼：[GitHub·點這裡](https://github.com/cicadasmile/data-manage-parent) || [GitEE·點這裡](https://gitee.com/cicadasmile/data-manage-parent) # 一、快取設計 ## 1、快取的作用 在業務系統中，查詢時最容易出現效能問題的模組，查詢面對的資料量大，篩選條件複雜，所以在系統架構中引入快取層，則是非常必要的，用來快取熱點資料，達到快速響應的目的。 快取使用的基本原則： - 所有快取資料，必須設定過期時間； - 核心業務流程不通過快取層； - 快取層移除，不影響現有流程； - 系統各個端首頁資料不實時查詢； - 報表資料不實時查詢載入； - 歸檔資料(定時統計的結果資料)不實時查詢； 這裡是業務架構中常用的快取策略，快取通過犧牲強一致性來提高效能，所以並不是所有的業務都適合用快取，實際考量都會針對具體的業務，比如使用者相關維度的資料修改頻率低，會使用快取，但是使用者許可權資料(比如：免費次數)會考慮實時校驗，快取層使用的相對較少。 ## 2、快取設計模式 **Cache-Aside模式** 業務中最常用的快取層設計模式，基本實現邏輯和相關概念如下：  - 快取命中：直接查詢快取且命中，返回資料； - 快取載入：查詢快取未命中，從資料庫中查詢資料，獲取資料後並載入到快取； - 快取失效：資料更新寫到資料庫，操作成功後，讓快取失效，查詢時候再重新載入； - 快取穿透：查詢資料庫不存在的物件，也就不存在快取層的命中； - 快取擊穿：熱點key在失效的瞬間，高併發查詢這個key，擊穿快取，直接請求資料庫； - 快取雪崩：快取Key大批量到過期時間，導致資料庫壓力過大； - 命中率：快取設計的是否合理要看命中率，命中率高說明快取有效抗住了大部分請求，命中率可以通過Redis監控資訊計算，一般來說命中率在(70-80)%都算合理。 併發問題 執行讀操作未命中快取，然後查詢資料庫中取資料，資料已經查詢到還沒放入快取，同時一個更新寫操作讓快取失效，然後讀操作再把查詢到資料載入快取，導致快取的髒資料。 在遵守快取使用原則下出現該情況概率非常低，可以通過複雜的Paxos協議保證一致性，一般情況是不考量該場景的處理，如果快取管理過於複雜，會和快取層核心理念相悖。 基本描述程式碼： ```java @Service public class KeyValueServiceImpl extends Ser