cache业务

2021年11月21日 阅读数:9
这篇文章主要向大家介绍cache业务,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。


最近一个业务为三个表的list数据分别展现redis

以及根据三个表来渲染的图表缓存

分别有各类查询mybatis

数据是excel导入ide

想加入缓存处理spa

构思解决:excel

第一种:在导入excel后,无论哪一个表,完成后调用@CacheEvit,指定对应缓存清除,排序

这样@Cacheable没法命中,再走缓存查询并再次缓存。接口

问题:好比图表有3个接口,并且查询时,要根据时间,各类id和类别进行查询,这样的话ci

数据缓存不会一致。字符串

好比第次用类别A查询,第二次类别B,在Cacheable上指定key使用了这个#p0参数

那么redis会有两个key对应,

处理:当导入新excel数据,将图表的key所有清空

第二种:查询图表有时间区间参数,若是导入的数据不在这个时间范围内,对应的图表key不予删除

由于那个查询的区间并不表明最新导入数据

因此就不必进行清理

惟独当指定的时间区间还囊括了新导入数据时间时,图表缓存key予以清理。

处理:如上

第三种:查询图表有根据数据内其它字段区间进行查询的,就要在导入数据后获取到本次数据中,

在这个字段区间内的min和max值,对应图表的key,予以删除或保留。

处理:如上,或直接删除图表key(简单)

第四种:开启mybatis二级缓存,不使用redis

 ​

处理:这种简单易行,但不是那么强烈的缓存形式,有周期性时间性等待。

第五种:对图表key再精细化处理,好比几个参数分别对应一个字符串的前缀,

在断定是否有该时间区间或类型或id时,能更快地进行缓存的更新。

处理:导出数据后,对应数据对应图表key的几个地方都进行相应处理,

好比A类型,B类型,是导入A类型,则只清理相似type-A的key,

B类型,只清理相似type-B的key。

建立时间,这个通常在数据导入就固定了,并且越新导入的数据时间越新,

只要看新导入数据是否囊括在以前的建立时间相似createTimeKey-2000-2002

更新时间,这个不必定,可是起初的更新时间和createTime是一致的,除非后期处理数据才进行变动,

这个也能够看更新时间相似是否在updateTimeKey-2000-2003之间

好比数据是2021年导入的(笔记时间),那么这个updateTimeKey就不该进行删除。逻辑同建立时间。

最后一个如数据内的时间,不一样于建立和更新时间,好比用户的身份证上的出生时间,

这个时间区间对应在idNumberKey-2000-2004之间的,才进行该key的删除。

如导入的excel大批量的数据中,身份证从1960年的到1999年的不等,

可是总体不包含在idNumberKey的下界,不予清理,

但若是导入数据中身份号最低最大分别为1980-2003,那么对应的2003已在2000-2004之间

因此该图表key予以删除。

在一个如根据部门ids做为了key,那么在做为key前要先排序好,

若是导入数据部门id就算有一个在里面,也要进行相应的图表的key的删除。固然,这个删除,

总体要看先看时间区间。

处理:若是仅是有时间区间(但包含建立/更新/身份证时间的区分),部门ids两种查询类别

做为图表key,那么首先要先查相应导入数据时间,是否匹配上,若是匹配上,再看对应部门id

是否包含,若是包含,则进行图表key的清理,让Cacheable从新获取缓存。

若是时间区间都没法匹配,则保留图表key便可,部门ids无需断定。

(开始)->

【导入新数据】-> 【拿去时间及部门特征结果】->【对比现有缓存cacheNames对应的key的时间和部门特征】

-> <<断定时间区间>> ->

[key不包含时间特征]-> 【不清理key】-> (结束)

[key包含时间特征]->

-> <<断定部门特征>> ->

[key不包含部门特征]-> 【不清理key】-> (结束)

[key包含部门特征]-> 【清理key】-> (结束)


上一篇: Gradle
下一篇: spring cloud stream