Redis缓存穿透和缓存雪崩以及解决方案

本文探讨了Redis缓存穿透和缓存雪崩的问题,分析了布隆过滤器、缓存空对象、高可用性、限流降级、数据预热及分布式锁等解决方案,以确保系统的稳定性和高效性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Redis缓存穿透和缓存雪崩以及解决方案

Redis缓存穿透和缓存雪崩以及解决方案缓存穿透解决方案布隆过滤缓存空对象比较缓存雪崩解决方案保证缓存层服务高可用性依赖隔离组件为后端限流并降级数据预热缓存并发分布式锁

缓存穿透

缓存穿透是指查询一个一定不存在的数据,由于缓存不命中,接着查询数据库也无法查询出结果,因此也不会写入到缓存中,这将会导致每个查询都会去请求数据库,造成缓存穿透;

解决方案

布隆过滤

对所有可能查询的参数以hash形式存储,在控制层先进行校验,不符合则丢弃,从而避免了对底层存储系统的查询压力;

 

缓存空对象

当存储层不命中后,即使返回的空对象也将其缓存起来,同时会设置一个过期时间,之后再访问这个数据将会从缓存中获取,保护了后端数据源;

但是这种方法会存在两个问题:

  1. 如果空值能够被缓存起来,这就意味着缓存需要更多的空间存储更多的键,因为这当中可能会有很多的空值的键;

  2. 即使对空值设置了过期时间,还是会存在缓存层和存储层的数据会有一段时间窗口的不一致,这对于需要保持一致性的业务会有影响。

比较

缓存雪崩

缓存雪崩是指,由于缓存层承载着大量请求,有效的保护了存储层,但是如果缓存层由于某些原因整体不能提供服务,于是所有的请求都会达到存储层,存储层的调用量会暴增,造成存储层也会挂掉的情况。

 

解决方案

保证缓存层服务高可用性

即使个别节点、个别机器、甚至是机房宕掉,依然可以提供服务,比如 Redis Sentinel 和 Redis Cluster 都实现了高可用。

依赖隔离组件为后端限流并降级

在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存,其他线程等待。

数据预热

可以通过缓存reload机制,预先去更新缓存,再即将发生大并发访问前手动触发加载缓存不同的key,设置不同的过期时间,让缓存失效的时间点尽量均匀。

 

缓存并发

缓存并发是指,高并发场景下同时大量查询过期的key值、最后查询数据库将缓存结果回写到缓存、造成数据库压力过大

 

分布式锁

在缓存更新或者过期的情况下,先获取锁,在进行更新或者从数据库中获取数据后,再释放锁,需要一定的时间等待,就可以从缓存中继续获取数据。

转载于:https://www.cnblogs.com/junjun511/p/10679641.html

### Redis缓存穿透、击穿雪崩及其解决方案 #### 缓存穿透 (Cache Penetration) 当查询的数据在数据库中不存在,每次请求都会穿透数据库层,造成大量无意义的查询压力。这种情况不仅浪费资源,还可能被恶意利用进行攻击。 为了防止这种现象的发生,可以采取如下措施: - **布隆过滤器**:使用布隆过滤器来判断数据是否存在,如果布隆过滤器返回false,则可以直接断定该键一定不存在于缓存数据库之中[^1]。 - **空对象缓存**:对于确实不存在的数据项,在缓存中存储一个特殊的标记(如`null`),并设置较短的有效期。这样下次再遇到相同的查询时就可以直接命中缓存而无需访问数据库。 ```python import redis r = redis.Redis() def get_data_with_null_object(key): data = r.get(key) if not data: # 假设db_get是从数据库获取数据的方法 db_result = db_get(key) if not db_result: r.setex(key, 60, "NULL") # 设置过期时间为60秒 return db_result elif data.decode('utf-8') == 'NULL': return None else: return data ``` #### 缓存击穿 (Cache Breakdown) 某个热点key突然失效,此时大量的并发请求会瞬间打到数据库上,给数据库带来巨大压力。为了避免这一情况发生,可采用以下方法: - **加锁机制**:通过分布式锁控制同一时间只有一个线程能够更新缓存中的特定条目;其他线程则等待直到新的值已经被加载回缓存为止。 - **设置随机有效期**:为热Key设定带有轻微波动范围的时间戳作为其TTL(Time To Live),从而减少因多个实例同时到期而导致的大规模刷新操作的可能性。 ```python from threading import Lock lock_dict = {} def set_value_with_lock(redis_client, key, value, ttl=None): lock_key = f'lock:{key}' with Lock() as lock: acquired = False try: while True: if not redis_client.exists(lock_key): acquired = bool(redis_client.setnx(lock_key, 1)) if acquired: break time.sleep(0.1) # 尝试获得锁 redis_client.set(key, value, ex=ttl or random.randint(90, 120)) # TTL带有一些随机性 finally: if acquired: redis_client.delete(lock_key) def get_or_set_cache(redis_client, key, fetch_func, ttl=None): result = redis_client.get(key) if result is None: set_value_with_lock(redis_client, key, fetch_func(), ttl) result = redis_client.get(key) return result ``` #### 缓存雪崩 (Cache Avalanche) 由于某些原因导致大量缓存在几乎相同时间内集体失效,进而引发对后端服务的巨大冲击。针对此问题有几种常见处理方式: - **分片策略**:将不同类型的业务逻辑按照一定的规则分配至不同的Redis节点保存,即使部分机器出现问题也不会影响整个系统的正常运作。 - **限流降级**:引入熔断器模式,在极端情况下自动拒绝超出服务能力之外的新请求,保护核心功能不受损害。 ```python class RateLimiter(object): def __init__(self, rate_limit_per_minute): self.rate_limit_per_minute = rate_limit_per_minute self.requests_in_last_min = [] def allow_request(self): current_time = int(time.time()) one_minute_ago = current_time - 60 filtered_requests = list(filter(lambda t: t >= one_minute_ago, self.requests_in_last_min)) if len(filtered_requests) < self.rate_limit_per_minute: self.requests_in_last_min.append(current_time) return True else: return False rate_limiter = RateLimiter(rate_limit_per_minute=100) if rate_limiter.allow_request(): process_user_request() else: respond_with_error("Too many requests.") ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值