spring緩存更新

① springboot開啟Cache緩存

一、Cache介面下Spring提供了各種xxxCache的實現；如RedisCache，EhCacheCache ,ConcurrentMapCache等；

每次調用需要緩存功能的方法時，Spring會檢查檢查指定參數的指定的目標方法是否已經被調用過；如果有就直接從緩存中獲取方法調用後的結果，如果沒有就調用方法並緩存結果後返回給用戶。下次調用直接從緩存中獲取。

使用Spring緩存抽象時我們需要關注以下兩點；

1、確定方法需要被緩存以及他們的緩存策略

2、從緩存中讀取之前緩存存儲的數據
二、注意：

1.當我們要使用root對象的屬性作為key時我們也可以將「#root」省略，因為Spring默認使用的就是root對象的屬性。 如

@Cacheable(key = "targetClass + methodName +#p0")

2.使用方法參數時我們可以直接使用「#參數名」或者「#p參數index」。 如：

@Cacheable(value="users", key="#id")

@Cacheable(value="users", key="#p0")
三、使用
1.依賴

2.啟動類註解@EnableCaching開啟緩存

3.緩存@Cacheable
@Cacheable註解會先查詢是否已經有緩存，有會使用緩存，沒有則會執行方法並緩存。

參考 https://www.cnblogs.com/yueshutong/p/9381540.html

② spring自帶緩存機制怎麼弄

此緩存方法既適用於層，也適用於service層。

spring配置文件配置：<!--緩存配置-->
<!--啟用緩存註解功能-->
<cache:annotation-drivencache-manager="cacheManager"/>
<!--spring自己的基於java.util.concurrent.ConcurrentHashMap實現的緩存管理器（該功能是從Spring3.1開始提供）-->
<beanid="cacheManager"class="org.springframework.cache.support.SimpleCacheManager">
<propertyname="caches">
<set>
<!--此處類concurrentMapCacheFactoryBean的作用是
-->
<beanname="myCache"class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean"/>
</set>
</property>
</bean>service層示例如下：@Transactional(readOnly=true)
@Cacheable(value="myCache")
publicJsonObjectgetWFK(JsonObjectparams){
OneObob=newOneOb();
try{
List<Map<String,Object>>map=LawAssistantMapper.getWFK();
ob.setOb(map);
}catch(Exceptione){
e.printStackTrace();
ob.setCode(500);
ob.setMsg("伺服器錯誤！！！");
returnnewJsonObject(Json.encode(ob));
}
ob.setCode(200);
ob.setMsg("ok");
logger.debug(Json.encode(ob));
returnnewJsonObject(Json.encode(ob));

}

由於使用的是spring自帶的緩存類，所以，僅僅需要兩步：1.在spring配置文件中聲明，2.在service層，方法代碼前增加註解，即可。


缺點：
spring自帶的緩存功能，實質上是通過java類來保存緩存的數據，這樣會佔用一定的內存消耗，並發率越高，對內存的壓力越大。
碼民直接使用的緩存類：org.springframework.cache.support.SimpleCacheManager，org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean

③ spring mvc緩存問題，我做了一個項目，修改信息後刷新了session，但是

這個和spring的緩存沒關系，問題在於頁面的跳轉。
嘗試著在頁面的跳轉過程中加一個跳轉頁，就可以了。禁用返回。
比如 B修改，提交,跳轉回B，那麼你肯定看不到效果的。必須跳轉到C，然後C跳轉回B才行。可以做自動跳轉。跳轉時間設為10ms，別人看不到的。

④ 如何更新緩存數據 SpringSecurity2

如果需要修改緩存，那麼可以修改這里的值，默認用的是ehcache:

⑤ spring一級緩存和二級緩存的區別是什麼

