使用redis作为缓存首先要考虑几个常见的问题。
1、缓存穿透
2、缓存雪崩
3、缓存击穿
4、数据一致性
1、缓存穿透
缓存穿透是指查询一个一定不存在的数据,由于缓存是不命中时被动写的,并且出于容错考虑,如果从存储层查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到存储层去查询,失去了缓存的意义。在流量大时,可能DB就挂掉了,要是有人利用不存在的key频繁攻击我们的应用,这就是漏洞。
解决方案:
1)布隆过滤器、将所有可能存在的数据哈希到一个足够大的bitmap中,一个一定不存在的数据会被 这个bitmap拦截 掉,从而避免了对底层存储系统的查询压力,有一定误判率
2)如果一个DB查询返回的数据为空(不管是数 据不存在,还是系统故障)仍然把这个空结果进行缓存,但它的过期时间会很短。
2、缓存雪崩
缓存雪崩是指在我们设置缓存时采用了相同的过期时间,导致缓存在某一时刻同时失效,请求全部转发到DB,DB瞬时压力过重雪崩。缓存失效时的雪崩效应对底层系统的冲击非常可怕。
解决方案:可以考虑用加锁或队列的方式保证缓存的单线程(进程)写,从而避免失效时大量的并发请求落到底层存储系统上。
1)将缓存失效时间分散开,比如我们可以在原有的失效时间基础上增加一个随机值,比如1-5分钟随机,这样每一个缓存的过期时间的重复率就会降低,就很难引发集体失效的事件。
2)使用两份缓存,一份短失效,一份长失效,甚至永久有效。在第一份缓存失效的时候,第一个到达的请求访问DB,后续请求访问备份缓存。
两种方案可以同时使用,单独使用也可。切忌将数据库某一张表整表缓存为1个key
题外话:如果不幸在你的项目中已经将整张表缓存为1个key,并且你的数据量已经有一定规模。更新一次key用时相当长。这时你可以在你的key上在加一条数据。数据内容保存(当前时间+2小时),你每次使用数据都将这个值取出来判断,且保证这个判断持续工作。在即将到达失效时间的前1小时开始更新。呵呵
3、缓存击穿
对于一些设置了过期时间的key,如果这些key可能会在某些时间点被超高并发地访问,是一种非常“热点”的数据。这个时候,需要考虑一个问题:缓存被“击穿”的问题,这个和缓存雪崩的区别在于这里针对某一key缓存,前者则是很多key。
缓存在某个时间点过期的时候,恰好在这个时间点对这个Key有大量的并发请求过来,这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存,这个时候大并发的请求可能会瞬间把后端DB压垮。
解决方案:
1)使用互斥锁(mutex key)
在缓存失效的时候,不是立即去DB,而是先存入一个值set一个mutex key,当操作返回成功时,再进行DB的操作并回设缓存;否则,就重试整个get缓存的方法。(可以改进为2.2,双缓存策略)
2)提前使用互斥锁(mutex key)
在value内部设置1个超时值,当读取超时值发现已经过期时候延长超时值并且调用DB
3)逻辑过期
不设置数据过期或失效时间。只在key对应的value里设置时间,如果发现要过期。调用异步的DB方法。也就是只在逻辑上存在过期时间,这种方式对性能非常友好。
4、缓存与数据库 数据一致性
尽量缓存不可变数据
假设先写数据库,再淘汰缓存:数据库操作成功,淘汰缓存失败。 db中是新数据,cache中是旧数据
假设先淘汰缓存,再写数据库:淘汰缓存成功,写数据库失败。一次Cache miss cache中无数据,db中是旧数据
这个问题实质上是和分布式数据一致性是一样的,数据库和缓存和看做分布式数据库或分布式缓存,都是存储数据的