SpringCache - 請求級別緩存的簡易實現

前言

SpringCache緩存初探中咱們研究瞭如何利用spring cache已有的幾種實現快速地知足咱們對於緩存的需求。這一次咱們有了新的更個性化的需求,想在一個請求的生命週期裏實現緩存html

需求背景是:一次數據的組裝須要調用多個方法,然而在這多個方法裏又會調用同一個IO接口,此時多浪費了一次IO的資源。首先想到的解決方案是將此次IO接口提出來調用,而後將結果做爲參數傳遞到多個方法中,可是這樣一來,每一個調用這些方法的地方都得添加額外的代碼。那麼第二個方案就是,咱們仍是分別調用,只不過將這個結果緩存起來,就像咱們以前作的那樣。java

這時候問題來了,這個數據結果咱們但願儘量實時,即便只緩存了一秒,致使在不一樣的請求裏用了同一份數據也不太好,又或者緩存效率很是低下,可能就這個請求會查幾回。看來不得不本身實現一個只保持在一次請求過程當中的緩存了。node

方案分析

要將數據緩存在一次請求週期內,那咱們先得區分是什麼環境下的請求,以分析咱們如何存儲數據。git

1. Web

Web環境下的有個絕佳的數據存儲位置 HttpServletRequestAttribute 。調用setAttributegetAttribute方法就能輕易地將咱們的數據用key-value的形式存儲在請求上,並且每次請求都自動擁有一個乾淨的Request 。想要獲取到HttpServletRequest 也很是簡單,在web請求中隨時隨地調用((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getRequest() 便可。github

2. RPC框架

我司所使用的rpc框架是基於finagle自研的,對外提供服務時使用線程池進行處理請求,即對於一次完整的請求,會使用同一個線程進行處理。首先想到的辦法仍是改動這個rpc框架服務端,增長一個能夠對外暴露的、能夠key-value存儲的請求上下文。爲了能在方便的地方獲取到這個請求上下文,得將其存儲在ThreadLocal中。 web


綜合這兩種環境考慮,咱們最好仍是實現一個統一的方案以減小維護和開發成本。Spring的RequestContextHolder.getRequestAttributes()其實也是使用ThreadLocal來實現的,那咱們能夠統一將數據存到ThreadLocal<Map<Object,Object>>,本身來維護緩存的清理spring

存儲位置有了,接下來實現SpringCache思路就比較清晰了。 windows

實現SpringCache

要實現SpringCache須要一個CacheManager,接口定義以下緩存

 
 
 
xxxxxxxxxx
 
 
 
 
public interface CacheManager {    
           Cache getCache(String name); 
           Collection<String> getCacheNames();
}
 

能夠看到其實只須要實現Cache接口就好了。 在上一篇文章中提到的SimpleCacheManager,它的Cache實現ConcurrentMapCache內部的存儲是依賴ConcurrentMap<Object, Object>。咱們的實現跟它很是相似,最主要的不一樣是咱們須要使用ThreadLocal<Map<Object, Object>> 下面給出幾處關鍵的實現,其餘部分簡單看下ConcurrentMapCache就能明白。app

1 extends  

咱們選擇不直接繼承Cache而是AbstractValueAdaptingCache,其被大多數緩存實現所繼承,它的做用主要是包裝value值以區分是沒有命中緩存仍是緩存的null值。

2 store

 
 
 
xxxxxxxxxx
 
 
 
 
private final ThreadLocal<Map<Object, Object>> store = ThreadLocal.withInitial(() -> new HashMap<>(128));
 

咱們的緩存數據存儲的地方,ThreadLocal保證緩存只會存在於這一個線程中。同時又由於只有一個線程可以訪問,咱們簡單地使用HashMap便可。 

3 get

 
 
 
xxxxxxxxxx
 
 
 
 
public <T> T get(Object key, Callable<T> valueLoader) {
    return (T) fromStoreValue(this.store.get().computeIfAbsent(key, r -> {        
        try {           
            return toStoreValue(valueLoader.call());        
        } catch (Throwable ex) {            
            throw new ValueRetrievalException(key, valueLoader, ex);     
        }  
     }));
 }   

至此咱們即將大功告成,只差一個步驟,ThreadLocal的清理:使用AOP實現便可。

 
 
 
xxxxxxxxxx
 
 
 
 
    @After("bean(server)")
    public void clearThreadCache() {
        threadCacheManager.clear();
    }
 

記得將Cache的clear方法經過咱們自定義的CacheManager暴露出來。同時也要確保切面能覆蓋每一個請求的結束。

總結與擴展

從以上一個簡單的ThreadLocalCacheManager實現,咱們對CacheManager又有了更多的理解。

同時可能也會有更多的疑問。

1. 咱們實現的這些方法,從方法名和邏輯上看起來都很簡單,那他們是如何配合使用的?跟@Cacheable上的sync又有什麼關係呢?

再回顧Spring Cache爲咱們提供的@Cacheable中的sync的註釋,它提到此功能的做用是: 同步化對被註解方法的調用,使得多個線程試圖調用此方法時,只有一個線程可以成功調用,其餘線程直接取此次調用的返回值。同時也提到這僅僅只是個hint,是否真的能成仍是要看緩存提供者。

咱們找到Spring Cache處理緩存調用的關鍵方法org.springframework.cache.interceptor.CacheAspectSupport#execute(org.springframework.cache.interceptor.CacheOperationInvoker, java.lang.reflect.Method, org.springframework.cache.interceptor.CacheAspectSupport.CacheOperationContexts) (spring-context-5.1.5.RELEASE)

通過分析,當sync = true 時, 只會調用以下代碼

 
 
 
xxxxxxxxxx
 
 
 
 
return wrapCacheValue(method, cache.get(key, () -> unwrapReturnValue(invokeOperation(invoker))))
 

即咱們上文實現的T get(Object key, Callable<T> valueLoader) 方法,回頭一看一切都清晰了。 只要咱們的this.store.get().computeIfAbsent是同步的,那這個sync = true就起做用了。 固然咱們這裏使用的HashMap不支持,可是咱們若是換成ConcurrentMap就可以實現同步化的功能。另外簡單粗暴地讓方法同步也是能夠的(RedisCache就是這樣作的)。

sync = false時,會組合Cache中其餘的方法進行緩存的處理。邏輯較爲簡單清晰,自行閱讀源碼便可。

2. 用ThreadLocal嚴格來講實現的只是線程內的緩存,萬一一次請求中有異步操做怎麼辦?

異步操做分兩種狀況,直接建立線程或者使用線程池。對於第一種狀況咱們能夠簡單地使用java.lang.InheritableThreadLocal 來替代ThreadLocal,建立的子進程會天然而然地共享父進程的InheritableThreadLocal;第二種狀況就相對比較複雜了,建議能夠參考 alibaba/transmittable-thread-local ,它實現了線程池下的ThreadLocal值傳遞功能。

相關文章
相關標籤/搜索