一級緩存：
就是Session級別的緩存。一個Session做了一個查詢操作，它會把這個操作的結果放在一級緩存中。
如果短時間內這個session（一定要同一個session）又做了同一個操作，那麼hibernate直接從一級緩存中拿，而不會再去連資料庫，取數據。
它是內置的事務范圍的緩存，不能被卸載。
二級緩存：
就是SessionFactory級別的緩存。顧名思義，就是查詢的時候會把查詢結果緩存到二級緩存中。
如果同一個sessionFactory創建的某個session執行了相同的操作，hibernate就會從二級緩存中拿結果，而不會再去連接資料庫。
這是可選的插件式的緩存，在默認情況下，SessionFactory不會啟用這個插件。
可以在每個類或每個集合的粒度上配置。緩存適配器用於把具體的緩存實現軟體與Hibernate集成。
嚴格意義上說，SessionFactory緩存分為兩類：內置緩存和外置緩存。我們通常意義上說的二級緩存是指外置緩存。
內置緩存與session級別緩存實現方式相似。前者是SessionFactory對象的一些集合屬性包含的數據，後者是指Session的一些集合屬性包含的數據
SessionFactory的內置緩存中存放了映射元數據和預定義SQL語句。
映射元數據是映射文件中數據的拷貝；
而預定義SQL語句是在Hibernate初始化階段根據映射元數據推導出來。
SessionFactory的內置緩存是只讀的，應用程序不能修改緩存中的映射元數據和預定義SQL語句，因此SessionFactory不需要進行內置緩存與映射文件的同步。
Hibernate的這兩級緩存都位於持久化層，存放的都是資料庫數據的拷貝。
緩存的兩個特性：
緩存的范圍
緩存的並發訪問策略
1、緩存的范圍
決定了緩存的生命周期以及可以被誰訪問。緩存的范圍分為三類。
事務范圍
進程范圍
集群范圍
註：
對大多數應用來說，應該慎重地考慮是否需要使用集群范圍的緩存，因為訪問的速度不一定會比直接訪問資料庫數據的速度快多少。
事務范圍的緩存是持久化層的第一級緩存，通常它是必需的；進程范圍或集群范圍的緩存是持久化層的第二級緩存，通常是可選的。
2、緩存的並發訪問策略
當多個並發的事務同時訪問持久化層的緩存的相同數據時，會引起並發問題，必須採用必要的事務隔離措施。
在進程范圍或集群范圍的緩存，即第二級緩存，會出現並發問題。
因此可以設定以下四種類型的並發訪問策略，每一種策略對應一種事務隔離級別。
事務型並發訪問策略是事務隔離級別最高，只讀型的隔離級別最低。事務隔離級別越高，並發性能就越低。
A 事務型：僅僅在受管理環境中適用。它提供了Repeatable Read事務隔離級別。
對於經常被讀但很少修改的數據，可以採用這種隔離類型，因為它可以防止臟讀和不可重復讀這類的並發問題。
B 讀寫型：提供了Read Committed事務隔離級別。僅僅在非集群的環境中適用。
對於經常被讀但很少修改的數據，可以採用這種隔離類型，因為它可以防止臟讀這類的並發問題。
C 非嚴格讀寫型：不保證緩存與資料庫中數據的一致性。
如果存在兩個事務同時訪問緩存中相同數據的可能，必須為該數據配置一個很短的數據過期時間，從而盡量避免臟讀。
對於極少被修改，並且允許偶爾臟讀的數據，可以採用這種並發訪問策略。
D 只讀型：對於從來不會修改的數據，如參考數據，可以使用這種並發訪問策略。
什麼樣的數據適合存放到第二級緩存中？
1、很少被修改的數據
2、不是很重要的數據，允許出現偶爾並發的數據
3、不會被並發訪問的數據
4、參考數據
不適合存放到第二級緩存的數據？
1、經常被修改的數據
2、財務數據，絕對不允許出現並發
3、與其他應用共享的數據。
Hibernate的二級緩存策略的一般過程如下：
1) 條件查詢的時候，總是發出一條select * from table_name where …. （選擇所有欄位）這樣的SQL語句查詢資料庫，一次獲得所有的數據對象。
2) 把獲得的所有數據對象根據ID放入到第二級緩存中。
3) 當Hibernate根據ID訪問數據對象的時候，首先從Session一級緩存中查；查不到，如果配置了二級緩存，那麼從二級緩存中查；查不到，再查詢資料庫，把結果按照ID放入到緩存。
4) 刪除、更新、增加數據的時候，同時更新緩存。
註：
Hibernate的二級緩存策略，是針對於ID查詢的緩存策略，對於條件查詢則毫無作用。為此，Hibernate提供了針對條件查詢的Query緩存。
Query緩存策略的過程如下：
1) Hibernate首先根據這些信息組成一個Query Key，Query Key包括條件查詢的請求一般信息：SQL, SQL需要的參數，記錄范圍（起始位置rowStart，最大記錄個數maxRows)，等。
2) Hibernate根據這個Query Key到Query緩存中查找對應的結果列表。如果存在，那麼返回這個結果列表；如果不存在，查詢資料庫，獲取結果列表，把整個結果列表根據Query Key放入到Query緩存中。
3) Query Key中的SQL涉及到一些表名，如果這些表的任何數據發生修改、刪除、增加等操作，這些相關的Query Key都要從緩存中清空。

