作用
本地缓存在高并发场景下，进行高并发读操作的利器，可以直接在应用实例内存内进行读取，没有多余的网络消耗，用在缓存方面效率很高，比redis还要高上很多，一般用在redis前一层做缓存，可以用来解决redis 热点key问题，即单分片负载过高。
一般业务的存储体系为：
- 本地缓存
- Redis缓存
- mysql数据库
本地缓存的不同使用场景
固定配置缓存
固定配置缓存是一个缓存内容不易变的场景，我们之前做触达系统有使用到，当时的场景是先用redis缓存了策略配置、用户分组配置、物料这些配置，在流量大的情况下出现了redis单分片负载过高的情况，原因是这些配置信息在整个触达检索的过程中要获取多次，那这个地方就有必要做下优化了，一则减少整体调用的耗时，二则减轻redis的调用压力。
整体方案是我们把这些配置信息分别缓存到对应配置类的Map局部变量中，定期加载到内存中，完成一批加载后，用buffer指针指向新加载的实体类。对于这种配置类的内容做本地缓存，可以这么直接自己实现做，原因是可以定期做加载更新，不用考虑做过期，lru evict这些问题。
这样做的优点是实现简单，并且每个实例内的配置缓存自身是一致的，不用考虑不同配置之间的一致性和依赖关系，比如先更新了策略配置，里面包含了物料A，新增加的物料A配置还没更新，这种情况下进行检索是会有问题的。
这种方式的缺点有两种：
- 实时性不够，运营改完配置后不会立马生效，要等1分钟左右才会生效，但对于配置类的功能，这个是完全可以接受的。并且也可以通过在改配置的时候通过消息队列进行广播，然后实例分别监听消息队列进行缓存的修改。
- 这样的话，每1分钟会有一个几M的垃圾产生，对于老年代的垃圾回收可能会有一定的影响，不过之前并没有太遇到问题，也就没特别多的研究。
易变缓存
易变缓存即容易发生变化的缓存内容，比如用户相关的缓存信息，或者说是视频下面的评论内容，这种情况下缓存内容会经常进行变化，且有实时性要求，也不可能对所有内容定期做主动更新。
这种情况下本地内存更适合做redis缓存的前置缓存，等于再加一层内存中的缓存，可以使用guava cache这种组件来完成，这个支持设置过期时间，包括writeAfter和accessAfter，也支持设置内存中不存在时进行加载的逻辑。
那这样的话，就可以从redis或mysql中重新加载内容，更符合常规缓存的用法和理念，当一个临时存储，上面的配置存储更像一个常驻存储了。
这种本地内存有三种更新方式：
- 收到更新消息通知，直接主动更新内存内信息，一般通过put操作即可完成覆盖。
- 收到更新消息通知，删除本地内存内对应项，等下次请求时做加载。
- 内存中缓存信息过期后，下次请求时做加载。
