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