⑥ 如何在spring中使用緩存

在Spring緩存機制中，包括了兩個方面的緩存操作：1.緩存某個方法返回的結果；2.在某個方法執行前或後清空緩存。
Spring僅僅是提供了對緩存的支持，但它並沒有任何的緩存功能的實現，spring使用的是第三方的緩存框架來實現緩存的功能。其中，spring對EHCache提供了很好的支持。
參考博客：http://www.cnblogs.com/fysola/p/6378400.html

⑦ Spring本地緩存的使用方法

我們現在在用的Spring Cache，可以直接看Spring Boot提供的緩存枚舉類，有如下這些：

EhCache：一個純Java的進程內緩存框架，所以也是基於本地緩存的。(注意EhCache2.x和EhCache3.x相互不兼容)。
Redis：分布式緩存，只有Client-Server(CS)模式，Java一般使用Jedis/Luttuce來操縱。
Hazelcast：基於內存的數據網格。雖然它基於內存，但是分布式應用程序可以使用Hazelcast進行分布式緩存、同步、集群、處理、發布/訂閱消息等。
Guava：它是Google Guava工具包中的一個非常方便易用的本地化緩存實現，基於LRU（最近最少使用）演算法實現，支持多種緩存過期策略。在Spring5.X以後的版本已經將他標記為過期了。
Caffeine：是使用Java8對Guava緩存的重寫版本，在Spring5中將取代了Guava，支持多種緩存過期策略。
SIMPLE：使用ConcurrentMapCacheManager，因為不支持緩存過期時間，所以做本地緩存基本不考慮該方式。

關於分布式緩存，我們需要後面會專門討論Redis的用法，這里只看本地緩存。性能從高到低，依次是Caffeine，Guava，ConcurrentMapCacheManager，其中Caffeine在讀寫上都快了Guava近一倍。

這里我們只討論在Spring Boot裡面怎麼整合使用Caffeine和EhCache。

主要有以下幾個步驟：

1)加依賴包：

2)配置緩存：
這里有兩種方法，通過文件配置或者在配置類裡面配置，先看一下文件配置，我們可以寫一個properties文件，內容像這樣：

然後還要在主類中加上@EnableCaching註解：

另外一種更靈活的方法是在配置類中配置：

應用類：

測試類：

導入依賴包，分為2.x版本和3.x版本。
其中2.x版本做如下導入：

3.x版本做如下導入：

導包完成後，我們使用JCacheManagerFactoryBean + ehcache.xml的方式配置：

參考資料：

https://blog.csdn.net/f641385712/article/details/94982916

http://www.360doc.com/content/17/1017/20/16915_695800687.shtml

⑧ 軟體更新丨Spring Cloud Alibaba發布第二個版本，Spring發來賀電

還是熟悉的面孔，還是熟悉的味道，不同的是，這次的 配方升級 了。

時隔 51天，Spencer Gibb再次在Spring官網的博客頁面宣布：Spring Cloud Alibaba發布了其開源後的 第二個版本0.2.1 ，隨後，Spring Cloud 官方Twitter也轉發了此消息。聖誕節的前一周，Josh Long向他的老朋友許曉斌發來賀電：

視頻地址：https://spring.io/blog/2018/12/26/spring-tips-bootiful-alibaba

一、新版本概要

Spring Cloud Alibaba RocketMQ

Spring Cloud Alibaba SchelerX

Spring Cloud Alibaba Nacos Config

Spring Cloud Alibaba Nacos Discovery

Spring Cloud Alibaba Sentinel

二、新版本背後的思考

Spring Cloud Alibaba Nacos Discovery

Nacos Discovery 在這個版本最大的更新就是支持在初始化的時候不使用本地文件緩存，目前初始化的時候已經默認不使用本地文件緩存。

為什麼要有緩存？首先我們來了解一下本地緩存的概念，為什麼需要這個本地緩存？

我們都知道，服務注冊與發現應該只是服務調用中的輔助性的一個環節，而不是一個關鍵的環節。一個良好的服務注冊與發現的設計，需要保證以下兩點。

