缓存穿透、缓存雪崩、缓存击穿

 

目录

缓存穿透

发生场景

解决方案

缓存雪崩

发生场景

解决方案

缓存击穿

解决方案

---

缓存穿透

 

 

缓存穿透（cache penetration）是用户访问的数据既不在缓存当中，也不在数据库中。出于容错的考虑，如果从底层数据库查询不到数据，则不写入缓存。这就导致每次请求都会到底层数据库进行查询，缓存也失去了意义。当高并发或有人利用不存在的Key频繁攻击时，数据库的压力骤增，甚至崩溃，这就是缓存穿透问题。

发生场景

1、原来数据是存在的，但由于某些原因（误删除、主动清理等）在缓存和数据库层面被删除了，但前端或前置的应用程序依旧保有这些数据

2、恶意攻击行为，利用不存在的Key或者恶意尝试导致产生大量不存在的业务数据请求

解决方案

• 缓存空值（null）或默认值

分析业务请求，如果是正常业务请求时发生缓存穿透现象，可针对相应的业务数据，在数据库查询不存在时，将其缓存为空值（null）或默认值。需要注意的是，针对空值的缓存失效时间不宜过长，一般设置为5分钟之内。当数据库被写入或更新该key的新数据时，缓存必须同时被刷新，避免数据不一致。

优点：实现简单，维护方便

缺点：额外的内存消耗，因为缓存了一些瞎编的id对应的空对象，但是可以通过给对象设置TTL解决，但是会造成短期的数据不一致

• 添加业务逻辑校验

检查请求参数是否合理、是否包含非法值、是否恶意请求等，提前有效阻断非法请求

• 使用布隆过滤器

在写入数据时，使用布隆过滤器进行标记（相当于设置白名单），业务请求发现缓存中无对应数据时，可先通过查询布隆过滤器判断数据是否在白名单内，如果不在白名单内，则直接返回空或失败

优点：内存占用少

缺点：实现复杂，存在误判

• 定制黑名单

当发生异常情况时，实时监控访问的对象和数据，分析用户行为，针对故意请求、爬虫或攻击者，进行特定用户的限制
可以考虑使用bitmaps类型定义

缓存雪崩

 

在使用缓存时，通常会对缓存设置过期时间，一方面目的是保持缓存与数据库数据的一致性，另一方面是减少冷缓存占用过多的内存空间
但当缓存中大量热点缓存采用了相同的实效时间，就会导致缓存在某一个时刻同时实效，请求全部转发到数据库，从而导致数据库压力骤增，甚至宕机。从而形成一系列的连锁反应，造成系统崩溃等情况，这就是缓存雪崩（Cache Avalanche）

发生场景

• 大量热点key同时过期
• 缓存服务故障

解决方案

• key的过期时间后面加上一个随机数（比如随机1-5分钟），让key均匀的失效
• 用队列或者锁的方式，保证缓存单线程写，但这种方案可能会影响并发量
• 热点数据可以考虑不失效，后台异步更新缓存，适用于不严格要求缓存一致性的场景
• 双key策略，主key设置过期时间，备key不设置过期时间，当主key失效时，直接返回备key值
• 构建缓存高可用集群（针对缓存服务故障情况）
• 当缓存雪崩发生时，服务熔断、限流、降级等措施保障

缓存击穿

缓存雪崩是指只大量热点key同时失效的情况，如果是单个热点key，在不停的扛着大并发，在这个key失效的瞬间，持续的大并发请求就会击破缓存，直接请求到数据库，好像蛮力击穿一样。这种情况就是缓存击穿（Cache Breakdown）。

解决方案

• 使用互斥锁（Mutex Key），只让一个线程构建缓存，其他线程等待构建缓存执行完毕，重新从缓存中获取数据。单机通过synchronized或lock来处理，分布式环境采用分布式锁。
• 热点数据不设置过期时间，后台异步更新缓存，适用于不严格要求缓存一致性的场景。
• ”提前“使用互斥锁（Mutex Key）：在value内部设置一个比缓存（Redis）过期时间短的过期时间标识，当异步线程发现该值快过期时，马上延长内置的这个时间，并重新从数据库加载数据，设置到缓存中去
• 二级缓存:对于热点数据进行二级缓存，并对于不同级别的缓存设定不同的失效时间