Redis缓存穿透击穿雪崩解决方法

缓存穿透、击穿和雪崩是Redis常见问题，解决方法各有不同。1. 缓存穿透是指查询不存在的数据，解决方案包括布隆过滤器拦截无效请求和缓存空值；2. 缓存击穿是热点Key失效导致并发冲击数据库，应对方法有永不过期机制、互斥锁和逻辑过期时间；3. 缓存雪崩是大量Key同时失效，解决办法包括设置随机过期时间、分级缓存策略和限流降级；4. 数据一致性问题常用做法为先更新数据库再删除缓存、延迟双删和消息队列异步更新，系统通常追求最终一致性。

缓存穿透、击穿和雪崩是Redis使用过程中常见的三大问题，它们都会导致大量请求直接打到数据库，造成性能压力甚至系统崩溃。要解决这些问题，需要根据具体场景采取不同的策略。

什么是缓存穿透？怎么防？

缓存穿透是指查询一个既不在缓存也不在数据库中的数据，比如恶意攻击者故意查询不存在的ID。由于缓存中没有这个Key，每次请求都会落到数据库上，如果并发很高，数据库就可能扛不住。

解决方案主要有两个：

• 布隆过滤器（Bloom Filter）：这是一个空间效率很高的数据结构，可以用来判断一个Key是否存在。虽然有一定的误判率，但能有效拦截大部分无效请求。
• 缓存空值（Null Caching）：即使数据库查不到结果，也把空值缓存起来，并设置一个较短的过期时间，比如5分钟。这样后续相同的无效请求就不会再访问数据库了。

需要注意的是，如果业务中确实存在大量合法的“空”结果，这种方式会占用更多缓存空间，所以得权衡好利弊。

缓存击穿如何处理？热点Key失效引发的问题

缓存击穿指的是某个非常热门的Key突然失效，大量并发请求直接冲击数据库。这种情况通常发生在热点数据过期的瞬间，比如商品秒杀信息、热搜内容等。

常见应对方法有：

• 永不过期机制：可以在业务层或者Redis中通过逻辑控制，让热点Key不会真正过期，而是后台异步更新。
• 互斥锁（Mutex Lock）：当缓存失效时，只允许一个线程去加载数据，其他线程等待结果返回后再从缓存读取。
• 逻辑过期时间：将过期时间存储在Value中，而不是依赖Redis本身的TTL机制。这样即使Key没过期，也能判断是否需要后台刷新。

举个例子，比如你缓存了一个爆款商品的信息，这时候可以用互斥锁来控制只有一次数据库查询，其余请求都走缓存，避免数据库被打爆。

缓存雪崩怎么破？大量Key同时失效的灾难

缓存雪崩是指大量Key在同一时间点失效，导致所有请求都转向数据库，极有可能压垮数据库服务。这种情况在系统高峰期尤其危险。

解决办法主要包括：

• 设置随机过期时间：在原有TTL基础上加一个随机值，比如1~300秒，让Key的过期时间分散开来。
• 分级缓存策略：使用本地缓存 + Redis缓存组合，部分请求可以直接从本地获取，减轻Redis的压力。
• 限流降级：在入口层做限流，比如用Nginx或Sentinel，防止突发流量对数据库造成冲击。

比如你在写入缓存的时候，给每个Key加上类似expire_time = base_time + random(0, 300)这样的策略，就能有效避免集中过期。

数据一致性怎么做？缓存和数据库同步问题

除了上述三种问题，还有一个常见痛点就是缓存与数据库的一致性问题。比如数据更新后，缓存没及时更新，就会导致用户读到旧数据。

常用做法包括：

• 先更新数据库，再删除缓存：这是最常见的方式，适用于大多数场景。
• 延迟双删：为了防止在并发情况下缓存未被正确删除，可以在第一次删除后等待一小段时间，再次删除缓存。
• 消息队列异步更新：适合高并发场景，通过MQ解耦数据更新流程，保证最终一致性。

当然，强一致性很难做到，一般系统都是追求最终一致性，只要在可接受的时间范围内保持一致即可。

总的来说，这三个问题是Redis使用中比较典型的风险点，解决思路各有侧重，但在实际项目中往往需要结合使用多种手段来保障系统的稳定性和可用性。基本上就这些，不复杂但容易忽略细节。