要實現以上兩點，緩存就不可或缺，而為了適應不同的場景，緩存又可以分成內存緩存和本地文件緩存，他們的概念和適用場景如下。

內存中的緩存

將服務提供者列表維護在內存中，每次調用時直接從內存中的列表獲取節點即可。內存緩存通過定時任務更新，或者在收到服務注冊中心的推送之後再更新。確保了即使在服務注冊中心宕機的情況下，也能保證服務仍能正常調用。

本地文件緩存

將上述提到的內存中的緩存，保留在本地的某個文件中，這樣在調用服務注冊中心失敗的時候，可以從本機的文件緩存中獲取服務提供者列表。這樣就保證了在服務注冊中心宕機的情況下，應用在重啟後也能找到服務提供者。

為什麼要關閉

有了以上背景知識後，讀者可能會有疑問，既然緩存這么好，你們為什麼默認要把它置為默認關閉呢？

我們在發布出第一個版本之後，很多用戶反饋，為什麼我服務下線之後還是有節點，仍舊可以被查詢到呢？這樣導致我這個監控數據完全不準，你們這個有 bug，完全不對。其實這是阿里巴巴在多年業務積累的經驗，對於服務發現來說，一個即使是已經過時的節點，也比沒有任何數據好。而且還有可能其實這個服務只是和服務注冊中心失去了心跳，但是應用本身是正常的。

當然，這也暴露了我們設計中存在的一些問題，沒有把服務發現本身，以及緩存的分層給做好，兩者糅合在一塊。所以在這一次的版本更新中我們還是選擇適配開源標准，默認關閉了本地文件緩存，留了一個開關給用戶自由選擇。

Spring Cloud Alibaba Nacos Config

Nacos Config 在這個版本中有兩個大的特性，支持了「共享配置」，修正了動態刷新的語義和行為。

共享配置的實現

在第一個版本還沒發布到時候，社區里對配置管理中心的討論就沒停止過，其中聽到最多的反饋應該就是支持多個應用共享一個配置。我們也通過 github issue 的方式，徵集了很多意見，詳情見 #12 , #141。

後來我們將這個模型抽象了一下，認清這些需求本質是一個應用可以從多個 DataID 和 GroupID 組合中獲取配置，並且這些配置還可以單獨指定優先順序和是否動態刷新。

最後我們推薦了這種使用方式，既保證了使用場景的靈活性，又保證了業務語義的明確性。更多詳情可以參考 WIKI。

注意 data-id 的值必須帶文件擴展名，文件擴展名支持 properties、yaml 和 yml。通過這種自定義擴展的配置項，既可以支持一個應用從多個配置項中獲取數據，也解決多個應用間配置共享的問題。

頭腦風暴，@fudali 同學還提出了更加靈活的一種方式 #161，就是可以通過一個配置項來配置所有的 DataID 的信息，然後可以通過修改這個配置項，可以修改整體配置項的邏輯。

這是一個非常好的想法，只不過這一期中我們沒有實現，原因是這種方式太靈活了。我們認為配置管理其實是一件很嚴肅的事情，太靈活導致生產中變更比較不可控。

雖然目前的邏輯也可以支持這種用法，但是我們並沒有把這種模式當做推薦模式，後續如果社區有更多的反饋認為這是一個強烈的需求，歡迎提 PR。

動態刷新的修正

簡單好用、實時可監控的動態刷新也許是 Nacos Config 相對於其他開源中間件相比最核心的優勢了，不同於 Spring Cloud Config Server 必須使用 Spring Cloud Bus 才能實現動態刷新，Nacos Config 無需依賴其他任何中間件就可以實現實時動態刷新，而且推送成功與否和刷新 歷史 還支持實時查詢。

但是我們發現在第一個版本中的實現發現兩個問題：

在這個版本中，我們修復了這兩個問題。

首先，動態刷新不再是直接去調用 ContextRefresher.refresh() 方法，而是 publish 了一個 RefreshEvent，讓 spring-cloud-commons 里的 RefreshEventListener 去觸發這個 ContextRefresher.refresh() 方法。

其次，我們修正了動態刷新的語義後，這一次是真正做到了，只有 refresh 屬性為 true 的配置項，才會在運行的過程中變更為新的值，refresh 屬性為 false 的配置項再也不用擔心應用在運行的過程中發生莫名其妙的變更了。

