高併發下快取穿透原理
阿新 • • 發佈:2019-02-12
請求1 Niginx 應用1 (pool)連線池不會設定太大
請求2 ----------> 應用2 --------------------------------> cache (主要是讀操作)----> DB(硬碟)
請求3 應用3
cache是減輕DB壓力。放在應用伺服器的記憶體中。
查詢是可以存在併發的,寫資料是不能有併發的。
雪崩效應
併發太快,快取。
問題:當第一個執行緒進入 查詢DB,還沒往快取插入資料,其餘的執行緒,開始進入,直接也去查DB。快取失效的情況下,也會這樣。或者是第一次進入。
解決方案: 在方法中加synchronized,重量級鎖。缺點是效率低。而且在查詢快取的時候不應該把這個放在方法級別鎖,在讀取快取時候還要排隊是不合理的。
public synchronized List<Order> query(){
而應該放在具體的程式碼塊:
synchronized(this){
List<Order> result=this.orderMapper.getAll();
ops.set(CACHE_KEY,JSON.toJSON(result),10,TimeUnit.MINUTES);
}
spring cache裡有雙重檢查鎖。
可以將程式碼模板化,解耦。快取其實是與業務無關的東西,可以將其抽出來,做成模板。用模板來。