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

前言

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

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

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

方案分析

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

1. Web

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

2. RPC框架

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

---

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

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

實現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就能明白。

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值傳遞功能。