更深入一點，在上個月 SpringOne Tour 中，我們和 Spring Cloud 的創始人 Spencer 聊到 Spring Cloud 的 Context.refresh() 成本太高，會刷新整個 Spring Context。他反復強調了兩次 Context.refresh() 只對 @RefreshScope 和 @ConfigurationProperties 有效，成本一點也不高。

之前我們接收到很多社區的反饋都是 Nacos Config 動態刷新支不支持 xxxx，支不支持 xxxx。之前我們都是回答只支持 @RefreshScope 和 @ConfigurationProperties ，如果他內置沒有支持，那就得自己加上相應的註解。

今天我們可以很愉快地回復，他監聽了 RefreshEvent 也能直接支持。而且如果添加 @RefreshScope 和 @ConfigurationProperties 都不滿足你的需求時，可以通過實現自己的 RefreshEventListener 更多高級的玩法。

Spring Cloud Alibaba Sentinel

Sentinel 在這個版本中有三個大的特性：全面支持 FeignClient ，完善了 RestTemplate 的支持，添加了熱點限流、集群限流。

FeignClient 集成 Sentinel

其實在這之前，Sentinel 支持 FeignClient 已經設計了很久了，之前我們的想法做一個兼容性較強的方案，支持 Sentinel 和 Hystrix 在 FeignClient 中同時使用，盡量做到對原有應用的侵入性做到最小。

這個方案我們也思考調研了很久，但是實現難度確實比較大，需要修改 FeignClient 的代碼才能實現兩者共存。正好前段時間在 Spring Cloud 屆最大的新聞就是 Hystrix 宣布不在維護了，於是我們就換了一個思路，直接使用 Sentinel 替代 Hystrix，不再去追求支持兩者共存。

我們實現了自己的 Feign.Builder，在構建的 FeignClient 執行調用的過程中，通過 SentinelInvocationHandler 完成 Sentinel 的流量統計和保護的動作。如果想使用 Sentinel 為 FeignClient 限流降級，首先需要引入 sentinel-starter 的依賴，然後打開 Sentinel 限流降級的開關 feign.sentinel.enabled=true ，就完成了 Sentinel 的接入。如果需要使用更加定製化的功能，則需要在 @FeignClient 添加 fallback 和 configuration 這些屬性的配置。

注意 @FeignClient 註解中的所有屬性，Sentinel 都做了兼容。

RestTemplate 集成 Sentinel

Spring Cloud Alibaba Sentinel 支持對 RestTemplate 的服務調用使用 Sentinel 進行保護，補全了 Hystrix 這一塊的空白。接入的方式也不復雜，在構造 RestTemplate bean 的時候需要加上 @SentinelRestTemplate 註解，然後在控制台配置相應的規則即可。

在觸發了限流降級時，默認的處理方式是返回 RestTemplate request block by sentinel 信息。

RestTemplate 的限流降級 ？Sentinel 也承包了！

熱點參數限流和集群限流

首先解釋一下什麼是熱點參數限流和集群限流。

熱點參數限流會統計傳入參數中的熱點參數，並根據配置的限流閾值與模式，對包含熱點參數的資源調用進行限流。熱點參數限流可以看做是一種特殊的流量控制，僅對包含熱點參數的資源調用生效。

集群流控主要解決的問題是：當我們需要控制整個集群流量總量，但是單機流量可能會不均勻，如果是單機維度去限制的話會無法精確地限制總體流量，因此需要引入集群維度的流量控制。

Sentinel v1.4.0 的 新功能 ，也能第一時間愉快地在 Spring Cloud Alibaba 上使用了。

三、新組件

Spring Cloud Alibaba RocketMQ

Spring Cloud Stream 是一個用於構建基於消息的微服務應用框架，它基於 SpringBoot 來創建具有生產級別的單機 Spring 應用，並且使用 Spring Integration 與 Broker 進行連接。它提供了消息中間件的統一抽象，推出了 publish-subscribe、consumer groups、partition 這些統一的概念。

RocketMQ 是一款開源的分布式消息系統，基於高可用分布式集群技術，提供低延時的、高可靠的消息發布與訂閱服務。具有以下特點：能夠保證嚴格的消息順序、提供豐富的消息拉取模式、高效的訂閱者水平擴展能力、實時的消息訂閱機制、億級消息堆積能力。

