场景
提升查询性能，修改操作如果大于查询操作时则没必要做Cache设计
Cache类型
客户端Cache
页面Cache
浏览器Cache
代理Cache(边缘Cache)
服务端Cache
DB Cache (MySql)
应用Cache
Cache算法
Ehcache
GuavaCache
Redis
Cache更新策略
1、定时全量更新
定时器按固定周期把最新数据全量更新到Cache中
问题： 不实时，全量加载太慢，REDIS场景下如果是DEl操作Cache中的老数据没有清除，需要设置过期时间；2、改进方法1：改为更新落库后实时增量的更新Cache, 从Cache中查数据，如果没命中，则查数据库
问题： 如果更新Cache出现失败，则查询都会走数据库；
3、改进方法2：方法二的基础上，如果没命中，查完数据库后更新到Cache中
问题：有两个更新入口，并发情况下回出现脏数据问题；
4、改进方法3：Cache Aside
修改时让Cache失效，由查询操作更新到Cache
理论上的并发问题：线程1查询DB后，线程2更新DB后把Cache失效，然后线程1再来到重新把Cache恢复成了老数据，由于更新操作比查询操作要慢很多，除非系统异常情况下，否则不会出现；5、有同事提出在Cache Aside 有空查询问题，即错误的数据都会查询一遍DB
这种情况我认为不会有问题，这种情况多出在恶意攻击注入的时候，这个时候应该是在上层做其他的拦截，例如限流、降级、黑名单等；
6、设计上的改进，将Cache和DB合并为一个服务，由Cache实现与DB的交互，屏蔽更新Cache的细节；
7、高可靠高并发的改进：所有更新和查询都在Cache 上实现，再由Cache异步的同步到DB上，这样DB只做一个数据恢复，这里需要Cache在实现上是高可用的，极小概率会出现数据丢失。
###