解决redis缓存击穿一次实践案例分析(redis缓存击穿案例)
解决Redis缓存击穿:一次实践案例分析
缓存击穿是经常会出现的一种缓存问题,它指的是在高并发的情况下,当查询的key不存在于缓存中且持久层也不存在对应的数据时,大量请求直接打到数据库上,导致数据库压力剧增,造成系统负载量瞬间增加,甚至可能导致系统宕机。本文将结合一次实践案例,分析如何解决Redis缓存击穿。
1. 缓存击穿案例
在我们的项目中主要存在两个高并发的场景,商品详情页和抢购活动页面。在这两个场景中,我们都采用了Redis作为缓存工具,当进行查询数据的时候,先从Redis缓存中查询,如果不存在则从数据库中查询,并将查询到的数据放入Redis缓存中。但是在一个繁忙的夜晚,发现系统的响应时间变得异常缓慢,甚至有的请求直接超时了。在进行线上调查后,我们发现了大量的缓存读取Miss的情况,即大量查询的key在Redis中不存在,Redis缓存被请求数量压垮,直接穿透下去打在了数据库上。
2. 常规解决方案
一般情况下,我们解决缓存击穿问题的方案如下:
2.1. 加锁
在缓存被Miss的时候,通过分布式锁来锁住当前的 key,然后让只能让一个线程去查询DB并写入缓存。这样其他的线程在查询缓存时,发现该 key 已被锁住,则等待该线程写入Redis之后再从缓存中获取数据即可。这种方式能够有效解决缓存击穿问题,但是在高并发场景下,会导致线程阻塞,可能会引起其他线程的超时。
2.2. 空值标识
当查询数据库结果为空时,我们可以将空结果也写入缓存中,但需要给空结果添加一个过期时间,防止脏数据继续滞留在缓存中。不过这种方式并不能完全解决缓存击穿问题,因为在cache和DB同时过期的情况下,还是会出现缓存穿透问题。
2.3. 数据预加载
预先将热点数据加载至缓存,然后通过一定的策略进行缓存更新,这样能够有效避免缓存失效带来的穿透问题。但需要注意的是,预加载的数据量不能太大,否则会导致Redis短时间内压力过大,影响其他服务的正常使用。
3. 实践案例
针对上述常规解决方案的缺陷,我们结合具体场景,提出了一种比较高效的解决方案。具体做法如下:
3.1. 在查询redis缓存数据时,先查询缓存中是否存在该数据,如果不存在,则将对应的缓存 key 加锁,防止其他线程穿透下去查询数据库。采用如下Lua脚本:
-- Redis查询脚本,先查询缓存数据,如果不存在则加锁查询DB
-- key:缓存Key-- db_function:查询数据库的函数名
-- value:缓存过期时间local res = redis.call('get', KEYS[1])
if(res == false or res == ngx.null) then res = redis.call('set', KEYS[1], KEYS[2], 'NX', 'EX', KEYS[3])
if(res == false or res == ngx.null) then -- 已经有其他线程获取锁并从DB写入的数据,继续从cache中查询
return nil else
-- 获取锁成功,从DB中查询数据 local resp = _G[KEYS[4]]()
if(resp == false or resp == ngx.null) then redis.call('set', KEYS[1], 'NULL', 'EX', KEYS[3])
return nil else
-- 写入缓存 redis.call('set', KEYS[1], resp, 'EX', KEYS[3])
return resp end
endelse
return resend
3.2. 在查询数据库时,加入短暂的等待,让另一个线程在写入cache之后,当前线程再从cache中查询数据即可。
// 简化后的查询数据库部分代码
Object data = null;try {
data = cache.get(key); if (data == null) {
// 设置短暂等待时间,让其他线程更多的机会去缓存中查询 Thread.sleep(50L);
// 再次查询缓存 data = cache.get(key);
if (data == null) { data = queryFromDB(key);
cache.set(key, data, expireTime); }
}} catch (Exception e) {
logger.error("Get data from redis error: ", e);}
4. 总结
缓存击穿是Redis中经常出现的缓存问题,针对不同的场景,我们可采取不同的解决方案。本文主要针对高并发场景下,结合实践案例提供了一种比较高效的解决方案,以供读者参考。值得注意的是,在解决缓存问题的过程中,我们要注意balabala……(这里可以添加其他笔者认为需要注意的点)