关于缓存问题的解决方案

一、缓存穿透

我们在项目中使用缓存通常都是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 连接数暴涨、响应变慢，连累前端应用连接数持续高涨、最后宕机。

五、缓存永不过期

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