在這次的 Spring Cloud Stream Binder RocketMQ 的實現中，我們適配了 Spring Cloud Stream 對於 message 抽象的 API，支持了 RocketMQ 的事務消息。消息訂閱時支持以 tags、SQL 表達式過濾消息，同時還支持順序、並發、延遲以及廣播消費模式。

Spring Cloud Alibaba SchelerX

SchelerX 是阿里中間件團隊開發的一款分布式任務調度產品，提供秒級、精準、高可靠、高可用的定時（基於 Cron 表達式）任務調度服務，同時提供分布式的任務執行模型，如網格任務，網格任務支持海量子任務均勻分配到所有 Worker（schelerx-client）上執行。

簡單易用的輕量分布式任務調度

您不需要關心調度邏輯，只需要在在 JobProcessor 介面的實現中添加業務邏輯即可，然後在自主運維控制台配置上一個 Job 即可完成使用。

高可用的分布式任務

不管是 SchelerX 服務端還是客戶端都是分布式架構設計，任務可以在多台客戶端機器里的任何一台機器執行，如果客戶端出現宕機的情況，服務端會自動選擇正常運行的客戶端去執行 Job，每個 Job 在服務端的不同機器均有備份，SchelerX 服務端任意宕掉部分機器仍能保證 Job 正常調度。

友好的用戶界面

SchelerX 提供了非常友好的頁面方便您創建、刪除或修改 Job，提供了立即觸發執行一次的功能，方便您測試以及關鍵時刻手動立即執行一次，還提供了 歷史 執行記錄查詢的功能，您可以看到任何一個 Job 過去 100 次的 歷史 執行記錄。

功能強大

提供了秒級、精準的定時任務調度服務，且提供了豐富的任務執行模型，包括單機執行，廣播執行，以及子任務的分布式執行。

四、What's Next?

Spring Cloud Alibaba Cloud SLS 針對日誌類數據的一站式服務，在阿⾥巴巴集團經歷大量大數據場景錘煉⽽成。您⽆需開發就能快捷地完成日誌數據採集、消費、投遞以及查詢分析等功能，提升運維、運營效率，建立 DT 時代海量日誌處理能力。

Spring Cloud Alibaba Dubbo Dubbo 是一款流行的開源 RPC 框架，我們會把 Dubbo 整合到 Spring Cloud Alibaba 中，讓大家在開發 Dubbo 時也能享受到 Spring Cloud 帶來的便利。

致謝

Spring Cloud Alibaba 從開源建設以來，受到了很多社區同學的關注。社區的每一個 issue ，每一個 PR，都是對整個項目的幫助，都在為建設更好用的 Spring Cloud 添磚加瓦。

↓↓↓

⑨ SpringCache優化、緩存一致性、多級緩存

先記錄一些綱要

1、SpringCache是寫庫之後更新的策略，對緩存一致性的不太友好

2、繼承RedisCacheManager重寫createRedisCache，繼承RedisCache重寫put

3、緩存一致性有兩個方案，一個是先寫庫再刪除緩存、第二個是先刪除緩存再寫庫。

先寫庫再刪除緩存配合超時時間一般沒啥問題，極端的情況遇到緩存失效，線程讀庫和加緩存之間，完成了一次寫庫和刪緩存的操作，導致加的緩存是舊的。總結就是讀中加入了一次寫。A讀庫 B寫庫 B刪緩存 A加緩存。

先刪緩存再寫庫的話，是寫中加入了一次讀。A刪緩存 B讀庫 B加緩存 A寫庫A。這個概率比上面的大。

這兩種方案的問題的解決方式是一樣的，就是延時雙刪策略。即：

刪緩存 寫庫 延時再次刪除緩存（需超過一次讀庫的時間，可以新啟線程完成）

或者 寫庫 刪緩存 延時再次刪除緩存（需超過一次讀庫的時間，可以新啟線程完成）

如果有主從讀寫分離，需要將延時再加上主從同步的時間。

還有個第二次刪除失敗的問題，這個問題可以通過消息中間件，反復嘗試進行。或者通過訂閱binlog，反復進行。

多級緩存可以參考阿里開源的JetCache的實現

後面會給出demo和源碼解析。

⑩ spring 緩存問題

@cacheable(value="cachedpointstasks")
當查詢方法使用次註解時，如果已查詢過，則將數據緩存到緩存空間，不再查詢資料庫。