缓存失效，导致高并发穿透DB的几种解决思路

其实，这个场景几乎每个程序员都会接触到，但是还是有很多程序员对这种思路没有好的办法，下面我再整理下之前收集到的资料，重新发下。由于该文章转载很多，找不到准确出处。如有侵权，请联系我。

 

当缓存失效时，容易出现高并发的查询DB，导致DB压力骤然上升，这种现象我们称之为缓存穿透。

这篇blog主要是探讨如何在缓存将要失效时，及时地更新缓存，而不是如何在缓存失效之后，如何防止高并发的DB查询

个人认为，当缓存将要失效时，及时地把新的数据刷到缓存里，这个是解决缓存失效瞬间高并发查DB的最好方法。 那么如何及时地知道缓存将要失效？

解决这个问题有几种思路：

比如一个key是testKey，失效时间是30s

1.定期从DB里查询数据，再刷到缓存里

缺点：有些业务的key可能是变化的，不确定的。而且不好界定哪些数据是应该查询出来放到缓存中的，难以区分冷热数据

2.当缓存取到为null时，加锁去查询DB，只允许一个线程去查询DB

缺点：这种方式不太靠谱，不多讨论。 而且如果是多个web服务器的话，还是有可能有并发的操作

3.在向缓存写入value时，同时写入当前机器在时间作为过期时间

当get得到数据时，如果当前时间 – 过期时间 > 5s，则后台启动一个任务去查询DB，更新缓存

当然，这里的后台任务必须保证同一个key，只有一个线程在执行查询DB的任务，不然这个还是高并发查询DB

缺点：是要把过期时间和value合在一起序列化，取出数据后，还要反序列化。 很不方便

网上大部分文章提到的全都是前面两种方式，有少数文章提到第3种方式。 下面提出一种基于两个key的方法：

4.两个key，一个key用来存放数据，另一个用来标记失效时间

比如key是testKey，设置失效时间为30s，则另一个key为expire_testKey，失效时间为25s。用multiget，同时取出testKey和expire_testKey，如果expire_testKey的为null，则后台启动一个任务加锁去查询DB，更新缓存。集群式的部署的，如何实现只允许一个任务执行，用到memcached的add命令,或redis的setnx命令。设置expire_testKey超时过间为3s，防止后台任务失败或者阻塞。

缺点：内存翻倍，而且程序上要维护2个key。

5.两个key,时间存到value里，结合add/setnx来保证原子性更新缓存

最近重新思考了下这个问题。 发现第4种两个key的办法比较耗memcached的内存，因为key数翻倍了。 结合第3种方式，重新设计了下，思路如下。

仍然使用2个key方案，但是expire_testKey相当于锁。只允许add/setnx成功的线程去更新数据。更新成功后把expire_testKey进行删除。由于这个expire_testKey存在时间较短，不会占用太多缓存内存。

优点：节省内存，数据是自然冷热适应的，不用担心集群带来并发风险

总结：

我个人是倾向于第5种方式的，因为很简单，直观。 比第4种方式要节省内存，而且不用mget，在使用memcached集群时不用担心出麻烦事

这种两个key的方式，还有一个好处，就是数据是自然冷热适应的。 如果是冷数据，30秒都没有人访问，那么数据会过期

如果是热门数据，一直有大流量访问，那么数据就是一直热的，而且数据一直不会过期