使用缓存时，一次请求过来，可能访问到缓存或数据库，这样就可能出现以下场景，主要问题在缓存和数据库的数据不一致问题
缓存穿透
出现原因
请求中的key在缓存和数据库都没有，数据库查询不到数据，每次请求就直达数据库，这就是缓存穿透
解决方案
- 布隆过滤器，同步数据库的key，不存在的直接过滤
- 缓存空对象，设置过期时间，防止数据不一致
缓存击穿
出现原因
数据库有请求的key,缓存还没有生成或者过期了，如果此时对key集中访问，就会导致并发请求全部到达数据库，造成缓存击穿。
解决方案
- 缓存预热，提前生成key
- 设置热点数据不过期
- 缓存过期重建时加锁，确保只有一个请求访问数据库重建缓存
缓存雪崩
出现原因
缓存中的key同时过期
解决方案
- 设置key的过期时间时增加随机数
- 设置热点数据不过期
- 重建缓存时加锁限流
- key设置过期标志，标志时间比key早一半时间，查缓存时如果标志过期，另起线程去更新缓存，同时返回原来缓存的数据
缓存预热
方案
- 数据量小，启动时直接加载到缓存
- 数据量多，通过定时加载刷新
- 数据量过多，只加载热点数据
缓存降级
原因
网络原因缓存超时或缓存服务器宕机
方案
- 根据服务重要级制定对应的策略
- 自动降级加人工降级加告警
缓存更新
更新策略
-
Cache Aside 模式
读：从cache读数据，有则返回，没有从数据库读，同时更新缓存
写：先把数据存到数据库中，成功后，再让缓存失效 -
read/write through模式
这个模式其实就是将 缓存服务 作为主要的存储，应用的所有读写请求都是直接与缓存服务打交道，而不管最后端的数据库了，数据库的数据由缓存服务来维护和更新。不过缓存中数据变更的时候是同步去更新数据库的，在应用的眼中只有缓存服务。
-
Write Behind模式。
在更新数据的时候，只更新缓存，不更新数据库，而我们的缓存会异步地批量更新数据库
可能存在问题
- Cache Aside 模式：假设缓存刚好到期失效时，读请求从db中读取数据，写请求更新完数据后再失效缓存后，读请求将旧数据存入到缓存中，这种情况也会导致脏数据的问题。实际上这种情况发生的概率很低，要发生这种情况的前提条件是写数据库要先于读数据库完成，一般而言读数据库相比于写数据库要耗时更短，这种前提条件成立的概率很低,可通过延时双删避免（先休眠1再次失效缓存）；如果是删除缓存失败，可通过canal订阅binlog日志提取key进行循环删除
- read/write through模式：对缓存服务的稳定性有较大要求，增加新缓存节点时还会有初始状态空数据问题。
- Write Behind模式：速度很快，效率会非常高，但是数据的一致性比较差，还可能会有数据的丢失情况，实现逻辑也较为复杂。
