在一次需求修改中，下游的服务附加提出了，针对某个业务数据缓存的生效时间的要求
原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进行切分