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

一般中小型传统软件企业,很难碰到这个问题。如果有大并发的项目,流量有几百万左右。这两个问题一定要深刻考虑。

# 缓存雪崩

缓存雪崩, 即缓存同一时间大面积的失效,这个时候又来了一波请求,结果请求都打到数据库上,从而导致数据库连接异常。

# 缓存雪崩解决方案

  • 平时开发: 随机失效时间;给缓存的失效时间,加上一个随机值,避免集体失效
  • redis的运维:
    • 发生雪崩事前:redis 高可用,主从+哨兵,redis cluster,避免全盘崩溃。
    • 发生雪崩事中:本地ehcache缓存 + hystrix 限流&降级,避免 MySQL 被打死。
    • 发生雪崩事后:redis持久化(RDB+AOF),一旦重启,自动从磁盘上加载数据,快速恢复缓存数据。

# 缓存穿透

缓存穿透,即黑客故意去请求缓存中不存在的数据,导致所有的请求都怼到数据库上,从而数据库连接异常。

低频的缓存穿透是 正常的,高频的缓存穿透才会影响数据库

# 缓存穿透解决方案

  1. 同样的请求ID的情况;
    • 分布式锁,使用互斥锁更新,保证同一个进程中针对同一个数据不会并发请求到 DB,减小 DB 压力。
    • 把查询到的结果(正常查询结果、NULL值等)写入到缓存中,可以过滤掉同样的请求
  2. 每次都是 不同的ID(最常见的攻击场景);
    • 利用布隆过滤器迅速判断请求所携带的 Key 是否合法有效,如果不合法,则直接返回;

# 缓存击穿

缓存击穿,就是某个热点数据失效时,大量针对这个数据的请求会穿透到数据源。

# 缓存击穿解决方案

  • 分布式锁,当热点数据失效的时候,去查询数据库时加上分布式锁