缓存穿透、击穿和雪崩

缓存穿透

缓存穿透的概念很简单,用户想要查询一个数据,发现redis内存数据库没有,也就是缓存没有命中,于是向持久层数据库查询。发现也没有,于是本次查询失败。当用户很多的时候,缓存都没有命中(秒杀),于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力,这时候就相当于出现了缓存穿透。 比如用一个不存在的用户id获取用户信息,不论缓存还是数据库都没有,若黑客利用此漏洞进行攻击可能压垮数据库。

解决方案

1.布隆过滤器:布隆过滤器是一种数据结构,对所有可能查询的参数以hash形式存储,在控制层先进行校验。不符合则丢弃,从而避免了对底层存储系统的查询压力。

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

  • 如果空值能够被缓存起来,则缓存需要更多的空间存储更多的键,因为这当中可能会有很多的空值的键;
  • 可能会使缓存层和存储层产生业务的不一致问题。

缓存击穿

这里需要注意和缓存击穿的区别缓存击穿,是指针对某一个key非常热点,大并发集中对这一个点进行访问,当这个key在失效的瞬间,持续的大并发就击穿缓存,直接请求数据库,就像在一个屏障上凿开了一个洞。当某个key在过期的瞬间,有大量的请求并发访问,这类数据一般是热点数据,由于缓存过期,会同时访问数据库来查询最新数据,并且回写缓存,会导使数据库瞬间压力过大。

解决方案

1.设置热点数据永不过期:从缓存层面来看,没有设置过期时间,所以不会出现热点 key 过期后产生的问题;

2.加互斥锁:使用分布式锁,保证对于每个key同时只有一个线程去查询后端服务,其他线程没有获得分布式锁的权限,因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁,因此对分布式锁的考验很大。

缓存雪崩

**缓存雪崩,是指在某一个时间段,缓存集中过期失效(多个Key),Redis 宕机!**产生雪崩的原因之一,比如在写本文的时候,马上就要到双十二零点,很快就会迎来一波抢购,这波商品时间比较集中的放入了缓存,假设缓存一个小时。那么到了凌晨一点钟的时候,这批商品的缓存就都过期了。而对这批商品的访问查询,都落到了数据库上,对于数据库而言,就会产生周期性的压力波峰。于是所有的请求都会达到存储层,存储层的调用量会暴增,造成存储层也会挂掉的情况。

解决方案

1.Redis高可用:多增设几台redis,一台挂掉之后其他的还可以继续工作,其实是搭建的集群;

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

3.数据预热:是在正式部署之前,我先把可能的数据先预先访问一遍,这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key,设置不同的过期时间,让缓存失效的时间点尽量均匀。

### 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、付费专栏及课程。

余额充值