在一次需求修改中,下游的服务附加提出了,针对某个业务数据缓存的生效时间的要求
原JVM设计方案:
采用jvm本地缓存机制,定时任务30秒刷新一次
现在redis方案:
- 因为很多地方使用了这个业务数据缓存,使用方面不能改动过多
- 因为是分布式部署,如果只使用jvm缓存,无法更新其他的服务器中的缓存数据,达不到立刻生效的要求
- 不使用二级缓存的原因:理由和第二个一样,如果优先使用jvm时,哪怕更新了redis,其他服务器也会先用jvm缓存(另外为什么会使用二级缓存?:因为jvm本地缓存更快而已,还得加重了架构的负担,为了一个需求)
所以:直接把维护jvm业务缓存改成redis来维护
那便需要考虑主动刷新 被动刷新 生效时间等
- 被动刷新:依旧使用jvm缓存的定时任务机制,30秒更新一次(无改动,使用原本的机制)
- 主动刷新:由于生效时间是一秒生效,则在修改和更新后,需要立即主动刷新该缓存(改动少,维护都在一个项目里,不需要采用什么监听mysql表的东西)
修改中的收获:
- 工具类中获取注入的问题 BeanUtil.getBean(RedisTemplate.class);
- redis Pipeline管道提速 redisTemplate.STRINGS.setEx(redisCacheList,refreshTime);
- 分割思想:更小的粒度 如:redis 一个key存储一个表的数据太大了,则根据表中关键key进行切分