預期讀者
- 準備使用 spring 的 data-redis-cache 的同學
- 瞭解
@CacheConfig
,@Cacheable
,@CachePut
,@CacheEvict
,@Caching
的使用 - 深入理解 data-redis-cache 的實現原理
文章內容說明
- 如何使用 redis-cache
- 自定義 keyGenerator 和過期時間
- 源碼解讀
- 自帶緩存機制的不足
快速入門
-
maven 加入 jar 包
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency>
-
配置 redis
spring.redis.host=127.0.0.1
-
開啓 redis-cache
@EnableCaching
-
@CacheConfig
,@Cacheable
,@CachePut
,@CacheEvict
,@Caching
的功能-
@Cacheable
會查詢緩存中是否有數據,如果有數據則返回,否則執行方法 -
@CachePut
每次都執行方法,並把結果進行緩存 -
@CacheEvict
會刪除緩存中的內容 -
@Caching
相當於上面三者的綜合,用於配置三者的行爲 -
@CacheConfig
配置在類上,用於配置當前類的全局緩存配置
-
詳細配置
經過上面的配置,就已經可以使用 redis-cache 了,但是還是有些問題需要問自己一下,比如
- 存儲在 redis 的 key 是什麼樣子的,我可以自定義 key 嗎
- 存儲到 redis 的 value 是怎麼序列化的
- 存儲的緩存是多久過期
- 併發訪問時,會不會直接穿透從而不斷的修改緩存內容
過期時間,序列化方式由此類決定 RedisCacheConfiguration
,可以覆蓋此類達到自定義配置。默認配置爲RedisCacheConfiguration.defaultCacheConfig()
,它配置爲永不過期,key 爲 String 序列化,並加上了一個前綴做爲命名空間,value 爲 Jdk 序列化,所以你要存儲的類必須要實現 java.io.Serializable
。
存儲的 key 值的生成由 KeyGenerator
決定,可以在各緩存註解上進行配置,默認使用的是 SimpleKeyGenerator
其存儲的 key 方式爲 SimpleKey [參數名1,參數名2],如果在同一個命名空間下,有兩個同參數名的方法就公出現衝突導致反序列化失敗。
併發訪問時,確實存在多次訪問數據庫而沒有使用緩存的情況 https://blog.csdn.net/clementad/article/details/52452119
Srping 4.3提供了一個sync參數。是當緩存失效後,爲了避免多個請求打到數據庫,系統做了一個併發控制優化,同時只有一個線程會去數據庫取數據其它線程會被阻塞。
自定義存儲 key
根據上面的說明 ,很有可能會存在存儲的 key 一致而導致反序列化失敗,所以需要自定義存儲 key ,有兩種實現辦法 ,一種是使用元數據配置 key(簡單但難維護),一種是全局設置 keyGenerator
使用元數據配置 key
@Cacheable(key = "#vin+#name")
public List<Vehicle> testMetaKey(String vin,String name){
List<Vehicle> vehicles = dataProvide.selectAll();
return vehicles.stream().filter(vehicle -> vehicle.getVin().equals(vin) && vehicle.getName().contains(name)).collect(Collectors.toList());
}
這是一個 spel 表達式,可以使用 號來拼接參數,常量使用 "" 來包含,更多例子
@Cacheable(value = "user",key = "targetClass.name '.' methodName")
@Cacheable(value = "user",key = "'list' targetClass.name '.' methodName #name ")
注意: 生成的 key 不能爲空值,不然會報錯誤 Null key returned for cache operation
常用的元數據信息
名稱 | 位置 | 描述 | 示例 |
---|---|---|---|
methodName | root | 當前被調用的方法名 | #root.methodName |
method | root | 被調用的方法對象 | #root.method.name |
target | root | 當前實例 | #root.target |
targetClass | root | 當前被調用方法參數列表 | #root.targetClass |
args | root | 當前被調用的方法名 | #root.args[0] |
caches | root | 使用的緩存列表 | #root.caches[0].name |
Argument Name | 執行上下文 | 方法參數數據 | #user.id |
result | 執行上下文 | 方法返回值數據 | #result.id |
使用全局 keyGenerator
使用元數據的特點是簡單,但是難維護,如果需要配置的緩存接口較多的話,這時可以配置一個 keyGenerator ,這個配置配置多個,引用其名稱即可。
@Bean
public KeyGenerator cacheKeyGenerator() {
return (target, method, params) -> {
return target+method+params;
}
}
自定義序列化和配置過期時間
因爲默認使用值序列化爲 Jdk 序列化,存在體積大,增減字段會造成序列化異常等問題,可以考慮其它序列化來覆寫默認序列化。
@Bean
public RedisCacheManager redisCacheManager(RedisConnectionFactory redisConnectionFactory){
RedisCacheConfiguration redisCacheConfiguration = RedisCacheConfiguration.defaultCacheConfig();
// 設置過期時間爲 30 天
redisCacheConfiguration.entryTtl(Duration.ofDays(30));
redisCacheConfiguration.serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(new KryoRedisSerializer()));
RedisCacheManager redisCacheManager = RedisCacheManager.builder(redisConnectionFactory)
.cacheDefaults(redisCacheConfiguration)
.withInitialCacheConfigurations(customConfigs)
.build();
}
個性化配置過期時間和序列化
上面的是全局配置過期時間和序列化,可以針對每一個 cacheNames 進行單獨設置,它是一個 Map 配置
Map<String, RedisCacheConfiguration> customConfigs = new HashMap<>();
customConfigs.put("cacheName1",RedisCacheConfiguration.defaultCacheConfig());
RedisCacheManager redisCacheManager = RedisCacheManager.builder(redisConnectionFactory)
.cacheDefaults(redisCacheConfiguration)
.withInitialCacheConfigurations(customConfigs)
.build();
源碼走讀
本源碼走讀只帶你入門,具體的細節需要具體分析
首先不用看源碼也知道這肯定是動態代理來實現的,代理目標方法,獲取配置,然後增強方法功能;
aop 就是幹這件事的,我們自己也經常加一些註解來實現日誌信息採集,其實和這個原理一致,spring-data-cache-redis 也是使用 aop 實現的。
從 @EnableCaching
開始,可以看到導入了一個選擇導入配置的配置類(有點繞,就是可以自己控制導入哪些配置類),默認使用 PROXY
模式
public class CachingConfigurationSelector extends AdviceModeImportSelector<EnableCaching>
PROXY
導入瞭如下配置類
private String[] getProxyImports() {
List<String> result = new ArrayList<>(3);
result.add(AutoProxyRegistrar.class.getName());
result.add(ProxyCachingConfiguration.class.getName());
if (jsr107Present && jcacheImplPresent) {
result.add(PROXY_JCACHE_CONFIGURATION_CLASS);
}
return StringUtils.toStringArray(result);
}
ProxyCachingConfiguration
重點的配置類是在這個配置類中,它配置了三個 Bean
BeanFactoryCacheOperationSourceAdvisor
是 CacheOperationSource
的一個增強器
CacheOperationSource
主要提供查找方法上緩存註解的方法 findCacheOperations
CacheInterceptor
它是一個 MethodInterceptor
在調用緩存方法時,會執行它的 invoke
方法
下面來看一下 CacheInterceptor
的 invoke
方法
// 關鍵代碼就一句話,aopAllianceInvoker 是一個函數式接口,它會執行你的真實方法
execute(aopAllianceInvoker, invocation.getThis(), method, invocation.getArguments());
進入 execute
方法,可以看到這一層只是獲取到所有的緩存操作集合,@CacheConfig
,@Cacheable
,@CachePut
,@CacheEvict
,@Caching
然後把其配置和當前執行上下文進行綁定成了 CacheOperationContexts
Class<?> targetClass = getTargetClass(target);
CacheOperationSource cacheOperationSource = getCacheOperationSource();
if (cacheOperationSource != null) {
Collection<CacheOperation> operations = cacheOperationSource.getCacheOperations(method, targetClass);
if (!CollectionUtils.isEmpty(operations)) {
return execute(invoker, method,
new CacheOperationContexts(operations, method, args, target, targetClass));
}
}
再進入 execute
方法,可以看到前面專門是對 sync
做了處理,後面纔是對各個註解的處理
if (contexts.isSynchronized()) {
// 這裏是專門於 sync 做的處理,可以先不去管它,後面再來看是如何處理的,先看後面的內容
}
// Process any early evictions 先做緩存清理工作
processCacheEvicts(contexts.get(CacheEvictOperation.class), true,
CacheOperationExpressionEvaluator.NO_RESULT);
// Check if we have a cached item matching the conditions 查詢緩存中內容
Cache.ValueWrapper cacheHit = findCachedItem(contexts.get(CacheableOperation.class));
// Collect puts from any @Cacheable miss, if no cached item is found 如果緩存沒有命中,收集 put 請求,後面會統一把需要放入緩存中的統一應用
List<CachePutRequest> cachePutRequests = new LinkedList<>();
if (cacheHit == null) {
collectPutRequests(contexts.get(CacheableOperation.class),
CacheOperationExpressionEvaluator.NO_RESULT, cachePutRequests);
}
Object cacheValue;
Object returnValue;
// 緩存有命中並且不是 @CachePut 的處理
if (cacheHit != null && !hasCachePut(contexts)) {
// If there are no put requests, just use the cache hit
cacheValue = cacheHit.get();
returnValue = wrapCacheValue(method, cacheValue);
}
else {
// Invoke the method if we don't have a cache hit 緩存沒有命中,執行真實方法
returnValue = invokeOperation(invoker);
cacheValue = unwrapReturnValue(returnValue);
}
// Collect any explicit @CachePuts
collectPutRequests(contexts.get(CachePutOperation.class), cacheValue, cachePutRequests);
// Process any collected put requests, either from @CachePut or a @Cacheable miss 把前面收集到的所有 putRequest 數據放入緩存
for (CachePutRequest cachePutRequest : cachePutRequests) {
cachePutRequest.apply(cacheValue);
}
// Process any late evictions
processCacheEvicts(contexts.get(CacheEvictOperation.class), false, cacheValue);
return returnValue;
看完了執行流程,現在看一下CacheInterceptor
的超類 CacheAspectSupport
,因爲我可以不設置 cacheManager
就可以使用,查看默認的 cacheManager
是在哪設置的
public abstract class CacheAspectSupport extends AbstractCacheInvoker
implements BeanFactoryAware, InitializingBean, SmartInitializingSingleton {
// ....
}
BeanFactoryAware 用來獲取 BeanFactory
InitializingBean 用來管理 Bean 的生命週期,可以在 afterPropertiesSet
後添加邏輯
SmartInitializingSingleton 實現該接口後,當所有單例 bean 都初始化完成以後, 容器會回調該接口的方法 afterSingletonsInstantiated
在 afterSingletonsInstantiated
中,果然進行了 cacheManager
的設置,從 IOC 容器中拿了一個 cacheManger
setCacheManager(this.beanFactory.getBean(CacheManager.class));
那這個 CacheManager
是誰呢 ,可以從RedisCacheConfiguration類知道答案 ,在這裏面配置了一個 RedisCacheManager
@Configuration
@ConditionalOnClass(RedisConnectionFactory.class)
@AutoConfigureAfter(RedisAutoConfiguration.class)
@ConditionalOnBean(RedisConnectionFactory.class)
@ConditionalOnMissingBean(CacheManager.class)
@Conditional(CacheCondition.class)
class RedisCacheConfiguration {}
@Bean
public RedisCacheManager cacheManager(RedisConnectionFactory redisConnectionFactory,
ResourceLoader resourceLoader) {
RedisCacheManagerBuilder builder = RedisCacheManager
.builder(redisConnectionFactory)
.cacheDefaults(determineConfiguration(resourceLoader.getClassLoader()));
List<String> cacheNames = this.cacheProperties.getCacheNames();
if (!cacheNames.isEmpty()) {
builder.initialCacheNames(new LinkedHashSet<>(cacheNames));
}
return this.customizerInvoker.customize(builder.build());
}
從 determineConfiguration()
方法中可以知道 cacheManager 的默認配置
最後看一下,它的切點是如何定義的,即何時會調用 CacheInterceptor
的 invoke
方法
切點的配置是在 BeanFactoryCacheOperationSourceAdvisor
類中,返回一個這樣的切點 CacheOperationSourcePointcut
,覆寫 MethodMatcher
中的 matchs
,如果方法上存在註解 ,則認爲可以切入。
spring-data-redis-cache 的不足
儘管功能已經非常強大,但它沒有解決緩存刷新的問題,如果緩存在某一時間過期 ,將會有大量的請求打進數據庫,會造成數據庫很大的壓力。
4.3 版本在這方面做了下併發控制,但感覺比較敷衍,簡單的鎖住其它請求,先把數據 load 到緩存,然後再讓其它請求走緩存。
後面我將自定義緩存刷新,並做一個 cache 加強控件,儘量不對原系統有太多的侵入,敬請關注
一點小推廣
創作不易,希望可以支持下我的開源軟件,及我的小工具,歡迎來 gitee 點星,fork ,提 bug 。
Excel 通用導入導出,支持 Excel 公式
博客地址:https://blog.csdn.net/sanri1993/article/details/100601578
gitee:https://gitee.com/sanri/sanri-excel-poi
使用模板代碼 ,從數據庫生成代碼 ,及一些項目中經常可以用到的小工具
博客地址:https://blog.csdn.net/sanri1993/article/details/98664034
gitee:https://gitee.com/sanri/sanri-tools-maven