一套不那么成熟的业务数据查询缓存方案

方案如图：

为什么会有这套方案的产生呢？主要出于以下原因：
1、业务查询接口性能要求较高。读写较频繁。现有数据库经过多轮优化后仍无法满足该要求。
2、普通的将vos结果缓存到redis在查询数据较大和频率擦除更新的情况下，查询性能得不到太大的提升。
3、表数据并非海量，只是关联的表和字段较多，字段内容较多，造成数据包大和查询慢。

方案简介：
1、项目启动时，将全部vos集缓存到本地。将vo的唯一键缓存到reids。
2、取数据时，先去redis取到vo的所有键。然后去本地缓存取到vo对象。组成结果集返回。
3、更新时，redis擦除数据量较小的key-ids，本地将修改或新增的数据刷新到本地缓存。并通过redis自带的发布订阅模式。将更新消息扩散到其他集群节点。

优点：
redis无需缓存vo大对象，更新时也不需要操作vo。只缓存key-ids，效率较高。
本地缓存读取vo速度快。
本地缓存更新数据只需在很小的范围内更新。比如新增，直接往本地缓存写一条k-vo。修改，直接修改k-vo。

缺点：
代码复杂，代码量较大。
占用服务器内存资源。

综上所述。主要作用于客户使用较热门的一些重要数据的展示。如报表、滚动大屏什么的。该方案最近急赶急试了下。感觉还不错。但可能还存在不少缺陷。仅供参考。