关于缓存问题的解决方案

一、缓存穿透
我们在项目中使用缓存通常都是APP先检查缓存中是否存在，如果存在直接返回缓存内容，如果不存在就直接查询数据库然后再缓存查询结果返回。这个时候如果我们查询的某一个数据在缓存中一直不存在，就会造成每一次请求都查询DB，这样缓存就失去了意义，在流量大时，可能DB就挂掉了。
这个问题其实经常遇到，只是没有引起足够的重视，在我想来，如果碰到这样的问题可以在封装的缓存SET和GET部分增加个步骤，如果查询一个KEY不存在，就已这个KEY为前缀设定一个标识KEY；以后再查询该KEY的时候，先查询标识KEY，如果标识KEY存在，就返回一个协定好的非FALSH或者NULL值，然后APP做相应的处理，这样缓存层就不会被穿透。当然这个验证KEY的失效时间不能太长。
 
缓存穿透
目的
防止访问（短期内）必然不存在的数据导致请求穿透缓存直接打到 DB。
原因
可能是数据真的不存在，但也可能是第三方恶意构造大量不存在的 id 来冲击 DB。
多种手段结合
1、 『存储EMPTY』思路：存储一个 EMPTY 对象到缓存对应键值，设置一个较短的过期时间。这样在缓存失效后，还能继续查询数据是否存在。
2、必须认真对待（不同业务不同端口的）缓存命中率（get_hits/cmd_get * 100）定期监控的结果，认真审视那些命中率低的缓存端口，找到命中率低的原因，提出优化方案。
3、『先行校验』思想：采用 布隆过滤器算法，将所有可能存在的数据（如所有有效商品的id）哈希到一个足够大的 bitmap 里，那么一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力。（出处）


二、缓存并发
有时候如果网站并发访问高，一个缓存如果失效，可能出现多个进程同时查询DB，同时设置缓存的情况，如果并发确实很大，这也可能造成DB压力过大，还有缓存频繁更新的问题。
解决方法是再 APP中对缓存查询加锁，如果KEY不存在，就加锁，然后查DB入缓存，然后解锁；其他进程如果发现有锁就等待，然后等解锁后返回数据或者进入DB查询。


缓存重建
  热点数据的缓存重建，无论是本地缓存还是远端缓存，都有必要加锁来确保进程内同一时刻只有一个 Worker 负责重建，甚至利用分布式锁保证集群环境下只有一个重建者，避免缓存雪崩时的 Race Condition。TimYang 早在2010年在《Memcache mutex设计模式》中描述过如下风险：”在大并发的场合，当cache失效时，大量并发同时取不到cache，会同一瞬间去访问db并回设cache，可能会给系统带来潜在的超负荷风险。我们曾经在线上系统出现过类似故障。“孙立将这种场景称为 cache key mutex 问题

  简而言之，缓存重建时，当多个 Client 对同一个缓存数据发起请求时，会在客户端采用加锁等待的方式，对同一个 CacheKey 的重建需要获取到相应的排他锁才行，只有拿到锁的 Client 才能访问数据库重建缓存，其他的 Client 都需要等待这个拿到锁的 Client 重建好缓存后直接读缓存。这样，对同一个缓存数据，只有一次数据库重建访问。但是如果访问分散比较严重，还是会瞬间对数据库造成非常大的压力。
 


三、缓存失效
引起这个问题的主要原因还是高并发的时候，平时我们设定一个缓存的过期时间时，可能有一些会设置5分钟啊，10分钟这些；并发很高时可能会出在某一个时间同时生成了很多的缓存，并且过期时间都一样，这个时候就可能引发一当过期时间到后，这些缓存同时失效，请求全部转发到DB，DB可能会压力过重。
其中的一个简单方案就时讲缓存失效 时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
 
缓存集体失效
  以下原因都会导致缓存集体失效，从而引发系统”抖动“甚至”雪崩“：
系统预热数据的缓存过期时间过于整齐划一；
缓存系统宕机或重启；
访问高峰期间种下了一大批缓存，过期时间非常接近。
  处理手段：
缓存过期时间散列开：在过期时间基础上增加一个随机值，如1秒～120秒随机，将大家的过期时间尽量打散。


四、分级缓存
  有些业务场景里，应该把 DB 当成仅是一个存储而已，靠分级缓存策略来层层抵挡缓存失效，不让请求打到 DB。
手段：
由远及近分层建立缓存，越靠近前端，缓存片段越大（或存储粒度越大）。
上一层的缓存失效，可以靠下一级的缓存迅速重建。
目的：
避免系统产生抖动。
减少缓存雪崩，防止 DB 连接数暴涨、响应变慢，连累前端应用连接数持续高涨、最后宕机。


五、缓存永不过期
  因为担心缓存失效带来的系统抖动，所以有些业务场景会让缓存永不过期，数据变化时，由后端负责维护缓存数据一致性。